Bug#983088: unblock: nitrokey-app/1.4.2-1

[Jan Luca Naumann]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: patryk@cisek.email

Please unblock package nitrokey-app

[ Reason ]
nitrokey-app has been removed out of testing since the dependency
libnitrokey had a RC bug which was fixed but migrated near the deadline.
I rebuilt the app to ensure compability with the new lib version but the
reupload to avoid bugs caused that I missed the deadline for bullseye.

nitrokey-app has been for a long time in testing/unstable and there was
no bug I know of that are a reason not to include it in bullseye. I hope
that it is possible to allow the migration of the package.

[ Impact ]
nitrokey-app is a package to allow the usage of Nitrokeys which are
open-hardware and open-source crypto usb gadgets. The cooperation
between the developer team and me as maintainer was always nice and
helpful so it would be a shame if the package could not be included in
bullseye so Debian users can easily use it.

[ Risks ]
The program is justed a helper tool for specific users. Up to my
knowledge it has no implications for other users. The tools normaly is
executed with user rights, access to priviliged tasks is done by udev.

unblock nitrokey-app/1.4.2-1

Bug#982554: dpkg: dpkg-deb fails to extract package contents on FAT32 devices

[Jan Luca Naumann]

To add some data for your information:

# dpkg -D100 --install
/var/cache/apt/archives/linux-image-5.10.0-3-amd64_5.10.13-1_amd64.deb
(Reading database ... 370596 files and directories currently installed.)
Preparing to unpack .../linux-image-5.10.0-3-amd64_5.10.13-1_amd64.deb ...
Unpacking linux-image-5.10.0-3-amd64 (5.10.13-1) over (5.10.12-1) ...
D000100: setupvnamevbs main='/.' tmp='/..dpkg-tmp' new='/..dpkg-new'
D000100: tarobject already exists
D000100: tarobject directory exists
D000100: setupvnamevbs main='/boot' tmp='/boot.dpkg-tmp'
new='/boot.dpkg-new'
D000100: tarobject already exists
D000100: tarobject directory exists
D000100: setupvnamevbs main='/boot/System.map-5.10.0-3-amd64'
tmp='/boot/System.map-5.10.0-3-amd64.dpkg-tmp'
new='/boot/System.map-5.10.0-3-amd64.dpkg-new'
D000100: tarobject already exists
D000100: tarobject file open size=83
D000100: tarobject file hash=e0a6c09212a19ed48183a052eab847e7
D000100: tarobject nondirectory, 'link' backup
dpkg: error processing archive
/var/cache/apt/archives/linux-image-5.10.0-3-amd64_5.10.13-1_amd64.deb
(--install):
 unable to make backup link of './boot/System.map-5.10.0-3-amd64' before
installing new version: Operation not permitted
D000100: setupvnamevbs main='/boot/System.map-5.10.0-3-amd64'
tmp='/boot/System.map-5.10.0-3-amd64.dpkg-tmp'
new='/boot/System.map-5.10.0-3-amd64.dpkg-new'
D000100: cu_installnew not restoring
D000100: secure_remove '/boot/System.map-5.10.0-3-amd64.dpkg-new' unlink OK
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/linux-image-5.10.0-3-amd64_5.10.13-1_amd64.deb


# ln System.map-5.10.0-3-amd64 System.map-5.10.0-3-amd64.bak
ln: failed to create hard link 'System.map-5.10.0-3-amd64.bak' =>
'System.map-5.10.0-3-amd64': Operation not permitted


# mount | grep boot
/dev/sda1 on /boot type vfat
(rw,noatime,nodiratime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)

On Thu, 11 Feb 2021 20:04:39 +0100 Jan Luca Naumann
 wrote:
> Package: dpkg
> Version: 1.20.7.1
> Severity: important
> 
> On EFI computer it is possible to use the ESP partition directly as
> /boot. But dpkg has problems to upgrade packages, e.g. the linux-image
> packages, then since it tries to create hardlinks as backup of existing
> files. This is not supported for FAT32 partitions.
> 
> dpkg should include some check if the target device systems may not
> support hard links so /boot on FAT32 is supported.

Bug#982554: dpkg: dpkg-deb fails to extract package contents on FAT32 devices

[Jan Luca Naumann]

Package: dpkg
Version: 1.20.7.1
Severity: important

On EFI computer it is possible to use the ESP partition directly as
/boot. But dpkg has problems to upgrade packages, e.g. the linux-image
packages, then since it tries to create hardlinks as backup of existing
files. This is not supported for FAT32 partitions.

dpkg should include some check if the target device systems may not
support hard links so /boot on FAT32 is supported.


-- Package-specific info:
System tainted due to merged-usr-via-aliased-dirs.

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

Kernel: Linux 5.10.0-3-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 dpkg depends on:
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-9
ii  liblzma5 5.2.5-1.0
ii  libselinux1  3.1-2+b2
ii  tar  1.32+dfsg-1
ii  zlib1g   1:1.2.11.dfsg-2

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt2.1.20
pn  debsig-verify  

-- no debconf information

Bug#979443: chromium: desktop GUI locks up as Xorg process goes to 100%

[Jan Luca Naumann]

Michel and I just prepared an security update for unstable and
buster-security which changes the default to "desktop". This should be
soon in the archive.

Best,
Jan

Am 11.01.21 um 15:14 schrieb Steve A.:
> After three full days of use, the desktop has not frozen again, and the
> Xorg process has remained below 7% CPU use.  Should I modify the menu to
> include the alternate launch command, or is there a beta version of
> chromium you would like me to try?
> 
> Steve
> 
> 
> Steve A. wrote on 1/8/21 6:32 AM:
>> Thanks, Jan.  I killed chromium, upgraded to 87* again, and
>> re-launched with the recommended command last night.  The user is back
>> on this morning and I'm monitoring from another machine.
>>
>> Steve
>>
>>
>> Jan Luca Naumann wrote on 1/7/21 2:30 AM:
>>> Dear Steve,
>>>
>>> with the upgrade to 87.* we included the ANGLE library which manages the
>>> OpenGL access of chromium. Maybe this is the cause of your problem.
>>>
>>> Could you try to launch "$ chromium --use-gl=desktop"? This should
>>> disable the usage of ANGLE.
>>>
>>> Best,
>>> Jan
>>>



OpenPGP_signature
Description: OpenPGP digital signature

Bug#979135: chromium: GPU hw-accel: ANGLE libs cause a lot of errors and warnings

[Jan Luca Naumann]

The reason I prefer at the moment the way to change the order in the
code is that there it is checked if the desktop implementation is an
allowed choice. I do not know what the behavior would be if this is not
a valid choice for some case but we use the command line flag.

The patch still allows to use "--use-gl=" in
/etc/chromium.d/default-flags if people want to use something else for
their installation.

Best,
Jan

Am 09.01.21 um 08:03 schrieb Sedat Dilek:
> Hi,
> 
> Jan Luca is working on a patch "Use desktop gl implementation as default"...
> 
> What about placing "--use-gl=desktop" in /etc/chromium.d/default-flags
> as an alternative?
> 
> # Default for GPU hardware-acceleration (Debian bug #979135)
> export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --use-gl=desktop"
> 
> Cannot say if this is wanted behaviour - to enable GPU hw-accel by default?
> Looks like a safer methon when GPU hw-accel is wanted.
> 
> In my logs I found references to Skia renderer...
> 
> [ chrome://flags ]
> 
> Skia API for compositing
> If enabled, the display compositor will use Skia as the graphics API
> instead of OpenGL ES. – Mac, Windows, Linux, Android
> Here set to "Default"
> 
> [ chrome://gpu ]
> Graphics Feature Status > Skia Renderer: Enabled
> 
> Cannot judge when not using ANGLE libs if there is a fallback to OpenGL ES.
> Might be OpenGL ES renderer is the better choice?
> 
> I have not looked for the parameters and cannot say I will play with them.
> 
> ( BTW, I played with Vulkan support enabled - slow performance here
> with Intel Sandy Bridge GPU. )
> 
> Regards,
> - Sedat -
> 
> [1] https://salsa.debian.org/janluca-guest/chromium/-/commits/angle_fix
> [2] https://wiki.archlinux.org/index.php/chromium#Force_GPU_acceleration
> [3] https://wiki.archlinux.org/index.php/chromium#Hardware_video_acceleration
> 



OpenPGP_signature
Description: OpenPGP digital signature

Bug#979533: chromium: New 87.0.4280.141 (CVE-2020-15995 CVE-2020-16043 CVE-2021-21106 CVE-2021-21107 CVE-2021-21108 CVE-2021-21109 CVE-2021-21110 CVE-2021-21111 CVE-2021-21112 CVE-2021-21113 CVE-2021-

[Jan Luca Naumann]

Michel is preparing an new version and I update the buster branch as
soon as the unstable version is uploaded.

Best,
Jan

On Thu, 07 Jan 2021 21:01:43 +0100 Salvatore Bonaccorso
 wrote:
> Source: chromium
> Version: 87.0.4280.88-0.4
> Severity: grave
> Tags: security upstream
> Justification: user security hole
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> Control: found -1 87.0.4280.88-0.4~deb10u1
> 
> Hi
> 
> Please see
> https://chromereleases.googleblog.com/2021/01/stable-channel-update-for-desktop.html
> here is a new round of CVE fixes for chromium accordingly.
> 
> CVE-2020-15995 seems a bit unclear, it was previously marked to affect
> only Chrome on Android, but now appears to affect as well us.
> 
> Regards,
> Salvatore
> 
> 



OpenPGP_signature
Description: OpenPGP digital signature

Bug#979443: chromium: desktop GUI locks up as Xorg process goes to 100%

[Jan Luca Naumann]

Dear Steve,

with the upgrade to 87.* we included the ANGLE library which manages the
OpenGL access of chromium. Maybe this is the cause of your problem.

Could you try to launch "$ chromium --use-gl=desktop"? This should
disable the usage of ANGLE.

Best,
Jan

On Wed, 6 Jan 2021 11:00:00 -0800 "Steve A."
 wrote:
> Package: chromium
> Version: 87.0.4280.88-0.4~deb10u1
> Severity: grave
> Tags: a11y
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> Subsequent to an upgrade from 83.0.4103.116-1~deb10u3 to 
> 87.0.4280.88-0.4~deb10u1, the desktop GUI randomly freezes, including 
> the clock.  This occurred three times over the course of two days. 
> Doing a ssh from another machine, and then running top, showed the Xorg 
> process pegged at 100%.  Killing just the chromium process did not 
> resolve the locking problem, and the only way to recover was to kill all 
> processes for the GUI user.  Chromium was rolled back to 
> 83.0.4103.116-1~deb10u3 and there have been no freezes in over two days.
> 
> 
> -- System Information:
> Debian Release: 10.7
>APT prefers stable-updates
>APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.19.0-13-amd64 (SMP w/16 CPU cores)
> Kernel taint flags: TAINT_WARN
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages chromium depends on:
> ii  chromium-common  87.0.4280.88-0.4~deb10u1
> ii  libasound2   1.1.8-1
> ii  libatk-bridge2.0-0   2.30.0-5
> ii  libatk1.0-0  2.30.0-2
> ii  libatspi2.0-02.30.0-7
> ii  libavcodec58 7:4.1.6-1~deb10u1
> ii  libavformat587:4.1.6-1~deb10u1
> ii  libavutil56  7:4.1.6-1~deb10u1
> ii  libc62.28-10
> ii  libcairo21.16.0-4
> ii  libcups2 2.2.10-6+deb10u4
> ii  libdbus-1-3  1.12.20-0+deb10u1
> ii  libdrm2  2.4.97-1
> ii  libevent-2.1-6   2.1.8-stable-4
> ii  libexpat12.2.6-2+deb10u1
> ii  libflac8 1.3.2-3
> ii  libfontconfig1   2.13.1-2
> ii  libfreetype6 2.9.1-3+deb10u2
> ii  libgbm1  18.3.6-2+deb10u1
> ii  libgcc1  1:8.3.0-6
> ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
> ii  libglib2.0-0 2.58.3-2+deb10u2
> ii  libgtk-3-0   3.24.5-1
> ii  libharfbuzz0b2.3.1-1
> ii  libicu63 63.1-6+deb10u1
> ii  libjpeg62-turbo  1:1.5.2-2+deb10u1
> ii  libjsoncpp1  1.7.4-3



OpenPGP_signature
Description: OpenPGP digital signature

Bug#973848: security update of chromium in Debian stable?

[Jan Luca Naumann]

Hey,

I have got a successful buster build half an hour ago :) As soon as [1]
is fixed or at least worked around (so we do not release a version with
a regression), I think we could do the update.

I will contact the security team now to discuss the update.

Best,
Jan

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977870

Am 28.12.20 um 12:37 schrieb Tomas Pospisek:
> Hi Jan Luca,
> 
> are you working on or respectively are you planing to do the stable build?
> 
> (I am not sure if I would be able to get access to a powerful enough
>  machine to do the build and get up to speed within reasonable time on how
>  to build chromium and on how to do it efficiently so that I do not have
>  to wait 24 hours for the build to proceed and fail again before I
>  apply the next fix...?)
> 
> Greetings!
> *t



OpenPGP_signature
Description: OpenPGP digital signature

Bug#973848: security update of chromium in Debian stable?

[Jan Luca Naumann]

Hey,

parallel to Michel's very nice work to get chromium into unstable
(thanks to him!), I tried to build the current version in a buster
chroot. At the moment I struggle that there seems a difference how
SFINAE[1] in a special case [2] is handled different between buster's
and unstable's clang version. Since I had not so much time I have not
found a fix to work around this.

If people are more experienced with C++ templates than me, I would be
happy to share the problem and the build log ;)

Best,
Jan

[1] https://en.wikipedia.org/wiki/Substitution_failure_is_not_an_error

[2]

In file included from
../../third_party/blink/common/privacy_budget/identifiability_metric_builder.cc:5:
In file included from
../../third_party/blink/public/common/privacy_budget/identifiability_metric_builder.h:9:
In file included from
/usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/vector:60:
In file included from
/usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/stl_algobase.h:64:
In file included from
/usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/stl_pair.h:59:
In file included from
/usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/move.h:55:
/usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/type_traits:2046:15:
error: only enumeration types
have underlying types
  typedef __underlying_type(_Tp) type;
  ^
../../third_party/blink/public/common/privacy_budget/identifiable_token.h:121:40:
note: in instantiation of template
 class 'std::underlying_type >' requested here
typename U = typename std::underlying_type::type,

Am 23.12.20 um 12:13 schrieb Tomas Pospisek:
> Hi all,
> 
> now that sid has seen an update of Chromium to v87 (hooray and thanks
> everybody!) does anybody know it there's activity or plans towards
> updating chromium in Debian stable?
> 
> Chromium from sid is not installable in Debian stable due to
> 
>     Depends: libc6 (>= 2.29)
> 
> whereas stable has 2.28.
> 
> I'm not sure what the correct procedure would be to kickstart the Debian
> stable update?
> 
> *t



OpenPGP_signature
Description: OpenPGP digital signature

Bug#973848: chromium: Unsupported version, many security bugs unfixed

[Jan Luca Naumann]

Hey,

I have uploaded my stuff to
https://salsa.debian.org/janluca-guest/chromium

We can meet in IRC or Matrix. I am janluca on irc.oftc.net.

Best,
Jan

On Mon, 14 Dec 2020 13:59:53 +0100 Michel Le Bihan 
wrote:
> Hello,
> 
> My work is in this repo:
> https://salsa.debian.org/mimi8/chromium/-/tree/master
> 
> I'm updating the commit every time I make a change. Making a new commit
> for each file doesn't really make sense, since those are separate files
> anyway.
> 
> 
> There is another repo from another person that also started work:
> https://github.com/berkley4/ungoogled-chromium-debian/commits/87.0.4280.88
> 
> And another one somebody told me about yesterday:
> https://www.zap.org.au/git-browser/debian-packages/pkg-chromium-browser.git/
> 
> Could you please commit your work to a fork of the Chromium repo on
> Salsa so we can compare patches?
> 
> Also, maybe we could meet on IRC/XMPP/Matrix or somewhere?
> 
> Michel Le Bihan
> 

Bug#973848: chromium: Unsupported version, many security bugs unfixed

[Jan Luca Naumann]

Hallo everybody,

I have done some of the work as well since I have not seen your message
about your efforts. I have uploaded a working build for unstable to
mentors including updated version of the patches:

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

This version is using the vendor-shipped version of libvpx which should
be changed but maybe we can put together the work done so far in a Git
repo and fixes the remaining stuff?

Best,
Jan

On Sun, 13 Dec 2020 14:45:01 -0800 David Worsham  wrote:
>  Hi there,
> 
> Thank you for all of the great work on this so far!
> 
> I'm interested in helping with this effort, and very familiar with C++ code
> and processes in Google code (though not specifically Chromium).  I have
> gotten the 83/84 versions in unstable/experimental building locally in a
> container as a sanity check.  I also have a fork on salsa to work from
> now:  https://salsa.debian.org/arbreng/chromium
> 
> However, I am very new to Debian packaging and so not sure what the "ideal"
> workspace setup and workflow is for this kind of work.  I just kinda made
> things up as I went along yesterday.  If one of ya'll could walk me through
> it that would be greatly appreciated - I only know what I learned from
> the debian Wiki.  I know how to build and hack on Chromium itself -- it's
> just the packaging bits that are still a bit mystifying to me.
> 
> Thanks again for all the effort!

Bug#946231: Versions, Upstream version versus Debian version

[Jan Luca Naumann]

Dear all,

since one concern pronounced in this bug report was that there is no
automatic migration. Therefore, I developed a helper script to convert
most kinds of pkla files to the JS-based format (see attachment). I
created a merge request in the upstream repo as well if they want to
include the converter as well [1].

Maybe it is now possible to upgrade polkit to a newer version including
the new-style rules?

Best,
Jan

[1] https://gitlab.freedesktop.org/polkit/polkit/-/merge_requests/66

On Fri, 6 Dec 2019 00:25:41 + Simon McVittie  wrote:
> On Thu, 05 Dec 2019 at 23:07:00 +0100, Geert Stappers wrote:
> > Upstream is at version 0.116 ( 
> > https://gitlab.freedesktop.org/polkit/polkit/-/tags )
> > Debian version is 0.105-something ( 
> > https://salsa.debian.org/utopia-team/polkit/blob/master/debian/changelog )
> > 
> > Debian changelog talks about changes from upstream version 0.114 and 0.116.
> 
> The latest upstream version is available in experimental.
> 
> The version in unstable is exactly what its version number indicates:
> a very old upstream version, with the majority of the upstream changes
> from later versions backported into it via debian/patches.
> 
> The reason for this is that upstream version
> 0.106 removed the "localauthority" backend (which
> configures polkit via .ini-style files like for example
> /var/lib/polkit-1/localauthority/10-vendor.d/org.freedesktop.Flatpak.pkla,
> which can be overridden by sysadmin configuration in
> /etc/polkit-1/localauthority or /var/lib/polkit-1/localauthority)
> and replaced it with a new JavaScript-based backend (which
> configures polkit via short JavaScript fragments like for example
> /usr/share/polkit-1/rules.d/org.freedesktop.Flatpak.rules, which can be
> overridden by sysadmin configuration in /etc/polkit-1/rules.d).
> 
> The migration path between the two is not obvious, and some of the Debian
> maintainers of polkit are strongly opposed to it being configured with
> JavaScript files, so at the moment we are stuck with polkit 0.105.
> 
> One day, I want to stop patching changes from 0.11x into 0.105,
> and instead start patching the "localauthority" backend into 0.11x,
> so that we can stick to the upstream version in all respects except
> for the configuration backend. However, all the maintainers of polkit
> (both in Debian and upstream) mostly work on other things, so it's rare
> that someone has enough uninterrupted time to do something like that.
> 
> There has been some upstream unhappiness with the current configuration
> arrangements, mostly because the mozjs library that is used for the
> JavaScript interpreter does not have a stable API; so it is possible that
> a newer upstream version will either change the configuration language
> (again), or change the JavaScript implementation to something more friendly
> (most likely a smaller interpreter like duktape).
> 
> smcv
> 
> 
#!/usr/bin/env python3

from __future__ import annotations

import argparse
import configparser
from dataclasses import dataclass
import enum
import sys
import traceback
from textwrap import dedent, indent
from typing import Dict, List, Optional, Union, cast


def ensure_indent(text: str, numspaces: int = 4) -> str:
return indent(dedent(text), " " * numspaces)


class PolkitConfConverterException(Exception):
def __init__(self, msg: str):
super().__init__()
self.msg = msg


class PolkitIdType(enum.Enum):
USER = enum.auto()
GROUP = enum.auto()
NETGROUP = enum.auto()

@classmethod
def parse_identity_type(cls, input: str) -> PolkitIdType:
result_map = {
"unix-user": cls.USER,
"unix-group": cls.GROUP,
"unix-netgroup": cls.NETGROUP,
}

try:
return result_map[input]
except KeyError as e:
raise PolkitConfConverterException("Unknown polkit identity type") from e


class PolkitResult(enum.Enum):
YES = enum.auto()
NO = enum.auto()
AUTH_SELF = enum.auto()
AUTH_SELF_KEEP = enum.auto()
AUTH_ADMIN = enum.auto()
AUTH_ADMIN_KEEP = enum.auto()

@classmethod
def parse_polkit_result(
cls, polkit_result: Optional[str]
) -> Optional[PolkitResult]:
if polkit_result is None:
return None

result_map = {
"yes": cls.YES,
"no": cls.NO,
"auth_self": cls.AUTH_SELF,
"auth_self_keep": cls.AUTH_SELF_KEEP,
"auth_admin": cls.AUTH_ADMIN,
"auth_admin_keep": cls.AUTH_ADMIN_KEEP,
}

try:
return result_map[polkit_result]
except KeyError as e:
raise PolkitConfConverterException("Unknown polkit result value") from e

@classmethod
def polkit_result_str(cls, element: PolkitResult) -> Optional[str]:
result_map = {
cls.YES: "polkit.Result.YES",
cls.NO: "polkit.Result.NO",
cls.AUTH_SELF: "polkit.Result.AUTH_SELF",
 

Bug#966922: libnitrokey: FTBFS: dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below

[Jan Luca Naumann]

Hey Scott,

since nitrokey-app has been kickout of testing today, I want to ask
about the update? Do you need some help I could offer?

Best,
Jan

Am 21.08.20 um 00:01 schrieb Scott Kitterman:
> I will take care of it.  The removal isn't scheduled for almost a month, so 
> there is plenty of time.
> 
> Scott K
> 
> On Thursday, August 20, 2020 12:28:17 PM EDT Jan Luca Naumann wrote:
>> Hey Scott,
>>
>> could you update the package? Since this is marked as RC bug,
>> libnitrokey and all depending packages are kicked out of testing.
>>
>> Best,
>> Jan
>>
>> On Mon, 03 Aug 2020 13:54:57 + Scott Kitterman
>>
>>  wrote:
>>> This is probably a result of a new GCC version.  C++ symbols can be
>>> painful to manage.  This will be trivial to update the next time I update
>>> the package.
>>>
>>> Scott K
>>>
>>> On August 3, 2020 9:15:16 AM UTC, Szczepan Zalega | Nitrokey 
>  wrote:
>>>> On 8/3/20 10:41 AM, Lucas Nussbaum wrote:
>>>>> (optional=templinst|arch=!amd64 !arm64 !x32)
>>>>> (optional=templinst)
>>>>
>>>> Hi!
>>>>
>>>> As far as I see the problem comes from the listing format difference,
>>>> not the actual symbol change.
>>>>
>>>> E.g.:
>>>> ```
>>>> - (optional=templinst|arch=!amd64 !arm64
>>>> !x32)_ZN8nitrokey5proto17ResponseDissectorILNS0_9CommandIDE65ERKNS0_14Dev
>>>> iceResponseILS2_65ENS0_12EmptyPayload24status_translate_commandB5cxx1
>>>> 1Ei@Base 3.5
>>>> +
>>>> (optional=templinst)_ZN8nitrokey5proto17ResponseDissectorILNS0_9CommandID
>>>> E65ERKNS0_14DeviceResponseILS2_65ENS0_12EmptyPayload24status_translat
>>>> e_commandB5cxx11Ei@Base 3.5
>>>> ```
> 

Bug#970088: systemd: Add trigger to update systemd-boot installation

[Jan Luca Naumann]

Package: systemd
Version: 246.4-1
Severity: wishlist

Dear maintainers,

it would be very nice if it would be possible to add a trigger to the postinst
of the systemd package which runs "bootctl update" if systemd-boot is installed
on the machine. Could you add this feature?

Thank you and best regards,
Jan

-- Package-specific info:

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'buildd-unstable'), (500, 
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.8.0-1-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.53-8
ii  libapparmor1 2.13.4-3
ii  libaudit11:2.8.5-3+b1
ii  libblkid12.36-3
ii  libc62.31-3
ii  libcap2  1:2.43-1
ii  libcrypt11:4.4.17-1
ii  libcryptsetup12  2:2.3.4-1
ii  libgcrypt20  1.8.6-2
ii  libgnutls30  3.6.15-1
ii  libgpg-error01.38-2
ii  libidn2-02.3.0-1
ii  libip4tc21.8.5-3
ii  libkmod2 27+20200310-2
ii  liblz4-1 1.9.2-2
ii  liblzma5 5.2.4-1+b1
ii  libmount12.36-3
ii  libpam0g 1.3.1-5
ii  libpcre2-8-0 10.34-7
ii  libseccomp2  2.4.3-1+b1
ii  libselinux1  3.1-2
ii  libsystemd0  246.4-1
ii  libzstd1 1.4.5+dfsg-4
ii  mount2.36-3
ii  systemd-timesyncd [time-daemon]  246.4-1
ii  util-linux   2.36-3

Versions of packages systemd recommends:
ii  dbus  1.12.20-1

Versions of packages systemd suggests:
ii  policykit-10.105-29
ii  systemd-container  246.4-1

Versions of packages systemd is related to:
ii  dracut   050+65-1
pn  initramfs-tools  
ii  libnss-systemd   246.4-1
ii  libpam-systemd   246.4-1
ii  udev 246.4-1

-- no debconf information

Bug#966922: libnitrokey: FTBFS: dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below

[Jan Luca Naumann]

Hey Scott,

could you update the package? Since this is marked as RC bug,
libnitrokey and all depending packages are kicked out of testing.

Best,
Jan

On Mon, 03 Aug 2020 13:54:57 + Scott Kitterman
 wrote:
> This is probably a result of a new GCC version.  C++ symbols can be painful 
> to manage.  This will be trivial to update the next time I update the package.
> 
> Scott K
> 
> On August 3, 2020 9:15:16 AM UTC, Szczepan Zalega | Nitrokey 
>  wrote:
> >On 8/3/20 10:41 AM, Lucas Nussbaum wrote:
> >> (optional=templinst|arch=!amd64 !arm64 !x32)
> >> (optional=templinst)
> >
> >Hi!
> >
> >As far as I see the problem comes from the listing format difference,
> >not the actual symbol change.
> >
> >E.g.:
> >```
> >- (optional=templinst|arch=!amd64 !arm64
> >!x32)_ZN8nitrokey5proto17ResponseDissectorILNS0_9CommandIDE65ERKNS0_14DeviceResponseILS2_65ENS0_12EmptyPayload24status_translate_commandB5cxx11Ei@Base
> >3.5
> >+
> >(optional=templinst)_ZN8nitrokey5proto17ResponseDissectorILNS0_9CommandIDE65ERKNS0_14DeviceResponseILS2_65ENS0_12EmptyPayload24status_translate_commandB5cxx11Ei@Base
> >3.5
> >```
> 
> 



signature.asc
Description: OpenPGP digital signature

Bug#948087: future of aufs in Debian.

[Jan Luca Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear all,

I have create a RFH since I have currently no time due to personal issue
s:

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

I hope somebody can help with the maintaining.

Best,
Jan

Am 26.05.20 um 16:33 schrieb Jan Luca Naumann:
> Dear Peter,
>
> I am in general still active but due to private stuff I was quite
> bad maintaining aufs the last months, I am really sorry. I will try
> to take a look into the package at the weekend. Additionally, I
> will create a RFH bug, maybe somebody wants to help me so there is
> no single point of failure in the future.
>
> Best, Jan
>
> On 26.05.20 15:18, peter green wrote:
>> The aufs package last saw a maintainer upload in September 2019
>> and was last-updated (by a NMU) in October 2019. It has had
>> broken build-dependencies in testing for half a year now (since
>> Linux 5.3.9-3 migrated to testing in November 2019).
>>
>> According to dak rm the aufs source-package has two
>> reverse-dependencies, aufs-tools and fsprotect neither of which
>> has any reverse-dependencies.
>>
>> Adrian filed a rc bug in November 2019 which received no
>> maintainer response, however the package was not autoremoved from
>> testing due to aufs and aufs-tools being considered a "key
>> packages" due to high popcon. This popcon actually seems to be
>> growing in both absolute and percentage terms. I presume the high
>> popcon is due to some deriviative (hence debian-derivatives and
>> debian-live in cc) using aufs in their live image builds (as far
>> as I can tell debian's own live images seem to use overlayfs
>> instead nowadays).
>>
>> aufs does seem to still be maintained upstream with upstream
>> claiming support for Linux 5.6.
>>
>> According to contributors.debian.net Jan Luca Naumann (the aufs
>> maintainer) was last active in September 2019. Jan: are you
>> still around? and if so do you still intend to maintain the aufs
>> package? if not is someone else going to step up to the plate? or
>> should these packages be removed from testing?
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEwNbeTg2NJIWRcwSlfhHX8Rn5cbsFAl7t5xkACgkQfhHX8Rn5
cbtQIRAAoOQXpteSVFE/ssF81zS80AqOTSTCjLzh76oXc7/az6eHUZpdVrNkPqd/
Cbz+iZiO2NDdpfw0APPA3bKoC9s9R+J9EpOxx7zS5eb87R7xJDAvTk5oskHl8lYH
V2oXcZvai8Rzf+l+sLKG2k3c4WRuoli/QxLZP8TnE0ySVqmtYOZCUUSeCRYwjLed
qAT6vW/5mgCaIIynZMXwYNW5889h8AVIt+n9WOHYCYEtltRTDkJU+n6ZpNx2VhbE
HdDS98T/RWhwNq2oZEIkQlfZfYp7yNP0MtThvCnPRML1dSZwuMTLd4/nrNaL3ITK
MBjt0/IZ6wlp1E18kePfpaHFLX7ekqhBqTr5PmCiQzyPorcgCaEq6rTkwfReuLWR
g58wQmx/8GkrYh4HcCziETSoODGscicskBkzipk6yT9lA9JDROFMqnu8mudUc5B5
/VocELuPiQaEql4h1G/tkoZ/KSkZterDFZ72ssYoYzLgJQxLLY1wSlVKovtKaMcX
5kJ3dzHjmjEO1IRfpbPyFJ5HaFlfTHAbkXx3Ll5saz08KiX+isHr6JGU+ZEt4O3R
P4+rc8Z+gjTURY/2xHo8XRvehEyuoRYfHDaXOmR3a7pazt6e4TZ0bR1uyOsbJWhy
StTmrl72U6dTEXk20IhJdMlG1pp7I0aMfoW85nl182TJwnhxFWc=
=W+Dn
-END PGP SIGNATURE-

Bug#948087: Please report state

[Jan Luca Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I have create a RFH since I have no time due to personal issues:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963191

I hope somebody can help with the maintaining.

Jan

On Mon, 1 Jun 2020 16:25:28 +0200 Eduard Bloch  wrote:
> Hello,
>
> I was notified by a prominent user who is seriouly worried about
> the state of this package.
>
> Please let us know whether it will be in releasable shape in the
> next weeks, or whether you need any support or a sponsored upload.
> Thank you.
>
> And in case that you no longer wish to maintain it, plesae follow
> the regular procedures (see policy) of orphaning, or at least
> consider raising a Request-For-Help, if appropriate.
>
> Best regards, Eduard.
>
> --  man  the AMD64 camp is not helped by the list of
> people supporting it  when nerode is on your side, you know
> you're doing something wrong
>
>
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEwNbeTg2NJIWRcwSlfhHX8Rn5cbsFAl7t5QEACgkQfhHX8Rn5
cbsScxAAj9M3uKxiINX7DqhUlFeWUtIg5lvSQplt0SyNVMfpaAU77Ea5WN2qUktz
TkQ8sdOc+0NRrcG+YxGxf/kd+TEtnov/KMXoZFOnq30LUaC1ph02maEZyM56RhNL
+CfmTrRVlWnIxjnrZaJCIzoIKaysWt9+UpGpHhWlfEOR9S9plogLdfOfhxpNraQ0
3n7xCUWU60+6DhKl4Lg7iGf3mVgyEndWZXBM9OArwDuQ4ieZ8jI4tBpi88eEsGlD
QZf3CQ3COtwYXLb2TIbN6yvfZZnA+Vax5uCnTE4Xj3wtxtoy13rjh50kjnuKUjrS
5DcZVlMF2KEKaHjeE1EPws2eomVgEcL7GxT/qXr2CK81DMkYtqD5HPQ0w8Zy6fK+
usi1MU1WU3trV6/edlYe+ZmX5XPuMatDQUAXzZEwKNN9NNfUOsgZQlUlb86Ms0e4
al0aysOrN6OwOgxOo8ep/YCBFHwTVLfELeBI5n6afdSW3qoga6DVMo1IvDjCIRv8
6vDw57eNMCY+0i1Ve/SW+sWpAHTQBsGTFNNO8CX3R1RGr+WTWw1srt5/j6ITopgE
bWRMh4u4SsJeKvW/BiEXr8oS4naZhxlGVoZTIgPJQMiMC8FqReamMuxFHz1eSTHZ
PJ90666yZ9ybt3aFfkrbHjQ/4PpuIa8hgori5u3z0YYrOFLIRcc=
=d9yC
-END PGP SIGNATURE-

Bug#963191: RFH: aufs

[Jan Luca Naumann]

Package: wnpp
Severity: normal

At the moment aufs is nearly unmaintained since I do not have time due to 
personal issues. Therefore, I would be happy if there is somebody to 
co-maintain the package.

Open issues are:

- Update to current version
- Add a version in backports
- Support multiple kernel versions at the same time

I try to take a look at this problems in the near future but I would be happy 
about help.

Bug#948087: future of aufs in Debian.

[Jan Luca Naumann]

Dear Peter,

I am in general still active but due to private stuff I was quite bad
maintaining aufs the last months, I am really sorry. I will try to take
a look into the package at the weekend. Additionally, I will create a
RFH bug, maybe somebody wants to help me so there is no single point of
failure in the future.

Best,
Jan

On 26.05.20 15:18, peter green wrote:
> The aufs package last saw a maintainer upload in September 2019 and was
> last-updated (by a NMU) in October 2019. It has had broken
> build-dependencies in testing for half a year now (since Linux 5.3.9-3
> migrated to testing in November 2019).
> 
> According to dak rm the aufs source-package has two
> reverse-dependencies, aufs-tools and fsprotect neither of which has any
> reverse-dependencies.
> 
> Adrian filed a rc bug in November 2019 which received no maintainer
> response, however the package was not autoremoved from testing due to
> aufs and aufs-tools being considered a "key packages" due to high
> popcon. This popcon actually seems to be growing in both absolute and
> percentage terms. I presume the high popcon is due to some deriviative
> (hence debian-derivatives and debian-live in cc) using aufs in their
> live image builds (as far as I can tell debian's own live images seem to
> use overlayfs instead nowadays).
> 
> aufs does seem to still be maintained upstream with upstream claiming
> support for Linux 5.6.
> 
> According to contributors.debian.net Jan Luca Naumann (the aufs
> maintainer) was last active in September 2019. Jan: are you still
> around? and if so do you still intend to maintain the aufs package? if
> not is someone else going to step up to the plate? or should these
> packages be removed from testing?

Bug#938961: aufs: needs update for new linux

[Jan Luca Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I will take care of the update next week. This week I'm on holidays
without a real computer.

Sorry for the delay and best
Jan

Am 30.08.19 um 17:26 schrieb Ivo De Decker:
> package: aufs severity: serious tags: bullseye sid
> 
> Hi,
> 
> The version of aufs in testing and unstable build-depends on 
> linux-kbuild-4.19, which is no longer availabe in testing.
> 
> Thanks,
> 
> Ivo
> 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEwNbeTg2NJIWRcwSlfhHX8Rn5cbsFAl1pZfgACgkQfhHX8Rn5
cbvOpw//WnObpPyNiJXd9UmIoC6eLI8MNDc/tGrwhWOyssR05sEOM56o4JkyaohF
tIkjHYHhypsCxkLtoETkfJjjhpxTxQVHs2NiDjGmo/S4zEwk/OTKZMOp8wyWNRhP
j8PvhcBz4jplGwF3RSsIt4wqXdygIgjG7mogzXtsbg+T6WOzQE583xZ3syUs/dbH
jJ4Jo2/BuZKO54tEd8WvDHDsL9v0fZlhv6wATCe9buMAlmSPtAaYp986nDLsvZIr
Gc7TXf02+CVqZ4GsuUNBIIHLuvP6zf6mryIIk5UsyCfQNRAZca4qH/UR1+bd5ZI3
NRJmYuUqtODwW6oh3p3ckoZ2ZY7gdljmAAiciWPxtkXpJAootlS39TmCePbK08CG
FecA2nSO8AxIAP5cm79lXkiUA7MRlwAvWmDfUcpxvjWosynsERy0Jp1b5zDv/yRY
bo4wnHopQHOcPwMsUdIoGWMjjRO6pp53I/nZM5TjHpnLFNoW8KJKd8udfbQCSvXx
m2dpbCX/QFFd7vQNeaXWM5YsiUvc6EHyFPCOaucxvu/W5IALL6mAqSGbnrtBvYKq
tn4bbyuOkLfvi/5aesEPpClWGUL+W9u6seStYqjOiuvFa7yG2LUBiV3iyJa+7zlL
Mo2JS8lpibru7Ue0VcgEIUpdzQTRfjfWFqtvDKqoEzt7AD+J2Ts=
=hISk
-END PGP SIGNATURE-

Bug#923882: [Pkg-sssd-devel] Bug#923882: sssd-tools: sssctl list-domains is broken

[Jan Luca Naumann]

Another way could be to check in the postinst files if there is already
an existing sssd.conf file and, if yes, do not enable the systemd units.

This should prevent breaking existing installations but would allow to
use the services after adjusting sssd.conf and new users would use the
sockets directly. Admins of existing installations could be informed
about this change via the NEWS file.

Would that be a useful solution?

Jan

Am 21.03.19 um 14:56 schrieb Timo Aaltonen:
> On 6.3.2019 19.22, Jan Luca Naumann wrote:
>> Package: sssd-tools
>> Version: 1.16.3-3
>> Severity: normal
>>
>> Since Debian deactivates the installation of the sssd-ifp.service (c.f. 
>> changelog for
>> Debian release 1.16.0-4) the subcommands using infopipe (e.g. list-domain 
>> and domain-status)
>> of the tool sssctl are broken:
>>
>> $ sssctl domain-list
>> Unable to get domains list [3]: Communication error
>> org.freedesktop.systemd1.NoSuchUnit: Unit sssd-ifp.service not found.
>>
>> Anyway, it would be nice if the responder service/socket can be installed
>> and a different solution is applied to avoid the problem of old configs,
>> e.g. do not enable the sockets at installation time.
> 
> I can push a package to experimental which re-enables socket activation,
> but I don't have a way to test if pam auth is still broken if the config
> has duplicate entries on the 'services=' line..
> 
> One option would be to enable just some of them, like ifp.
> 

Bug#923882: sssd-tools: sssctl list-domains is broken

[Jan Luca Naumann]

Package: sssd-tools
Version: 1.16.3-3
Severity: normal

Since Debian deactivates the installation of the sssd-ifp.service (c.f. 
changelog for
Debian release 1.16.0-4) the subcommands using infopipe (e.g. list-domain and 
domain-status)
of the tool sssctl are broken:

$ sssctl domain-list
Unable to get domains list [3]: Communication error
org.freedesktop.systemd1.NoSuchUnit: Unit sssd-ifp.service not found.

Anyway, it would be nice if the responder service/socket can be installed
and a different solution is applied to avoid the problem of old configs,
e.g. do not enable the sockets at installation time.

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

Kernel: Linux 4.19.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages sssd-tools depends on:
ii  libbasicobjects0   0.6.1-2
ii  libc6  2.28-7
ii  libcollection4 0.6.1-2
ii  libdbus-1-31.12.12-1
ii  libdhash1  0.6.1-2
ii  libini-config5 0.6.1-2
ii  libldb12:1.5.1+really1.4.3-1
ii  libpam0g   1.3.1-5
ii  libpopt0   1.16-12
ii  libref-array1  0.6.1-2
ii  libselinux12.8-1+b1
ii  libsss-simpleifp0  1.16.3-3
ii  libtalloc2 2.1.14-2
ii  libtdb11.3.16-2+b1
ii  libtevent0 0.9.37-1
ii  python 2.7.15-4
ii  python-sss 1.16.3-3
ii  sssd-common1.16.3-3

sssd-tools recommends no packages.

sssd-tools suggests no packages.

-- no debconf information

Bug#920025: python3-lib389: Missing dependency on libnss3-tools

[Jan Luca Naumann]

Package: python3-lib389
Version: 1.4.0.20-3
Severity: normal

The package python3-lib389 is missing a dependency on the package
libnss3-tools which provides the tool certutil. Without this package
the instance creation via dscreate is broken if using self-signed
certificate.

Bug#913820: [Pkg-freeipa-devel] Bug#913820: cockpit-389-ds: Debian-packaged JS libs not sufficient to run cockpit-plugin

[Jan Luca Naumann]

Hey,

the fix of this bug is not complete, the installation of the JS-stuff is
still excluded in debian/rules. Could you please take another look into
the bug?

Best regards,
Jan

On Fri, 16 Nov 2018 11:20:44 +0200 Timo Aaltonen 
wrote:
> On 15.11.2018 18.22, Jan Luca Naumann wrote:
> > Package: cockpit-389-ds
> > Version: 1.4.0.18-1
> > Severity: grave
> > Justification: renders package unusable
> > 
> > At the momenent the package cockpit-389-ds applies a patch to use the Debian
> > packaged JS libraries. In contrast to the vendored libraries the Debian 
> > versions
> > do not work with the current version of the cockpit-389-plugin, c.f. the
> > backtrace attached. Removing the Debian-specific patch and installing the
> > vendored JS libs resolves the issue.
> 
> yeah, and all the minified stuff is already in debian/missing-sources,
> so it should be fine to just drop the patch.. Thanks for the bug!
> 
> 
> -- 
> t
> 
> 

Bug#917857: NMU diff for aufs 4.19+20181217-0.1

[Jan Luca Naumann]

Hey,

thank you for the upload and your work. I am sorry that I did not manage
to upload the new version due to too much other workload.

I have seen that your delete the dependency on linux-kbuild. I have
added it to avoid transition of the aufs-packages to testing before the
linux package is available in the requested version. One time there was
the problem that the aufs-package already migrated but the linux package
had some RC-bug.

Jan

Am 07.01.19 um 20:08 schrieb Ben Hutchings:
> I made an NMU to fix this bug (and related ones).  I also fixed some
> more minor issues with the packaging that I noticed.
> 
> The attached debdiff is restricted to the debian/ directory.  I created
> the new orig tarball from upstream git commit
> dc68432bc8fed5faf20f2a0889739a13110abdc1.
> 
> Ben.
> 

Bug#916911: nitrokey-app: Please announce supported hardware via appstream

[Jan Luca Naumann]

Dear Szczepan,
Dear Jan,

in the Debian bug tracker there is a request to include the supported
hardware via appstream. Below the initial message is included the
complete conversation can be found here:

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

This feature should be added upstream so could you please take look
into it?

Best regards,
Jan

Am 20.12.18 um 13:02 schrieb Petter Reinholdtsen:
> 
> Package: nitrokey-app Version: 1.3.1-1 Tags: patch
> 
> It would be nice if the package provided information about what
> hardware it support to appstream, to allow the isenkram tool and
> other users of appstream data to propose the package when the
> appropriate USB dongle is inserted into a machine.
> 
> Here is a proposed patch to do so, based on the udev file included
> in libnitrokey:
> 
> --- data/com.nitrokey.nitrokey-app.appdata.xml.~1~  2018-05-13
> 08:58:17.0 + +++
> data/com.nitrokey.nitrokey-app.appdata.xml  2018-12-20
> 11:57:44.572350004 + @@ -21,6 +21,11 @@   
> nitrokey-app +
> usb:v20A0p4107d* +
> usb:v20A0p4108d* +
> usb:v20A0p4109d* +
> usb:v20A0p4211d* +
> usb:v20A0p4230d*   type="desktop-id">nitrokey-app.desktop  type="homepage">https://www.nitrokey.com/
> 

Bug#913821: python3-lib389: dscreate searches files in hard-coded paths

[Jan Luca Naumann]

Package: python3-lib389
Version: 1.4.0.18-1
Severity: important
Tags: upstream patch

As described in the upstream bug [1] dscreate searches files in hard-coded paths
and tries to use /etc/sysconfig instead of /etc/default.

A patch to fix this behaviour is attached.

[1] https://pagure.io/389-ds-base/issue/49974
--- a/src/lib389/lib389/instance/setup.py
+++ b/src/lib389/lib389/instance/setup.py
@@ -593,10 +593,10 @@
 for line in template_init.readlines():
 initconfig += line.replace('{{', '{', 1).replace('}}', '}', 
1).replace('-', '_')
 try:
-os.makedirs("%s/sysconfig" % slapd['sysconf_dir'], mode=0o775)
+os.makedirs("%s" % slapd['initconfig_dir'], mode=0o775)
 except FileExistsError:
 pass
-with open("%s/sysconfig/dirsrv-%s" % (slapd['sysconf_dir'], 
slapd['instance_name']), 'w') as f:
+with open("%s/dirsrv-%s" % (slapd['initconfig_dir'], 
slapd['instance_name']), 'w') as f:
 f.write(initconfig.format(
 SERVER_DIR=slapd['lib_dir'],
 SERVERBIN_DIR=slapd['sbin_dir'],

Bug#913820: cockpit-389-ds: Debian-packaged JS libs not sufficient to run cockpit-plugin

[Jan Luca Naumann]

Package: cockpit-389-ds
Version: 1.4.0.18-1
Severity: grave
Justification: renders package unusable

At the momenent the package cockpit-389-ds applies a patch to use the Debian
packaged JS libraries. In contrast to the vendored libraries the Debian versions
do not work with the current version of the cockpit-389-plugin, c.f. the
backtrace attached. Removing the Debian-specific patch and installing the
vendored JS libs resolves the issue.

Uncaught SyntaxError: Unexpected token <
dataTables.select.min.js:1 Uncaught SyntaxError: Unexpected token <
moment.min.js:1 Uncaught SyntaxError: Unexpected token <
dataTables.datetime-moment.js:27 Uncaught ReferenceError: moment is not defined
at dataTables.datetime-moment.js:27
at dataTables.datetime-moment.js:29
jstree.min.js:1 Uncaught SyntaxError: Unexpected token <
bootstrap.min.js:1 Uncaught SyntaxError: Unexpected token <
c3.min.js:1 Uncaught SyntaxError: Unexpected token <
d3.min.js:1 Uncaught SyntaxError: Unexpected token <
plugins.js:3 Uncaught TypeError: $(...).DataTable is not a function
at HTMLDivElement. (plugins.js:3)
at HTMLDivElement. (jquery-3.3.1.min.js:2)
at Function.each (jquery-3.3.1.min.js:2)
at w.fn.init.each (jquery-3.3.1.min.js:2)
at Object. (jquery-3.3.1.min.js:2)
at u (jquery-3.3.1.min.js:2)
at Object.fireWith [as resolveWith] (jquery-3.3.1.min.js:2)
at k (jquery-3.3.1.min.js:2)
at XMLHttpRequest. (jquery-3.3.1.min.js:2)
replication.js:244 Uncaught TypeError: $(...).DataTable is not a function
at HTMLDivElement. (replication.js:244)
at HTMLDivElement. (jquery-3.3.1.min.js:2)
at Function.each (jquery-3.3.1.min.js:2)
at w.fn.init.each (jquery-3.3.1.min.js:2)
at Object. (jquery-3.3.1.min.js:2)
at u (jquery-3.3.1.min.js:2)
at Object.fireWith [as resolveWith] (jquery-3.3.1.min.js:2)
at k (jquery-3.3.1.min.js:2)
at XMLHttpRequest. (jquery-3.3.1.min.js:2)
monitor.js:156 Uncaught TypeError: $(...).jstree is not a function
at HTMLDivElement. (monitor.js:156)
at HTMLDivElement. (jquery-3.3.1.min.js:2)
at Function.each (jquery-3.3.1.min.js:2)
at w.fn.init.each (jquery-3.3.1.min.js:2)
at Object. (jquery-3.3.1.min.js:2)
at u (jquery-3.3.1.min.js:2)
at Object.fireWith [as resolveWith] (jquery-3.3.1.min.js:2)
at k (jquery-3.3.1.min.js:2)
at XMLHttpRequest. (jquery-3.3.1.min.js:2)
servers.js:405 Uncaught TypeError: $(...).DataTable is not a function
at HTMLDivElement. (servers.js:405)
at HTMLDivElement. (jquery-3.3.1.min.js:2)
at Function.each (jquery-3.3.1.min.js:2)
at w.fn.init.each (jquery-3.3.1.min.js:2)
at Object. (jquery-3.3.1.min.js:2)
at u (jquery-3.3.1.min.js:2)
at Object.fireWith [as resolveWith] (jquery-3.3.1.min.js:2)
at k (jquery-3.3.1.min.js:2)
at XMLHttpRequest. (jquery-3.3.1.min.js:2)
security.js:60 Uncaught TypeError: $(...).DataTable is not a function
at HTMLDivElement. (security.js:60)
at HTMLDivElement. (jquery-3.3.1.min.js:2)
at Function.each (jquery-3.3.1.min.js:2)
at w.fn.init.each (jquery-3.3.1.min.js:2)
at Object. (jquery-3.3.1.min.js:2)
at u (jquery-3.3.1.min.js:2)
at Object.fireWith [as resolveWith] (jquery-3.3.1.min.js:2)
at k (jquery-3.3.1.min.js:2)
at XMLHttpRequest. (jquery-3.3.1.min.js:2)
backend.js:148 Uncaught TypeError: $(...).jstree is not a function
at load_jstree (backend.js:148)
at HTMLDivElement. (backend.js:210)
at HTMLDivElement. (jquery-3.3.1.min.js:2)
at Function.each (jquery-3.3.1.min.js:2)
at w.fn.init.each (jquery-3.3.1.min.js:2)
at Object. (jquery-3.3.1.min.js:2)
at u (jquery-3.3.1.min.js:2)
at Object.fireWith [as resolveWith] (jquery-3.3.1.min.js:2)
at k (jquery-3.3.1.min.js:2)
at XMLHttpRequest. (jquery-3.3.1.min.js:2)

Bug#910796: python3-lib389: Conflicts and Replaces statements are not compatible with backports

[Jan Luca Naumann]

Package: python3-lib389
Version: 1.4.0.18-1
Severity: normal

The Conflicts and Replaces statements are not compatible with backports of
the version 1.4.0.18-1. The correct statements should be:

Conflicts: python-lib389 (<< 1.3.7.8),
 389-ds-base (<< 1.4.0.18-1~),
Replaces: python-lib389 (<< 1.3.7.8),
 389-ds-base (<< 1.4.0.18-1~),

Bug#909329: libnitrokey: Please backport version 3.3 for Stretch

[Jan Luca Naumann]

Source: libnitrokey
Severity: wishlist

Please backport libnitrokey version 3.3 for Stretch. This allows to backport
nitrokey-app 1.3.1 for Stretch as well.

Thank you in advance

Bug#897210: nitrokey-app: Need to coordinate move of udev rule to libnitrokey

[Jan Luca Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Control: tags 897210 fixed-in-experimental

Dear Scott,

I have uploaded nitrokey-app in the current versiont to experimental
as well to allow testing the changes. I have removed the udev-releated
stuff from the package.

I found a small mistake in the libnitrokey package: The installation
path for udev-rules seems to be /lib/udev/rules.d. I have opened a
merge request on salsa to fix this:

https://salsa.debian.org/kitterman/libnitrokey/merge_requests/1

The other paths I have applied to the rules was just to get rid of
linitan warnings that could not parse the IF/GOTO-statements
correctly. The current version seems to be fixed so this patch is not
necessary anymore.

Best regards,
Jan

Am 30.04.2018 um 07:09 schrieb Scott Kitterman:
> Package: nitrokey-app Version: 1.2-1 Severity: important
> 
> Nitrokey has released libnitrokey 3.3 and nitrokey-app 1.3.  They
> moved the udev rule to the lib.  I have created a package and will
> upload it to experimental.  Unfortunately, it has to go through
> New, so I don't know when it will be there.
> 
> In the meantime, it's in git:
> https://salsa.debian.org/kitterman/libnitrokey
> 
> I would appreciate it if you would review the upstream provided
> udev rule and see what changes you would recommend (since I recall
> you patched the rule in nitrokey-app).
> 
> Also, please take a look and see if nitrokey-app 1.3 works with
> libnitrokey 3.3.  Once I have confirmation, I'll upload to
> unstable.
> 
> Thanks,
> 
> Scott K
> 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEwNbeTg2NJIWRcwSlfhHX8Rn5cbsFAlr4EoUACgkQfhHX8Rn5
cbvi+A//TB4fCXVTFgviS+JX0Yx3aLkwYHTdLECLYdDAIChs/NzhaUI309A4pbgQ
doIKFjLiYP7D8Mpe+HspBov3hCd7Te3NnUkrSzsuCtYoHVvTlOnui/ytAtaMXYXA
FKCoNi/r26PMm/ghKXlun8mIM/d9HKXnHUlS35pqndYKteIQ9vGLPkY6UC5EwAqr
hAYkf2TsqLO4LPQmLJ4tIprLURPaRMaF/WWZhzG8u5T84LgSFSghVDRau7GYl3ep
FcpbxAorIUoRIzE9gaim3KtZq5M1a5yKlkRd5CYXcUTYOj1eYjMc8g50ON+EdZ6Y
F6PT5fQdC6Rk3I2x53fVOI511BRcmXRc3+PmBoyF1mxUgjXEo8SX1BOA9c585daU
DFR2FYIeMhwwOYa1z6vpjJ4Bl39ttq76h7qYRchIfeA7VjRS/39TJcQ72n1H8D53
bkY9InmWX9peXy0cPoG+fb+PMMrPy1ZCxmZlD+ZAqEBIXG8OGF1YLMuKfU76/UEY
uHxN77J4eu46o174WD2OyNRvPEvdZzV4ZHNy7FBjh00EC4pIg6HOWuGQN70aQSPq
hSZ8PosMhtUAuZv5pfsvALcaaXL74SymgvsCe+DLotGrHFSqOG1F0YIoS2u+ZipF
REZwn+jAXhZ5qvKgHwYv5+TdixctEPG5YNZeRz6K1X3DHse77mI=
=aGJn
-END PGP SIGNATURE-

Bug#897210: nitrokey-app: Need to coordinate move of udev rule to libnitrokey

[Jan Luca Naumann]

Hey Scott,

I will try to plan in some time on the weekend for this.

Best regards,
Jan

Am 03.05.2018 um 14:03 schrieb Scott Kitterman:
> Libnitrokey 3.3 has been accepted into experimental.
> 
> Scott K
> 



signature.asc
Description: OpenPGP digital signature

Bug#891022: rustc: Missing Build-Dep on curl and ca-certificates for build profile "pkg.rustc.dlstage0"

[Jan Luca Naumann]

Source: rustc
Version: 1.23.0+dfsg1-1
Severity: normal

For the build-profile "pkg.rustc.dlstage0" there are missing build dependencies 
on
curl and ca-certificates. Without them the download of the upstream rustc for 
the
bootstrap process is failing.

Bug#886329: [Filesystems-devel] Bug#886329: Bug#886329: Bug#886329: aufs-dkms: Cannot use aufs union mount with Linux 4.14.7-1: kernel BUG at /var/lib/dkms/aufs/4.14+20171218/build/fs/aufs/finfo.c:113

[Jan Luca Naumann]

Dear aufs-maintainer,

below a Debian bug reporting a seg fault is attached. A online version
of the bug can be found here:

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

I could reproduce the bug using a 4.15 kernel. Could you please take a
look into this?

Thank you very much and best regards,
Jan

Am 19.02.2018 um 08:49 schrieb intrigeri:
> Hi,
> 
> Jan Luca Naumann:
>> could you please provide the additional information the upstream
>> developer requests for in the README, then I will forward it to upstream:
> 
> Sure!
> 
> To make communication with upstream easier I've retried with Linux
> 4.15.0-1 and manually compiled aufs4.15 20180219 in an up-to-date and
> mostly clean sid VM.
> 
> This bug appeared after upgrading from Linux 4.13 to Linux 4.14.
> 
>> When you have any problems or strange behaviour in aufs, please let me
>> know with:
>> - /proc/mounts (instead of the output of mount(8))
> 
> # cat /proc/mounts 
> sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
> proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
> udev /dev devtmpfs rw,nosuid,relatime,size=1005588k,nr_inodes=251397,mode=755 
> 0 0
> devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 
> 0 0
> tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=204484k,mode=755 0 0
> /dev/mapper/sid--desktop--vg-root / ext4 
> rw,relatime,errors=remount-ro,data=ordered 0 0
> securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
> tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
> tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
> tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0
> cgroup /sys/fs/cgroup/unified cgroup2 
> rw,nosuid,nodev,noexec,relatime,nsdelegate 0 0
> cgroup /sys/fs/cgroup/systemd cgroup 
> rw,nosuid,nodev,noexec,relatime,xattr,name=systemd 0 0
> pstore /sys/fs/pstore pstore rw,nosuid,nodev,noexec,relatime 0 0
> cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0
> cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0
> cgroup /sys/fs/cgroup/net_cls,net_prio cgroup 
> rw,nosuid,nodev,noexec,relatime,net_cls,net_prio 0 0
> cgroup /sys/fs/cgroup/perf_event cgroup 
> rw,nosuid,nodev,noexec,relatime,perf_event 0 0
> cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 
> 0 0
> cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 
> 0 0
> cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0
> cgroup /sys/fs/cgroup/cpu,cpuacct cgroup 
> rw,nosuid,nodev,noexec,relatime,cpu,cpuacct 0 0
> cgroup /sys/fs/cgroup/pids cgroup rw,nosuid,nodev,noexec,relatime,pids 0 0
> systemd-1 /proc/sys/fs/binfmt_misc autofs 
> rw,relatime,fd=27,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=12446
>  0 0
> debugfs /sys/kernel/debug debugfs rw,relatime 0 0
> mqueue /dev/mqueue mqueue rw,relatime 0 0
> hugetlbfs /dev/hugepages hugetlbfs rw,relatime,pagesize=2M 0 0
> /dev/vda1 /boot ext2 rw,relatime,block_validity,barrier,user_xattr,acl 0 0
> tmpfs /run/user/116 tmpfs 
> rw,nosuid,nodev,relatime,size=204480k,mode=700,uid=116,gid=120 0 0
> configfs /sys/kernel/config configfs rw,relatime 0 0
> tmpfs /run/user/0 tmpfs rw,nosuid,nodev,relatime,size=204480k,mode=700 0 0
> aufs /tmp/mount aufs rw,relatime,si=df346fccc2a2e857 0 0
> 
>> - /sys/module/aufs/*
> 
> Not sure what exactly I should extract from this directory so let's
> try that:
> 
> # for param in /sys/module/aufs/parameters/* ; do echo " - $(basename 
> $param): $(cat $param)"; done 
>  - allow_userns: N
>  - brs: 1
>  - debug: 1
> 
> # for f in $(find /sys/module/aufs -maxdepth 1 -type f); do echo " - 
> $(basename $f): $(cat $f)" ; done
>  - version: 4.15-20180219
>  - taint: O
>  - initsize: 0
>  - initstate: live
>  - srcversion: 4AEC6984C511AF142683949
>  - coresize: 376832
>  - refcnt: 2
> cat: /sys/module/aufs/uevent: Permission denied
>  - uevent: 
> 
>> - /sys/fs/aufs/* (if you have them)
> 
> # cat /sys/fs/aufs/config 
> CONFIG_AUFS_FS=m
> CONFIG_AUFS_BRANCH_MAX_127=y
> CONFIG_AUFS_SBILIST=y
> CONFIG_AUFS_DEBUG=y
> 
> # for f in /sys/fs/aufs/*/*; do echo " - $(basename $f): $(cat $f)" ; done
>  - br0: /tmp/rw=rw
>  - br1: /tmp/ro=rr+wh
>  - brid0: 64
>  - brid1: 65
>  - xi_path: /tmp/rw/.aufs.xino
> 
>> - /debug/aufs/* (if you have them)
> 
> I have no /debug.
> 
>> - linux kernel version
>>   if your kernel is not plain, for example modified by distributor,
>>   the url where i can download its source is necessary too.
> 
> Debian sid's linux-image-4.15.0-1-amd64, version 4.15.4-1.

Bug#886329: [Filesystems-devel] Bug#886329: Bug#886329: aufs-dkms: Cannot use aufs union mount with Linux 4.14.7-1: kernel BUG at /var/lib/dkms/aufs/4.14+20171218/build/fs/aufs/finfo.c:113

[Jan Luca Naumann]

Hey,

could you please provide the additional information the upstream
developer requests for in the README, then I will forward it to upstream:

5. Contact

When you have any problems or strange behaviour in aufs, please let me
know with:
- /proc/mounts (instead of the output of mount(8))
- /sys/module/aufs/*
- /sys/fs/aufs/* (if you have them)
- /debug/aufs/* (if you have them)
- linux kernel version
  if your kernel is not plain, for example modified by distributor,
  the url where i can download its source is necessary too.
- aufs version which was printed at loading the module or booting the
  system, instead of the date you downloaded.
- configuration (define/undefine CONFIG_AUFS_xxx)
- kernel configuration or /proc/config.gz (if you have it)
- behaviour which you think to be incorrect
- actual operation, reproducible one is better
- mailto: aufs-users at lists.sourceforge.net

Best regards,
Jan

Am 24.01.2018 um 09:50 schrieb intrigeri:
> Indeed!
> 
> I've just reproduced this in an up-to-date sid VM where /tmp is on
> the ext4 root filesystem. I've purged and reinstalled aufs-dkms to
> make sure I had a fresh copy built with the current compiler etc.
> from sid. I've also tried with AppArmor disabled, same result.
> 
> anonym can reproduce it too, and the bug can be reproduced 
> consistently while booting Tails 3.5 (for testing purposes, one
> can grab the ISO from 
> http://dl.amnesia.boum.org/tails/stable/tails-amd64-3.5/ and boot
> it in a VM).
> 
> Perhaps we should take it upstream and hope the debug trace will
> ring a bell for them?

Bug#886329: [Filesystems-devel] Bug#886329: aufs-dkms: Cannot use aufs union mount with Linux 4.14.7-1: kernel BUG at /var/lib/dkms/aufs/4.14+20171218/build/fs/aufs/finfo.c:113

[Jan Luca Naumann]

Hey,

the underlying filesystem is a tmpfs for me as well:

# uname -a
Linux 4.14.0-3-amd64 #1 SMP Debian 4.14.13-1 (2018-01-14) x86_64

# mount | grep /tmp
none on /tmp type tmpfs (rw,nosuid,nodev,noatime,nodiratime)

# modprobe aufs debug=1 \
  && mkdir /tmp/{ro,rw,mount} \
  && touch /tmp/ro/bla \
  && mount -t aufs -o dirs=/tmp/rw=rw:/tmp/ro=rr+wh aufs /tmp/mount \
  && ls /tmp/mount ; \
 ls /tmp/mount
bla
bla

I get no segfault for the call still so there has to be another reason...

Best regards,
Jan

Am 23.01.2018 um 12:44 schrieb intrigeri:
> anonym:
>> I guess that you, Jan, are *not* mounting a tmpfs on /tmp and I am guessing 
>> that you,
>> intrigeri, *are*. Am I correct? :)
> 
> I am indeed. Jan, can you reproduce if the underlying filesystem is tmpfs?
> 
>> At least for me, the segfault only triggers when the underlying fs
>> is a tmpfs.
> 
> That may be exactly the info Jan needs to forward this upstream.
> 
> Cheers!
> 

Bug#886329: [Filesystems-devel] Bug#886329: aufs-dkms: Cannot use aufs union mount with Linux 4.14.7-1: kernel BUG at /var/lib/dkms/aufs/4.14+20171218/build/fs/aufs/finfo.c:113

[Jan Luca Naumann]

Control: tags -1 unreproducible

Hey,

sorry for the long delay for my answer.

I tested your code sample below and I could not reproduce the bug with a
current 4.14.13 kernel on my system. Could you please test it again?

Best regards,
Jan

Am 04.01.2018 um 15:42 schrieb intrigeri:
> Hi,
> 
> interestingly, only the first access to the aufs mountpoint triggers
> the bug. See the first `ls' failing and the second one working:
> 
>   # modprobe aufs debug=1 \
> && mkdir /tmp/{ro,rw,mount} \
> && touch /tmp/ro/bla \
> && mount -t aufs -o dirs =/tmp/rw=rw:/tmp/ro=rr+wh aufs /tmp/mount \
> && ls /tmp/mount ; \
> ls /tmp/mount
>   Segmentation fault
>   bla
> 
> I've tested replacing that first read access with a write access,
> same result.
> 
> (Off-topic: I'll try to implement a workaround in live-boot.)
> 
> Cheers,
> 

Bug#886329: [Filesystems-devel] Bug#886329: aufs-dkms: Cannot use aufs union mount with Linux 4.14.7-1: kernel BUG at /var/lib/dkms/aufs/4.14+20171218/build/fs/aufs/finfo.c:113

[Jan Luca Naumann]

Hey,

I am not at home for another two days and do not have a proper computer with 
me. I will take a look at the problem on the weekend.

Jan

Am 4. Januar 2018 15:42:56 MEZ schrieb intrigeri :
>Hi,
>
>interestingly, only the first access to the aufs mountpoint triggers
>the bug. See the first `ls' failing and the second one working:
>
>  # modprobe aufs debug=1 \
>&& mkdir /tmp/{ro,rw,mount} \
>&& touch /tmp/ro/bla \
>   && mount -t aufs -o dirs =/tmp/rw=rw:/tmp/ro=rr+wh aufs /tmp/mount \
>&& ls /tmp/mount ; \
>ls /tmp/mount
>  Segmentation fault
>  bla
>
>I've tested replacing that first read access with a write access,
>same result.
>
>(Off-topic: I'll try to implement a workaround in live-boot.)
>
>Cheers,

Bug#884008: [Filesystems-devel] Bug#884008: aufs-dkms: aufs triggers kernel WARN during boot

[Jan Luca Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear aufs-maintainer,

the following Debian bug (see also webpage [1]) seems to be a upstream
problem of the aufs-kernel-module. Could you take a look into it?

Best regards,
Jan

[1] http://bugs.debian.org/884008

Am 10.12.2017 um 13:28 schrieb Ralf Jung:
> Package: aufs-dkms Version: 4.9+20161219-1 Severity: normal
> 
> Dear Maintainer,
> 
> we have aufs installed on our server to be able to run docker. 
> During boot, I see the following arror a couple dozen times:
> 
> S Sun Dec 10 12:10:27 2017 p4 kernel: aufs 
> au_opts_verify:1607:dockerd[1339]: dirperm1 breaks the protection 
> by the permission bits on the lower branch S Sun Dec 10 12:10:27 
> 2017 p4 kernel: [ cut here ] S Sun Dec 10 
> 12:10:27 2017 p4 kernel: WARNING: CPU: 0 PID: 1490 at 
> /var/lib/dkms/aufs/4.9+20161219/build/fs/aufs/cpup.c:423 
> au_cp_regular+0x16c/0x250 [aufs] S Sun Dec 10 12:10:27 2017 p4 
> kernel: .wh..wh.setup_maker_elements-i.ri.0007 Please report this 
> warning to aufs-users ML S Sun Dec 10 12:10:27 2017 p4 kernel: 
> Modules linked in: S Sun Dec 10 12:10:27 2017 p4 kernel:  aufs(O) 
> xenfs xen_privcmd joydev hid_generic usbhid hid ppdev sg pcspkr 
> parport_pc parport serio_raw evdev ip_tables x_tables autofs4 ext4 
> crc16 jbd2 crc32c_generic fscrypto ecb glue_helper lrw gf128mul 
> ablk_helper cryptd aes_x86_64 mbcache sr_mod cdrom ata_generic 
> xen_netfront xen_blkfront crc32c_intel ata_piix psmouse cirrus ttm 
> drm_kms_helper drm i2c_piix4 uhci_hcd ehci_hcd usbcore usb_common 
> libata scsi_mod floppy button S Sun Dec 10 12:10:27 2017 p4
> kernel: CPU: 0 PID: 1490 Comm: auplink Tainted: G   O 
> 4.9.0-4-amd64 #1 Debian 4.9.65-3 S Sun Dec 10 12:10:27 2017 p4 
> kernel: Hardware name: Xen HVM domU, BIOS 4.4.1-xs116341 01/13/2016
> S Sun Dec 10 12:10:27 2017 p4 kernel:   
> a8928e84 bba581ee7a60  S Sun Dec 10 
> 12:10:27 2017 p4 kernel:  a8675efe bba581ee7d58 
> bba581ee7ab8  S Sun Dec 10 12:10:27 2017 p4 
> kernel:  9512c3ab3800 9512c50e2d00 95128a6ec780 
> a8675f7f S Sun Dec 10 12:10:27 2017 p4 kernel: Call Trace:
>  S Sun Dec 10 12:10:27 2017 p4 kernel:  [] ? 
> dump_stack+0x5c/0x78 S Sun Dec 10 12:10:27 2017 p4 kernel: 
> [] ? __warn+0xbe/0xe0 S Sun Dec 10 12:10:27 2017 
> p4 kernel:  [] ? warn_slowpath_fmt+0x5f/0x80 S 
> Sun Dec 10 12:10:27 2017 p4 kernel:  [] ? 
> au_cp_regular+0x16c/0x250 [aufs] S Sun Dec 10 12:10:27 2017 p4 
> kernel:  [] ? au_cp_regular+0x241/0x250 [aufs] S 
> Sun Dec 10 12:10:27 2017 p4 kernel:  [] ? 
> au_cp_regular+0x1b7/0x250 [aufs] S Sun Dec 10 12:10:27 2017 p4 
> kernel:  [] ? cpup_entry+0x73c/0x890 [aufs] S
> Sun Dec 10 12:10:27 2017 p4 kernel:  [] ? 
> vfsub_lookup_one_len+0x44/0xf0 [aufs] S Sun Dec 10 12:10:27 2017
> p4 kernel:  [] ? sprintf+0x56/0x70 S Sun Dec 10 
> 12:10:27 2017 p4 kernel:  [] ? 
> au_cpup_single.constprop.23+0x187/0x760 [aufs] S Sun Dec 10 
> 12:10:27 2017 p4 kernel:  [] ? dput+0x38/0x250 S 
> Sun Dec 10 12:10:27 2017 p4 kernel:  [] ? 
> au_cpup_simple+0x5b/0xa0 [aufs] S Sun Dec 10 12:10:27 2017 p4 
> kernel:  [] ? au_do_sio_cpup_simple+0xcf/0xf0 
> [aufs] S Sun Dec 10 12:10:27 2017 p4 kernel:  [] 
> ? au_pin_and_icpup+0x2a3/0x4e0 [aufs] S Sun Dec 10 12:10:27 2017
> p4 kernel:  [] ? aufs_setattr+0x4e4/0x620 [aufs]
> S Sun Dec 10 12:10:27 2017 p4 kernel:  [] ? 
> xattr_resolve_name+0xa2/0xc0 S Sun Dec 10 12:10:27 2017 p4 kernel: 
> [] ? notify_change+0x2ef/0x460 S Sun Dec 10 
> 12:10:27 2017 p4 kernel:  [] ? 
> chown_common+0x165/0x1c0 S Sun Dec 10 12:10:27 2017 p4 kernel: 
> [] ? strncpy_from_user+0x48/0x160 S Sun Dec 10 
> 12:10:27 2017 p4 kernel:  [] ? 
> SyS_chown+0x94/0xd0 S Sun Dec 10 12:10:27 2017 p4 kernel: 
> [] ? system_call_fast_compare_end+0xc/0x9b S Sun 
> Dec 10 12:10:27 2017 p4 kernel: ---[ end trace fc137d6061ab0b9c 
> ]--- S Sun Dec 10 12:10:27 2017 p4 kernel: [ cut here 
> ] S Sun Dec 10 12:10:27 2017 p4 kernel: WARNING: CPU:
> 0 PID: 1490 at 
> /var/lib/dkms/aufs/4.9+20161219/build/fs/aufs/cpup.c:423 
> au_cp_regular+0x16c/0x250 [aufs] S Sun Dec 10 12:10:27 2017 p4 
> kernel: .wh..wh.resources-i.ri.000b Please report this warning to 
> aufs-users ML S Sun Dec 10 12:10:27 2017 p4 kernel: Modules linked 
> in: S Sun Dec 10 12:10:27 2017 p4 kernel:  aufs(O) xenfs 
> xen_privcmd joydev hid_generic usbhid hid ppdev sg pcspkr 
> parport_pc parport serio_raw evdev ip_tables x_tables autofs4 ext4 
> crc16 jbd2 crc32c_generic fscrypto ecb glue_helper lrw gf128mul 
> ablk_helper cryptd aes_x86_64 mbcache sr_mod cdrom ata_generic 
> xen_netfront xen_blkfront crc32c_intel ata_piix psmouse cirrus ttm 
> drm_kms_helper drm i2c_piix4 uhci_hcd ehci_hcd usbcore usb_common 
> libata scsi_mod floppy button S Sun Dec 10 12:10:27 2017 p4
> kernel: CPU: 0 PID: 1490 Comm: auplink Tainted: GW  O 
> 4.9.0-4-amd64 #1 Debian 4.9.65-3 S Sun Dec 10 12:10:27 2017 

Bug#880387: [Filesystems-devel] Bug#880387: aufs-dkms: the module is not built for Linux 4.14

[Jan Luca Naumann]

Hey,

I have already prepared an upload but there was a seg fault on my test
system I want to investigate before uploading.

Best regards,
Jan

Am 04.12.2017 um 10:44 schrieb intrigeri:
> Control: severity -1 serious
> 
>> Linux 4.14-rc7 was uploaded to experimental; we're getting close to
>> the 4.14 final release and its upload to sid. How about uploading
>> a version of aufs-dkms that's compatible with Linux 4.14 (to sid, or
>> to experimental if that's impractical or not feasible) so that we're
>> ready when 4.14 reaches sid?
> 
> Linux 4.14 is now in sid so I think this makes this bug RC.
> 
> Cheers,
> 

Bug#875620: aufs-dkms: Please enable compilation with kernel 4.13

[Jan Luca Naumann]

I have uploaded the new version, sorry for the delay.

The Git repo is up-to-date as well now, I forgot to push the last changes.

Best regards,
Jan

On Thu, 05 Oct 2017 11:37:02 +0200 intrigeri  wrote:
> Control: severity -1 serious
> 
> Hi,
> 
> > I tried aufs with kernel 4.13-rc7 from experimental and it seems to
> > compile and work well. Please consider enabling this kernel in
> > dkms.conf.
> 
> Too bad this didn't happen before 4.13 reached sid and gets
> depended on by linux-image-amd64 ⇒ bumping severity to RC.
> 
> I wanted to propose a Git branch ready to merge, but the latest tag
> pushed to Vcs-Git is debian/4.11+20170703-1 (and the master branch
> matches), which makes it harder to help than I would like.
> 
> Cheers,
> -- 
> intrigeri
> 
> 

Bug#865614: [Filesystems-devel] Bug#865614: Bug#865614: Bug#865614: aufs-dkms: aufs-dkms does not support Linux 4.11

[Jan Luca Naumann]

Hey,

I have seen that there is the updated kernel today, I will take a look
into aufs later this day.

Best regards,
Jan

Am 14.08.2017 um 14:43 schrieb intrigeri:
> Jan Luca Naumann:
>> I have prepared a version for 4.11 and upload it as soon as I have
>> tested it (at the moment I'm blocked by https://bugs.debian.org/869511 )
> 
> Now 4.12 is in sid and I believe there's no blocker anymore :)
> … assuming there's an updated aufs patchset for 4.12.
> 
> ___
> Filesystems-devel mailing list
> filesystems-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/filesystems-devel
> 

Bug#871935: [Filesystems-devel] Bug#871935: aufs-dkms: wrong symbolic link /usr/share/doc/aufs-dkms/README

[Jan Luca Naumann]

Control: forcemerge 857783 871935

This bug is a duplicate of bug #857783 which is already closed in a
newer version.

Best regards,
Jan

Am 12.08.2017 um 20:16 schrieb marjoram:
> Package: aufs-dkms
> Version: 4.9+20161219-1
> Severity: minor
> 
> Dear Maintainer,
> 
> the symbolic link /usr/share/doc/aufs-dkms/README points at
> Documentation/filesystems/aufs/README, but that file is not part of any Debian
> package. Please either:
> * rename the link to /usr/share/doc/aufs-dkms/README.gz and change its target 
> to
>   filesystems/aufs/README.gz, or
> * delete the symbolic link, or
> * do something else.
> 
> Thanks.
> 
> ___
> Filesystems-devel mailing list
> filesystems-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/filesystems-devel
> 

Bug#863166: [Filesystems-devel] Bug#863166: aufs-dkms: Please enable CONFIG_AUFS_XATTR

[Jan Luca Naumann]

Am 24.07.2017 um 16:43 schrieb Geoffrey Thomas:
> 
> Hi maintainers,
> 
> Now that the freeze is over, can we get this change in buster and
> stretch-backports? Let me know if there's something I can do to help,
> e.g., test packages with this change in.
> 
> Thanks!
> 

Hey Geoffrey,

I will take a look into this some time later this week.

Best regards,
Jan

Bug#865614: [Filesystems-devel] Bug#865614: Bug#865614: aufs-dkms: aufs-dkms does not support Linux 4.11

[Jan Luca Naumann]

Control: tag -1 pending

Hey,

I have prepared a version for 4.11 and upload it as soon as I have
tested it (at the moment I'm blocked by https://bugs.debian.org/869511 )

Best regards,
Jan

Am 18.07.2017 um 18:55 schrieb David R. Hedges:
> Hi!
> 
> Jan Luca Naumann:
>> I will try to package a new version as soon as 4.11.7+ is uploaded.
> 
> I'm sorry to be a bother, but 4.11.11 is in unstable, and 4.12.2 is in the
> NEW queue awaiting FTP master review. Could you please push the new version
> to unstable when you have a chance (and/or NEW, to catch 4.12 when that
> makes its way in)?
> 
> Thanks!
> -David
> 
> ___
> Filesystems-devel mailing list
> filesystems-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/filesystems-devel

Bug#865614: [Filesystems-devel] Bug#865614: Bug#865614: aufs-dkms: aufs-dkms does not support Linux 4.11

[Jan Luca Naumann]

Hey,

there was the problem that the aufs module for 4.11 had some problems.
There is a version for 4.11.7+ now available upstream but in Debian the
current kernel version is 4.11.6. I will try to package a new version as
soon as 4.11.7+ is uploaded.

Jan

Am 05.07.2017 um 08:52 schrieb intrigeri:
> Hi,
> 
> Jan Luca Naumann:
>> thank you for the trigger, it seems that I missed the point where 4.11
>> was uploaded to sid. I will update the aufs package over the weekend.
> 
> Do you have an updated timeline for this?
> 
> Cheers,
> 

Bug#867257: linux: Please update aufs4 patches

[Jan Luca Naumann]

Source: linux
Version: 4.11.6-1
Severity: wishlist

Hey,

I'm preparing at the moment the upload of a new version of the aufs
DKMS package for sid. According to the upstream webpage [1] there was
a problem with the patches up to 4.11.7.

Could you apply the newest patches for 4.11.7+ in course of the upload
of the newest version?

Thank you,
Jan

[1] http://aufs.sourceforge.net/

Bug#865614: [Filesystems-devel] Bug#865614: aufs-dkms: aufs-dkms does not support Linux 4.11

[Jan Luca Naumann]

Hey,

thank you for the trigger, it seems that I missed the point where 4.11
was uploaded to sid. I will update the aufs package over the weekend.

Best regards,
Jan

Am 23.06.2017 um 08:58 schrieb intrig...@debian.org:
> Package: aufs-dkms
> Version: 4.9+20161219-2
> Severity: important
> User: tails-...@boum.org
> Usertags: misc-reported
> 
> Hi,
> 
> Linux 4.11 is now in sid. The aufs-dkms package currently has
> BUILD_EXCLUSIVE_KERNEL="^4.9.*", so:
> 
>   Error!  The dkms.conf for this module includes a BUILD_EXCLUSIVE directive 
> which
>   does not match this kernel/arch.  This indicates that it should not be 
> built.
>   Skipped.
> 
> Can you please update the package so it works on current sid?
> 
> Thanks in advance, and thank you for maintaining aufs in Debian! :)
> 
> (Setting severity > normal as this problem makes the package unusable
> on current sid.)
> 
> Cheers,
> 

Bug#859497: ITP: libqtaccountsservice -- Qt-style API for AccountsService DBus interface

[Jan Luca Naumann]

Package: wnpp
Severity: wishlist
Owner: Jan Luca Naumann <j.naum...@fu-berlin.de>

* Package name: libqtaccountsservice
  Version : 0.7.0
  Upstream Author : Pier Luigi Fiorini <pierluigi.fior...@gmail.com>
* URL : https://github.com/lirios/qtaccountsservice
* License : LGPL
  Programming Lang: C++
  Description : Qt-style API for AccountsService DBus interface

This library provides a Qt-style API to use freedesktop.org's AccountsService
DBus service. For more information see description of AccountsService under
http://www.freedesktop.org/wiki/Software/AccountsService

Bug#856509: unblock: dracut/044+241-2

[Jan Luca Naumann]

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

Please unblock package dracut

The version 044+241-2 contains only the patch to 
fix bug #855370. The bug is about the problem that
the dracut-module "aufs" included in the Debian
package only works if the the aufs is in the module
path of the modules included directly in the kernel.
Since the aufs-module has been removed from the kernel
package and is provided by the DKMS-package "aufs-dkms"
the check() function of the dracut-module have to check
the old path and the installation path of DKMS.

Since the aufs-feature of dracut is very useful for read-only
NFS-roots that are mounted with a tmpfs as aufs-overlay, it
is very desirable to include the patch in stretch. Otherwise
many setups that use this NFS read-only/tmpfs-setup will fail
and this setup are not untypical for FAI or clusters.

unblock dracut/044+241-2
diff -Nru dracut-044+241/debian/90aufs/module-setup.sh 
dracut-044+241/debian/90aufs/module-setup.sh
--- dracut-044+241/debian/90aufs/module-setup.sh2017-01-24 
15:36:24.0 +0100
+++ dracut-044+241/debian/90aufs/module-setup.sh2017-02-28 
11:29:58.0 +0100
@@ -2,7 +2,7 @@
 
 check() {
 # do not add modules if the kernel does not have aufs support
-[ -d /lib/modules/$kernel/kernel/fs/aufs ] || return 1
+[ -d /lib/modules/$kernel/kernel/fs/aufs ] || [ -f 
/lib/modules/$kernel/updates/dkms/aufs.ko ] || return 1
 }
 
 depends() {
diff -Nru dracut-044+241/debian/changelog dracut-044+241/debian/changelog
--- dracut-044+241/debian/changelog 2017-01-24 15:40:24.0 +0100
+++ dracut-044+241/debian/changelog 2017-02-28 11:29:58.0 +0100
@@ -1,3 +1,9 @@
+dracut (044+241-2) unstable; urgency=low
+
+  * add patch for dkms aufs modules, Closes: #855370
+
+ -- Thomas Lange   Tue, 28 Feb 2017 11:29:58 +0100
+
 dracut (044+241-1) unstable; urgency=low
 
   * merge upstream changes

Bug#854880: Fwd: firmware-atheros ships binary ath9k_htc firmwares containing GPL code

[Jan Luca Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Linux-Firmware-Maintainers,

as reported in the Debian bug report #854880[1] (mail attached below),
the firmware files ath9k_htc/htc_7010-1.4.0.fw,
ath9k_htc/htc_9271-1.4.0.fw has been created using GPL components and
thus the source code has to be included.

Can you please take a look on the issue? IMHO it is the best to fix
this directly in the upstream linux-firmware repository.

Thank you,
Jan

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854880

On Sat, 11 Feb 2017 15:09:30 +0100 Julian Andres Klode
 wrote:
> The binary files
> 
> Files: ath9k_htc/htc_7010-1.4.0.fw, ath9k_htc/htc_9271-1.4.0.fw
> 
> were created from files that include GPL components according to 
> the copyright file, specially, the eCos files:
> 
> eCos is free software; you can redistribute it and/or modify it
> under the terms of the GNU General Public License as published by
> the Free Software Foundation; either version 2 or (at your option)
> any later version. . As a special exception, if other files
> instantiate templates or use macros or inline functions from this
> file, or you compile this file and link it with other works to
> produce a work based on this file, this file does not by itself
> cause the resulting work to be covered by the GNU General Public 
> License. However the source code for this file must still be made
> available in accordance with section (3) of the GNU General Public
> License. . This exception does not invalidate any other reasons why
> a work based on this file might be covered by the GNU General
> Public License.
> 
> These need to be either added to the package or the firmware needs 
> to be removed from the archive.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEwNbeTg2NJIWRcwSlfhHX8Rn5cbsFAlixzOsACgkQfhHX8Rn5
cbtJ2RAAlpx4cKAO7Quu4hAy6NrmdbC1l29Yq3f5gYlA+wWZFs0TXOaubYy4E5ay
K9JixISdu3jgnZInlwkyFKAXX7L7jta6DowdoMDOKjcXCN9djy1meWfbVGEmqepe
eBOCyxetKIrnx5Sp2Fp/GNwpdRKX913vusmR1iSsYRss8S3YgJ6oAPYpYyc5SyWj
qA/pExt6f59fi7MfAVxMrJsW6eq0gmZiEIjEGMoQfVDZRAe8fJUo5cQI3hukRWLd
zlmVoMgPfTyfoc1GdDICg8sW39+TjWxoYXLwELZkhfaGPo2OUsTyjQeI4a9aP1Hb
WPONEiBMY2OYBr5w2wvFTDNFY9UPMZ46W3qVCGGuTPy8yV46DyD0rhgq7qP3Z2zj
kKq24ONmfjrdFVzj+h7SQWyQKcSfaB3bIKJfB44fSzNCmw35hAVTF+pwDOOB0+p9
/NkQ7KUfczksatMUg9IWvsuZT/nR2MimwyP+wB0U/sxjnNbVNH3m9KBuACbZ2+4M
bCSze7gVdPPa83T9i/pQH+R/nQoVBeb4TT6IWhQHIYasFV+3at2Rb57SCHKvt8E+
E1LjY4CdhCfnFjK5tGrfCtvHrPYHFooDDcArgMpHTjoGLleT9gMx4hP+oI3NViGK
vNbrwnf0eIOtJcPBLG5zVNV+6otuWbiMTxTADPeegs6SAhJ4lPw=
=KS0/
-END PGP SIGNATURE-

Bug#856148: unblock: ntfs-3g/1:2016.2.22AR.1+dfsg.1-0.1

[Jan Luca Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Sat, 25 Feb 2017 17:35:06 +0100 Jan Luca Naumann
<j.naum...@fu-berlin.de> wrote:
> Package: release.debian.org Severity: normal User: 
> release.debian@packages.debian.org Usertags: unblock
> 
> Please unblock package ntfs-3g
> 
> This version fixes the copyright issue described in bug #808463.
> It copy the fixed file boot.c from upstream version 2016.2.22AR.2 
> which contains copyright information for the file.
> 
> The debdiff between ntfs-3g-2016.2.22AR.1-4 and 
> ntfs-3g-2016.2.22AR.1+dfsg.1-0.1 is attached.
> 
> unblock ntfs-3g/1:2016.2.22AR.1+dfsg.1-0.1

Forgot to mention that the new version can be found here:

https://mentors.debian.net/package/ntfs-3g

Jan
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEwNbeTg2NJIWRcwSlfhHX8Rn5cbsFAlixs6YACgkQfhHX8Rn5
cbv1QQ//dqDjLcrO22/nzqYOaFafncT3F1i2lzgQMW5WU3tRXGxioBgqK4SDNE3e
Wn2c0ihK21x6vMxZvKtouh3VCA0IXy8pUWznPIz+HrkzUIK3Hm5NNKgsjthCnqA4
r59rjef3zvcNkp0lzC+BsHxQieKr+7ez0CH5YEEx+7hLChD/luOGBL0h4jINhFTP
HQAyFGuF4fB2kn54h+ZV+1oT26eReDG8LM3p2f3NgOBwfauisK5OkMyqfVf7JlQa
kI6/hsbIOtTFbi48HMKhIVGMlMICJtDavn19Au9rCVeshth5Dpgyjri6oPtuffUZ
gPw4pS6uLLHp9BZl31ytcuWhl88gt69ppl4hqyCctLKUGogOf+HrhLWeq0SiBy5u
j2xP/ifqtBfHmoi89rfvfiXtp9+tC/PGgXL2S1zIduKI5QyVl/pfvBwQFsrpa+gW
SJ/MqjsRSIcGaPT4u3YEWB2rmG253OTR59IDQ+9IoJydxHj0+hBKp+8vcf0ZlTrx
5QMOcGrrYnK02VfykRwS45GT7cqRnAo/OPTzXFSUpwLd49IOGoizYS9drdSiyldk
LDhKv7wemFH60FJw6N9V0tojVSpyuMgOOs8iwzHv0M4pFrOODbqt1zG76Be7pA7z
hqcgxDyK5xf7cTvTaBIGCQNVGV76x2AOocNq/kAAwhebZzyi8lg=
=NRHR
-END PGP SIGNATURE-

Bug#856148: unblock: ntfs-3g/1:2016.2.22AR.1+dfsg.1-0.1

[Jan Luca Naumann]

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

Please unblock package ntfs-3g

This version fixes the copyright issue described in
bug #808463. It copy the fixed file boot.c from
upstream version 2016.2.22AR.2 which contains copyright
information for the file.

The debdiff between ntfs-3g-2016.2.22AR.1-4 and
ntfs-3g-2016.2.22AR.1+dfsg.1-0.1 is attached.

unblock ntfs-3g/1:2016.2.22AR.1+dfsg.1-0.1
diff -Nru ntfs-3g-2016.2.22AR.1/debian/changelog 
ntfs-3g-2016.2.22AR.1+dfsg.1/debian/changelog
--- ntfs-3g-2016.2.22AR.1/debian/changelog  2017-02-01 07:23:28.0 
+0100
+++ ntfs-3g-2016.2.22AR.1+dfsg.1/debian/changelog   2017-02-25 
16:09:45.0 +0100
@@ -1,3 +1,12 @@
+ntfs-3g (1:2016.2.22AR.1+dfsg.1-0.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Repack of source tar file:
+Backport ntfsprogs/boot.c file from version 2016.2.22AR.2 (Closes: #808463)
+  * Update debian/copyright to match boot.c backported to this version.
+
+ -- Jan Luca Naumann <j.naum...@fu-berlin.de>  Sat, 25 Feb 2017 16:09:45 +0100
+
 ntfs-3g (1:2016.2.22AR.1-4) unstable; urgency=high
 
   * Fix CVE-2017-0358: modprobe influence vulnerability via environment
diff -Nru ntfs-3g-2016.2.22AR.1/debian/copyright 
ntfs-3g-2016.2.22AR.1+dfsg.1/debian/copyright
--- ntfs-3g-2016.2.22AR.1/debian/copyright  2016-04-02 18:18:49.0 
+0200
+++ ntfs-3g-2016.2.22AR.1+dfsg.1/debian/copyright   2017-02-25 
16:09:45.0 +0100
@@ -17,6 +17,16 @@
  2006-2010 Adam Cecile <gand...@le-vert.net>
 License: GPL-2+
 
+Files: ntfsprogs/boot.c
+Copyright: 1991 Linus Torvalds <torva...@klaava.helsinki.fi>
+   1992-1993 Remy Card <c...@masi.ibp.fr>
+   1993-1994 David Hudson <d...@humbug.demon.co.uk>
+   1998 H. Peter Anvin <h...@zytor.com>
+   1998-2005 Roman Hodek <roman.ho...@informatik.uni-erlangen.de>
+   2008-2014 Daniel Baumann <m...@daniel-baumann.ch>
+   2015 Andreas Bombe <a...@debian.org>
+License: GPL-3.0+
+
 License: GPL-2+
  This program is free software: you can redistribute it and/or modify
  it under the terms of the GNU General Public License as published by
@@ -50,3 +60,20 @@
  .
  The complete text of the GNU Lesser General Public License
  can be found in /usr/share/common-licenses/LGPL-2 file.
+
+License: GPL-3.0+
+ This program is free software: you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation, either version 3 of the License, or
+ (at your option) any later version.
+ .
+ This package is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ GNU General Public License for more details.
+ .
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see <https://www.gnu.org/licenses/>.
+ .
+ On Debian systems, the complete text of the GNU General
+ Public License version 3 can be found in "/usr/share/common-licenses/GPL-3".
diff -Nru ntfs-3g-2016.2.22AR.1/ntfsprogs/boot.c 
ntfs-3g-2016.2.22AR.1+dfsg.1/ntfsprogs/boot.c
--- ntfs-3g-2016.2.22AR.1/ntfsprogs/boot.c  2016-02-22 08:34:33.0 
+0100
+++ ntfs-3g-2016.2.22AR.1+dfsg.1/ntfsprogs/boot.c   2016-10-01 
08:41:58.0 +0200
@@ -1,268 +1,103 @@
-#include "boot.h"
+/*
+ * NTFS bootsector, adapted from the vfat one.
+ */
 
-/**
- * boot_array - the first 4136 bytes of $Boot
+/* mkfs.fat.c - utility to create FAT/MS-DOS filesystems
+ * Copyright (C) 1991 Linus Torvalds <torva...@klaava.helsinki.fi>
+ * Copyright (C) 1992-1993 Remy Card <c...@masi.ibp.fr>
+ * Copyright (C) 1993-1994 David Hudson <d...@humbug.demon.co.uk>
+ * Copyright (C) 1998 H. Peter Anvin <h...@zytor.com>
+ * Copyright (C) 1998-2005 Roman Hodek <roman.ho...@informatik.uni-erlangen.de>
+ * Copyright (C) 2008-2014 Daniel Baumann <m...@daniel-baumann.ch>
+ * Copyright (C) 2015 Andreas Bombe <a...@debian.org>
  *
- * The first 4136 bytes of $Boot. The rest is just zero. Total 8192 bytes.
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ * The complete text of the

Bug#808463: ntfs-3g: non-free code in boot.c

[Jan Luca Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Control: tags -1 + patch

Hey,

I have created a NMU to fix this issue. It would be nice if someone
can sponsor it:

https://mentors.debian.net/package/ntfs-3g

The debdiff is attached.

Best regards,
Jan
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEwNbeTg2NJIWRcwSlfhHX8Rn5cbsFAlixr9QACgkQfhHX8Rn5
cbuXthAAxqVwQ2O4gXQWEU22EXSF5kNREwphSySvWhi2vmQU16T6PlcwpfY+A7oB
0PxY7Yw5qExV6CYdtDOCmp3Rbc4h07FInyXDcISHLLXaShzbbz0zYHTUzRreeXMV
qIUgF9HanhYiBPpLaBxK224hwqYONMIATXjQ5xlW9JdUF09gOWaK9ibl1vhld/Eu
evtx1DPlzCyPyK9JG2/wySCEsW8h7hbmyXl1DjXhovxQBAOLjGKSBIP2hG+1texn
jACHB3L7vZ9ZPEr2qYLttN8G/mATeaHKhCSVPIHzYmYGgJibumBZqdGYjnCsN+dC
E+mVcOp4FChX/Y+/wn3FAlCGoLN++O0rlWne7O1foOf5Hiq47ojhxhgrsVaNmCVu
Eb62UUAkqWARbwjZSnqVbt719/mBnxELfY93FRHde9n4N6IFLFVE2evZSCfJ9OBi
e4jK2/FPVOFJ64aseIPcqKTW+ybUgTLXcXoE+tl4gY5qkDz4IcTZV9+FPlbyF7eX
oej/fTkusxi7ELDymslboPgCOS/duoiKELJjNoaQ393KdIRQ2+8WS8KfGWP0xkRz
HsQFnnKyd/ULZsNtQd/tXw482OPusZWFylXokhtrWkEnRH1Ym042pDIFPp1xM+QP
HlemI0XJ9rpY9PlvrtbX/RowjkE/j1cfR7/d2CMZUq88fDea27o=
=ubz4
-END PGP SIGNATURE-
diff -Nru ntfs-3g-2016.2.22AR.1/debian/changelog ntfs-3g-2016.2.22AR.1+dfsg.1/debian/changelog
--- ntfs-3g-2016.2.22AR.1/debian/changelog	2017-02-01 07:23:28.0 +0100
+++ ntfs-3g-2016.2.22AR.1+dfsg.1/debian/changelog	2017-02-25 16:09:45.0 +0100
@@ -1,3 +1,12 @@
+ntfs-3g (1:2016.2.22AR.1+dfsg.1-0.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Repack of source tar file:
+Backport ntfsprogs/boot.c file from version 2016.2.22AR.2 (Closes: #808463)
+  * Update debian/copyright to match boot.c backported to this version.
+
+ -- Jan Luca Naumann <j.naum...@fu-berlin.de>  Sat, 25 Feb 2017 16:09:45 +0100
+
 ntfs-3g (1:2016.2.22AR.1-4) unstable; urgency=high
 
   * Fix CVE-2017-0358: modprobe influence vulnerability via environment
diff -Nru ntfs-3g-2016.2.22AR.1/debian/copyright ntfs-3g-2016.2.22AR.1+dfsg.1/debian/copyright
--- ntfs-3g-2016.2.22AR.1/debian/copyright	2016-04-02 18:18:49.0 +0200
+++ ntfs-3g-2016.2.22AR.1+dfsg.1/debian/copyright	2017-02-25 16:09:45.0 +0100
@@ -17,6 +17,16 @@
  2006-2010 Adam Cecile <gand...@le-vert.net>
 License: GPL-2+
 
+Files: ntfsprogs/boot.c
+Copyright: 1991 Linus Torvalds <torva...@klaava.helsinki.fi>
+   1992-1993 Remy Card <c...@masi.ibp.fr>
+   1993-1994 David Hudson <d...@humbug.demon.co.uk>
+   1998 H. Peter Anvin <h...@zytor.com>
+   1998-2005 Roman Hodek <roman.ho...@informatik.uni-erlangen.de>
+   2008-2014 Daniel Baumann <m...@daniel-baumann.ch>
+   2015 Andreas Bombe <a...@debian.org>
+License: GPL-3.0+
+
 License: GPL-2+
  This program is free software: you can redistribute it and/or modify
  it under the terms of the GNU General Public License as published by
@@ -50,3 +60,20 @@
  .
  The complete text of the GNU Lesser General Public License
  can be found in /usr/share/common-licenses/LGPL-2 file.
+
+License: GPL-3.0+
+ This program is free software: you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation, either version 3 of the License, or
+ (at your option) any later version.
+ .
+ This package is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ GNU General Public License for more details.
+ .
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see <https://www.gnu.org/licenses/>.
+ .
+ On Debian systems, the complete text of the GNU General
+ Public License version 3 can be found in "/usr/share/common-licenses/GPL-3".
diff -Nru ntfs-3g-2016.2.22AR.1/ntfsprogs/boot.c ntfs-3g-2016.2.22AR.1+dfsg.1/ntfsprogs/boot.c
--- ntfs-3g-2016.2.22AR.1/ntfsprogs/boot.c	2016-02-22 08:34:33.0 +0100
+++ ntfs-3g-2016.2.22AR.1+dfsg.1/ntfsprogs/boot.c	2016-10-01 08:41:58.0 +0200
@@ -1,268 +1,103 @@
-#include "boot.h"
+/*
+ *		NTFS bootsector, adapted from the vfat one.
+ */
 
-/**
- * boot_array - the first 4136 bytes of $Boot
+/* mkfs.fat.c - utility to create FAT/MS-DOS filesystems
+ * Copyright (C) 1991 Linus Torvalds <torva...@klaava.helsinki.fi>
+ * Copyright (C) 1992-1993 Remy Card <c...@masi.ibp.fr>
+ * Copyright (C) 1993-1994 David Hudson <d...@humbug.demon.co.uk>
+ * Copyright (C) 1998 H. Peter Anvin <h...@zytor.com>
+ * Copyright (C) 1998-2005 Roman Hodek <roman.ho...@informatik.uni-erlangen.de>
+ * Copyright (C) 2008-2014 Daniel Baumann <m...@daniel-baumann.ch>
+ * Copyright (C) 2015 Andreas Bombe <a...@debian.org>
  *
- * The first 4136 bytes of $Boot. The rest is just zero. Total 8192 bytes.
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Pub

Bug#855370: dracut-core: Check installation path of aufs-dkms in module-setup.sh

[Jan Luca Naumann]

Hey,

I have packaged the module some time ago since overlayfs has still
problems with NFS-roots[1] which is as far as I know bad for e.g. FAI.

Best regards,
Jan

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832451#15

Am 17.02.2017 um 11:52 schrieb Thomas Lange:
> > I forgot to note that the aufs-module can be found in the package
> > aufs-dkms (source: aufs) in Debian stretch+.
> I thought aufs was replaced by overlayfs. But you are right, there's
> still aufs in the dkms package.
> 

Bug#855370: dracut-core: Check installation path of aufs-dkms in module-setup.sh

[Jan Luca Naumann]

On Fri, 17 Feb 2017 09:46:26 +0100 Jan Luca Naumann
<j.naum...@fu-berlin.de> wrote:
> At the moment the module-setup.sh script of the aufs-module included in the
> Debian package do not check if there is an aufs module installed in the
> DKMS path.
> 
> The attached patch adds the feature that the check() function of the setup
> file also controls the DKMS location and thus adds support for the aufs-dkms
> package.
> 
> Best regards,
> Jan

I forgot to note that the aufs-module can be found in the package
aufs-dkms (source: aufs) in Debian stretch+.

Best regards,
Jan

Bug#855371: dracut-core: Check installation path of aufs-dkms in module-setup.sh

[Jan Luca Naumann]

Package: dracut-core
Version: 044+241-1
Severity: important
Tags: patch

At the moment the module-setup.sh script of the aufs-module included in the
Debian package do not check if there is an aufs module installed in the
DKMS path.

The attached patch adds the feature that the check() function of the setup
file also controls the DKMS location and thus adds support for the aufs-dkms
package.

Best regards,
Jan
diff --git a/debian/90aufs/module-setup.sh b/debian/90aufs/module-setup.sh
index 56d24580..9987cc87 100755
--- a/debian/90aufs/module-setup.sh
+++ b/debian/90aufs/module-setup.sh
@@ -2,7 +2,7 @@
 
 check() {
 # do not add modules if the kernel does not have aufs support
-[ -d /lib/modules/$kernel/kernel/fs/aufs ] || return 1
+[ -d /lib/modules/$kernel/kernel/fs/aufs ] || [ -f 
/lib/modules/$kernel/updates/dkms/aufs.ko ] || return 1
 }
 
 depends() {

Bug#855370: dracut-core: Check installation path of aufs-dkms in module-setup.sh

[Jan Luca Naumann]

Package: dracut-core
Version: 044+241-1
Severity: important
Tags: patch

At the moment the module-setup.sh script of the aufs-module included in the
Debian package do not check if there is an aufs module installed in the
DKMS path.

The attached patch adds the feature that the check() function of the setup
file also controls the DKMS location and thus adds support for the aufs-dkms
package.

Best regards,
Jan
diff --git a/debian/90aufs/module-setup.sh b/debian/90aufs/module-setup.sh
index 56d24580..9987cc87 100755
--- a/debian/90aufs/module-setup.sh
+++ b/debian/90aufs/module-setup.sh
@@ -2,7 +2,7 @@
 
 check() {
 # do not add modules if the kernel does not have aufs support
-[ -d /lib/modules/$kernel/kernel/fs/aufs ] || return 1
+[ -d /lib/modules/$kernel/kernel/fs/aufs ] || [ -f 
/lib/modules/$kernel/updates/dkms/aufs.ko ] || return 1
 }
 
 depends() {

Bug#854566: fai-server: fai-make-nfsroot have to create $NFSROOT/dev/pts if it not exists

[Jan Luca Naumann]

Package: fai-server
Version: fai/5.3.3~bpo8+2
Severity: important
Tags: patch

Hey,

fai-make-nfsroot mounts $NFSROOT/dev/pts in the upgrade_nfsroot() function.
When trying to create a stretch nfsroot, the mountpoint $NFSROOT/dev/pts does 
not
already exists so fai-make-nfsroot should take care of this and create the 
folder
if needed, otherwise the mount operation is not successful.

The attached patch should fix the problem.

Best regards,
Jan
diff --git a/bin/fai-make-nfsroot b/bin/fai-make-nfsroot
index 8aebd6d..a6874bc 100755
--- a/bin/fai-make-nfsroot
+++ b/bin/fai-make-nfsroot
@@ -443,6 +443,7 @@ upgrade_nfsroot() {
 
 mount -t proc   /proc  $NFSROOT/proc
 mount -t sysfs  /sys   $NFSROOT/sys
+[ -d $NFSROOT/dev/pts ] || mkdir -p $NFSROOT/dev/pts
 mount -t devpts devpts $NFSROOT/dev/pts
 /usr/lib/fai/mkramdisk $NFSROOT/var/lib/dpkg $NFSROOT/var/cache
 mkdir $NFSROOT/etc/mdadm; touch $NFSROOT/etc/mdadm/mdadm.conf # stop mdadm from calling mkconf

Bug#854550: fai-server: make-fai-nfsroot tries to remove $MNTPOINT from host and not from $NFSROOT

[Jan Luca Naumann]

Package: fai-server
Version: 5.3.3~bpo8+2
Severity: important
Tags: patch

Hey,

at the moment fai-make-nfsroot tries to remove the mount point
set in the variable $MNTPOINT from the host system and not from
the NFSROOT.

IMHO should the line 501 in the script be fixes as shown in the
attached patch.

Best regards,
Jan
diff --git a/bin/fai-make-nfsroot b/bin/fai-make-nfsroot
index 8aebd6d..6d32b00 100755
--- a/bin/fai-make-nfsroot
+++ b/bin/fai-make-nfsroot
@@ -502,7 +502,7 @@ umount_dirs() {
 
 if [ -n "$FAI_DEBMIRROR" ]; then
 test -d $NFSROOT/$MNTPOINT && umount $NFSROOT/$MNTPOINT || true
-	rmdir $MNTPOINT || true
+rmdir $NFSROOT/$MNTPOINT || true
 fi
 # show directories still mounted on nfsroot
 mount | grep " on $NFSROOT " || true

Bug#841301: ITP: libwlc -- wlc a compositor library for Wayland

[Jan Luca Naumann]

Hey,

my main intention is to use the lib for sway but I'm glad if I can help
you with the package. How could I help you?

Best regards,
Jan

On 28.12.2016 14:05, Stefanos Boglou wrote:
> Hello,
> 
> I have made a few prototype packages and seems to be not that difficult.
> There are a few issues however:
> 1) in the latest released version it does not seem to detect the installed
> wayland-protocols package and instead uses the one bundled with it but it
> is fixed in master
> 2) libchck is not packaged for debian thus it must be included in the
> source package
> 3) I have not taken the time to make shlib definitions yet
> 4) While the whole libwlc/sway seems to mostly work it has a few show
> stopping bugs that propably should be addressed first before even thinking
> about 
> 
> May I ask why do you ask? Do you wish to help with packaging/developing it?
> Or are you just hoping to use it?
> 
> 
> On Tue, Dec 27, 2016 at 7:01 PM, Jan Luca Naumann <j.naum...@fu-berlin.de>
> wrote:
> 
> Hey,
> 
> nice that someone want to package the library :)
> 
> What is the current status of the ITP?
> 
> Best regards,
> Jan
> 
> On Wed, 19 Oct 2016 16:30:32 +0300 Stefanos Boglou <vfxc...@gmail.com>
> wrote:
>>>> Package: wnpp Severity: wishlist Owner: Stefanos Boglou
>>>> <vfxc...@gmail.com>
>>>>
>>>> * Package name: libwlc Version : 0.0.6 Upstream Author
>>>> : Jari Vetoniemi <mailro...@gmail.com> * URL :
>>>> https://github.com/Cloudef/wlc * License : MIT Programming
>>>> Lang: C Description : A compositor library for Wayland
>>>>
>>>> This is a compositor library for Wayland. . Wayland is a computer
>>>> protocol that specifies the communication between a display server
>>>> (called Wayland cimpositor) and its clients. It aims to replace X
>>>> protocol soon(r).
>>>>
>>>>
>>>> Currently only weston is packaged in Debian, this should allow
>>>> easier packaging/development for window managers that depend on
>>>> this library (among others an almost drop-in replacement for i3).
>>>>
>>>> It is a requirment for the following window managers: * orbment -
>>>> Modular Wayland compositor * ocaml-loliwm - Translation of loliwm
>>>> to OCaml * sway - i3-compatible window manager for Wayland *
>>>> way-cooler - customizeable window manager written in Rust
>>>>
>>>> There are bindings for the following languages: * ocaml-wlc - OCaml
>>>> (experimental) * go-wlc - Go * rust-wlc - Rust
>>>>
>>>> Similar projects: * swc - A library for making a simple Wayland
>>>> compositor * libwlb - A Wayland back-end library * libweston -
>>>> Weston as a library
>>>>
>>>> The official name is "wlc" but wlc name is taken by another
>>>> package not related to this one.
>>>>
>>>>
>>
> 
> 
> 



signature.asc
Description: OpenPGP digital signature

Bug#849568: aufs-dkms: dkms install fails

[Jan Luca Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Control: severity -1 serious
Control: tags -1 pending

Oh, this was a debug line that should not be in the patch. I prepare a
upload to fix the bug now.

Best regards,
Jan

On Thu, 29 Dec 2016 09:04:50 +0100 Gabriel Mainberger
 wrote:
> The DKMS module did not compile for me, when the patch 
> 0003-enable-CONFIG_AUFS_EXPORT.patch has been enabled.
> 
> But it worked well, after I commented out the  $(error hier) line.
> 
> config.mk 54c54 < $(error hier) ---
>> #$(error hier)
> 
> 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEwNbeTg2NJIWRcwSlfhHX8Rn5cbsFAlhmlqoACgkQfhHX8Rn5
cbtNMQ//SuyIkADiausSMRtgM5F1sndBgO5Qz2cYHUaFkPAJw01cWoYZy78Smxu2
wGOD/G+7wQrW+3CZKynmC7wS+jc83YhtR0okq0c4npA6/hNQ/dKISsdRwYatPwpK
TleJSNupAmw5gB6GRbagXMH6MgvD9KhPWfA6Zzok0L3JpZxC2+4px1cBdXBEg2aN
Iq9oMv4eN2qaGtcXHAxhB86Ikm/HtBIN9F+v/4t/3s7+hYcZ9JWyN7gOvJnKrR3j
/KkQTV4sztKPTW00wLip7A2NNn8NnMHSpChXbAM1b5ZNWskAirGx7rDGm+5+StrL
ulseCUeK3WgN1YXCvZA6w+cA+hCguE2B6A25BeORLynHh9VSR4xEbWY4on+AhQCw
Z7cRUmJZzik4oSAog5mGBdhztYUmNvXDi16yKewOnoP+xrKdQpbXPHYTaMu7B3aZ
nI+ZAtPUcRVt3Yan0cdBs7ZxIPQ8nsQFKnlce4jNz+vo5Pcq/fWOdoQ6waCjG3yg
ZiNLV9gAUvqAm4tyHA4GmtvDi7wJjONNcN6dtg2qO4/rMk3M4D3RQCAEITWnVANc
GrvmdNlRDJp+HxDHYDDUK6Ma35Dyu5OO1o+axzpqFQpeDDElXgMMQuiAG7YKchRM
gzogtIdU0m7Mqq23KXetL2mRTBJfWyCMxSshukjoR5wmo08LbzQ=
=pzpI
-END PGP SIGNATURE-

Bug#841301: ITP: libwlc -- wlc a compositor library for Wayland

[Jan Luca Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hey,

nice that someone want to package the library :)

What is the current status of the ITP?

Best regards,
Jan

On Wed, 19 Oct 2016 16:30:32 +0300 Stefanos Boglou 
wrote:
> Package: wnpp Severity: wishlist Owner: Stefanos Boglou
> 
> 
> * Package name: libwlc Version : 0.0.6 Upstream Author
> : Jari Vetoniemi  * URL :
> https://github.com/Cloudef/wlc * License : MIT Programming
> Lang: C Description : A compositor library for Wayland
> 
> This is a compositor library for Wayland. . Wayland is a computer
> protocol that specifies the communication between a display server
> (called Wayland cimpositor) and its clients. It aims to replace X
> protocol soon(r).
> 
> 
> Currently only weston is packaged in Debian, this should allow
> easier packaging/development for window managers that depend on
> this library (among others an almost drop-in replacement for i3).
> 
> It is a requirment for the following window managers: * orbment -
> Modular Wayland compositor * ocaml-loliwm - Translation of loliwm
> to OCaml * sway - i3-compatible window manager for Wayland *
> way-cooler - customizeable window manager written in Rust
> 
> There are bindings for the following languages: * ocaml-wlc - OCaml
> (experimental) * go-wlc - Go * rust-wlc - Rust
> 
> Similar projects: * swc - A library for making a simple Wayland
> compositor * libwlb - A Wayland back-end library * libweston -
> Weston as a library
> 
> The official name is "wlc" but wlc name is taken by another
> package not related to this one.
> 
> 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEwNbeTg2NJIWRcwSlfhHX8Rn5cbsFAlhinkwACgkQfhHX8Rn5
cbtGdw/6Ah+Je7Vqn4TKc9aFAydTDaQxha6kXHEPWxhZVu1TVdnz6uAE+NL0j0My
Ej93czP9F7RSErEjh14ZYFjyKjNXciX1cDxpWGvj5JLHmPAWdw8fXGdg7rEqEdhe
PIT9/3m4E1yAshN6xIkzws9SBkAfbaCeIchXgS5Pjtp5age8CDuxxRjkuC2J76qS
2dmIKfBitrnOJX1dXBSBXsz4Q1gT5+S72vrafLtlEch70aph1V6ubgtyBCMKvm58
NmaAZGE9bnGFu4UWzvl9gTB966jpZLR85MWnBrE00AgyleqYNY4KsDjazzN921Xj
C7sAL//h1rrwNdilu+A7RqLcHiwBob9gGV8F8D2ur0EaVjw3+bV7wHnCHo0+5jlY
KNgmZkuF3R6EjhYxYdXjo6S34+5TIfo9O/fxnIBjQqnSDF6pAAZjHexPiBiHpHO8
fDOq0WybXPlVEkFz01QDWfVgZVV8jqBbLGPsmQdm2EbzRIgoDd4SXuRz98m16GtG
ouiVTRSzp/ur26/tLCEJkFAEGpsxANmtQh6VevfWxN70AMVcikB+HBThub0cWITu
kMSczJpxRKRvP+T3bk/M/fK3P9f4W/qUHsTjHkc6vbEL0P4yzKSpqrnk4vvXIQqP
86pSicn6RhLXCNNjT5/Y2Dwd/nfA/vWQHqgD7fYB5DvtH6FN3dk=
=6ziq
-END PGP SIGNATURE-

Bug#821397: RFP: sway -- i3-compatible window manager for Wayland

[Jan Luca Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Oh sorry, that was my fault: I have read ITP (Intend to package) but
this unfortunately only a RFP yet.

Sorry for the spam,
Jan

Am 27.12.2016 um 17:52 schrieb Jan Luca Naumann:
> Hey,
> 
> it is very nice that someone want to take care of sway for Debian :)
> 
> What is the current status of the packaging process?
> 
> Best regards,
> Jan
> 
> On Mon, 18 Apr 2016 15:16:41 +0200 Holger Levsen
> <hol...@layer-acht.org> wrote:
>> Package: wnpp Severity: wishlist
> 
>> * Package name: sway Version : 0.5 Upstream Author :
>> s...@cmpwn.com * URL : http://swaywm.org/ 
>> https://github.com/SirCmpwn/sway * License : BSD 
>> Programming Lang: C Description : i3-compatible window manager
>> for Wayland
> 
>> Sway is a drop-in replacement for the i3 window manager, but for
>> Wayland instead of X11. It works with your existing i3
>> configuration and supports most of i3's features, and a few extras.
> 
> 
>> -- cheers, Holger
> 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEwNbeTg2NJIWRcwSlfhHX8Rn5cbsFAlhinKkACgkQfhHX8Rn5
cbs8BhAAijzh6x/eXtsPym2spNg3oQFdPJPK8kV665NB+yXs0GypCOwu82Wt6Cy/
wRpe2yx+X2bq4u/7Vohhtnf8izY0NZu0ZW1wdbQEqpSIxDR4ZeLj6PrbuSP0n7a0
2ChCJp5Sl1Pwbkqv1ecjjp/cesaR1Yr35+fpGJLbNVgcqhgflPL1zHmVdNR42Cng
iGCFJM3WiMZokd5JddWnj9dEqan4RXSk2q8SDdxHrObYnlGJZ2hZmIMUEMH6vuhw
T3zERh8/P4n2q2dcFzvgrzFyuY+TR6XTyak7G6l333q85lx9WycIYkGDQtFWjVx0
kyLcleXHWh9HpjbcxG/mp2m9ODRZdbPVU8eBhy/KzoQOQI/waT1FiAML+O4d6QIu
Ta9eE6w2bd8H9/ePKIhxv+tqNascZlZnXyRPrsL7bfH3vCMTDR6G1qetnR0AjEZK
uKFdRvREmI7Z48LpqXFg/wgbtg044OBTcyN1T/SmK8/3i1uoYOJ+BcYQwIMcDx0b
qV6NPJFKxzjWPPYVFkibHd48iORvlp9KvKS1JuQ/Vw+i/WF4hDDt54GTWryKFakv
CJOSSflAh4eIMgJ6MugER9KibNVeyoIN/w9MMMAtZTs3hEi+x/P9dtMAfbLYCTK7
Na26606FcKq5SEj+ZjLC+JtVEBOdeOZqdjDC/dit9mebNwLwkWA=
=S2b1
-END PGP SIGNATURE-

Bug#821397: RFP: sway -- i3-compatible window manager for Wayland

[Jan Luca Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hey,

it is very nice that someone want to take care of sway for Debian :)

What is the current status of the packaging process?

Best regards,
Jan

On Mon, 18 Apr 2016 15:16:41 +0200 Holger Levsen
 wrote:
> Package: wnpp Severity: wishlist
> 
> * Package name: sway Version : 0.5 Upstream Author :
> s...@cmpwn.com * URL : http://swaywm.org/ 
> https://github.com/SirCmpwn/sway * License : BSD 
> Programming Lang: C Description : i3-compatible window manager
> for Wayland
> 
> Sway is a drop-in replacement for the i3 window manager, but for
> Wayland instead of X11. It works with your existing i3
> configuration and supports most of i3's features, and a few extras.
> 
> 
> -- cheers, Holger
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEwNbeTg2NJIWRcwSlfhHX8Rn5cbsFAlhinE0ACgkQfhHX8Rn5
cbsK+g/+Pvz3jPrKdpwlSilkkDU7XzZ6Fk3n3AwDYAp5gQU6dxFCAHHpsxWj6jPm
PGMAZmweeyzkcugYB9ys8SjWOuT7+Zu6xlKGg/sYWG7JSnHf+jLWa8nOubi8ryff
W/yGqW7kMWw76xpenBSQEL4SQed6Lg6uDMYSPfJ2xXK6xX2h4ODH+lEJwqOAESs2
KHm2WHjO4vDu6NBrOuglNrEe5HN3xwJHKMTwZEnLhJA7Vs0FgcwqwT6O1whdrmJ2
Eh4TnL+XeJBiH0EjCwyig1QDI10FVea3nbk2/LstQKAC9YhNoaxwcXpPmnVoUP69
ozF0bxPh4lVNtT4ZW2bleGzBT8HDmiJekBXRWu2BFM2Oes507TFmeT0PTh0/K2nn
F+eiHgo6GRswvGOSvaxdkyyTSHZPoao64pKR439Z2f40HhOz0gPilOc7ralizUWK
ZuQ9cG+ImrchoBBC02YVTfYiJYWl+4Ssdtn1OdZftInpGyFOhgylcGJYh+6vQp6S
IsAVyMMMavkgXU3iyQePqQ+ca3jJslfsdaRKdQdcoUUC3jhkBbQ/cO0b5EVsX599
awWCGEwfs/OsoEYl1ge74mn4DgPEIPLbUQBZeUeplZ0GhEiKP0isLGnnv1LkAn6T
UMJTgaDBaflqsJdATLLTsugDi50rY8ywSmAMC31D+Ghzpa9pPto=
=BgcN
-END PGP SIGNATURE-

Bug#847773: [Filesystems-devel] Bug#847773: aufs-tools: auplink crashes with SIGSEGV in ftw_startup()

[Jan Luca Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hey Flos,

since I have never used docker and don't have a testing environment
thus: Could you try in a test environment if the problem exists with
the version 4.1+20161010-1 from testing, too? The aufs-tools should be
backward-compatible as far as I know.

Best regards,
Jan

Am 11.12.2016 um 16:00 schrieb Flos Lonicerae:
> Package: aufs-tools Version: 1:3.2+20130722-1.1 Severity: normal
> 
> Hi,
> 
> auplink always segfault unexpectedly:
> 
> root@mydesktop:~# cat /var/log/messages|grep segf Dec 11 13:13:17
> mydesktop kernel: [ 1627.466470] auplink[7024]: segfault at 
> 7ffe2ab8ced8 ip 7fbe37812dd9 sp 7ffe2ab8cee0 error 6 in 
> libc-2.19.so[7fbe37735000+1a1000] Dec 11 13:17:55 mydesktop kernel:
> [ 1906.022100] auplink[7873]: segfault at 7ffd75202628 ip
> 7f40cf05bdd9 sp 7ffd75202630 error 6 in 
> libc-2.19.so[7f40cef7e000+1a1000] Dec 11 13:18:43 mydesktop kernel:
> [ 1953.601864] auplink[8108]: segfault at 7ffc839d5098 ip
> 7f3139e72dd9 sp 7ffc839d50a0 error 6 in 
> libc-2.19.so[7f3139d95000+1a1000] Dec 11 17:44:01 mydesktop kernel:
> [17882.322580] auplink[1085]: segfault at 7fffec5c2868 ip
> 7fc4ff0b7dd9 sp 7fffec5c2870 error 6 in 
> libc-2.19.so[7fc4fefda000+1a1000] Dec 11 17:45:09 mydesktop kernel:
> [17949.768431] auplink[1393]: segfault at 7ffc17e547e8 ip
> 7fd62f627dd9 sp 7ffc17e547f0 error 6 in 
> libc-2.19.so[7fd62f54a000+1a1000] Dec 11 17:45:55 mydesktop kernel:
> [17995.873865] auplink[1605]: segfault at 7ffe1250f0e8 ip
> 7f3a0d4dfdd9 sp 7ffe1250f0f0 error 6 in 
> libc-2.19.so[7f3a0d402000+1a1000] Dec 11 20:10:17 mydesktop kernel:
> [ 3343.931533] auplink[6082]: segfault at 7ffe5e6edd28 ip
> 7fb2d520ddd9 sp 7ffe5e6edd30 error 6 in 
> libc-2.19.so[7fb2d513+1a1000] Dec 11 22:37:44 mydesktop kernel:
> [12197.065105] auplink[16901]: segfault at 7ffcf1a52ce8 ip
> 7f6c86f79dd9 sp 7ffcf1a52cf0 error 6 in 
> libc-2.19.so[7f6c86e9c000+1a1000]
> 
> Backtrace as follows:
> 
> Core was generated by `auplink 
> /var/lib/docker/aufs/mnt/d486a4d276491ddd7f3c91e8fb87cb3561a971bdc5aa1
f'.
>
> 
Program terminated with signal SIGSEGV, Segmentation fault.
> #0  ftw_startup (dir=dir@entry=0x1d2c010 
> "/var/lib/docker/aufs/mnt/d486a4d276491ddd7f3c91e8fb87cb3561a971bdc5aa
1f17882e4b6d2cdd74de",
>
> 
is_nftw=is_nftw@entry=1,
> func=func@entry=0x401458 , descriptors=1048566, 
> flags=flags@entry=19) at ../sysdeps/wordsize-64/../../io/ftw.c:656 
> 656 ../sysdeps/wordsize-64/../../io/ftw.c: No such file or
> directory. (gdb) thread apply all backtrace full
> 
> Thread 1 (LWP 6082): #0  ftw_startup (dir=dir@entry=0x1d2c010 
> "/var/lib/docker/aufs/mnt/d486a4d276491ddd7f3c91e8fb87cb3561a971bdc5aa
1f17882e4b6d2cdd74de",
>
> 
is_nftw=is_nftw@entry=1,
> func=func@entry=0x401458 , descriptors=1048566, 
> flags=flags@entry=19) at ../sysdeps/wordsize-64/../../io/ftw.c:656 
> data = {dirstreams = 0x7ffe5e6edd30, actdir = 0, maxdir = 1048566, 
> dirbuf = 0x34 ,
> dirbufsize = 0, ftw = { base = 91, level = 0}, flags = 1, cvt_arr =
> 0x0, func = 0x77006e, dev = 0, known_objects = 0x7c} st =
> {st_dev = 140730491133504, st_ino = 6303912, st_nlink = 0, st_mode 
> = 30590112, st_uid = 0, st_gid = 3580704400, __pad0 = 32690,
> st_rdev = 30589088, st_size = 5324, st_blksize = 140406059601351,
> st_blocks = 1, st_atim = {tv_sec = 0, tv_nsec = 4294967296},
> st_mtim = {tv_sec = 140406055741616, tv_nsec = 0}, st_ctim =
> {tv_sec = 5324, tv_nsec = 30590240}, __glibc_reserved =
> {140406059627237, 1048576, 19}} result = 0 save_err =  out> cwdfd = -1 cwd = 0x0 cp =  #1
> 0x7fb2d520e2ba in __new_nftw (path=path@entry=0x1d2c010 
> "/var/lib/docker/aufs/mnt/d486a4d276491ddd7f3c91e8fb87cb3561a971bdc5aa
1f17882e4b6d2cdd74de",
>
> 
func=func@entry=0x401458 , descriptors=,
> flags=flags@entry=19) at ../sysdeps/wordsize-64/../../io/ftw.c:859 
> No locals. #2  0x00401cac in do_plink (br=,
> nbr=, cmd=0, cwd=0x1d2c010 
> "/var/lib/docker/aufs/mnt/d486a4d276491ddd7f3c91e8fb87cb3561a971bdc5aa
1f17882e4b6d2cdd74de")
>
> 
at plink.c:303
> err = 0 i =  rlim = {rlim_cur = 1048576, rlim_max =
> 1048576} func = 0x401458  l =  p =
>  #3  au_plink (cwd=cwd@entry=0x1d2c010 
> "/var/lib/docker/aufs/mnt/d486a4d276491ddd7f3c91e8fb87cb3561a971bdc5aa
1f17882e4b6d2cdd74de",
>
> 
cmd=cmd@entry=0,
> flags=flags@entry=1, fd=fd@entry=0x0) at plink.c:364 err =
>  nbr = 4 ent = {mnt_fsname = 0x1d2c3b0 "none",
> mnt_dir = 0x1d2c3d0 
> "/var/lib/docker/aufs/mnt/d486a4d276491ddd7f3c91e8fb87cb3561a971bdc5aa
1f17882e4b6d2cdd74de",
>
> 
mnt_type = 0x1d2c440 "aufs", mnt_opts = 0x1d2c460
> "rw,relatime,si=a1ff9db3fc41830a,dio,dirperm1", mnt_freq = 0,
> mnt_passno = 0} br = 0x1d2c080 p =  si =
> "si=a1ff9db3fc41830a" #4  0x004013ae in main
> (argc=, argv=) at auplink.c:64 err =
>  cmd = 0 (gdb)
> 
> 
> Looks like the upstream bug:
> https://sourceforge.net/p/aufs/bugs/26/
> 
> Any thoughts?
> 
> Thanks and Regards, Flos
> 
> 
> 
> -- 

Bug#845724: aufs-tools FTCBFS: uses host architecture compiler for build tools

[Jan Luca Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Sorry for the long delay, I will take later a look on your patch.

Best regards,
Jan

On Sat, 26 Nov 2016 09:25:06 +0100 Helmut Grohne 
wrote:
> Source: aufs-tools Version: 1:4.1+20161010-1 Tags: patch User:
> helm...@debian.org Usertags: rebootstrap
> 
> aufs-tools fails to cross build from source, because it compiles a
> few build tools using the host architecture compiler. Recent
> debhelper started to pass cross compilers via the CC command line
> variable to make. This does not work well with aufs-tools as it
> needs to locally reassign CC. Thus the attached patch stops using
> dh_auto_build to let the upstream Makefile override CC and thus
> succeed in cross building. Please consider applying it.
> 
> Helmut
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEwNbeTg2NJIWRcwSlfhHX8Rn5cbsFAlhNOd4ACgkQfhHX8Rn5
cbsBuQ//W3Bk1xvS7XLQjZ9ycr0MuUjvXGs1kL/UO1gCsePt8ng7dvVTT//viYDi
B4VfgR/yj5AWRLtOshQScK059BMQ3bFsbnGEPMSUdDkDkalVVFN3btc2EI2iPNCC
v2CYLEOs2WLLL99r8ptUegmWzK1qe+Q5UKRhFHBfT/HLLmOTaVMXUnOZs3uA81Rv
enMpPcZsSTp1WNMdI/Rw3gkk9x4nMra9uQbO89KIRxjbobDe4NJ4Wp0jxRDz/6uF
O7eM8rOIcXxwXTqR1aV63bdnLs+3/6r3CR32WoesMqvMhsJjoTAbfmi1Us8B69UK
hvPSLzUjUbatcIOtbGaVf7hjeh6Wr1W86JLkLuAizw5sw73skEaq2zs2HaOlaO8+
jMa5LjBLn3RMRMXUb1H8/V4KTqGBGVbgDywq8SVTi1wtvNIeQyqwWKU0A9IKFmNr
BhfYZOkjq9ymoOfdJMuaasMe/Gn3wd63S/FmI/ChhOmQZKOH2DmcUkrJ2r0g2Kqh
V3554KGTQYYrTrlO+7i3aQA/f09YBKrXgYjb536YNTgdjsjeR2EsMdIEKWEyh76k
fG3I0Qewf/SdmP/gLX2zG7b+9WYUsfpKyTKfztYKPOwtnnthQqaF5dxMlNq4RjFj
wZh+SaPK8D/SohNkdsWj/jntLKAOHpgZO4zGY+C+7tJHGyqrQh0=
=uwmm
-END PGP SIGNATURE-

Bug#847217: RFS: python-django-allauth/0.29.0-1 [ITP]

[Jan Luca Naumann]

Hey,

I forgot to mention that I upload the package to the Git repo of the
Python modules team as soon as my request to join the team is   accepted.

Best regards,
Jan

On Tue, 06 Dec 2016 16:16:17 +0100 Jan Luca Naumann
<j.naum...@fu-berlin.de> wrote:
> Package: sponsorship-requests Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "python-django-allauth"
> 
> * Package name: python-django-allauth Version : 
> 0.29.0-1 Upstream Author : Raymond Penners and contributors * URL :
> http://www.intenct.nl/projects/django-allauth/ * License : MIT 
> Section : python
> 
> It builds those binary packages:
> 
> python-django-allauth - Django apps for local and social 
> authentication (Python 2) python-django-allauth-doc - Django apps 
> for local and social authentication (common docs) 
> python3-django-allauth - Django apps for local and social 
> authentication (Python 3)
> 
> To access further information about this package, please visit the 
> following URL:
> 
> https://mentors.debian.net/package/python-django-allauth
> 
> Alternatively, one can download the package with dget using this 
> command:
> 
> dget -x 
> https://mentors.debian.net/debian/pool/main/p/python-django-allauth/python-django-allauth_0.29.0-1.dsc
>
>
>
>
> 
More information about python-django-allauth can be obtained from
> http://www.intenct.nl/projects/django-allauth/ .
> 
> Best regards, Jan
> 
> 



signature.asc
Description: OpenPGP digital signature

Bug#847217: RFS: python-django-allauth/0.29.0-1 [ITP]

[Jan Luca Naumann]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "python-django-allauth"

 * Package name: python-django-allauth
   Version : 0.29.0-1
   Upstream Author : Raymond Penners and contributors
 * URL : http://www.intenct.nl/projects/django-allauth/
 * License : MIT
   Section : python

It builds those binary packages:

 python-django-allauth - Django apps for local and social authentication 
(Python 2)
 python-django-allauth-doc - Django apps for local and social authentication 
(common docs)
 python3-django-allauth - Django apps for local and social authentication 
(Python 3)

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

 https://mentors.debian.net/package/python-django-allauth

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

 dget -x 
https://mentors.debian.net/debian/pool/main/p/python-django-allauth/python-django-allauth_0.29.0-1.dsc

More information about python-django-allauth can be obtained from
http://www.intenct.nl/projects/django-allauth/ .

Best regards,
Jan

Bug#843846: [Filesystems-devel] Bug#843846: aufs for 4.8: "../fs/mount.h not found" when enabling NFS export

[Jan Luca Naumann]

Hey,

thank you for analyzing the bug and the fix :-)

@Philipp: I will upload a new version to the Debian archive as soon as it
available.

Best regards,
Jan

>
> Philipp Marek:
>> But fs/mount.h does
>>
>> #include 
>>
>> and it seems that the linux/mount.h contains everything that AUFS needs.
>>
>>
>> I've got the module up and running for a few hours, mounting/unmounting
>> directories all the time (in a testsuite)... so it looks as if it's not
>> _completely_ broken ;)
>
> Sorry for the long delay.
> This "aufs is compiled and working" news surprised me, and I digged down
> the git log to find out why fs/mount.h is necessary.
> And here is the fix which will be included in next aufs release.
>
> Thanx for reporting, two of you.
> J. R. Okajima
>
> commit 348da45314afe6fc88e6f91a74da4587ec6555af
> Author: J. R. Okajima <hooanon...@gmail.com>
> Date:   Tue Nov 22 00:51:45 2016 +0900
>
> aufs: dependency bugfix, linux/fs/mount.h
>
> linux/fs/mount.h is included from two aufs source files,
> fs/aufs/export.c and fs/aufs/vfsub.c.
> For export.c, it is unnecessary which means a build dependency bug.
> The
> bug was born back in 2012.
>   c70a5cf 2012-01-13 aufs: tiny for 3.3, arg for iterate_mounts()
> For vfsub.c, it is necessary and it is not a bug. But it is just for
> CONFIG_AUFS_BR_FUSE only. So it should be refined by "#ifdef
> CONFIG_AUFS_BR_FUSE".
>
> Reported-by: Jan Luca Naumann <j.naum...@fu-berlin.de>
> See-also: https://github.com/sfjro/aufs4-standalone/pull/1
> Reported-by: Philipp Marek <philipp.ma...@linbit.com>
> See-also: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843846
> Signed-off-by: J. R. Okajima <hooanon...@gmail.com>
>
> diff --git a/fs/aufs/export.c b/fs/aufs/export.c
> index 2b2380a..afba472 100644
> --- a/fs/aufs/export.c
> +++ b/fs/aufs/export.c
> @@ -12,7 +12,6 @@
>  #include 
>  #include 
>  #include 
> -#include "../fs/mount.h"
>  #include "aufs.h"
>
>  union conv {
> diff --git a/fs/aufs/vfsub.c b/fs/aufs/vfsub.c
> index f2d1b36..fc52351 100644
> --- a/fs/aufs/vfsub.c
> +++ b/fs/aufs/vfsub.c
> @@ -10,7 +10,9 @@
>  #include 
>  #include 
>  #include 
> +#ifdef CONFIG_AUFS_BR_FUSE
>  #include "../fs/mount.h"
> +#endif
>  #include "aufs.h"
>
>  #ifdef CONFIG_AUFS_BR_FUSE
>

Bug#799281: [Mailman-Developers] Let's try to package mailman3 in Debian!

[Jan Luca Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Control: subscribe -1 j.naum...@fu-berlin.de

Hey,

my point was to start packaging the Mailman 3.1 development version
already since this version switches to python3.5 and many bug fixes
are applied there (I currently administrate a 3.0.3 installation,
there are many things not working properly). For the new
django-allauth dependency I have created a new ITP bug (you should be
in CC of the bug).

My GitHub account is JanLuca.

Best regards,
Jan

Am 14.11.2016 um 22:42 schrieb Pierre-Elliott Bécue:
> Le vendredi 11 novembre 2016 à 14:39:18+0100, Jan Luca Naumann a 
> écrit :
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA512
>> 
>> Hey Pierre-Elliott,
>> 
>> my idea is that we package the current development versions and 
>> upload them to Debian experimental since the development time of 
>> 3.1 will last some more time according to the Mailman 
>> developers...
>> 
>> If you have no problem I could submit some changes to your 
>> repository either as pull requests or as direct pushs?
> 
> As said, there is two issues.
> 
> First, HyperKitty deps are missing, second, mailman relies on 
> python3.4.
> 
> If you have some patches to offer let's go for it, what is your 
> github login please?
> 
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJYLyC+AAoJEH4R1/EZ+XG7FoQP/3XHmbQlxo0kMO4YXLoTQuKW
HvJVW8lwiIyBTRdY7RyY/obtGXjLvNDXpnUPyGULWUX3XUC0O15F2PHXFjbxc3b4
AI/uJEDfpbr88z46fYFRCPov5/A4tUEp+Rn0qBtl6jFI3tU8kcU9dS01tTml0aw8
sexwc8W7Qu/YQ93OjrSQG4p+O95d6V9ksTgf5XihdaieQQCg9Yf+rb97oJ4c3R2A
Y9bixue+NA3fDYdkBEX52okUsVCij2iujdBuDAwOCfrhN9rhVsdtlQB480UST8j+
/a6zzOZRKcHQwbF4+QtKnAdA3KLKgmn8L/oTy+FPFit1Ew+6kb6QInx8if49VWVl
Z25f/EDUNV40xiQAvrnbwIkGqqo3mtIqZPwgak5g4IkMEtRY1kbglZT10evRkTWD
724K+604cP0/GlybDWiZIvFolH/WMyUjopLRFRccFgiJEyo1egeV8G2HBYfYKGAn
dSRpnnDCURUDNlQCEGXBd9pcLXwDK1X04o55aQxN09m8RnUuwAxDpg/bqGktwUCs
ktBoQuSDjPf7XcMjSxXIhBW9hradvQHDD/gXbD9x10kklj68kE2YtkHRuQgTbgyf
Flp8wfYwBT5ff5x8o/uyGSeDa2eedxT1XNihrmJWg4QoSebZbBkII3HNDii6Ysho
xQpjpvTGXub26IQ/WB+/
=sa/A
-END PGP SIGNATURE-

Bug#844743: ITP: python-django-allauth -- Django app that allows both local and social authentication

[Jan Luca Naumann]

Package: wnpp
Severity: wishlist
Owner: Jan Luca Naumann <j.naum...@fu-berlin.de>

* Package name: python-django-allauth
  Version : 0.28.0
  Upstream Author : Raymond Penners and contributors
* URL : http://www.intenct.nl/projects/django-allauth/
* License : MIT
  Programming Lang: Python
  Description : Django app that allows both local and social authentication

Integrated set of Django applications addressing authentication,
registration, account management as well as
3rd party (social) account authentication.

Bug#844205: [Filesystems-devel] Bug#844205: aufs-dkms: I can't load the kernel module after upgrade from Jessie to Stretch.

[Jan Luca Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hey,

1. In the Debian archive there can be only one version of a package at
one time so there will be always only the version compatible to the
current kernel version. The upgrades are needed since there are new
development in the module and changes in the kernel interfaces.
Normally the linux kernel should be already be 4.8. in testing, too,
but it seems that there are problems with the package so the aufs was
unfortunately faster in testing.

2. There is a snapshot of the version 4.7+20160912-2:
http://snapshot.debian.org/package/aufs/4.7%2B20160912-2/

Jan

Am 13.11.2016 um 14:06 schrieb Leo:
> Hi Jan, thanks a lot for your response! :)
> 
> 2016-11-13 13:34 GMT+01:00 Jan Luca Naumann
> <j.naum...@fu-berlin.de <mailto:j.naum...@fu-berlin.de>>:
> 
> The current version is packaged for the current unstable kernel,
> the problem in this case is that the kernel 4.8 is not migrated to
> testing yet. Please wait for the migration (see 
> https://tracker.debian.org/pkg/linux 
> <https://tracker.debian.org/pkg/linux> ) and upgrade then to the
> kernel 4.8, then the module should be available.
> 
> 
> I suspected that the problem was this one.. XD
> 
> I don't know exactly how the process "unstable -> testing" works,
> but I'd like to make some question:
> 
> 1. why the aufs was upgraded before the kernel? Was the version
> for kernel 4.7 broken?
> 
> 2. It's possible to be able to find in the repository also the
> previous version (for 4.7)? In order to be able to install the
> correct version for the kernel currently available in repository.
> 
> What do you think? Thanks again for your help.
> 
> Best regards, Leonardo Rossi
> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJYKGxHAAoJEH4R1/EZ+XG7YBAQAKnIFCC8vGCuVchZcpYakItu
lKYfDz88L1QxunrSyYXAgxl0GsBWZGsG/QBog56Z730EQyPwqn5KkwUNSyTm2Zv8
O1T4anwXKq2hJR92oBnzLtg3+/fOdacdZpwgTXuMjHHw5d50xcAJdfVGPnDBgiq6
YLV8nRzmNResPIXyX5v4/xS/R+tvqY3wSt4hDryRLVuuHgnpMgAeZI9GB29armQY
akjwtlt5SAbmXaUa3pcXCAUTD8UFGftQVTI5MDrgwZjBL5wjrPYxpP5ZCK1UHTU9
HuqgCWme6eCcLXLLWyDBQBWW0syqg+nzgcA1MFO8Sh3oPK+8+tZGo/j2d958UmZN
UPbH7ga6VscjQom75GdImbDhPXXAYsX7+NaSStbhE2agFAauEVG+vnxKeI5jgWw8
pn8CGcK6yFDy0CR4xFH0iWRxXCDlwj1urf7BLpeokWzoyGhqaa4E9Rc2Fm6cRof3
oxKVpssLeFZmd8XsYOIblXHP4fGDwoxF1vcWKvGq5ymTPXmFNINzJQgvfL3l7R0b
qoTtysp5caOzKVVSpHnhocAleFc1d3T+BP8WaNfo8E8rMw3zDvuWdHYcVslXfNa7
XI3mZCiWmawcRVMaXNzno/MkuXeTHrTQ0K+EYFpO7CaU6mg2W40Q5AKTnaWzxAx/
wzotDax8VH6JshoI5dtH
=pnWF
-END PGP SIGNATURE-

Bug#799281: [Mailman-Developers] Let's try to package mailman3 in Debian!

[Jan Luca Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hey Pierre-Elliott,

my idea is that we package the current development versions and upload
them to Debian experimental since the development time of 3.1 will
last some more time according to the Mailman developers...

If you have no problem I could submit some changes to your repository
either as pull requests or as direct pushs?

Jan

Am 07.11.2016 um 22:26 schrieb Pierre-Elliott Bécue:
> 
> Dear Jan,
> 
> I'd be happy to work with you.
> 
> Mostly, all parts of mailman are "pre-packaged" on my server. I met
> issues with HyperKitty regarding dependencies, currently, these are
> not fully solved, as the devs had to move from django-browserid
> (implementation of persona protocol, by Mozilla) to another
> dependency offering implementation of a still used protocol
> (Mozilla is dropping persona).
> 
> The second "issue" is mailman itself. It's using python3.4, but
> default version of python3 in debian is 3.5 for something like 10
> months. I'm waiting mailman version 3.1, as Barry Warsaw told me
> it'd use python3.5.
> 
> If you wish I can give you the developper accesses on my github
> repositories which contain the current packages, except hyperkitty
> (because of what I mentioned before).
> 
> Cheers,
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJYJcoCAAoJEH4R1/EZ+XG7+loP/3McoCqbTvwbPNLcSjw9Cnbi
VNDzOoHCLMfvTOsmODH3fOJOgSUHEcpoUHF3EL3xbPYsRc+Qf2BKXcPcXJeRuHJn
qCTvXJbUNpGO+jECN4FbVjPPU3HUBLmw+m15t92ZTi5xvxBUCMwDObpErC6YtNSf
Jf7RIxk+0IpUmj4Loxq3GBJBBG7DWdDPxs5p8O7mLnT7Ep+9K3bL9ErlDMCQmP5q
tWnPoPwv+t3h5pj8kyYxhXzII5mREljytxrm2cMx4c94l/hCm7orxigeBnZfQnni
3aqKYgpAsHW2bG+S7d9kCv/rcV0C3vwM/xFu7Vi9urB0gFUu5yfmmdWP0Yl+uxOK
R5pVmZF5ckeluIjZ1qELAZvEw41HIhd0qKuIvt4pocIkplFNtME6oNdnoiJ28Z+t
T6kXrIl3j3ptYIrNQCrLq+6jJrlH/TcMrjSvSSXw27jhDw/SXE9iTXgpx1AI8FW3
QacW9WzN0c/dTnJfA4CUWMY4N6bpoCIxnIRmYBonEkBPNcB14BTs5NxpYOFzfKTU
L0PpZ5Yu+4pmWiIz3K9IMCYNNgW9jEiY4uiACq3QQ2qYt+zGXO5my1rwR0LXEOj/
5SJMquiIBGl/3inrhTJvI/QJJmY3c51ja/jhY8nhT+CPLg+riLdDYlgGj958CtDa
lmr/WRHbElhrzqXk0bKt
=N08F
-END PGP SIGNATURE-

Bug#843846: [Filesystems-devel] Bug#843846: aufs for 4.8: "../fs/mount.h not found" when enabling NFS export

[Jan Luca Naumann]

Caution: linux/mount.h is not the same as fs/mount.h, see 
https://github.com/torvalds/linux/blob/master/fs/mount.h
vs.
https://github.com/torvalds/linux/blob/master/include/linux/mount.h

Jan

Am 10. November 2016 09:56:49 MEZ, schrieb Philipp Marek 
:
>Hi Jan,
>
>
>> the file fs/mount.h belongs to the normal kernel source. Upstream
>suggest 
>> to build the aufs-module inside the kernel source tree.
>Yes, by replacing the relative #include paths with absolute ones I got
>it 
>working.
>
>> Since this is not 
>> simply possible for the automatic Debian package builds, I have to
>think 
>> about a good solution for thr Debian package.
>The build is run from the kernel source directory, so why not fix the
>path 
>to via a patch?
>
>> If I find a good solution 
>> I also could enable the setting CONFIG_AUFS_EXPORT=y by default for
>the 
>> package.
>That would be helpful.
>
>
>Please see the attached patch.

Bug#843846: [Filesystems-devel] Bug#843846: aufs for 4.8: "../fs/mount.h not found" when enabling NFS export

[Jan Luca Naumann]

Hey Phil,

the file fs/mount.h belongs to the normal kernel source. Upstream suggest to 
build the aufs-module inside the kernel source tree. Since this is not simply 
possible for the automatic Debian package builds, I have to think about a good 
solution for thr Debian package. If I find a good solution I also could enable 
the setting CONFIG_AUFS_EXPORT=y by default for the package.

Jan

Am 10. November 2016 09:26:27 MEZ, schrieb Philipp Marek 
:
>Hi Junjiro,
>
>using https://github.com/sfjro/aufs4-standalone.git as 
>e9fd128dcb16167417683e199a5feb14f3c9eca8 and setting
>
>CONFIG_AUFS_EXPORT = y
>
>only gives me a compile error:
>
>/usr/src/aufs4-standalone/fs/aufs/vfsub.c:26:25: fatal error:
>../fs/mount.h file or directory not found
>
>As the NFS change was your commit, but that one didn't include a file 
>"mount.h", would you please send it to me and/or push it to the
>upstream 
>repository?
>
>
>Thank you very much.
>
>
>Regards,
>
>Phil
>
>___
>Filesystems-devel mailing list
>filesystems-de...@lists.alioth.debian.org
>http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/filesystems-devel

Bug#843846: [Filesystems-devel] Bug#843846: aufs-dkms: enabling NFS export gives "export.c: fatal error: ../fs/mount.h not found"

[Jan Luca Naumann]

Hey,

I will take a look on the problem but I will have less time the next days so 
there could be some delay.

Best regards,
jan

Am 10. November 2016 09:17:24 MEZ, schrieb Philipp Marek 
:
>Package: aufs-dkms
>Version: 4.8+20161010-1
>Severity: normal
>
>I tried to enable the NFS export by setting
>))n see e
>CONFIG_AUFS_EXPORT = y
>
>but that breaks the build:
>
>/var/lib/dkms/aufs/4.8+20161010/build/fs/aufs/export.c:28:25: fatal
>error: ../fs/mount.h: File or directory not found
>
>
>-- System Information:
>Debian Release: stretch/sid
>  APT prefers testing
>APT policy: (500, 'testing'), (500, 'stable'), (200, 'unstable'), (100,
>'experimental')
>Architecture: amd64 (x86_64)
>
>Kernel: Linux 4.8.0-1-amd64 (SMP w/8 CPU cores)
>Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8)
>Shell: /bin/sh linked to /bin/dash
>
>Versions of packages aufs-dkms depends on:
>ii  dkms  2.3-1
>
>Versions of packages aufs-dkms recommends:
>ii  aufs-tools  1:4.1+20161010-1
>
>Versions of packages aufs-dkms suggests:
>pn  aufs-dev  
>
>-- no debconf information
>
>-- debsums errors found:
>debsums: changed file /usr/src/aufs-4.8+20161010/config.mk (from
>aufs-dkms package)
>
>___
>Filesystems-devel mailing list
>filesystems-de...@lists.alioth.debian.org
>http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/filesystems-devel

Bug#799281: [Mailman-Developers] Let's try to package mailman3 in Debian!

[Jan Luca Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Pierre-Elliott Bécue,

what is the current status of your packaging intend. Since I did not
the WNPP-list very well I started another ITP (that I closed of course
now) and maybe we can work together and/or I can take over some of the
work.

Best regards,
Jan

On Fri, 19 Feb 2016 11:26:15 +0100 Pierre-Elliott
=?iso-8859-1?Q?B=E9cue?=  wrote:
> 
> Hello!
> 
> Before requesting for sponsorship, and packaging officially the
> other components of mailman3, I'd like some "testers" for the core
> package I built, in order to be sure that it works, and that I will
> not introduce some stupid caveats on the packaging of the other
> components.
> 
> .deb can be found here:
> http://peb.pimeys.fr/mailman/mailman3-core/ git repo can be found
> there: https://gitlab.pimeys.fr/PEB/mailman3-core and there:
> https://github.com/P-EB/mailman3-core
> 
> Any volunteer welcome! Please, I need your help, I cannot review my
> work alone! :)
> 
> -- PEB
> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJYIOctAAoJEH4R1/EZ+XG7QdEQAKvSTrZeexBJLZnHXddRxCW+
W5HUxJryZvQiu73cw5w/1ra008bjWZOHzCD+oj9WdbxrKE+QFf46Zl+gFEfQO2Qf
+nNHjZIxzwK5UFrw119lhxqTrALoaJs7FgoWxnA98v0wXQ9UdXcmve7HA4fVIAOS
uL5tvybnj+SLUpw7/VPEgl1SGdhOrcRQD5m/6notmR+2JgRfYCzvptoNxv4uDGD4
ZEV/t+BxJsMuv4mS9l+mZLN6FoOBaq+Wwd9w3/Vea9npxliIFRJ54Zp0nT+uhzjG
Uyhepw4/qgRAj1hBDx+UnKwn84qd1YsTJ9LzPqMJg48LBR58bt+y5d6hX8MFpfAW
NG2aunZlwj/i7/J1uvkYJTXA/1VLtBxaWHuR2jjAQVvFjnEPHBquNSIUqinl2hv/
d+xSCnx8OGDUG231uWYiQAZWhXUGy3eyEjJjpEiyKTQyhW0msgxow9IozdVpKURY
wBcykEpa815YDfzCtHOYtdGziTEHq6Z2mGEc1kbCd9q51b7fsSMeABr7pxqyDcyA
Y5csXo9PsrdSg10a5USn29kTZiiE3V7jiiK/q6HUpcochAn2ebyE1sDea2m8HDMc
FHEJ4wlWQwRqbJ/D2PwnoZUTXyA8oe8AJTqKKqAWHLhO2qWEm9WOIf1wZ8efiyzx
K32qAoT/7AAazKn8puGY
=2jY1
-END PGP SIGNATURE-

Bug#843546: ITP: python-mailman -- Core module for Mailman3

[Jan Luca Naumann]

Package: wnpp
Severity: wishlist
Owner: Jan Luca Naumann <j.naum...@fu-berlin.de>

* Package name: python-mailman
  Version : 3.1.0
  Upstream Author : the Free Software Foundation, Inc.
* URL : https://gitlab.com/mailman/mailman
* License : GPL-3+
  Programming Lang: Python
  Description : Core module for Mailman3

Mailman is free software for managing electronic mail discussion
and e-newsletter lists. Mailman is integrated with the web,
making it easy for users to manage their accounts and for list
owners to administer their lists. Mailman supports built-in
archiving, automatic bounce processing, content filtering,
digest delivery, spam filters, and more.

This packages installs the core module for the new Mailman3
version.

Bug#842682: mp3splt: depending libmp3splt version not available yet (0.7.3 vs 0.9.2)

[Jan Luca Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Sorry, forgot to add a description in the message before: The bug
should be closed in version 2.6.2-0.1

Best regards,
Jan

On Mon, 31 Oct 2016 11:39:10 +0100 der_...@opentrash.com wrote:
> Package: mp3spltVersion: 2.4.2-2mp3splt in sid depends on version
> of libmp3splt0 (0.7.3~) that is not longer available in sid
> (0.9.2-0.1):#LANG=C apt install -s mp3spltReading package lists...
> DoneBuilding dependency tree
> Reading state information... DoneSome packages could not be
> installed. This may mean that you haverequested an impossible
> situation or if you are using the unstabledistribution that some
> required packages have not yet been createdor been moved out of
> Incoming.The following information may help to resolve the
> situation:The following packages have unmet
> dependencies:mp3splt : Depends: libmp3splt0 ( 0.7.3~) but
> 0.9.2-0.1 is to be installedE: Unable to correct problems, you have
> held broken packages.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJYGy/DAAoJEH4R1/EZ+XG7wWsQAI8cYe23AZWj4OZw5enNZ/yp
BHqJcJAsOuiEZMfEsYmlO6lUuAD3HZ0rnacvVfSoa4ewmbdPdNAvg5gqNLlNSZdp
rkryIRf6PNgDy6YRoSJSgWiWcRdxmB5JAaknfD6nnDtjzE+vda2vsO3eITTjCyt8
hhXekb2wVj/OTUQUpcTJWM0aaAsIim/LbnOI40UfaFiVkutkT4ME0COZJIVVONcT
IdLTfrpDIjhA5N7UvrQMrT4E0cQn/Icmj8eezSEA6/fLlSk5E6TeGEYpXXcdLWEv
/46h0ZIGcHA5hDE+2VLIWCnHDh+DKWRco0Xwck1jaQ3d1pGjtdnUcAihXP5/GOwZ
0zbRUNUkuqk4VpfhSP4hO1B3rdPeYi74RBOnYbZ0Lm62ab22smvUVYexQXenEGLn
a7OOuplhYSc1X2HOTG04gkmN5GpyQnlR+v2B5NzFEVbLkM9JBMvUwG58h4+GsABl
Mk/6kaYsD3ANPywhxBsR37Y1pISebYvdE+6U3CYXZCN69r7I2/R8YGrYpXl1Y8NM
KlgrYpLnzBCBXl7N9wWxM8X7oMgQttv86LYhzQK8kK6lZFJM9qDREi7HAz0ZPMgk
HyrMxSawfSTAoiRFPz6GgJcOwnQUrci8dC9EDfBRESneK9r3ZbP41SqZttC3tRrZ
RieLMUIRrBNqfP1a7QR0
=Nz8q
-END PGP SIGNATURE-

Bug#741164: fixed in mp3splt 2.6.2-0.1

[Jan Luca Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hey,

I can take a look on it and try to get it back to the archive again.

Best regards,
Jan

Am 02.11.2016 um 08:07 schrieb Amr Ibrahim:
> Thanks Jan for the update. Are you planning to update mp3splt-gtk
> also? https://tracker.debian.org/pkg/mp3splt-gtk
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJYGgW9AAoJEH4R1/EZ+XG7bo4QAL8iomY6XFS7XznSnsRjiL1Y
cicnH0oofcUC2kw1I33VJyuY0EooS7P2H9li23RkeTb9ojWIlROd9T32HRykMKIF
NhUwSpnle+3qEK3/IDYK9JMu3rnbbLvif3fMbMc309T6KZJc/9i9Fub7Zg7+PtjI
Ojx8XsKXTz8U4X/+HNZ/1CgeQRDbvAbH5Wa1UKNfvPjKklg/lDypl4wa/VDvwC+h
Txm7l91jXVnLJCiF64VhXP7F0H0is0t1D+wK/IjSEvim0tvc1Z4h4VSlfZjV0C6Y
8gjkNyFcBJuDCYOyxPpzRX/X0Iz+ACpdRLq4PyXCQ/BgEgPC+DXit2//6X4+mNrR
K4Pkz/quQQHg+IH1uWp1JCpo7za97F3EjsdECc2MXq2hlJlq6qI56evOUvJ/z2+S
l8B12qaJCYcOBsmWvUuCBClBeJQdxPPBnvRYpNrakHiaw/TFza2S4W1t/GWpMH9R
7qYVKL6pPDfDrl42YSwQSv8Jlf2tijtdJv9XrhvbzcorGaTldK3HZqDSQQ+xZP59
7RO3Xs5sLQM9gjTUZ3F8QLQhzpVHdJCg1bnd5ARMqHCHpz909NEirV6x4kwBUJoZ
yA87WX4RA2KnZkbI5ri7SG/nognPXaj9VIhdm3QhCfFw1b7jV4MWA+EyYF/bsLUs
vuCb7q62hWOWQWQhloN2
=+BrY
-END PGP SIGNATURE-

Bug#842162: ITP: anything-sync-daemon -- Anything-sync-daemon (asd) is a tiny pseudo-daemon designed to manage user specified directories referred to as sync targets from here on out, in tmpfs and to

[Jan Luca Naumann]

Package: wnpp
Severity: wishlist
Owner: Jan Luca Naumann <j.naum...@fu-berlin.de>

* Package name: anything-sync-daemon
  Version : 5.83
  Upstream Author : graysky <gray...@archlinux.us>
* URL : https://github.com/graysky2/anything-sync-daemon
* License : Expat
  Programming Lang: Bash
  Description : Sync user specified directories into RAM

Anything-sync-daemon (asd) is a tiny pseudo-daemon designed to
manage user specified directories referred to as sync targets
from here on out, in tmpfs and to periodically sync them back to
the physical disc (HDD/SSD). This is accomplished via a symlinking step
and an innovative use of rsync to maintain synchronization between a
tmpfs copy and media-bound backups. Additionally, asd features several
crash recovery features.

Bug#741164: mp3splt: Please update to current version 2.6

[Jan Luca Naumann]

Hey,

I would like to help with the package and want to upload a NMU with a
new version to mentors.debian.net.

Best regards,
Jan



signature.asc
Description: OpenPGP digital signature

Bug#754159: New upstream release available: 0.9.1

[Jan Luca Naumann]

Hey,

I would like to help with the package and want to upload a NMU with a
new version to mentors.debian.net.

Best regards,
Jan



signature.asc
Description: OpenPGP digital signature

Bug#835521: RFP: nitrokey-app -- Application to manage the nitrokey

[Jan Luca Naumann]

Hey Guido,

the tool looks interesting, I will package it for Debian :-)

Best regards,
Jan

On Fri, 26 Aug 2016 15:27:01 +0200 Guido =?iso-8859-1?Q?G=FCnther?=
 wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: nitrokey-app
>   Version : 0.4.26
>   Upstream Author : Szczepan Zalega 
> * URL : https://github.com/Nitrokey/nitrokey-app
> * License : GPL-3.0+
>   Programming Lang: C++
>   Description : Application to manage the nitrokey
> 
> The nitro key adds a tray icon that shows if the nitrokey is
> inserted. It also allows changing pins.
> 
> There is an upstream backacke one could work from.
> 
> 



signature.asc
Description: OpenPGP digital signature

Bug#839049: /usr/bin/profile-sync-daemon: line 359: ${#DIRArr @ ##*/}: bad substitution

[Jan Luca Naumann]

Control: tags -1 = upstream pending

Thank you for forwarding the upstream bug report. I will upload a Debian
version with the patch applied soon.

Jan

Am 28.09.2016 um 21:27 schrieb Ian Kelling:
> I hit this bug, and submitted a fix upstream:
> https://github.com/graysky2/profile-sync-daemon/pull/185
> It's just a few characters, you can do it manually until
> it makes it into the package.
> 



signature.asc
Description: OpenPGP digital signature

Bug#839049: /usr/bin/profile-sync-daemon: line 359: ${#DIRArr[@]##*/}: bad substitution

[Jan Luca Naumann]

Tags: unreproducible

Hey Brent,

I tried to reproduce your problem but at my test system I do not get this
error message. The steps I tried to reproduce the problem are:

1) Install "profile-sync-daemon" on Debian unstable
2) Run "profile-sync-daemon parse" with the resulting message "First time
running psd so please edit /home/jan/.config/psd/psd.conf to your liking
and run again."
3) Enable the usage of overlayfs by uncomment the line
'USE_OVERLAYFS="yes"' in /home/jan/.config/psd/psd.conf
4) Run "profile-sync-daemon parse" again with the resulting message
"ERROR! To use overlayfs mode, jan needs sudo access to
/usr/bin/psd-overlay-helper [...]"
5) Edit the /etc/sudoers file as described
6) Run "profile-sync-daemon parse" again without any error message.

Did you do some other steps I have not done? Do you use "/bin/bash" as
shell or something else?

I hope we find the cause of your problem.

Best regards,
Jan

> Package: profile-sync-daemon
> Version: 6.25-1
> Severity: normal
>
> Dear Maintainer,
>
> I first got this message:
>
> bclark@bclark:~$ profile-sync-daemon parse
>  ERROR! To use overlayfs mode, bclark needs sudo access to /usr/bin/psd-
> overlay-helper
>
>  Add the following line to the end of /etc/sudoers to enable this
> functionality:
>   bclark ALL=(ALL) NOPASSWD: /usr/bin/psd-overlay-helper
>
> I what was suggested, and then run:
>
> bclark@bclark:~$ profile-sync-daemon parse
> /usr/bin/profile-sync-daemon: line 359: ${#DIRArr[@]##*/}: bad
> substitution
>
> Kind Regards
> Brent Clark
>
>
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.7.0-1-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_ZA.utf8, LC_CTYPE=en_ZA.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages profile-sync-daemon depends on:
> ii  rsync  3.1.1-3
>
> profile-sync-daemon recommends no packages.
>
> Versions of packages profile-sync-daemon suggests:
> ii  libpam-systemd  231-7
> ii  systemd-sysv231-7
>
> -- no debconf information
>

Bug#788513: aufs-tools: FTBFS: linux/aufs_type.h: No such file or directory

[Jan Luca Naumann]

Hey.

there is already another bug about this topic:
https://bugs.debian.org/838632

I already started to prepare a upload to fix this issue.

Best regards,
Jan

> Hey.
>
> Is it really necessary that the userland tools binary package depends
> on the kernel driver package?
>
> That seems to be rather uncommon among similar packages...
>
> Cheers,
> Chris.

Bug#772190: Debian bug reports for aufs-utils

[Jan Luca Naumann]

Hey,

in Debian there are two open bugs for aufs-utils that belongs to the
upstream code:

1. https://bugs.debian.org/772190
2. https://bugs.debian.org/777559 (contains patch)

Both reported problems seem not to be fixed in the current version yet
so you want to fix them maybe :-)

Best regards,
Jan



signature.asc
Description: OpenPGP digital signature

Bug#834764: linux: Please update aufs4-patches to latest version

[Jan Luca Naumann]

Source: linux
Version: 4.7_rc7-1_exp1
Severity: wishlist

Hey,

I'm packaging aufs4 for Debian at the moment. It would be very nice if you
could update the aufs4 kernel-patches applied by Debian to the latest version
(seems to be "4.6-20160815" and "4.7-20160815" at the moment).

Thank you,
Jan

Bug#833135: profile-sync-daemon fails to work properly after system crash

[Jan Luca Naumann]

Dear Michael,

I have forwarded your bug to upstream:
https://github.com/graysky2/profile-sync-daemon/issues/178

It would be nice if you can provide some more informations in the
upstream bug report, for more informations see responses of upstream
author graysky).

Thank you and best regards,
Jan

Am 01.08.2016 um 11:42 schrieb Michael Meier:
> Package: profile-sync-daemon
> Version: 6.25-1
> Severity: important
> 
> After a system crash (or blackout), profile-sync-daemon doesn't work properly 
> anymore, when using the overlay filesystem.
> It does not sync any changes back anymore, maynly because of following 
> message:
> 
> Aug  1 11:20:57 RMMbook profile-sync-daemon[5565]: ln: failed to create 
> symbolic link '/home/rmm/.mozilla/firefox/rk7hh7a0.default/null': File exists
> Aug  1 11:20:57 RMMbook profile-sync-daemon[5565]: mv: cannot overwrite 
> directory '/home/rmm/.mozilla/firefox/rk7hh7a0.default-backup' with 
> non-directory
> Aug  1 11:21:04 RMMbook profile-sync-daemon[5565]: #033[01mfirefox resync 
> successful#033[00m
> Aug  1 11:21:04 RMMbook profile-sync-daemon[5565]: #033[01mfirefox unsync 
> successful#033[00m
> 
> It says it is successfull, but in reality it didn't sync changes back, also 
> the mounts still exist even after ending the daemon.
> After deleting that null file, things seem to work again. I'm not sure what 
> that "non-directory" message has to do with everything.
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (900, 'testing'), (800, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.6.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 profile-sync-daemon depends on:
> pn  rsync  
> 
> profile-sync-daemon recommends no packages.
> 
> Versions of packages profile-sync-daemon suggests:
> ii  libpam-systemd  230-7
> ii  systemd-sysv230-7
> 
> -- no debconf information
> 



signature.asc
Description: OpenPGP digital signature

Bug#832451: ITP: aufs4 -- advanced multi layered unification filesystem version 4.x

[Jan Luca Naumann]

Am 26.07.2016 um 02:07 schrieb Ben Hutchings:
> On Mon, 2016-07-25 at 21:05 +0200, Thomas Goirand wrote:
>> We have already overlayfs in modern kernels. Could you explain why we
>> need aufs4 as well?
> 
> I believe aufs stil has these advantages over overlayfs:
> 
> - Can be exported via NFS
> - White-outs share an inode rather than
> requiring an inode each
> - Sparse files remain sparse when copied-up
> -
> Multiple writeable branches
> - Creating a hard link does not require a
> copy-up
> 
> Ben.

Ben summarized better than I could the still existing advantages of
aufs. In a production setup I administrate, we particularly use the NFS
feature.

Jan.



signature.asc
Description: OpenPGP digital signature

Bug#832359: linux-kbuild-4.6: Please include "scripts/headers_install.sh" and "scripts/unifdef", needed by "scripts/Makefile.headersinst"

[Jan Luca Naumann]

Am 26.07.2016 um 02:10 schrieb Ben Hutchings:
> On Sun, 2016-07-24 at 17:10 +0200, Jan Luca Naumann wrote:
>> Package: linux-kbuild-4.6
>> Version: 4.6.4-1
>> Severity: normal
>>
>> In linux-kbuild-* the Makefile "scripts/Makefile.headersinst" is included.
>> The Makefile needs the shell script "scripts/headers_install.sh" which is
>> not included in the current version of linux-kbuild-4.6. 
>>
>> Can you please include this script "scripts/headers_install.sh" and the tool
>> "scripts/unifdef" (needed by scripts/headers_install.sh) in the package?
> 
> linux-kbuild exists to support building out-of-tree modules, for which
> I believe this Makefile is never needed.
> 
> Ben.
> 

The Makefile is used by aufs4, see end of following file:
https://github.com/sfjro/aufs4-standalone/blob/aufs4.6/Makefile

In the course of packaging this module I found the problem that the two
scripts are missing in the current linux-kbuild.

Jan



signature.asc
Description: OpenPGP digital signature

Bug#723594: ITA: aufs-tools -- Tools to manage aufs filesystems

[Jan Luca Naumann]

On Tue, 17 Sep 2013 21:25:38 +0200 Luk Claes  wrote:
> Package: wnpp
> Severity: normal
> 
> Hi
> 
> As I've lost interest in the package, I'm looking for a new maintainer for 
> aufs-tools and some other filesystem related packages.
> 
> Cheers
> 
> Luk
> 
> 

Hey,

in course of the packaging of aufs4 (see bug #832451), I'm also
intending to maintain the aufs-tools in the new version 4.x.

Best regards,
Jan



signature.asc
Description: OpenPGP digital signature

Bug#832451: ITP: aufs4 -- advanced multi layered unification filesystem version 4.x

[Jan Luca Naumann]

Package: wnpp
Severity: wishlist
Owner: Jan Luca Naumann <j.naum...@fu-berlin.de>

* Package name: aufs4
  Version : 4.6+20160523
  Upstream Author : Junjiro R. Okajima <hooanon...@gmail.com>
* URL : http://aufs.sourceforge.net/
* License : GPL2+
  Programming Lang: C
  Description : advanced multi layered unification filesystem version 4.x

Aufs is a stackable unification filesystem such as Unionfs, which unifies
several directories and provides a merged single directory.
In the early days, aufs was entirely re-designed and re-implemented
Unionfs Version 1.x series. After
many original ideas, approaches and improvements, it
becomes totally different from Unionfs while keeping the basic features.
See Unionfs Version 1.x series for the basic features.
Recently, Unionfs Version 2.x series begin taking some of same
approaches to aufs's.

I'm intending to package the version 4.x for Debian. The module
should use dkms to be build as kernel module.

I hope to do the work as part of the filesystems project on Alioth:
https://alioth.debian.org/projects/filesystems/

I need a sponsor for the package.

Bug#832359: linux-kbuild-4.6: Please include "scripts/headers_install.sh" and "scripts/unifdef", needed by "scripts/Makefile.headersinst"

[Jan Luca Naumann]

Package: linux-kbuild-4.6
Version: 4.6.4-1
Severity: normal

In linux-kbuild-* the Makefile "scripts/Makefile.headersinst" is included.
The Makefile needs the shell script "scripts/headers_install.sh" which is
not included in the current version of linux-kbuild-4.6. 

Can you please include this script "scripts/headers_install.sh" and the tool
"scripts/unifdef" (needed by scripts/headers_install.sh) in the package?

Thank you,
Jan

Bug#827127: ITP: profile-sync-daemon -- Symlinks and syncs browser profile dirs to RAM thus reducing HDD/SDD calls and speeding-up browsers.

[Jan Luca Naumann]

Package: wnpp
Severity: wishlist
Owner: Jan Luca Naumann <j.naum...@fu-berlin.de>

* Package name: profile-sync-daemon
  Version : 6.22
  Upstream Author : graysky <gray...@archlinux.us>
* URL : https://github.com/graysky2/profile-sync-daemon
* License : MIT
  Programming Lang: Bash
  Description : Symlinks and syncs browser profile dirs to RAM thus 
reducing HDD/SDD calls and speeding-up browsers.

Profile-sync-daemon (psd) is a tiny pseudo-daemon designed to manage your 
browser's profile in tmpfs and to periodically sync it back to your physical 
disc (HDD/SSD). This is accomplished via a symlinking step and an innovative 
use of rsync to maintain back-up and synchronization between the two. One of 
the major design goals of psd is a completely transparent user experience.

For more information see 
https://wiki.archlinux.org/index.php/Profile-sync-daemon


I need a sponsor for the package to upload it to Debian.

Bug#825864: ITP: sedutil -- Tool to use functionality of Self Encrypting Drives (SED) that comply with the TCG OPAL 2.00 standard

[Jan Luca Naumann]

Package: wnpp
Severity: wishlist
Owner: Jan Luca Naumann <j.naum...@fu-berlin.de>

* Package name: sedutil
  Version : 1.12
  Upstream Author : Bright Plaza Inc. <drivetr...@drivetrust.com>, r0m30 
<r0...@r0m30.com>
* URL : https://github.com/Drive-Trust-Alliance/sedutil
* License : GPL
  Programming Lang: C++
  Description : Tool to use functionality of Self Encrypting Drives (SED) 
that comply with the TCG OPAL 2.00 standard

Tool to use functionality of Self Encrypting Drives (SED) that comply with the 
TCG OPAL 2.00 standard. 

The tool includes a Pre-Boot Authorization image to unlock the drive 
independently of the BIOS functions.

The package allows users to use their OPAL disks with free software.

I need a sponsor for the package to upload it to Debian.

Bug#796163: dracut: Moving aufs module from dracut-network to dracut causes Trying to overwrite ... error

[Jan Luca Naumann]

Package: dracut
Version: 043-1+zedv1
Severity: normal

Using the current version 043-1 from unstable causes error trying to overwrite
'/usr/lib/dracut/modules.d/90aufs/aufs-mount.sh', which is also in package 
dracut-network 040+1-1
when upgrading the package from version 040+1-1.

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

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

Versions of packages dracut depends on:
ii  console-setup  1.123
ii  cpio   2.11+dfsg-4.1
ii  kmod   18-3
ii  kpartx 0.5.0-6+deb8u1
ii  libc6  2.19-18
ii  pkg-config 0.28-1
ii  udev   215-17+deb8u1
ii  util-linux 2.25.2-6

Versions of packages dracut recommends:
ii  cryptsetup  2:1.6.6-5
ii  dmraid  1.0.0.rc16-5
ii  dmsetup 2:1.02.90-2.2
ii  lvm22.02.111-2.2
ii  mdadm   3.3.2-5

Versions of packages dracut suggests:
ii  dracut-network  043-1+zedv1

-- no debconf information

Bug#778615: installation-reports: Lenovo T61 8889-B35 NVIDIA G86M Quadro NVS 140M

[Jan Luca Naumann]

Package: installation-reports
Severity: normal

Dear Maintainer,

installation, wethernet, wireless and brightness controll works without any 
problems.

There is a problem with graphics when waking up from suspend, I will fill in a 
seperate bug report upstream.

-- Package-specific info:

Boot method: CD
Image version: 
http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/jessie_di_beta_2/amd64/iso-cd/firmware-jessie-DI-b2-amd64-netinst.iso
Date: Date and time of the install

Machine: Lenovo T61 8889-B35 NVIDIA G86M Quadro NVS 140M
Partitions: 
DateisystemTyp  1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
/dev/sda1  ext4 88776 5925684  995919766% /
udev   devtmpfs 10240   0 102400% /dev
tmpfs  tmpfs   40490861163987922% /run
tmpfs  tmpfs  1012268  80   10121881% /dev/shm
tmpfs  tmpfs 5120   4  51161% /run/lock
tmpfs  tmpfs  1012268   0   10122680% /sys/fs/cgroup
tmpfs  tmpfs   202456   42024521% /run/user/1000
tmpfs  tmpfs   202456  122024441% /run/user/119


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:

Description of the install, in prose, and any thoughts, comments
  and ideas you had during the initial install.


-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION=Debian GNU/Linux installer
DISTRIB_RELEASE=8 (jessie) - installer build 20141002
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux znote-t61-03 3.16-2-amd64 #1 SMP Debian 3.16.3-2 (2014-09-20) 
x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Mobile 
PM965/GM965/GL960 Memory Controller Hub [8086:2a00] (rev 0c)
lspci -knn: Subsystem: Lenovo Device [17aa:20b1]
lspci -knn: 00:01.0 PCI bridge [0604]: Intel Corporation Mobile 
PM965/GM965/GL960 PCI Express Root Port [8086:2a01] (rev 0c)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:19.0 Ethernet controller [0200]: Intel Corporation 82566MM 
Gigabit Network Connection [8086:1049] (rev 03)
lspci -knn: Subsystem: Lenovo Device [17aa:20b9]
lspci -knn: Kernel driver in use: e1000e
lspci -knn: 00:1a.0 USB controller [0c03]: Intel Corporation 82801H (ICH8 
Family) USB UHCI Controller #4 [8086:2834] (rev 03)
lspci -knn: Subsystem: Lenovo Device [17aa:20aa]
lspci -knn: Kernel driver in use: uhci_hcd
lspci -knn: 00:1a.1 USB controller [0c03]: Intel Corporation 82801H (ICH8 
Family) USB UHCI Controller #5 [8086:2835] (rev 03)
lspci -knn: Subsystem: Lenovo Device [17aa:20aa]
lspci -knn: Kernel driver in use: uhci_hcd
lspci -knn: 00:1a.7 USB controller [0c03]: Intel Corporation 82801H (ICH8 
Family) USB2 EHCI Controller #2 [8086:283a] (rev 03)
lspci -knn: Subsystem: Lenovo Device [17aa:20ab]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation 82801H (ICH8 Family) 
HD Audio Controller [8086:284b] (rev 03)
lspci -knn: Subsystem: Lenovo Device [17aa:20ac]
lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) 
PCI Express Port 1 [8086:283f] (rev 03)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.1 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) 
PCI Express Port 2 [8086:2841] (rev 03)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.2 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) 
PCI Express Port 3 [8086:2843] (rev 03)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.3 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) 
PCI Express Port 4 [8086:2845] (rev 03)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.4 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) 
PCI Express Port 5 [8086:2847] (rev 03)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1d.0 USB controller [0c03]: Intel Corporation 82801H (ICH8 
Family) USB UHCI Controller #1 [8086:2830] (rev 03)
lspci -knn: Subsystem: Lenovo Device [17aa:20aa]
lspci