Bug#901194: jessie-pu: package openldap/2.4.40+dfsg-1+deb8u4

[Ryan Tandy]

On Wed, Jun 13, 2018 at 07:13:24PM +0100, Adam D. Barratt wrote:

Please go ahead.


Thank you. Uploaded and accepted.

Bug#901192: stretch-pu: package openldap/2.4.44+dfsg-5+deb9u2

[Ryan Tandy]

On Wed, Jun 13, 2018 at 07:14:24PM +0100, Adam D. Barratt wrote:

Please go ahead.


Thank you. Uploaded and accepted.

Bug#901494: ITP: erlang-erlware-commons -- Erlware common libraries

[Nobuhiro Iwamatsu]

Package: wnpp
Owner: Nobuhiro Iwamatsu 
Severity: wishlist

* Package name: erlang-erlware-commons
  Version : 1.0.0
  Upstream Author : Erlware, LLC
* URL : https://github.com/erlware/erlware_commons
* License : Expat
  Programming Lang: Erlang
  Description : Erlware common libraries

 Erlware commons  provides extensions to the stdlib application distributed
 in Erlang. The functions provided by this are used in Erlware's production
 application.

Bug#750697: Reassigning to php-pear

[Mathieu Parent]

Control: reassign -1 php-pear
Control: affects -1 pkg-php-tools

As per comment #12.

Regards
-- 
Mathieu Parent

Bug#895868: Probably #853848

[Jim Paris]

This is probably https://bugs.debian.org/853848, fixed by upgrading/removing:
  fonts-beng-extra
  fonts-deva-extra
  fonts-gujr-extra
  fonts-guru-extra
  fonts-orya-extra

Jim

Bug#901136: can't remove if install fails

[KAction]

[2018-06-14 00:32] Wouter Verhelst 
> Hi,

Hi!

> On Wed, Jun 13, 2018 at 03:21:11AM +0300, kact...@gnu.org wrote:
> > I never worked with NSS, but how did it happen, that useradd {in postinst}
> > created user in a way, that userdel {in prerm} could not find?
> 
> That's not what happened.
> 
> The sreview user already existed before the sreview-common package was
> installed, but it did not exist in /etc/passwd; instead, it existed in a
> different location, configured through an NSS module.

Am I correct, some time ago it was created by previous version of maintainer 
script,
when I did not use dh-sysuser?

> The easiest way for you to test this is probably to install libnss-db,
> change the value of ETC in /etc/default/libnss-db to some other
> directory and cull the DBS value so it contains just passwd, then create
> a file called "passwd" in the directory that you pointed ETC to, run
> "make -C /var/lib/misc", and add "db" to /etc/nsswitch.conf on the
> "passwd" line.
> 
> Meanwhile, I'm going to have to implement it properly and remove
> dh_sysuser from my build-depends. Ah well.

So sad. Maybe you could suggest what should I use instead of 'useradd/userdel'
in sysuser-helper to make dh-sysuser also work with NSS?

Bug#901484: targetcli aborts with the error message "NameError: name 'readline' is not defined" when running in interactive shell mode

[Ritesh Raj Sarraf]

Control: tag -1 +confirmed, pending


Oh! I looked at the newer unreleased sources in our repository. This
fix is included in the latest import that Christophe has prepared,
currently pending an upload to the repository.

python-configshell-fb (1.1.24-1) UNRELEASED; urgency=medium

  * New upstream version.

 -- Christophe Vu-Brugier   Sun, 28 Jan 2018 18:03:36 
+0100


On Thu, 2018-06-14 at 10:21 +0545, Ritesh Raj Sarraf wrote:
> Control: tag -1 +moreinfo
> 
> On Wed, 2018-06-13 at 17:06 -0400, Matt Coleman wrote:
> > Error Output:
> > 
> > Traceback (most recent call last):
> >   File "/usr/lib/python3/dist-packages/configshell_fb/shell.py",
> > line
> > 893, in run_interactive
> > old_completer = readline.get_completer()
> > NameError: name 'readline' is not defined
> > 
> > During handling of the above exception, another exception occurred:
> > 
> > Traceback (most recent call last):
> >   File "/usr/bin/targetcli", line 121, in 
> > main()
> >   File "/usr/bin/targetcli", line 111, in main
> > shell.run_interactive()
> >   File "/usr/lib/python3/dist-packages/configshell_fb/shell.py",
> > line
> > 899, in run_interactive
> > readline.set_completer(old_completer)
> > NameError: name 'readline' is not defined
> >  in /home/matt/reproduce/vendor/symfony/ in
> > /home/matt/reproduce/vendor/symfony/symfony/src/Symfony/Component/P
> > ro
> > cess/Process.php on line 239
> 
> I think there may be something non-standard in your setup.
> 
> Because:
> 
> if sys.stdout.isatty():
> import readline
> tty=True
> else:
> tty=False
> 
> # remember the original setting
> oldTerm = os.environ.get('TERM')
> os.environ['TERM'] = ''
> 
> import readline
> 
> # restore the orignal TERM setting
> if oldTerm != None:
> os.environ['TERM'] = oldTerm
> del oldTerm
> 
> In either case, readline needs to be imported.
> 
> readline supported is provided through package libpython2.7-
> stdlib:amd64 for Python2.
> 
> @Matt:
> 
> Are you able to import the readline module on the standard python
> interpreter ?
> 
> Here, on my setup, I can:
> 
> $ ipython
> Python 2.7.15 (default, May  1 2018, 05:55:50) 
> Type "copyright", "credits" or "license" for more information.
> 
> IPython 5.5.0 -- An enhanced Interactive Python.
> ? -> Introduction and overview of IPython's features.
> %quickref -> Quick reference.
> help  -> Python's own help system.
> object?   -> Details about 'object', use 'object??' for extra
> details.
> [TerminalIPythonApp] WARNING | File not found: '/home/rrs/.pythonrc'
> 
> In [1]: import readline
> 
> In [2]: help(readline)
> 
> 
> In
> [3]: 
>
> Do you really want to exit ([y]/n)? 
> 10:17 ♒♒♒   ☺ 
> 
> 
-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System

signature.asc
Description: This is a digitally signed message part

Bug#901484: targetcli aborts with the error message "NameError: name 'readline' is not defined" when running in interactive shell mode

[Ritesh Raj Sarraf]

Control: tag -1 +moreinfo

On Wed, 2018-06-13 at 17:06 -0400, Matt Coleman wrote:
> Error Output:
> 
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/configshell_fb/shell.py", line
> 893, in run_interactive
> old_completer = readline.get_completer()
> NameError: name 'readline' is not defined
> 
> During handling of the above exception, another exception occurred:
> 
> Traceback (most recent call last):
>   File "/usr/bin/targetcli", line 121, in 
> main()
>   File "/usr/bin/targetcli", line 111, in main
> shell.run_interactive()
>   File "/usr/lib/python3/dist-packages/configshell_fb/shell.py", line
> 899, in run_interactive
> readline.set_completer(old_completer)
> NameError: name 'readline' is not defined
>  in /home/matt/reproduce/vendor/symfony/ in
> /home/matt/reproduce/vendor/symfony/symfony/src/Symfony/Component/Pro
> cess/Process.php on line 239

I think there may be something non-standard in your setup.

Because:

if sys.stdout.isatty():
import readline
tty=True
else:
tty=False

# remember the original setting
oldTerm = os.environ.get('TERM')
os.environ['TERM'] = ''

import readline

# restore the orignal TERM setting
if oldTerm != None:
os.environ['TERM'] = oldTerm
del oldTerm

In either case, readline needs to be imported.

readline supported is provided through package libpython2.7-stdlib:amd64 for 
Python2.

@Matt:

Are you able to import the readline module on the standard python interpreter ?

Here, on my setup, I can:

$ ipython
Python 2.7.15 (default, May  1 2018, 05:55:50) 
Type "copyright", "credits" or "license" for more information.

IPython 5.5.0 -- An enhanced Interactive Python.
? -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help  -> Python's own help system.
object?   -> Details about 'object', use 'object??' for extra details.
[TerminalIPythonApp] WARNING | File not found: '/home/rrs/.pythonrc'

In [1]: import readline

In [2]: help(readline)


In [3]: 
   
Do you really want to exit ([y]/n)? 
10:17 ♒♒♒   ☺ 


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System

signature.asc
Description: This is a digitally signed message part

Bug#901493: ITP: erlang-cf -- Erlang/OTP library for termial colour printing

[Nobuhiro Iwamatsu]

Package: wnpp
Owner: Nobuhiro Iwamatsu 
Severity: wishlist

* Package name: erlang-cf
  Version : 0.3.1
  Upstream Author : Project-FiFo UG
* URL : https://github.com/project-fifo/cf
* License : BSD
  Programming Lang: Erlang
  Description : Erlang/OTP library for termial colour printing

 A Erlang/OTP helper library for termial colour printing extending the
 io:format syntax to add colours.

Bug#896684: Embedded in s6

[rondeauchandra1]

INSTALL NOW!
 Free app: 
https://play.google.com/store/apps/details?id=com.appsusu.EmbeddedSystemsTutorialSent
 from my Samsung Galaxy smartphone.

Bug#900936: Editing /etc/geoclue/geoclue.conf

[quentin g]

Adding the following lines to /etc/geoclue/geoclue.conf seems to be a good
workaround:

[redshift]
allowed=true
system=false
users=

I also have the demo agent installed, although I don't know if its important


-- 
My git repository:
https://github.com/freezeeedos

Bug#900936: Editing /etc/geoclue/geoclue.conf

[quentin g]

Also, here is the source of the workaround
https://github.com/jonls/redshift/issues/158

2018-06-14 5:08 GMT+02:00 quentin g :

> Adding the following lines to /etc/geoclue/geoclue.conf seems to be a good
> workaround:
>
> [redshift]
> allowed=true
> system=false
> users=
>
> I also have the demo agent installed, although I don't know if its
> important
>
>
> --
> My git repository:
> https://github.com/freezeeedos
>



-- 
My git repository:
https://github.com/freezeeedos

Bug#850926: foremost FTCBFS: important compiler flags cleared during cross builds

[Raúl Benencia]

tags 850926 + pending
thanks

Hi Helmut,

On Wed, Jan 11, 2017 at 11:13:26AM +0100, Helmut Grohne wrote:
> foremost fails to cross build from source, because it has a rather
> uncommon way to handle the CC variable and its assumptions on CC are
> broken by how dh_auto_build uses it. During cross compilation,
> dh_auto_build overrides CC with a cross compiler, but foremost stuffs
> all sorts of flags into CC. The proper way to cross compile foremost is
> overriding RAW_CC and leaving CC alone. The attached patch does just
> that. Please consider applying it.

Thanks for reporting this issue. This indeed is a problem, but the right thing
to do here is to fix the Makefile so it can accept the standard CFLAGS, CPPFLAGS
and LDFLAGS. I've actually prepared a patch for that, so it will be fixed soon.

Cheers,
Rul


signature.asc
Description: PGP signature

Bug#901134: RFS: anbox-modules/0.0~git20180608-1 [ITP]

[Shengjing Zhu]

On Thu, Jun 14, 2018 at 01:09:39AM +0100, Ben Hutchings wrote:
> On Wed, 2018-06-13 at 13:23 +0200, Adam Borowski wrote:
> > Hi Ben!
> > Could you please chime in to bug #901134 (RFS: anbox-modules)?
> > 
> > This package wants to ship redundant copies of two modules (ashmem and
> > binder) that are already in mainline since a long time ago.  This strikes me
> > as thoroughly wrong, yet I'm very ignorant about packaged kernels, thus I
> > can't offer good advice.
> 
> I agree, I don't think it makes much sense to build these OOT if they
> can be built in-tree.
>

Here goes the bug #901492 (linux: Please enable Android ashmem and binder 
module)

> The in-tree version of ashmem *cannot* be built as a module, though,
> which we would probably want to change.
> 

Don't have knowledge about this, but I'd like to see it built as module.


signature.asc
Description: PGP signature

Bug#901492: linux: Please enable Android ashmem and binder module

[Shengjing Zhu]

Source: linux
Severity: wishlist

Dear Maintainer,

Could you add Android ashmem and binder modules to config? These modules
are needed to run Android inside a container.

To run Android inside container, you can use something like Anbox[1].

Related bug is #884797 ITP: anbox -- Run Android applications on any GNU/Linux 
operating system
#901130 ITP: anbox-modules -- Android kernel driver (binder, ashmem) in DKMS 
format

This will obsolete #901130.

[1] https://github.com/anbox/anbox

Thanks
Shengjing Zhu


signature.asc
Description: PGP signature

Bug#901332: d-i: Offer to shut down / power off instead of reboot at the end

[Rick Thomas]

On Jun 12, 2018, at 8:56 PM, Ben Hutchings  wrote:

>> So, please, at the end, where it tells the reboot message, add
>> a third button that shuts down / powers off the system instead
>> of rebooting.
> 
> Still, I do agree that this would be useful in general.

Especially if it could be pre-seeded.

For example: Imagine setting up a bunch of machines all at once to be 
distributed to various locations after the install.  You can use pre-seeding to 
answer all the questions while you go off and get a cup of tea.  It might be 
better to have them all install then shutdown, rather than install then reboot 
— wasting power and requiring a manual shutdown before moving to the target 
location.

Rick

Bug#833692: pinot: links GPLv2+ code with OpenSSL

[Olly Betts]

On Thu, Jun 14, 2018 at 12:45:38AM +0200, Jonas Smedegaard wrote:
> I still like pinot and believe there is a use for it in Debian as 
> alternative to extract and tracker.  But evidently it keeps falling too 
> low on my priority list :-(
> 
> Please do adopt it.  Or co-maintain it with me, if you prefer that.

Sounds good.  I've made a start on preparing an upload.

It looks like the packaging was on collab-maint which has now gone - do
you have a checkout of it handy?  Not vital, but preserving the history
seems useful if it's easy to do.

Cheers,
Olly

Bug#901279: duplicate of bug #250626

[Greg Alexander]

Hi again - Sorry I had a problem and didn't check if this bug is already
listed.  It may be the same as bug #250626.  I'm not clear on how to
merge it so I'll leave that for someone else if it's appropriate.

However, this bug should not be given severity of "wishlist", it occurred
on a normal "apt-get update" package upgrade, and information was lost
for no reason.  I suppose the idea is that now we should treat grub.cfg
as output and instead put our configuration in /etc/grub.d.  But the fact
that we have not done this yet is no reason to delete our old
configuration!

For god's sake, simply make update-grub script "mv grub.cfg grub.cfg~"
before it overwrites it!  Arguing why it was appropriate to delete user
information is crap.

Thanks,
- Greg

Bug#901134: RFS: anbox-modules/0.0~git20180608-1 [ITP]

[Shengjing Zhu]

On Thu, Jun 14, 2018 at 8:09 AM Ben Hutchings  wrote:
[...]
> I do wonder what the value of enabling these as in-tree modules would
> be.  I don't think we package the many Android userspace services and
> libraries that would be needed to run Android apps.  So how would these
> modules be useful?  Is the idea to support running an Android system in
> a container?

Yes, there's no value for most people to have these two modules. It's
only used when you want to run Android in a container(most probably
you want to run some applications/games which only have mobile version
but no free alternative on Debian).
Anbox[1] is the approach to do this. If you want to test, you can have
a look at my other RFS(#901137). Also noted, anbox will be in contrib
area, since we don't have Android image(rootfs) in main.

[1] https://github.com/anbox/anbox


--
Best regards,
Shengjing Zhu

Bug#792394: vtund sends UDP socket number over the network in host order

[Greg Alexander]

severity 792394 important
tags 792394 patch ipv6

Hi!  I ran into this same problem.  The patch
07-dual-family-transport.patch changed it to use host order instead of
network order when sending the UDP port number to the remote host.

Background: When a vtun client connects, it first connects on a TCP port
and gets configuration.  If that configuration tells it to connect on a
UDP port, then there is a bidirectional exchange of UDP port numbers over
the TCP port just before closing the TCP socket.  This exchange is
supposed to happen in network byte order, but an oversight in the patch
caused it to happen in host byte order instead.

Discussion: This is a sticky problem because if you fix it, some small
number of users who had successfully upgraded both endpoints of a tunnel
to the same wrong version will experience difficulty.  The exposure is
somewhat limited by the fact that many users probably do not use UDP.
Also in our favor is that vtund is largely used for historical
compatibility (new Debian<=>Debian tunnels would probably use OpenVPN?)
by users who probably do not upgrade any more often than I do...

At any rate, the current situation is wrong.  Even modern Debian hosts
with different byte orders will be unable to talk to eachother.

Here's my patch, which is relative to the tree after an
"apt-get source vtun".  I'm confident in it (I'm using it right now), but
I'm sorry I don't really know anything about debian packaging so I just
hope this is useful for you guys..

Thanks! - Greg

diff -ur vtun-3.0.3.orig/netlib.c vtun-3.0.3/netlib.c
--- vtun-3.0.3.orig/netlib.c2018-06-13 20:11:33.0 -0400
+++ vtun-3.0.3/netlib.c 2018-06-13 20:30:01.0 -0400
@@ -224,18 +224,19 @@
  }
 
  /* Write port of the new UDP socket */
- port = get_port();
+ host->sopt.lport = get_port();
+ port = htons(host->sopt.lport);
  if( write_n(host->rmt_fd,(char *),sizeof(short)) < 0 ){
 vtun_syslog(LOG_ERR,"Can't write port number");
 return -1;
  }
- host->sopt.lport = htons(port);
 
  /* Read port of the other's end UDP socket */
  if( readn_t(host->rmt_fd,,sizeof(short),host->timeout) < 0 ){
 vtun_syslog(LOG_ERR,"Can't read port number %s", strerror(errno));
 return -1;
  }
+ port = ntohs(port);
 
  opt = sizeof(saddr);
  if( getpeername(host->rmt_fd,(struct sockaddr *),) ){
@@ -260,7 +261,7 @@
  is_rmt_fd_connected=1;
}
  
- host->sopt.rport = htons(port);
+ host->sopt.rport = port;
 
  /* Close TCP socket and replace with UDP socket */
  close(host->rmt_fd); 

Bug#901491: acbuild build-depends on cruft package golang-go.crypto-dev

[peter green]

Package: acbuild
Severity: serious

acbuild build-depends on golang-go.crypto-dev which is no longer built by 
golang-go.crypto, the replacement appears to be golang-golang-x-crypto-dev. I 
was able to succesfully do a build in raspbian bister with the build-dependency 
changed.

Bug#901134: RFS: anbox-modules/0.0~git20180608-1 [ITP]

[Ben Hutchings]

On Wed, 2018-06-13 at 13:23 +0200, Adam Borowski wrote:
> Hi Ben!
> Could you please chime in to bug #901134 (RFS: anbox-modules)?
> 
> This package wants to ship redundant copies of two modules (ashmem and
> binder) that are already in mainline since a long time ago.  This strikes me
> as thoroughly wrong, yet I'm very ignorant about packaged kernels, thus I
> can't offer good advice.

I agree, I don't think it makes much sense to build these OOT if they
can be built in-tree.

The in-tree version of ashmem *cannot* be built as a module, though,
which we would probably want to change.

[...]
> Indeed, these two modules are not built within Debian kernels.  They depend
> on CONFIG_ANDROID, which doesn't look like it does anything anymore except
> allowing to enable these two modules.  I have bad memories of Android
> kernels doing some very naughty things (magic hard-coded uids/gids, etc),
> but I don't know if that was related to CONFIG_ANDROID or not.  Even if it
> was in the past, it seems that in mainline that setting is safe to enable.
>
> But, all of this lies in Ben's kingdom, of which I'm not knowledgeable
> enough.  Thus, some advice would be nice.

I do wonder what the value of enabling these as in-tree modules would
be.  I don't think we package the many Android userspace services and
libraries that would be needed to run Android apps.  So how would these
modules be useful?  Is the idea to support running an Android system in
a container?

Ben.

-- 
Ben Hutchings
The most exhausting thing in life is being insincere.
 - Anne Morrow Lindberg



signature.asc
Description: This is a digitally signed message part

Bug#901420: ksoftirqd/0: page allocation failure: order:1, mode:0x2284020(GFP_ATOMIC|__GFP_COMP|__GFP_NOTRACK)

[Ben Hutchings]

Control: tag -1 - moreinfo
Control: severity -1 normal

On Wed, 2018-06-13 at 07:01 -0500, Luigi P. Bai wrote:
> Hi Ben,
> 
> Thank you for looking at this report.
> 
> You asked what is running on the machine. The first thing I want to
> point out is that it's the same stack of processes that were running on
> the 3.x version of the kernel; the kernel was the only upgrade. The
> system is "mostly jessie" with "apt-get -t stretch install
> linux-image-orion5x".
>
> This is a QNAP NAS, so it mostly runs a steady state of apache, nagios,
> smb, cups, dnscache, mysql, postfix, slapd, and the other "regular"
> daemons. In the middle of the night it'll catch an rsync request backing
> up another machine on the network. These OOM reports seem to happen both
> at night and during the "steady state" during the day when I'm at work
> and away from the machines (this is happening on my other QNAP too).

This seems like quite a lot of services to run on a 256 MB system.

> I seem to remember the (very rare) OOM reports I'd seen in the past also
> listing the process name, number, and backtrace when the process was
> killed. Has the OOM reporting changed? Has page allocation changed from
> 3.x to 4.x to cause this? I'm not noticing that long running processes
> are being killed, and I'm not seeing any other reports in the log files
> of processes being killed.

When handling received network packets, the kernel cannot wait for
memory to be freed up (that's what the "GFP_ATOMIC" indicates), so it
relies on the kernel memory manager keeping some memory free at all
times.  I think that the "OOM killer" will only be triggered by
allocation requests that can wait to free up memory, but I'm not sure.

This error was triggered by a request for 2 adjacent pages of memory,
when there were only single pages of memory free.  It's possible that
the change in behaviour is due to a kernel structure growing to occupy
2 pages where it previously fit into 1.

You might be able to reduce the likelihood of this error by increasing
the vm.min_free_kbytes sysctl.  Or by running fewer services.

Ben.

-- 
Ben Hutchings
The most exhausting thing in life is being insincere.
 - Anne Morrow Lindberg



signature.asc
Description: This is a digitally signed message part

Bug#901490: RFP: cloudflare-zlib -- compression library - cloudflare optimized version

[Yaroslav Halchenko]

Package: wnpp
Severity: wishlist

* Package name: cloudflare-zlib
  Version : v1.2.8-28-ge55212b
  Upstream Author : zlib authors + 9 new contributors
* URL : http://github.com/cloudflare/zlib
* License : BSD-3
  Programming Lang: C
  Description : compression library - cloudflare optimized version

I've not yet analyzed if work in this fork was submitted partially or in full
upstream (which now has 1.2.11 version).  It provides a set of optimization
patches for recent x86 processors, speeding up operations a number of
folds (see e.g. "Optimizing zlib" of
http://www.mccauslandcenter.sc.edu/crnl/optimizing-spmfsl).

I just discovered about it because upcoming release of dcm2niix is
offering an option to build its superbuild against this fork, since it
has shown to lead to great runtime advantages.  Not yet sure if it is
worthwhile packaging or some optimization patches could be generalized to be
adopted upstream.

Bug#601006: monkeysphere & set -e

[Elliott Mitchell]

Bug #601006 is quite the blast from the past.  I'm pretty sure `set -e`
is strongly endorsed at this point due to security concerns.

While an interesting historic relic, is it worth keeping #601006 around
to point out how attitudes have changed?


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#901476: stretch-pu: package systemd/232-25+deb9u4

[Cyril Brulebois]

Hi,

Michael Biebl  (2018-06-13):
> I'd like to make a stable upload fixing a few (minor) issues that were
> requested to be fixed by various users.  Strictly speaking, those
> issues are not important per se and would therefore qualify for a
> stable upload, but given the importance of the systemd package, making
> it work more smoothly seems worthwile nonetheless.
> 
[…]
> 
> Those changes do not touch udeb, so should not be affected d-i.
> That said, I've CCed KiBi, as usual, for a d-i ACK.

Thanks; I'm quite convinced by your assessment regarding the d-i side,
so no objections.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#901489: Does monkeysphere need real shell?

[Elliott Mitchell]

Package: monkeysphere
Version: 0.41-1

Unless there is a very *good* reason, the monkeysphere user should almost
certainly have /bin/false or /usr/sbin/nologin as its shell.  This may
not be a huge security hole, but it is very poor practice.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#833692: pinot: links GPLv2+ code with OpenSSL

[Jonas Smedegaard]

Quoting Olly Betts (2018-05-31 23:47:10)
> On Thu, May 31, 2018 at 12:22:58AM +0200, Sebastian Andrzej Siewior wrote:
>> pinot has currently two RC bugs and failed to build during the curl4 
>> transition / binNMU.
>> Does it make sense to add the two patches (Olly pointed to) and 
>> upload it or would a RM make sense?
> 
> Popcon suggests pinot usage is low:
> 
> https://qa.debian.org/popcon.php?package=pinot
> 
> I'm not sure there's really a direct equivalent though, so it seems
> worth uploading with at least the RC fixes.  I can prepare an upload
> (or happy for someone else to).
> 
> Jonas: Are you still interested in maintaining pinot?  I ask because
> it's had RC bugs open for a long time without any maintainer response,
> and the last maintainer upload was over five years ago now.
> 
> Let me know and if not I can orphan or adopt in my upload.

I still like pinot and believe there is a use for it in Debian as 
alternative to extract and tracker.  But evidently it keeps falling too 
low on my priority list :-(

Please do adopt it.  Or co-maintain it with me, if you prefer that.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#901488: Please provide static archives inside libtqt4-dev !

[none]

Package: qt4-x11
Version: 4:4.8.7+dfsg-11


Looks like debbuild doesn’t works well when used for cross compiling (I 
don’t have enough ram for native building on the target device) :


-march=armv8-a+crc+crypto+simd -mtune=cortex-a73.cortex-a53 -std=gnu++11 
-c -g -O2 -fdebug-prefix-map=/home/invite/qt4-x11-4.8.7+dfsg=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -std=gnu++11 -I/usr/include/freetype2 -pthread 
-I/usr/include/glib-2.0 -I/usr/lib/aarch64-linux-gnu/glib-2.0/include 
-O2 -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W 
-D_REENTRANT -fPIC -DQT_BUILD_CORE_LIB -DQT_NO_USING_NAMESPACE 
-DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT 
-DQT_USE_QSTRINGBUILDER -DQLIBRARYINFO_EPOCROOT -DQT_USE_ICU 
-DHB_EXPORT=Q_CORE_EXPORT -DQT_NO_DEBUG -D_LARGEFILE64_SOURCE 
-D_LARGEFILE_SOURCE -I../../mkspecs/linux-g++ -I. -I../../include 
-I../../include/QtCore -I.rcc/release-static -Iglobal 
-I../../tools/shared -I../3rdparty/harfbuzz/src -I../3rdparty/md5 
-I../3rdparty/md4 -I.moc/release-static -o 
.obj/release-static/qfutureinterface.o concurrent/qfutureinterface.cpp

{standard input}: Assembler messages:
{standard input}:8398: Error: operand mismatch -- `swpb x2,x20,[x19]'
{standard input}:8398: Info:did you mean this?
{standard input}:8398: Info:swpb w2, w20, [x19]
{standard input}:8419: Error: operand mismatch -- `swpb x4,x20,[x19]'
{standard input}:8419: Info:did you mean this?
{standard input}:8419: Info:swpb w4, w20, [x19]
{standard input}:8448: Error: operand mismatch -- `swpb x3,x5,[x6]'
{standard input}:8448: Info:did you mean this?
{standard input}:8448: Info:swpb w3, w5, [x6]
{standard input}:8491: Error: operand mismatch -- `swpb x10,x20,[x19]'
{standard input}:8491: Info:did you mean this?
{standard input}:8491: Info:swpb w10, w20, [x19]
{standard input}:8512: Error: operand mismatch -- `swpb x11,x20,[x19]'
{standard input}:8512: Info:did you mean this?
{standard input}:8512: Info:swpb w11, w20, [x19]
{standard input}:8541: Error: operand mismatch -- `swpb x3,x12,[x13]'
{standard input}:8541: Info:did you mean this?
{standard input}:8541: Info:swpb w3, w12, [x13]
{standard input}:8803: Error: operand mismatch -- `swpb x2,x20,[x19]'
{standard input}:8803: Info:did you mean this?
{standard input}:8803: Info:swpb w2, w20, [x19]
{standard input}:8824: Error: operand mismatch -- `swpb x4,x20,[x19]'
{standard input}:8824: Info:did you mean this?
{standard input}:8824: Info:swpb w4, w20, [x19]
{standard input}:8853: Error: operand mismatch -- `swpb x3,x5,[x6]'
{standard input}:8853: Info:did you mean this?
{standard input}:8853: Info:swpb w3, w5, [x6]
{standard input}:8896: Error: operand mismatch -- `swpb x10,x20,[x19]'
{standard input}:8896: Info:did you mean this?
{standard input}:8896: Info:swpb w10, w20, [x19]
{standard input}:8917: Error: operand mismatch -- `swpb x11,x20,[x19]'
{standard input}:8917: Info:did you mean this?
{standard input}:8917: Info:swpb w11, w20, [x19]
{standard input}:8946: Error: operand mismatch -- `swpb x3,x12,[x13]'
{standard input}:8946: Info:did you mean this?
{standard input}:8946: Info:swpb w3, w12, [x13]
{standard input}:9180: Error: operand mismatch -- `swpb x2,x20,[x19]'
{standard input}:9180: Info:did you mean this?
{standard input}:9180: Info:swpb w2, w20, [x19]
{standard input}:9203: Error: operand mismatch -- `swpb x4,x20,[x19]'
{standard input}:9203: Info:did you mean this?
{standard input}:9203: Info:swpb w4, w20, [x19]
{standard input}:9234: Error: operand mismatch -- `swpb x3,x5,[x6]'
{standard input}:9234: Info:did you mean this?
{standard input}:9234: Info:swpb w3, w5, [x6]
{standard input}:9407: Error: operand mismatch -- `swpb x2,x20,[x19]'
{standard input}:9407: Info:did you mean this?
{standard input}:9407: Info:swpb w2, w20, [x19]
{standard input}:9430: Error: operand mismatch -- `swpb x4,x20,[x19]'
{standard input}:9430: Info:did you mean this?
{standard input}:9430: Info:swpb w4, w20, [x19]
{standard input}:9461: Error: operand mismatch -- `swpb x3,x5,[x6]'
{standard input}:9461: Info:did you mean this?
{standard input}:9461: Info:swpb w3, w5, [x6]
{standard input}:9604: Error: operand mismatch -- `swpb x0,x20,[x19]'
{standard input}:9604: Info:did you mean this?
{standard input}:9604: Info:swpb w0, w20, [x19]
{standard input}:9627: Error: operand mismatch -- `swpb x3,x20,[x19]'
{standard input}:9627: Info:did you mean this?
{standard input}:9627: Info:swpb w3, w20, [x19]
{standard input}:9658: Error: operand mismatch -- `swpb x1,x6,[x5]'
{standard input}:9658: Info:did you mean this?
{standard input}:9658: Info:swpb w1, w6, [x5]
{standard 

Bug#901136: can't remove if install fails

[Wouter Verhelst]

Hi,

On Wed, Jun 13, 2018 at 03:21:11AM +0300, kact...@gnu.org wrote:
> I never worked with NSS, but how did it happen, that useradd {in postinst}
> created user in a way, that userdel {in prerm} could not find?

That's not what happened.

The sreview user already existed before the sreview-common package was
installed, but it did not exist in /etc/passwd; instead, it existed in a
different location, configured through an NSS module.

The easiest way for you to test this is probably to install libnss-db,
change the value of ETC in /etc/default/libnss-db to some other
directory and cull the DBS value so it contains just passwd, then create
a file called "passwd" in the directory that you pointed ETC to, run
"make -C /var/lib/misc", and add "db" to /etc/nsswitch.conf on the
"passwd" line.

Meanwhile, I'm going to have to implement it properly and remove
dh_sysuser from my build-depends. Ah well.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#901486: python/python3: no package currently in testing/unstable/experimental ships the python policy

[Matthias Klose]

Control: tags -1 + pending

On 13.06.2018 23:55, Julian Gilbey wrote:

Package: python3
Version: 3.6.5-3
Severity: normal

Hiya,

I just upgraded my testing machine to python 2.7.15-3, which says in
its changelog:
   * Remove the Debian Python policy, now found in the python3 package.

Unfortunately that is not the case: the python3 package does not ship
this file (at least not as of version 3.6.5-3 or experimental version
3.6.5-5).  Probably an oversight.


yes, will be fixed with the next upload.

Bug#895936: patch 2.7.5-1+deb9u1 flagged for acceptance

[Adam D Barratt]

Control: tags -1 + pending

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: patch
Version: 2.7.5-1+deb9u1

Explanation: fix arbitrary command execution in ed-style patches 
[CVE-2018-1000156]

Bug#901487: theano.gpuarray unusable - needs newer pygpu

[Rebecca N. Palmer]

Package: python3-pygpu,python3-theano

theano.gpuarray does not work because the currently packaged version of 
pygpu is too old for it.


Is there a reason for not packaging 0.7.x or have you just not got 
around to it?  According to codesearch, theano is the only package using 
pygpu, so compatibility does not appear to be a blocker.


>>> import theano.gpuarray
ERROR (theano.gpuarray): Could not initialize pygpu, support disabled
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/theano/gpuarray/__init__.py", 
line 227, in 

use(config.device)
  File "/usr/lib/python3/dist-packages/theano/gpuarray/__init__.py", 
line 214, in use

init_dev(device, preallocate=preallocate)
  File "/usr/lib/python3/dist-packages/theano/gpuarray/__init__.py", 
line 73, in init_dev

pygpu_version.fullversion)
ValueError: Your installed version of pygpu(0.6.9) is too old, please 
upgrade to 0.7.0 or later (but below 0.8.0)

Bug#901486: python/python3: no package currently in testing/unstable/experimental ships the python policy

[Julian Gilbey]

Package: python3
Version: 3.6.5-3
Severity: normal

Hiya,

I just upgraded my testing machine to python 2.7.15-3, which says in
its changelog:
  * Remove the Debian Python policy, now found in the python3 package.

Unfortunately that is not the case: the python3 package does not ship
this file (at least not as of version 3.6.5-3 or experimental version
3.6.5-5).  Probably an oversight.

Best wishes,

   Julian

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

Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_GB.UTF-8), LANGUAGE=en_GB.utf8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_GB.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3 depends on:
ii  libpython3-stdlib  3.6.5-3
ii  python3-minimal3.6.5-3
ii  python3.6  3.6.5-9

python3 recommends no packages.

Versions of packages python3 suggests:
ii  python3-doc   3.6.5-3
ii  python3-tk3.6.5-4
pn  python3-venv  

-- no debconf information

Bug#895131: Acknowledgement (linux-perf-4.16: Add libopencsd support to perf)

[Wookey]

On 2018-04-07 12:06 +, Debian Bug Tracking System wrote:
> libopencsd is now in the NEW queue. I'm not sure if you'll get a
> noticfication when the ITP bug closure unblocks this one so I'll
> comment again here when that happens.

OK. libopencsd is now in the archive, so this patch to allow the perf
build to use it can now be applied.

Thanks

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/

Bug#901474: [Pkg-javascript-devel] Bug#901474: Bug#901474: [nodejs][RFC] Multiarch and /usr/local search path

[Jérémy Lal]

2018-06-13 23:28 GMT+02:00 Bastien ROUCARIES :

> On Wed, Jun 13, 2018 at 10:46 PM, Jérémy Lal  wrote:
> >
> >
> > 2018-06-13 22:09 GMT+02:00 Bastien ROUCARIÈS <
> roucaries.bast...@gmail.com>:
> >>
> >> Package: nodejs
> >> Version: 10.4.0~dfsg-2
> >> Severity: important
> >> tags: patch
> >>
> >>
> >> Hi,
> >>
> >> In order to get search path in multiarch path and in /usr/local I use
> the
> >> following patch
> >>
> >> ../..
> >>
> >> globalPaths:
> >>[ '/home/bastien/.node_modules',
> >>  '/home/bastien/.node_libraries',
> >>  '/usr/local/lib/x86_64-linux-gnu/nodejs',
> >>  '/usr/local/share/nodejs',
> >>  '/usr/local/lib/nodejs',
> >>  '/usr/lib/x86_64-linux-gnu/nodejs',
> >>  '/usr/share/nodejs',
> >>  '/usr/lib/nodejs' ],
> >>
> >> I have also added arch triplet because some module will need it.
> >
> >
> > Cool ! I'll take only the fix for the require path of
> > system-multiarch-installed addons.
> > (nodejs does not search /usr/local - yarn global does not either - only
> npm
> > might
> > be concerned).
>
> Yes and no.
>
> Admin could want to delegate to staff group /usr/local and staff group
> will install under /usr/local.  It is the policy, and a SHOULD but it
> is nice to implement and document.
>
> But if you see the list is defined in debian/rules. Not hard coded.
>


nodejs allows one to set NODE_PATH environment variable,
so there is no need to recompile it to use /usr/local/xxx as a global
search path.
The only thing left to do is to properly place the node addon in the right
place (/usr/lib/x86_64-linux-gnu/nodejs) - and that can be achieved manually
or with a patch to npm... which would be easier to achieve if the actual
triplet was available to nodejs users, since it's "hard to guess".

Jérémy

Bug#834854: jessie-pu: package charybdis/3.4.2-5~deb8u1

[Antoine Beaupré]

On 2018-06-13 16:00:41, Adam D. Barratt wrote:
> On Tue, 2016-09-13 at 12:04 +0200, Julien Cristau wrote:
>> On Sun, Sep 11, 2016 at 16:58:34 -0400, Antoine Beaupré wrote:
>> 
>> > 1. ignore the above two extra issues and simply add the patch for
>> > #215
>> > to the pile of patches in jessie
>> > 2. import the new gnutls.c module from an eventual new 3.5 release
>> > upstream directly in jessie - this may be difficult because of
>> > internal
>> > API changes
>> > 3. import 3.5.x directly in jessie
>> > 
>> > I would like to have feedback from the release team as to which
>> > approach
>> > to take forward.
>> > 
>> 
>> I don't think 3 is a reasonable option.  The rest will depend on
>> specifics.
>
> There's been no further activity on this bug since the above, so I
> think it's reasonable to say it's unlikely to be getting fixed in
> jessie at this point?

Hmm... I am not sure what to do with this... 3.4 is pretty much dead at
this point, and I suspect most people will have migrated to 3.5. the
complete fix is pretty invasive so I guess we can just punt this away
for ever and assume people will upgrade to stretch already... :/

a.
-- 
Software gets slower faster than hardware gets faster.
 - Wirth's law

Bug#881205: NMU for backintime 1.1.24

[Fabian Wolff]

Hi,

since there has not been any progress on this for a while now, I have
decided to prepare a non-maintainer upload myself, including the
latest upstream release, 1.1.24, as well as some minor maintenance
work.

Jonathan, could you have a look at this? Of course I won't upload a
NMU without your consent. Also, I would need a sponsor. I have
uploaded my package to Mentors:

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

I have also forked your repository and pushed my changes:

  https://salsa.debian.org/wolff-guest/pkg-backintime

If you're satisfied with my changes, I can add a debian/1.1.24-0.1 tag
and open a merge request, or you could give me write access to your
repository so that I can push the changes myself.

Thanks!

Best regards,
Fabian

Bug#901474: [Pkg-javascript-devel] Bug#901474: Bug#901474: [nodejs][RFC] Multiarch and /usr/local search path

[Bastien ROUCARIES]

On Wed, Jun 13, 2018 at 10:46 PM, Jérémy Lal  wrote:
>
>
> 2018-06-13 22:09 GMT+02:00 Bastien ROUCARIÈS :
>>
>> Package: nodejs
>> Version: 10.4.0~dfsg-2
>> Severity: important
>> tags: patch
>>
>>
>> Hi,
>>
>> In order to get search path in multiarch path and in /usr/local I use the
>> following patch
>>
>> ../..
>>
>> globalPaths:
>>[ '/home/bastien/.node_modules',
>>  '/home/bastien/.node_libraries',
>>  '/usr/local/lib/x86_64-linux-gnu/nodejs',
>>  '/usr/local/share/nodejs',
>>  '/usr/local/lib/nodejs',
>>  '/usr/lib/x86_64-linux-gnu/nodejs',
>>  '/usr/share/nodejs',
>>  '/usr/lib/nodejs' ],
>>
>> I have also added arch triplet because some module will need it.
>
>
> Cool ! I'll take only the fix for the require path of
> system-multiarch-installed addons.
> (nodejs does not search /usr/local - yarn global does not either - only npm
> might
> be concerned).

Yes and no.

Admin could want to delegate to staff group /usr/local and staff group
will install under /usr/local.  It is the policy, and a SHOULD but it
is nice to implement and document.

But if you see the list is defined in debian/rules. Not hard coded.

> I think it will be easier to explain to upstream once we have an example to
> show,
> node-mapnik, for instance.

Don't know but will let you explain
>
> Jérémy
>
>
> --
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#848968: [Piuparts-devel] Bug#848968: Bug#839162: marked as done (Enabled merged-/usr by default)

[Holger Levsen]

On Wed, Jun 13, 2018 at 06:39:22PM +, Holger Levsen wrote:
> >* Enable merged-/usr by default (Closes: #839046)
> >  This is applied for buster and later.
> raising severity of this bug accordingly :)

and then I wonder: do we need to do anything at all? For buster it later
piuparts should just automatically test with merged-/usr and before it
should and will not.

so maybe closing this bug is the right cause of action?


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#891216: seconded 891216: Requre d-devel consultation for epoch bump

[Paul Gevers]

I second the diff below.

Paul

diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
index 0771346..166cdd8 100644
--- a/policy/ch-controlfields.rst
+++ b/policy/ch-controlfields.rst
@@ -552,9 +552,10 @@ The three components here are:
 omitted, in which case zero is assumed. If it is omitted then the
 ``upstream_version`` may not contain any colons.

-It is provided to allow mistakes in the version numbers of older
-versions of a package, and also a package's previous version
-numbering schemes, to be left behind.
+Epochs can help when the upstream version numbering scheme
+changes, but they must be used with care.  You should not change
+the epoch, even in experimental, without getting consensus on
+debian-devel first.

 ``upstream_version``
 This is the main part of the version number. It is usually the
@@ -622,9 +623,23 @@ These two steps (comparing and removing initial
non-digit strings and
 initial digit strings) are repeated until a difference is found or both
 strings are exhausted.

-Note that the purpose of epochs is to allow us to leave behind mistakes
-in version numbering, and to cope with situations where the version
-numbering scheme changes. It is *not* intended to cope with version
+Epochs should be used sparingly
+^^^
+
+Note that the purpose of epochs is to cope with situations where the
+upstream version numbering scheme changes and to allow us to leave
+behind serious mistakes.
+If you think that increasing the epoch is the right solution,
+you should consult debian-devel and get consensus before doing so
+(even in experimental).
+
+Epochs should not be used when a package needs to be rolled back.
+In that case, use the ``+really`` convention: for example, if you
+uploaded ``2.3-3`` and now you need to go backwards to upstream 2.2,
+call your reverting upload something like ``2.3+really2.2-1``.
+Eventually, when we upload upstream 2.4, the +really part can go away.
+
+Epochs are also not intended to cope with version
 numbers containing strings of letters which the package management
 system cannot interpret (such as ``ALPHA`` or ``pre-``), or with silly
 orderings.  [#]_



signature.asc
Description: OpenPGP digital signature

Bug#901485: RFS: runescape/0.2-2 -- Multiplayer online game set in a fantasy world

[Carlos Donizete Froes]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "runescape"

 * Package name: runescape
   Version : 0.2-2
   Upstream Author : Carlos Donizete Froes 
 * URL : https://gitlab.com/coringao/runescape
 * License : BSD-2-Clauses
   Section : non-free/games

  It builds those binary packages:

  runescape  - Multiplayer online game set in a fantasy world

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/non-free/r/runescape/runescape_0.2-2.dsc

  More information about Runescape can be obtained from 
https://gitlab.com/coringao/runescape/wikis.

  Changes since the last upload:

  * Switch to compat level 11
  * debian/control:
+ Bump debhelper compat to 11
+ Declare compliance with Debian Policy: 4.1.4
+ Changed homepage link GitLab
+ Move Vcs URLs to salsa.d.g
  * debian/copyright:
+ Update source URL move to GitLab
+ Added a short comment as legal notice
+ Year updated on 'Files: debian/*'
  * Updated d/upstream/metadata URLs move to GitLab
  * Updated d/watch file upstream move to GitLab

  Regards,
   Carlos Donizete Froes [a.k.a coringao]

Bug#897494: ditaa: FTBFS: src/org/stathissideris/ascii2image/core/JavadocTaglet.java:26: error: package com.sun.tools.doclets does not exist

[Markus Koschany]

Control: tags -1 pending patch

Dear maintainer,

I have uploaded a new version of ditaa, versioned as 0.10+ds1-1.2, that
addresses the build failure with Java 10. The taglet class has been
removed and since a custom taglet is not really required for running the
program, I have dropped the JavaDocTaglet class completely.

Please find attached the debdiff.

Regards,

Markus
diff -Nru ditaa-0.10+ds1/debian/changelog ditaa-0.10+ds1/debian/changelog
--- ditaa-0.10+ds1/debian/changelog 2017-01-13 18:13:14.0 +0100
+++ ditaa-0.10+ds1/debian/changelog 2018-06-13 23:03:10.0 +0200
@@ -1,3 +1,11 @@
+ditaa (0.10+ds1-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Work around the FTBFS with Java 10 by removing the JavadocTaglet class.
+(Closes: #897494)
+
+ -- Markus Koschany   Wed, 13 Jun 2018 23:03:10 +0200
+
 ditaa (0.10+ds1-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru ditaa-0.10+ds1/debian/patches/remove-JavadocTaglet.patch 
ditaa-0.10+ds1/debian/patches/remove-JavadocTaglet.patch
--- ditaa-0.10+ds1/debian/patches/remove-JavadocTaglet.patch1970-01-01 
01:00:00.0 +0100
+++ ditaa-0.10+ds1/debian/patches/remove-JavadocTaglet.patch2018-06-13 
23:03:10.0 +0200
@@ -0,0 +1,345 @@
+From: Markus Koschany 
+Date: Wed, 13 Jun 2018 22:58:25 +0200
+Subject: remove JavadocTaglet
+
+Remove JavadocTaglet class because the Taglet class has been removed in
+Java 10.
+
+Bug-Debian: https://bugs.debian.org/897494
+---
+ .../ascii2image/core/JavadocTaglet.java| 326 -
+ 1 file changed, 326 deletions(-)
+ delete mode 100644 src/org/stathissideris/ascii2image/core/JavadocTaglet.java
+
+diff --git a/src/org/stathissideris/ascii2image/core/JavadocTaglet.java 
b/src/org/stathissideris/ascii2image/core/JavadocTaglet.java
+deleted file mode 100644
+index f1642ef..000
+--- a/src/org/stathissideris/ascii2image/core/JavadocTaglet.java
 /dev/null
+@@ -1,326 +0,0 @@
+-/* 
+- * Text Diagram Taglet 
+- *
+- * Copyright (C) 2006 Nordic Growth Market NGM AB,
+- * Mikael Brannstrom. 
+- *
+- * 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 2 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, write to the Free Software
+- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+- *
+- */
+-package org.stathissideris.ascii2image.core;
+-
+-import com.sun.javadoc.ProgramElementDoc;
+-import com.sun.javadoc.Tag;
+-import com.sun.tools.doclets.Taglet;
+-import com.sun.tools.doclets.internal.toolkit.Configuration;
+-import com.sun.tools.doclets.standard.Standard;
+-import java.awt.image.RenderedImage;
+-import java.io.File;
+-import java.io.IOException;
+-import java.io.UnsupportedEncodingException;
+-import java.lang.reflect.Field;
+-import java.lang.reflect.Method;
+-import java.util.Map;
+-import java.util.regex.Pattern;
+-import javax.imageio.ImageIO;
+-
+-import org.stathissideris.ascii2image.text.TextGrid;
+-import org.stathissideris.ascii2image.graphics.Diagram;
+-import org.stathissideris.ascii2image.core.ConversionOptions;
+-import org.stathissideris.ascii2image.graphics.BitmapRenderer;
+-
+-/** This class is a custom Javadoc taglet for embedding ditaa diagrams in
+- * javadoc comments. The tag is an inline which can be used in any javadoc
+- * comment. The tag can also be used in package documentation and in the 
+- * overview.
+- * This taglet assumes that the Standard Javadoc Doclet is being used.
+- * 
+- * The syntax is:
+- * 
+- * @textdiagram diagram_name
+- * the ascii art diagram
+- * 
+- * 
+- * 
+- * The diagram name will be used when generating the image, so that the image 
+- * can be referenced to somewhere else (by using an a-href HTML tag). The 
+- * diagram name can only contain letters, numbers and underscore. The name of 
+- * the generated image will become "classname-diagram 
name.png". 
+- * 
+- * The syntax for the ditaa diagram is described at 
+- * http://ditaa.sourceforge.net/;>http://ditaa.sourceforge.net/. 
+- * 
+- * Note: The overview file needs to be named "overview.html" if it lies
+- * in the source path, otherwise it is sufficient that it ends with ".html". 
+- *
+- * @author Mikael Brannstrom
+- */
+-public class JavadocTaglet implements Taglet {
+-
+-  private static final String NAME = "textdiagram";
+-  private static final Pattern FIGURE_NAME_PATTERN = 
Pattern.compile("\\w+");
+-
+-  private final File[] srcPath;
+-  private 

Bug#898902: javadoc: error - Error fetching URL: file:/usr/share/doc/default-jdk/api/

[Emmanuel Bourg]

Le 13/06/2018 à 23:01, Adrian Bunk a écrit :

> The /usr/share/doc/default-jdk symlink is shipped in the default-jdk 
> package that is not installed by the build dependencies of 
> libgpars-groovy-java.

Ok, because libgpars-groovy-java build-depends on default-jdk-headless
instead of default-jdk the symlink doesn't work. I couldn't reproduce it
because I pre-installed default-jdk in my pbuilder to speed up the
builds. I'll fix that.

Thank you for the help Adrian.

Bug#901474: [Pkg-javascript-devel] Bug#901474: [nodejs][RFC] Multiarch and /usr/local search path

[Jérémy Lal]

2018-06-13 22:09 GMT+02:00 Bastien ROUCARIÈS :
>
>
> You could check the patch by doing require('os').constants and see
>  ARCH_TRIPLET: 'x86_64-linux-gnu',
>   GLOBAL_NODE_PATH:
>'/usr/local/lib/x86_64-linux-gnu/nodejs:/usr/local/share/
> nodejs:/usr/local/lib/nodejs:/usr/lib/x86_64-linux-gnu/
> nodejs:/usr/share/nodejs:/usr/lib/nodejs',
>

That kind of configuration variables should go into
process.config.variables
where you can see that there is almost already that information:
target_arch, host_arch, node_prefix

Taking into account my previous comment about no /usr/local,
let me refine your proposal to:
/usr/share/nodejs (because 99% modules are pure js, let's search them first)
/usr/lib/x86_64-linux-gnu/nodejs (because addons should go there)
/usr/lib/nodejs (keep the old path until no debian package use it)

to the global default search path.

Jérémy

Bug#901484: targetcli aborts with the error message "NameError: name 'readline' is not defined" when running in interactive shell mode

[Matt Coleman]

Package: python3-configshell-fb
Version: 1.1.20-1

Reproduced with python3-configshell-fb 1.1.20-1 on fully-updated Ubuntu Server 
18.04 by attempting to run targetcli via PHP using Symfony Process:

Test script (in a directory with Symfony 3.4.1 pulled in via Composer)

setInput('ls');

$process->mustRun();

var_dump($process->getOutput());



Actual output

PHP Fatal error: Uncaught 
Symfony\Component\Process\Exception\ProcessFailedException: The command 
"targetcli" failed.

Exit Code: 1(General error)

Working directory: /home/matt/reproduce

Output:

targetcli shell version 2.1.fb43
Copyright 2011-2013 by Datera, Inc and others.
For help on commands, type 'help'.

Error Output:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/configshell_fb/shell.py", line 893, in 
run_interactive
old_completer = readline.get_completer()
NameError: name 'readline' is not defined

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/targetcli", line 121, in 
main()
  File "/usr/bin/targetcli", line 111, in main
shell.run_interactive()
  File "/usr/lib/python3/dist-packages/configshell_fb/shell.py", line 899, in 
run_interactive
readline.set_completer(old_completer)
NameError: name 'readline' is not defined
 in /home/matt/reproduce/vendor/symfony/ in 
/home/matt/reproduce/vendor/symfony/symfony/src/Symfony/Component/Process/Process.php
 on line 239



Expected output

string(1324) "targetcli shell version 2.1.fb43
Copyright 2011-2013 by Datera, Inc and others.
For help on commands, type 'help'.

/> o- / 
.
 [...]
  o- backstores 
..
 [...]
  | o- block 
..
 [Storage Objects: 0]
  | o- fileio 
.
 [Storage Objects: 0]
  | o- pscsi 
..
 [Storage Objects: 0]
  | o- ramdisk 

 [Storage Objects: 0]
  o- iscsi 

 [Targets: 0]
  o- loopback 
.
 [Targets: 0]
  o- vhost 

 [Targets: 0]
/> exit
"


I assume the package version 1.1.20 correpsonds to the project's 1.1fb20 tag on 
GitHub.

This bug was fixed in this commit and released in 1.1fb23: 
https://github.com/open-iscsi/configshell-fb/commit/82f79eb2f967ecd820d531488d0b64d6015b1aaf

I suggest updating the package to contain the most recent tagged version from 
the GitHub repository (currently 1.1fb24).

Bug#898902: javadoc: error - Error fetching URL: file:/usr/share/doc/default-jdk/api/

[Adrian Bunk]

On Wed, Jun 13, 2018 at 10:54:05PM +0200, Emmanuel Bourg wrote:
> Control: tags -1 + help
> 
> Le 13/06/2018 à 22:42, Adrian Bunk a écrit :
> > Control: reopen -1
> > 
> > On Thu, May 17, 2018 at 09:39:07AM +, Debian Bug Tracking System wrote:
> > 
> > https://buildd.debian.org/status/fetch.php?pkg=libgpars-groovy-java=all=1.2.1-8=1526551079=0
> >   javadoc: error - Error fetching URL: file:/usr/share/doc/default-jdk/api/
> > 
> > default-jdk-doc ships /usr/share/doc/default-jdk-doc/api/ but not the 
> > non-doc location javadoc tries.
> 
> Hum I don't understand these errors. /usr/share/doc/default-jdk
> redirects to /usr/share/doc/default-jre, which redirects to
> /usr/share/doc/default-jre-headless which contains an api symlink
> redirecting to /usr/share/doc/openjdk-10-doc/api, which redirects to
> /usr/share/doc/openjdk-10-jre-headless/api which eventually contains the
> javadoc.
> 
> So the /usr/share/doc/default-jdk/api/ path that has been used for years
> is still valid.
>...

The /usr/share/doc/default-jdk symlink is shipped in the default-jdk 
package that is not installed by the build dependencies of 
libgpars-groovy-java.

> Emmanuel Bourg

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#901483: bind9: CVE-2018-5738: improperly permits recursive query service to unauthorized clients

[Salvatore Bonaccorso]

Source: bind9
Version: 1:9.11.3+dfsg-1
Severity: grave
Tags: security upstream
Justification: user security hole

Hi,

The following vulnerability was published for bind9, affecting the
version present in unstable (older suites do not include the upstream
change #4777).

CVE-2018-5738[0]:
|Some versions of BIND can improperly permit recursive query service to
|unauthorized clients

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-5738
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-5738
[1] https://kb.isc.org/article/AA-01616/0/CVE-2018-5738

Regards,
Salvatore

Bug#841234: jessie-pu: package libiberty/20141014-1

[Anton Gladky]

Hi Adam,

I forgot about this bug. Actually I do not have any interest and time
now to make an upload. So, I think the bug can be closed.

Thanks

Anton


2018-06-13 22:17 GMT+02:00 Adam D. Barratt :
> On Sat, 2016-12-17 at 11:42 +0100, Julien Cristau wrote:
>> Control: tag -1 moreinfo
>>
>> On Tue, Oct 18, 2016 at 20:32:56 +0200, Anton Gladky wrote:
>>
>> > Package: release.debian.org
>> > Severity: normal
>> > Tags: jessie
>> > User: release.debian@packages.debian.org
>> > Usertags: pu
>> >
>> > Dear release team,
>> >
>> > libiberty needs to be updated in Jessie, because the newer version
>> > fixes many security issues:
>> >
>> > CVE-2016-4487 CVE-2016-4488 CVE-2016-4489 CVE-2016-4490
>> > CVE-2016-4492 CVE-2016-4493 CVE-2016-2226 CVE-2016-6131
>> >
>>
>> What makes it impossible to backport just the fixes for the above
>> issues, rather than importing a full new upstream release?  A short
>> description of the issues so we don't have to look them up would also
>> have been helpful.
>>
>
> Ping? The above was 18 months ago, and we're within a few days of
> closing updates to jessie before it becomes LTS.
>
> Regards,
>
> Adam

Bug#898902: javadoc: error - Error fetching URL: file:/usr/share/doc/default-jdk/api/

[Emmanuel Bourg]

Control: tags -1 + help

Le 13/06/2018 à 22:42, Adrian Bunk a écrit :
> Control: reopen -1
> 
> On Thu, May 17, 2018 at 09:39:07AM +, Debian Bug Tracking System wrote:
> 
> https://buildd.debian.org/status/fetch.php?pkg=libgpars-groovy-java=all=1.2.1-8=1526551079=0
>   javadoc: error - Error fetching URL: file:/usr/share/doc/default-jdk/api/
> 
> default-jdk-doc ships /usr/share/doc/default-jdk-doc/api/ but not the 
> non-doc location javadoc tries.

Hum I don't understand these errors. /usr/share/doc/default-jdk
redirects to /usr/share/doc/default-jre, which redirects to
/usr/share/doc/default-jre-headless which contains an api symlink
redirecting to /usr/share/doc/openjdk-10-doc/api, which redirects to
/usr/share/doc/openjdk-10-jre-headless/api which eventually contains the
javadoc.

So the /usr/share/doc/default-jdk/api/ path that has been used for years
is still valid.

I wonder if this is a regression in the javadoc tool which would no
longer be able to follow symlinks.

Emmanuel Bourg

Bug#901481: cpl-plugin-uves: please make the build reproducible

[Chris Lamb]

Source: cpl-plugin-uves
Version: 5.9.1+dfsg-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that cpl-plugin-uves could not be built reproducibly.

This is due to non-determinstic iteration over various data
structures. Patch attached. :)

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/create_manpage.py  2018-06-13 19:45:34.907564917 +0200
--- b/debian/create_manpage.py  2018-06-13 22:45:59.518527078 +0200
@@ -80,7 +80,7 @@
type = p.type.__name__,
description = p.__doc__.replace("'", "\\'"),
default = p.default)
-   for p in recipe.param)
+   for p in sorted(recipe.param, key = lambda x: x.name))
 
 def seealso(recipe, template):
 return ",\n".join(template.format(name = name,
--- a/debian/create_sphinx.py   2018-06-13 19:45:34.907564917 +0200
--- b/debian/create_sphinx.py   2018-06-13 22:45:19.422301804 +0200
@@ -154,7 +154,7 @@
 type = p.type.__name__,
 description = p.__doc__.replace("\n", "  "),
 default = '"{0}"'.format(p.default) if p.type is str else p.default
-) for i, p in enumerate(recipe.param) if count is None or i < count)
+) for i, p in enumerate(sorted(recipe.param, key = lambda x: x.name)) if 
count is None or i < count)
 
 def get_description(s):
 o = []

Bug#884571: [Pkg-privacy-maintainers] Bug#884571: RM: torbrowser-launcher/0.1.9-1+deb8u3

[Adam D. Barratt]

On Sat, 2018-02-24 at 14:03 +0100, intrigeri wrote:
> Adam D. Barratt:
> > # Broken Depends:
> > onionshare/contrib: onionshare
> 
> So I guess Jessie should first get the fix we applied to onionshare
> in
> testing/sid, i.e. move torbrowser-launcher to Recommends.

Ping?

Regards,

Adam

Bug#901474: [Pkg-javascript-devel] Bug#901474: [nodejs][RFC] Multiarch and /usr/local search path

[Jérémy Lal]

2018-06-13 22:09 GMT+02:00 Bastien ROUCARIÈS :

> Package: nodejs
> Version: 10.4.0~dfsg-2
> Severity: important
> tags: patch
>
>
> Hi,
>
> In order to get search path in multiarch path and in /usr/local I use the
> following patch
>
> ../..

globalPaths:
>[ '/home/bastien/.node_modules',
>  '/home/bastien/.node_libraries',
>  '/usr/local/lib/x86_64-linux-gnu/nodejs',
>  '/usr/local/share/nodejs',
>  '/usr/local/lib/nodejs',
>  '/usr/lib/x86_64-linux-gnu/nodejs',
>  '/usr/share/nodejs',
>  '/usr/lib/nodejs' ],
>
> I have also added arch triplet because some module will need it.
>

Cool ! I'll take only the fix for the require path of
system-multiarch-installed addons.
(nodejs does not search /usr/local - yarn global does not either - only npm
might
be concerned).

I think it will be easier to explain to upstream once we have an example to
show,
node-mapnik, for instance.

Jérémy

Bug#898902: closed by Emmanuel Bourg (Bug#898902: fixed in libgpars-groovy-java 1.2.1-8)

[Adrian Bunk]

Control: reopen -1

On Thu, May 17, 2018 at 09:39:07AM +, Debian Bug Tracking System wrote:
>...
>  libgpars-groovy-java (1.2.1-8) unstable; urgency=medium
>...
>* Added the missing build dependency on default-jdk-doc (Closes: #898902)
>...
> Source: libgpars-groovy-java
> Severity: serious
> Tags: sid buster
> User: debian-j...@lists.debian.org
> Usertags: default-java10
> 
> libgpars-groovy-java fails to build with Java 10 due to a javadoc issue:
> 
>   Starting process 'command 
> '/usr/lib/jvm/java-10-openjdk-amd64/bin/javadoc''. Working directory: 
> /build/1st/libgpars-groovy-java-1.2.1 Command: 
> /usr/lib/jvm/java-10-openjdk-amd64/bin/javadoc 
> @/build/1st/libgpars-groovy-java-1.2.1/build/tmp/javadoc/javadoc.options
>   Successfully started process 'command 
> '/usr/lib/jvm/java-10-openjdk-amd64/bin/javadoc''
>   javadoc: error - Error fetching URL: file:/usr/share/doc/default-jdk/api/
>   javadoc: warning - You have not specified the version of HTML to use.
>   The default is currently HTML 4.01, but this will change to HTML5
>   in a future release. To suppress this warning, please specify the
>   version of HTML used in your documentation comments and to be
>   generated by this doclet, using the -html4 or -html5 options.
>   1 error
>   1 warning

https://buildd.debian.org/status/fetch.php?pkg=libgpars-groovy-java=all=1.2.1-8=1526551079=0
  javadoc: error - Error fetching URL: file:/usr/share/doc/default-jdk/api/

default-jdk-doc ships /usr/share/doc/default-jdk-doc/api/ but not the 
non-doc location javadoc tries.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#901425: file 5.22+15-2+deb8u4 flagged for acceptance

[Adam D Barratt]

Control: tags -1 + pending

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian jessie.

Thanks for your contribution!

Upload details
==

Package: file
Version: 5.22+15-2+deb8u4

Explanation: avoid reading past the end of a buffer [CVE-2018-10360]]

Bug#901477: mawk-1.3.3-17+b3 segfaults

[Christoph Junghans]

Package: mawk
Version: 1.3.3-17+b3

Run 
https://github.com/flang-compiler/flang/blob/master/runtime/libpgmath/tools/mth_z2yy.awk
in mawk:
$ mawk -v TARGET=X8664 -f mth_z2yy.awk
Segmentation fault

While gawk works:
$ gawk -v TARGET=X8664 -f mth_z2yy.awk


The most recent version of mawk from:
https://github.com/ThomasDickey/mawk-snapshots/commit/f448f2385c499fabaa9a342bb1f3e207db67daf8
works.

-- 
Christoph Junghans
Web: http://www.compphys.de

Bug#901132: typo in fix for #901132 - openmpi psm2 support

[Lucas Nussbaum]

Hi,

I think that there's a typo in the fix for this bug.

--- openmpi-3.1.0/debian/rules  2018-05-28 20:46:30.0 +0200
+++ openmpi-3.1.0/debian/rules  2018-06-09 14:36:15.0 +0200
@@ -18,6 +18,7 @@
 NO_VERBS_ARCH:= hurd-i386 kfreebsd-amd64 kfreebsd-i386 s390x 
 FABRIC_ARCH:= amd64 i386 
 PSM_ARCH:= amd64 i386
+PSM2_ARCH:= amd64
 BUILTIN_ATOMICS_ARCH:= s390x
 NO_CMA_ARCH:= s390x mipsel hppa alpha armhf armel m68k sparc64
 NO_JAVA_ARCH:= hppa hurd-i386 ia64 riscv64
@@ -44,6 +45,9 @@
 ifneq ($(filter $(PSM_ARCH),$(DEB_HOST_ARCH)),)
PSM:= --with-psm
 endif
+ifneq ($(filter $(PSM2_ARCH),$(DEB_HOST_ARCH)),)
+   PSM:= --with-psm2
+endif
 ifeq ($(filter $(NO_JAVA_ARCH),$(DEB_HOST_ARCH)),)
 ifeq ($(filter stage1,$(DEB_BUILD_PROFILES)),)
JAVA := --with-jdk-dir=/usr/lib/jvm/default-java --enable-mpi-java
@@ -88,7 +92,7 @@
--disable-silent-rules \
--disable-wrapper-runpath \
--with-package-string="Debian OpenMPI" \
-   $(VERBS) $(FABRIC) $(PSM) $(CMA) $(PMIX) \
+   $(VERBS) $(FABRIC) $(PSM) $(PSM2) $(CMA) $(PMIX) \
$(ENABLE_BUILTIN_ATOMICS) \
$(JAVA) \
$(STATIC_CONFIG_PARAMS) \

I think you meant
+   PSM2:= --with-psm2
not
+   PSM:= --with-psm2

since that's the variable you are using later on.

Lucas

Bug#901476: stretch-pu: package systemd/232-25+deb9u4

[Michael Biebl]

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

Hi,

I'd like to make a stable upload fixing a few (minor) issues that were
requested to be fixed by various users.
Strictly speaking, those issues are not important per se and would
therefore qualify for a stable upload, but given the importance of the
systemd package, making it work more smoothly seems worthwile
nonetheless.

The full debdiff is attached.
All changes are cherry-picked upstream fixes, i.e. are in
unstable/testing.

systemd (232-25+deb9u4) stretch; urgency=medium

  * core/load-fragment: Add RemoveIPC=
Allow RemoveIPC= to be set in the unit file not only via D-Bus.
(Closes: #892829)

https://salsa.debian.org/systemd-team/systemd/commit/6854cdeb080e5c35a93430f0efcd2fc15c4b7012

  * nspawn: Add missing -E to getopt_long.
The -E alias for --setenv in systemd-nspawn was not working as
documented. This commit fixes that by adding -E to getopt_long.
(Closes: #895798)

https://salsa.debian.org/systemd-team/systemd/commit/c16bbb83f6adbb1766932b21f45dd9a9def8f948

  * login: Respect --no-wall when cancelling a shutdown request
(Closes: #897938)

https://salsa.debian.org/systemd-team/systemd/commit/2aceef88c722b31352c63b403ecc829da23a8e08


Those changes do not touch udeb, so should not be affected d-i.
That said, I've CCed KiBi, as usual, for a d-i ACK.

Regards,
Michael


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

Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/changelog b/debian/changelog
index 1117655..a81c855 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+systemd (232-25+deb9u4) stretch; urgency=medium
+
+  * core/load-fragment: Add RemoveIPC=
+Allow RemoveIPC= to be set in the unit file not only via D-Bus.
+(Closes: #892829)
+  * nspawn: Add missing -E to getopt_long.
+The -E alias for --setenv in systemd-nspawn was not working as
+documented. This commit fixes that by adding -E to getopt_long.
+(Closes: #895798)
+  * login: Respect --no-wall when cancelling a shutdown request
+(Closes: #897938)
+
+ -- Michael Biebl   Wed, 13 Jun 2018 22:20:36 +0200
+
 systemd (232-25+deb9u3) stretch; urgency=medium
 
   [ Cyril Brulebois ]
diff --git a/debian/patches/core-load-fragment-add-RemoveIPC-7288.patch 
b/debian/patches/core-load-fragment-add-RemoveIPC-7288.patch
new file mode 100644
index 000..b74f2d8
--- /dev/null
+++ b/debian/patches/core-load-fragment-add-RemoveIPC-7288.patch
@@ -0,0 +1,28 @@
+From: Yu Watanabe 
+Date: Fri, 10 Nov 2017 18:15:55 +0900
+Subject: core/load-fragment: add RemoveIPC= (#7288)
+
+PR #3865 introduced RemoveIPC= but the option is not listed in
+load-fragment-gperf.gperf. So, the option could be used only via d-bus.
+This adds RemoveIPC= in load-fragment-gperf.gperf. Then, now we can
+set the option in unit files.
+
+Fixes #7281.
+
+(cherry picked from commit c54515b1e42384ad4c582f7fb13434f9224c148f)
+---
+ src/core/load-fragment-gperf.gperf.m4 | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/src/core/load-fragment-gperf.gperf.m4 
b/src/core/load-fragment-gperf.gperf.m4
+index cb2f384..10a5682 100644
+--- a/src/core/load-fragment-gperf.gperf.m4
 b/src/core/load-fragment-gperf.gperf.m4
+@@ -35,6 +35,7 @@ $1.Environment,  config_parse_environ,   
0,
+ $1.EnvironmentFile,  config_parse_unit_env_file, 0,   
  offsetof($1, exec_context.environment_files)
+ $1.PassEnvironment,  config_parse_pass_environ,  0,   
  offsetof($1, exec_context.pass_environment)
+ $1.DynamicUser,  config_parse_bool,  0,   
  offsetof($1, exec_context.dynamic_user)
++$1.RemoveIPC,config_parse_bool,  0,   
  offsetof($1, exec_context.remove_ipc)
+ $1.StandardInput,config_parse_exec_input,0,   
  offsetof($1, exec_context)
+ $1.StandardOutput,   config_parse_exec_output,   0,   
  offsetof($1, exec_context)
+ $1.StandardError,config_parse_exec_output,   0,   
  offsetof($1, exec_context)
diff --git 
a/debian/patches/login-change-variable-type-of-enable_wall_messages-as-it-.patch
 
b/debian/patches/login-change-variable-type-of-enable_wall_messages-as-it-.patch
new file mode 100644
index 000..1018019
--- /dev/null
+++ 

Bug#837458: jessie-pu: package mactelnet/0.4.0-1

[Adam D. Barratt]

Control: tags -1 -moreinfo

On Thu, 2017-01-05 at 20:06 +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sun, 2016-09-11 at 19:55 +0200, haakon.nessj...@gmail.com wrote:
> 
> > Request for uploading to stable, as there is posted a CVE for a bug
> > in mactelnet-client.
> > This update is a backport of the fix that is done upstream, that
> > fixes only the mentioned bug.
> > 
> > Mor information here: https://security-tracker.debian.org/tracker/C
> > VE-2016-7115
> > and here: https://bugs.debian.org/836320
> 
> +mactelnet (0.4.0-2) stable; urgency=low
> 
> The version should be 0.4.0-1+deb8u1. With that change, please go
> ahead.
> 

And the distribution should be "jessie". If this is still of interest,
please upload *soon*.

Regards,

Adam

Bug#877457: stretch update for trafficserver

[Jean Baptiste Favre]

Hello Adrian,
Sorry for my late answer.

I opened a bug against release.debian.org [1] to backport the fix, which
has been declined.

I'm afraid the dependency issue won't be solved in stable.

Cheers,
JB

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

On 20/03/2018 22:43, Adrian Bunk wrote:
> On Fri, Mar 16, 2018 at 02:47:42PM +0100, Jean Baptiste Favre wrote:
>> Hello Adrian,
> 
> Hello Jean,
> 
>> I'd love to fix  it for Stretch.
> 
> thanks!
> 
>> But, I'm only a Debian Maintainer and I'm not sure I've upload rights.
> 
> Your upload rights also work for uploads to (old)stable
> (and this is nothing that would go through NEW).
> 
>> Besides, I don't know the exact procedure I'll have to follow to
>> propagate such fixes to stable (but I'm eager to learn it :) )
> 
> https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable
> 
>> Cheers,
>> Jean Baptiste
> 
> cu
> Adrian
> 
>> On 14/03/2018 18:58, Adrian Bunk wrote:
>>> On Wed, Jan 17, 2018 at 09:42:09AM +, Debian Bug Tracking System wrote:
 ...
  trafficserver (7.1.1-1) unstable; urgency=medium
  .
* Fix trafficserver-dev dependencies. (Closes: #877457)
 ...
>>>
>>> Thanks a lot for fixing this bug for unstable.
>>>
>>> It is still present in stretch, could you also fix it there?
>>> Alternatively, I can fix it for stretch if you don't object.
>>>
>>> Thanks
>>> Adrian
>>>
> 




signature.asc
Description: OpenPGP digital signature

Bug#901475: RM: trafficserver [armhf] -- ROM; Unsupported upstream on armhf

[Jean Baptiste Favre]

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear FTP team,

Please delete the package from armhf architecture to enable testing migration.
Upstream doesn't suppport 32 bits architecture anymore.

Cheers,
JB

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEToRbojDLTUSJBphHtN1Tas99hzcFAlshed1fFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDRF
ODQ1QkEyMzBDQjRENDQ4OTA2OTg0N0I0REQ1MzZBQ0Y3RDg3MzcACgkQtN1Tas99
hzduARAAjcS+CuyuPSow0HlQP2xcedDBVyDWvLNNYoo4+IhTmJCXMIqUO6FSRS5r
NvNM2TaaxMisPhl+wiwe4ZJ+VewBQJHR49RXkMdArT06XqsTBLyYm07uEFGyz7bq
aA7Nk7f1wt6TwqNdpVGkIuByyweEYXTNZoAlggYmLPsRyDq5VY2UY3LhnOGo8jzw
/a+eK0nCLZKIsczKOFa7+reitYvCcnK8PNEuLiVdVbWQbzDhcecjaGqzqVOd+sSs
rNwZ/ibnOIyhVMWHbXZ/yRgg28nSc24NZ3XlhC946SHP2A22TTPDGqNiLNlBeXxs
UrZmf4D0R1SpH6P89Gqa0r6iv5Ez/dAwLlrjnLhqh/QUCeP7/VSSgQIugBUAvo+n
L8KOb7EsfIxtJPAJ/DMYFO85c9C9pIK2wy98p1W5rIRbuwM7Ju5lp+L3wR+/hM1W
GdvmCCpMmlKsaUIN5RiMdFPDBxWZSySBeL95V0Z8j37wLpDKFulBSRS3qm3ckawB
njg4yBxp2c16dNPDUdO4ijD5q70gJEdOmuX5akeDXwHQ1lJYNb6C0DL87YAs5WsB
CJzW2DAYqrMkyaG7aMCJeg2RRoC/LuIImivPd9zd49jZPSWF/RW6VCgvFc5iT9R9
fuJc1rRiVkAWZ2bLwfeUppwa0ytRXsSxUa6D6V59mLKynwjkCaA=
=sOuX
-END PGP SIGNATURE-

Bug#848365: jessie-pu: package coquelicot/0.9.2-4+deb8u1

[Adam D. Barratt]

On Sat, 2017-01-07 at 17:06 +0100, Julien Cristau wrote:
> On Thu, Jan  5, 2017 at 10:20:19 +0100, Jérémy Bobbio wrote:
> 
> > You are right. I agree it's not a minimal change but the initscript
> > using init-d-script has been in Stretch for more than a year. I
> > thought
> > it would be safer to use a version that has received more testing
> > than
> > to patch the older one. I could still do that if you'd prefer.
> > 
> 
> Yes please.
> 

There's been no follow-up since that point, and we're now only a few
days away from closing updates to jessie before it becomes LTS.

Is this something you're still interested in addressing?

Regards,

Adam

Bug#841234: jessie-pu: package libiberty/20141014-1

[Adam D. Barratt]

On Sat, 2016-12-17 at 11:42 +0100, Julien Cristau wrote:
> Control: tag -1 moreinfo
> 
> On Tue, Oct 18, 2016 at 20:32:56 +0200, Anton Gladky wrote:
> 
> > Package: release.debian.org
> > Severity: normal
> > Tags: jessie
> > User: release.debian@packages.debian.org
> > Usertags: pu
> > 
> > Dear release team,
> > 
> > libiberty needs to be updated in Jessie, because the newer version
> > fixes many security issues:
> > 
> > CVE-2016-4487 CVE-2016-4488 CVE-2016-4489 CVE-2016-4490
> > CVE-2016-4492 CVE-2016-4493 CVE-2016-2226 CVE-2016-6131
> > 
> 
> What makes it impossible to backport just the fixes for the above
> issues, rather than importing a full new upstream release?  A short
> description of the issues so we don't have to look them up would also
> have been helpful.
> 

Ping? The above was 18 months ago, and we're within a few days of
closing updates to jessie before it becomes LTS.

Regards,

Adam

Bug#804787: jessie-pu: package servefile/0.4.3-1

[Adam D. Barratt]

On Fri, 2016-01-01 at 18:08 +, Adam D. Barratt wrote:
> On Tue, 2015-11-24 at 18:01 +0100, Sebastian Lohff wrote:
> > I attached a new debdiff with a more meaningful changelog.
> > 
> > +servefile (0.4.4-1~deb8u1) jessie; urgency=high
> > +
> > +  * Upstream bugfix release
> > +  * Fix for path traversal bug in directory listing mode
> > +  * SSL hardening (prefer TLS1.2/TLS1)
> 
> Thanks.
> 
> +   # choose TLS1.2 or TLS1, if available
> +   sslMethod = None
> +   if hasattr(SSL, "TLSv1_2_METHOD"):
> +   sslMethod = SSL.TLSv1_2_METHOD
> +   elif hasattr(SSL, "TLSv1_METHOD"):
> +   sslMethod = SSL.TLSv1_METHOD
> 
> Why is TLS1.1 explicitly avoided here? Might it make more sense to
> use
> TLS_METHOD and SSL_OP_NO_SSLv3 and let the client and server
> negotiate
> the highest mutually-supported protocol?
> 

Ping?

The above mail was sent nearly 2.5 years ago, and there's been no
follow-up. The window for getting fixes into jessie before it becomes
LTS closes during the coming weekend.

Regards,

Adam

Bug#901474: [nodejs][RFC] Multiarch and /usr/local search path

[Bastien ROUCARIÈS]

Package: nodejs
Version: 10.4.0~dfsg-2
Severity: important
tags: patch


Hi,

In order to get search path in multiarch path and in /usr/local I use the 
following patch

/usr/local part will allow to satisfy policy 9.1.2 and the other part to get 
node package multiarch like perl or python.

I think this patch could be upstreamed if needed

search order is :
usr/local/lib/$(DEB_HOST_MULTIARCH)/nodejs:/usr/local/share/nodejs:/usr/local/lib/nodejs:/usr/lib/$(DEB_HOST_MULTIARCH)/nodejs:/usr/share/nodejs:/usr/lib/nodejs

note that /usr/lib/nodejs will tested last.

You could check the patch by doing require('os').constants and see 
 ARCH_TRIPLET: 'x86_64-linux-gnu',
  GLOBAL_NODE_PATH:
   
'/usr/local/lib/x86_64-linux-gnu/nodejs:/usr/local/share/nodejs:/usr/local/lib/nodejs:/usr/lib/x86_64-linux-gnu/nodejs:/usr/share/nodejs:/usr/lib/nodejs',

then checking the load path by:
require('module')
and see the array globalPaths:
lobalPaths:
   [ '/home/bastien/.node_modules',
 '/home/bastien/.node_libraries',
 '/usr/local/lib/x86_64-linux-gnu/nodejs',
 '/usr/local/share/nodejs',
 '/usr/local/lib/nodejs',
 '/usr/lib/x86_64-linux-gnu/nodejs',
 '/usr/share/nodejs',
 '/usr/lib/nodejs' ],

I have also added arch triplet because some module will need it.

Bastien

diff --git a/debian/patches/pass-arch-dir-to-constants 
b/debian/patches/pass-arch-dir-to-constants
new file mode 100644
index ..b12f0f4e
--- /dev/null
+++ b/debian/patches/pass-arch-dir-to-constants
@@ -0,0 +1,51 @@
+Index: nodejs/src/node_constants.cc
+===
+--- nodejs.orig/src/node_constants.cc
 nodejs/src/node_constants.cc
+@@ -1309,6 +1309,15 @@ void DefineConstants(v8::Isolate* isolat
+   NODE_DEFINE_CONSTANT(fs_constants, UV_FS_COPYFILE_FICLONE);
+   NODE_DEFINE_CONSTANT(fs_constants, UV_FS_COPYFILE_FICLONE_FORCE);
+ 
++  // Define arch triplet
++#ifdef DEBIAN_ARCH_TRIPLET
++  NODE_DEFINE_STRING_CONSTANT(os_constants, "ARCH_TRIPLET", 
DEBIAN_ARCH_TRIPLET);
++#endif
++
++#ifdef DEBIAN_GLOBAL_NODE_PATH
++  NODE_DEFINE_STRING_CONSTANT(os_constants, "GLOBAL_NODE_PATH", 
DEBIAN_GLOBAL_NODE_PATH);
++#endif
++
+   os_constants->Set(OneByteString(isolate, "dlopen"), dlopen_constants);
+   os_constants->Set(OneByteString(isolate, "errno"), err_constants);
+   os_constants->Set(OneByteString(isolate, "signals"), sig_constants);
+Index: nodejs/lib/internal/modules/cjs/loader.js
+===
+--- nodejs.orig/lib/internal/modules/cjs/loader.js
 nodejs/lib/internal/modules/cjs/loader.js
+@@ -26,6 +26,7 @@ const util = require('util');
+ const vm = require('vm');
+ const assert = require('assert').ok;
+ const fs = require('fs');
++const GLOBAL_NODE_PATH = (require("os").constants).GLOBAL_NODE_PATH;
+ const internalFS = require('internal/fs/utils');
+ const path = require('path');
+ const {
+@@ -768,7 +769,17 @@ Module._initPaths = function() {
+   } else {
+ prefixDir = path.resolve(process.execPath, '..', '..');
+   }
+-  var paths = [path.resolve(prefixDir, 'lib', 'nodejs')];
++  var paths = [];
++  // prefer /usr/local over /usr and arch over all
++
++  if (GLOBAL_NODE_PATH) {
++paths = GLOBAL_NODE_PATH.split(path.delimiter).filter(function 
pathsFilterCB(path) {
++  return !!path;
++}).concat(paths);
++  }
++  else {
++paths.push(path.resolve('/usr','lib','nodejs'));
++  }
+ 
+   if (homeDir) {
+ paths.unshift(path.resolve(homeDir, '.node_libraries'));
diff --git a/debian/patches/series b/debian/patches/series
index cd794b90..b35d3b3e 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -8,3 +8,4 @@ build-doc-using-js-yaml.patch
 test_ci_buildd.patch
 fix_disable_cctest.patch
 benchmark_without_alice.patch
+pass-arch-dir-to-constants
diff --git a/debian/rules b/debian/rules
index a9014f81..c0f3a53b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -188,6 +188,13 @@ CPPFLAGS+=-fPIC
 CFLAGS+=-g
 CPPFLAGS+=-g
 CXXFLAGS+=$(CPPFLAGS)
+
+GLOBAL_NODE_PATH= 
/usr/local/lib/$(DEB_HOST_MULTIARCH)/nodejs:/usr/local/share/nodejs:/usr/local/lib/nodejs
+GLOBAL_NODE_PATH:= 
$(GLOBAL_NODE_PATH):/usr/lib/$(DEB_HOST_MULTIARCH)/nodejs:/usr/share/nodejs:/usr/lib/nodejs
+
+CFLAGS+=-DDEBIAN_ARCH_TRIPLET=\"$(DEB_HOST_MULTIARCH)\" 
-DDEBIAN_GLOBAL_NODE_PATH=\"$(GLOBAL_NODE_PATH)\" 
+CPPFLAGS+=-DDEBIAN_ARCH_TRIPLET=\"$(DEB_HOST_MULTIARCH)\" 
-DDEBIAN_GLOBAL_NODE_PATH=\"$(GLOBAL_NODE_PATH)\"
+CXXFLAGS+=-DDEBIAN_ARCH_TRIPLET=\"$(DEB_HOST_MULTIARCH)\" 
-DDEBIAN_GLOBAL_NODE_PATH=\"$(GLOBAL_NODE_PATH)\"
 export CPPFLAGS
 export CXXFLAGS
 export CFLAGS


signature.asc
Description: This is a digitally signed message part.

Bug#819977: jessie-pu: package roger-router/1.8.9-2jessie1

[Adam D. Barratt]

Hi,

The below mail was sent over two years ago now, and there's been no
follow-up from you.

The window for getting fixes into jessie before it becomes LTS closes
during the coming weekend. Are you still interested in addressing these
issues?

Regards,

Adam

On Wed, 2016-04-06 at 17:51 +0100, Adam D. Barratt wrote:
> On 2016-04-06 17:37, Rolf Leggewie wrote:
> > On 04.04.2016 16:58, Adam D. Barratt wrote:
> > > > I'd like to request to upload a bug-fix for the roger-router
> > > > package
> > > > to Jessie.  This would fix bugs #798471 and #774116.
> > > > 
> > > > Roger Router is a tool to interact with Fritzbox hardware from
> > > > AVM.
> > > > One of the things it can do is to send a fax.  This was broken
> > > > until
> > > > version 1.8.9-3 because compilation happened as --with-cups-yes
> > > > assuming this would include cups-support when in fact this
> > > > disabled
> > > > a known-good code base for cups-support and replaced it with a
> > > > known-broken, experimental one.  The patches are cherry-picked
> > > > from
> > > > 1.8.9-3 and 1.8.9-4.
> > > 
> > > Please provide a source debdiff of the proposed package as built
> > > and
> > > tested on Jessie, rather than indvidual patches; that's what
> > > we'll be
> > > acking (or otherwise).
> > 
> > Sure.
> > 
> > I thought the individual patches would be easier to inspect and
> > approve/reject as necessary.  Attached is a single debdiff.
> 
> For one thing, the debdiff that people provide often doesn't
> actually 
> match the result of simply applying the patches...
> 
> +roger-router (1.8.9-2jessie1) jessie; urgency=medium
> 
> That style of version numbering has been discouraged for at least
> two 
> release cycles now - 1.8.9-2+deb8u1, please.
> 
> +  * do not build the experimental (!) cups backend. Closes: #774116
> +Upstream uses a very funny (NOT!) semantics to their make-
> switches.
> +Who would expect that "--with-cups=yes" actually DISABLES a
> working
> +cups support?
> 
> I'd prefer if we could drop the commentary here, or at least make
> the 
> description more factual.
> 
>   Build-Depends: debhelper (>= 9), dh-autoreconf,
>    libappindicator3-dev,
>    libcapi20-dev (>= 1:3.24),
> - libcups2-dev,
>    libebook1.2-dev,
> - libgconf2-dev,
> 
> I'm afraid that I'm somewhat confused here. How does building the
> CUPS 
> backend that does work not require development files for CUPS? Why
> is 
> libgconf2-dev dropped?
> 
> --- a/debian/libroutermanager0.symbols
> +++ b/debian/libroutermanager0.symbols
> @@ -81,7 +81,7 @@ libroutermanager.so.0 libroutermanager0 #MINVER#
>    fax_send@Base 1.8.4
>    fax_set_log_level@Base 1.8.4
>    fax_spandsp_workaround@Base 1.8.4
> - fax_spooler_new_dir_cb@Base 1.8.4
> +#MISSING: 1.8.9-2# fax_spooler_new_dir_cb@Base 1.8.4
>    fax_transfer@Base 1.8.4
>    faxophone_close@Base 1.8.4
>    faxophone_connect@Base 1.8.4
> 
> I realise that libroutermanager0 doesn't have any in-archive users 
> outside of roger-router itself, but that's surely still an ABI
> change.
> 
> Regards,
> 
> Adam
> 
> 

Bug#901473: jenkins.debian.org: Vary merged-usr in reproducibility testing?

[Chris Lamb]

Package: jenkins.debian.org
Severity: wishlist
X-Debbugs-CC: jrt...@debian.org

>From #debian-devel:

   < jrtc27> does r-b do merged/non-merged [usr] variation?
   
< lamby> No. Do you expect it to find *r-b* variations, or simply
 FTBFS?
 
   < jrtc27> lamby: both, but more worried about the former
   < jrtc27> e.g. systemd had been broken when built in usr-merge
 chroots as it searched PATH for various core utilities
   < jrtc27> the result was hard-coded in the output binary so blew up
 on non-usr-merge systems
   < jrtc27> (#843433)


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#821239: jessie-pu: package ledgersmb/1.3.40-1~deb8u1

[Adam D. Barratt]

On Sun, 2016-05-15 at 17:37 -0400, Robert James Clay wrote:
> Control: retitle -1 jessie-pu: package ledgersmb/1.3.40-1~deb8u1
> 
> On Sunday, May 15, 2016 09:58:06 AM Julien Cristau wrote:
> > The usual sequence is *not* unstable -> testing -> jessie-pu.  The
> > usual
> > sequence is to fix the bugs in unstable/testing, and then
> > separately
> > cherry-pick the fixes that warrant the stable update to the stable
> > version of the package,
> 
>   Thank you for clarifying that.  (My mistake; I was going too much
> by the 
> last time I did something like this, which was an upstream issue and
> not a 
> packaging issue...) 
> 
> 
> > so in this case that would mean preparing a ledgersmb 1.3.40-
> > 1+deb8u1 with
> > the fixes you want to see in stable, and not the unrelated upstream
> > bits.
> 
>   I'll take care of that and then update the bug again.

That was two years ago, and there's been no further activity.

The window for getting fixes into jessie before it becomes LTS closes
during this weekend. Is there still any interest here?

Regards,

Adam

Bug#863129: jessie-pu: package salt/2014.1.13+ds-3

[Adam D. Barratt]

Ping? We're a few days away from closing the window for the final
jessie point release before it becomes LTS.

Regards,

Adam


On Wed, 2017-06-28 at 01:44 +0200, Cyril Brulebois wrote:
> Control: tag -1 moreinfo
> 
> Hi,
> 
> Comments below:
> 
> Benjamin Drung  (2017-05-22):
> > diff -Nru salt-2014.1.13+ds/debian/patches/CVE-2015-6918.patch
> > salt-2014.1.13+ds/debian/patches/CVE-2015-6918.patch
> > --- salt-2014.1.13+ds/debian/patches/CVE-2015-6918.patch197
> > 0-01-01 01:00:00.0 +0100
> > +++ salt-2014.1.13+ds/debian/patches/CVE-2015-6918.patch201
> > 7-04-18 12:18:56.0 +0200
> > @@ -0,0 +1,46 @@
> > +From 528916548726976dcc75626dc6f6641ceb206ee3 Mon Sep 17 00:00:00
> > 2001
> > +From: Tarjei Husøy 
> > +Date: Wed, 19 Aug 2015 11:41:10 -0700
> > +Subject: [PATCH] Git: Don't leak https user/pw to log
> > +Origin: backport, https://github.com/saltstack/salt/commit/28aa9b1
> > 05804ff433d8f663b2f9b804f2b75495a
> > +
> > +---
> > + salt/modules/git.py| 17 ++---
> > + tests/unit/modules/git_test.py | 18 ++
> > + 2 files changed, 32 insertions(+), 3 deletions(-)
> > +
> > +--- a/salt/modules/git.py
> >  b/salt/modules/git.py
> > +@@ -5,6 +5,7 @@
> > + 
> > + # Import python libs
> > + import os
> > ++import re
> > + import tempfile
> > + try:
> > + import pipes
> > +@@ -75,6 +76,7 @@
> > + result = __salt__['cmd.run_all'](cmd,
> > +  cwd=cwd,
> > +  runas=runas,
> > ++ output_loglevel='quiet',
> > +  env=env,
> > +  **kwargs)
> > + 
> > +@@ -86,7 +88,15 @@
> > + if retcode == 0:
> > + return result['stdout']
> > + else:
> > +-raise exceptions.CommandExecutionError(result['stderr'])
> > ++stderr = _remove_sensitive_data(result['stderr'])
> > ++raise exceptions.CommandExecutionError(stderr)
> > ++
> > ++
> > ++def _remove_sensitive_data(sensitive_output):
> > ++'''
> > ++Remove HTTP user and password.
> > ++'''
> > ++return re.sub('(https?)://.*@', r'\1://@',
> > sensitive_output)
> 
> This is possibly going to remove too much stuff if one has something
> like ?
> 
> Anyway, it's probably an acceptable loss compared to the various
> security bug fixes, so it's probably a good idea to proceed anyway.
> 
> I'm tagging this with moreinfo for the time being, as some feedback
> from your side would be welcome.
> 
> 
> KiBi.

Bug#834854: jessie-pu: package charybdis/3.4.2-5~deb8u1

[Adam D. Barratt]

On Tue, 2016-09-13 at 12:04 +0200, Julien Cristau wrote:
> On Sun, Sep 11, 2016 at 16:58:34 -0400, Antoine Beaupré wrote:
> 
> > 1. ignore the above two extra issues and simply add the patch for
> > #215
> > to the pile of patches in jessie
> > 2. import the new gnutls.c module from an eventual new 3.5 release
> > upstream directly in jessie - this may be difficult because of
> > internal
> > API changes
> > 3. import 3.5.x directly in jessie
> > 
> > I would like to have feedback from the release team as to which
> > approach
> > to take forward.
> > 
> 
> I don't think 3 is a reasonable option.  The rest will depend on
> specifics.

There's been no further activity on this bug since the above, so I
think it's reasonable to say it's unlikely to be getting fixed in
jessie at this point?

Regards,

Adam

Bug#885617: stretch-pu: package libextractor/1:1.3-4

[Adam D. Barratt]

Control: tags -1 -moreinfo +confirmed

On Sun, 2018-02-25 at 19:18 +0100, Bertrand Marc wrote:
> Le 10/02/2018 à 11:13, Julien Cristau a écrit :
> > Control: tag -1 moreinfo
> > 
> > On Thu, Dec 28, 2017 at 17:11:02 +0100, Bertrand Marc wrote:
> > 
> > > diff -Nru libextractor-1.3/debian/patches/CVE-2017-15600.patch
> > > libextractor-1.3/debian/patches/CVE-2017-15600.patch
> > > --- libextractor-1.3/debian/patches/CVE-2017-15600.patch  1
> > > 970-01-01 01:00:00.0 +0100
> > > +++ libextractor-1.3/debian/patches/CVE-2017-15600.patch  2
> > > 017-12-28 11:39:33.0 +0100
> > > @@ -0,0 +1,29 @@
> > > +From: Bertrand Marc , Markus Koschany  > > ian.org>
> > > +Subject: CVE-2017-15600
> > > +
> > > +Bug-Upstream: http://lists.gnu.org/archive/html/bug-libextractor
> > > /2017-10/msg4.html
> > > +Origin: https://gnunet.org/git/libextractor.git/commit/?id=38e89
> > > 33539ee9d044057b18a971c2eae3c21aba7
> > > +--- a/src/plugins/nsf_extractor.c
> > >  b/src/plugins/nsf_extractor.c
> > > +@@ -152,13 +152,17 @@
> > > +   char nsfversion[32];
> > > +   const struct header *head;
> > > +   void *data;
> > > ++  ssize_t ds;
> > > + 
> > > +-  if (sizeof (struct header) >
> > > +-  ec->read (ec->cls,
> > > +-,
> > > +-sizeof (struct header)))
> > > ++  ds = ec->read (ec->cls,
> > > ++ ,
> > > ++ sizeof (struct header));
> > > ++  if ( (-1 == ds) ||
> > > ++   (sizeof (struct header) > ds) )
> > > + return;
> > > +   head = data; 
> > > ++  if (NULL == head)
> > > ++return 0; 
> > > + 
> > 
> > Curious how that works.  3 lines above is plain "return", and here
> > "return 0".  What's the type of that function and how did the
> > compiler
> > not flag this?
> > 
> > Cheers,
> > Julien
> 
> Indeed, sorry. The type of the function was changed from void (in
> wheezy) to int (in jessie). I updated the patch attached accordingly.
> 

Please go ahead.

Regards,

Adam

Bug#863862: jessie-pu: package multipath-tools/0.5.0-6+deb8u2

[Adam D. Barratt]

On Wed, 2017-06-28 at 02:04 +0200, Cyril Brulebois wrote:
[...]
> The patches themselves look reasonable to me though.
> 
> 
> To sum it up: please adjust metadata for both bug reports in the BTS,
> and send a cleaner debdiff for a second look.
> 

Ping? We're a few days away from closing the window for the final
jessie point release before it becomes LTS.

Regards,

Adam

Bug#885619: jessie-pu: package libextractor/1:1.3-2

[Adam D. Barratt]

Control: tags -1 -moreinfo +confirmed

On Mon, 2018-06-11 at 22:07 +0200, Bertrand Marc wrote:
> Le 08/06/2018 à 22:24, Adam D. Barratt a écrit :
> > Control: tags -1 + moreinfo
> > 
> > On Thu, 2017-12-28 at 17:32 +0100, Bertrand Marc wrote:
> > > Would you allow an update of libextractor 1.3-2 in Jessie to fix
> > > several minor security issues?
> > > 7 issues skipped by the security teams:
> > > 
> > 
> > [...]
> > >    * CVE-2017-15600  > > CVE-
> > > 2017-15600>: In GNU Libextractor 1.4, there is a NULL Pointer
> > > Dereference in the
> > >  EXTRACTOR_nsf_extract_method function of
> > > plugins/nsf_extractor.c.
> > > 
> > 
> > I assume the same issue that Julien raised for the stretch package
> > applies here.
> > 
> > Regards,
> > 
> > Adam
> 
> Indeed. The attached patch would fix the issue.

Thanks. Please go ahead.

Regards,

Adam

Bug#837388: jessie-pu: package scons-doc/2.3.1-1

[Adam D. Barratt]

On Sat, 2017-01-28 at 16:51 +, Adam D. Barratt wrote:
> Ping?
> 
> On Sat, 2016-09-17 at 22:27 +0100, Adam D. Barratt wrote:
> > Control: tags -1 + moreinfo
> > 
> > On Sun, 2016-09-11 at 11:13 +0200, Jörg Frings-Fürst wrote:
> > > the version 2.3.1-1 contains non free svg files[1].
> > > The attached debdiff replace them with free files from upstream.
> > 
> > So far as I can tell, the situation is that:
> > 
> > - the files are "only" non-free, not also non-distributable
> > - "replacing" the files in practice just means changing the license
> > information embedded within the files
> > - Debian has a valid license to distribute the files under, which
> > is
> > already documented in the package in unstable
> > 
> > Is all of the above correct? If so, we have generally treated such
> > situations as representing documentation updates, which means they
> > can
> > be included as part of uploads to stable alongside other fixes, but
> > not
> > usually on their own.
> > 

Ping? We're a few days away from closing the window for the final
jessie point release before it becomes LTS.

Regards,

Adam

Bug#831459: jessie-pu: package virtualbox-guest-additions-iso

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2016-09-29 at 17:45 +0100, Adam D. Barratt wrote:
> On 2016-09-29 14:37, Gianfranco Costamagna wrote:
> > control: tags -1 -moreinfo
> > > (I'm not removing moreinfo tag)
> > 
> > removing it now.
> 
> fwiw the mail you're replying to does not appear to have made it to 
> debian-release.
> 

If you're still interested in getting this updated in jessie before it
becomes LTS, please go ahead, bearing in mind the time constraints.

Regards,

Adam

Bug#901472: deborphan: Repository should be migrated to Salsa

[Aurélien COUDERC]

Package: deborphan
Version: 1.7.28.8-0.3+b1
Severity: normal

Dear Maintainer,

deborphan is still using alioth as the VCS.
It should be migrated to salsa now that Alioth is down.


Cheers,
--
Aurélien



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

Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages deborphan depends on:
ii  libc6  2.27-3

Versions of packages deborphan recommends:
ii  apt   1.6.1
pn  dialog
ii  gettext-base  0.19.8.1-6+b1

deborphan suggests no packages.

-- no debconf information

Bug#900581: linux: Enable Buster kernel features for newer ARM64 servers.

[Geoff Levand]

On 06/09/2018 05:15 AM, Ian Campbell wrote:

> I think this is probably something for the arch (or perhaps platform)
> code to deal with. See for example all the various platform quirks in
> arch/x86/kernel/acpi/boot.c, which fixup various wrongness and/or
> disable features.

I followed your advice and created a fix in the arm64 acpi init
code of arch/arm64/kernel/acpi.c.  Here's the submission:

  https://marc.info/?l=linux-acpi=152891415600796=2
  https://www.spinics.net/lists/linux-acpi/msg82887.html

Bug#901439: ntpsec: peers not found when starting under post-4.17.0 kernels

[Richard Laager]

This seems related:
https://patchwork.ozlabs.org/patch/928421/

It looks like a kernel change broke userspace and has been or is in the
process of being reverted?

-- 
Richard

Bug#901276: jessie-pu: package lame/3.99.5+repack1-7+deb8u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2018-06-10 at 14:59 -0400, Hugo Lefeuvre wrote:
> lame 3.99.5+repack1-7+deb8u1 is affected by several vulnerabilities
> in
> the code used to read the input file. These issues are not present in
> any Debian release after Jessie because the package switched to
> libsndfile to read and write audio files. The upstream code itself
> was
> recently fixed in 3.100.
> 
> Following advices from lame's upstream and from lame's maintainer I
> proposed the attached patch. In this patch we modify the Jessie
> package to use libsndfile instead of the internal code. The security
> team considers these issues not worth a DSA but recommended me to
> submit this patch as jessie-pu.
> 

+lame (3.99.5+repack1-7+deb8u2) oldstable; urgency=high

Please use "jessie" as the distribution there, and feel free to upload.

Regards,

Adam

Bug#901233: wbulgarian: Word list file should be in UTF-8, not in ISO-8859 anymore

[Damyan Ivanov]

-=| Pander, 13.06.2018 16:03:01 +0200 |=-
> Yes, see
> 
> $ ls -l wbulgarian_4.1-5_all.deb
> -rw-rw-r-- 1 sander sander 1468408 Jun 13 13:18 wbulgarian_4.1-5_all.deb
> 
> after dpkg -x and gunzip:
> 
> $ file usr/share/doc/wbulgarian/changelog
> usr/share/doc/wbulgarian/changelog: ISO-8859 text

Ah, *that* one. I was looking at the debian changelog.

4.1-6 will have that fixed.

Bug#804638: me too

[Andras Korn]

Hi,

I also have this problem on and off. I have not yet been able to discern any
pattern. Sometimes it seems that starting certain applications (like the
Citrix ICA client, with an actual remote window open) brings it about; other
times, it seems like the system rolls dice on boot, and on unlucky rolls I
get the notification until I reboot (but I haven't verified this).

The following gets logged to .xsession-errors whenever the "window switcher
installation is broken" notification is displayed:

2018-06-13 19:31:55.120698500 Currrent active notifications: 
QHash(("notification 4", "KDE Power Management SystemBattery Critical (5% 
Remaining)"))
2018-06-13 19:31:55.120740500 Guessing partOf as: 0
2018-06-13 19:31:55.120751500  New Notification:  "" "The Window Switcher 
installation is broken, resources are missing.\nContact your distribution about 
this." 2 & Part of: 0
2018-06-13 19:31:55.125681500 QXcbConnection: XCB error: 3 (BadWindow), 
sequence: 26941, resource id: 100663316, major code: 18 (ChangeProperty), minor 
code: 0

Possibly relevant package versions:

ii  kdeplasma-addons-data  4:5.12.5-1 all  
locale files for kdeplasma-addons
ii  kwin-addons4:5.12.5-1 amd64
additional desktop and window switchers for KWin
ii  kwin-common4:5.12.5-1 amd64KDE 
window manager, common files
ii  kwin-data  4:5.12.5-1 all  KDE 
window manager data files
ii  kwin-style-breeze  4:5.12.5-1 amd64KWin 
Breeze Style
ii  kwin-x11   4:5.12.5-1 amd64KDE 
window manager, X11 version
ii  libkf5plasma5:amd645.46.0-1   amd64
Plasma Runtime components
ii  libkf5plasmaquick5:amd64   5.46.0-1   amd64
Plasma Runtime components
ii  libkwin4-effect-builtins1  4:5.12.5-1 amd64KDE 
window manager effect builtins library
ii  libkwineffects11   4:5.12.5-1 amd64KDE 
window manager effects library
ii  libkwineffects1abi54:4.11.22-3amd64
library used by effects for the KDE window manager
ii  libkwinglutils11   4:5.12.5-1 amd64KDE 
window manager gl utils library
ii  libkwinglutils1abi24:4.11.22-3amd64
library with OpenGL utilities for the KDE window manager
ii  libkwinxrenderutils11  4:5.12.5-1 amd64KDE 
window manager render utils library
ii  libplasma-geolocation-interface4   4:4.11.22-3amd64
library for the Plasma geolocation
ii  libplasma-geolocation-interface5   4:5.12.5-1 amd64
Plasma Workspace for KF5 library
ii  libplasma3 4:4.14.36-1amd64
Plasma Library for the KDE Platform
ii  libplasmaclock4abi44:4.11.22-3amd64
library for Plasma clocks
ii  libplasmagenericshell4 4:4.11.22-3amd64
shared elements for all the plasma shells
ii  plasma-containments-addons 4:4.14.2-1 amd64
additional containment plugins for Plasma
ii  plasma-dataengines-addons  4:5.12.5-1 amd64
additional data engines for Plasma
ii  plasma-desktop 4:5.12.5-1 amd64
Tools and widgets for the desktop
ii  plasma-desktop-data4:5.12.5-1 all  
Tools and widgets for the desktop data files
ii  plasma-framework   5.46.0-1   amd64
Plasma Runtime components
ii  plasma-integration 5.12.5-1   amd64Qt 
Platform Theme integration plugins for KDE Plasma
ii  plasma-scriptengine-javascript 4:17.08.3-2amd64
JavaScript script engine for Plasma
ii  plasma-wallpapers-addons   4:5.12.5-1 amd64
additional wallpaper plugins for Plasma 5
ii  plasma-widget-adjustableclock  4.1.4-1amd64
Plasma widget clock to show date and time
ii  plasma-widget-folderview   4:16.04.1-1amd64
plasma widget showing the content of a folder
ii  plasma-workspace   4:5.12.5-1 amd64
Plasma Workspace for KF5
ii  qml-module-org-kde-kwindowsystem:amd64 5.46.0-1   amd64
provides integration of QML and KDE frameworks - kwindowsystem

I'd be happy to attach an strace to the relevant process, but I have no idea
which process that is. On a hunch, I tried the plasmashell process; grepping
for system calls that return errors, I see:

[pid  5402] <... futex resumed> )   = -1 EAGAIN (Resource temporarily 
unavailable)
[pid  5402] <... futex resumed> )   = -1 EAGAIN (Resource temporarily 
unavailable)
[pid  

Bug#901471: thunderbird: AppArmor denies access to ~/.cache/mesa_shader_cache/index after recent Mesa update

[Vincas Dargis]

Package: thunderbird
Version: 1:60.0~b6-1
Severity: normal
Tags: upstream

Dear Maintainer,

I've noticed new DENIED message after recent pack of Sid updates, where
some new Mesa packages where received:

```
type=AVC msg=audit(1528914778.433:521): apparmor="DENIED" operation="open" 
profile="thunderbird" name="/home/vincas/.cache/mesa_shader_cache/index" 
pid=10212 comm="thunderbird" requested_mask="wrc" denied_mask="wrc" fsuid=1000 
ouid=1000
```

Breakpoint:

```
#0  0x7f8f8600942e in __libc_open64 (file=0x7f8f84fc8370 
"/home/vincas/.cache/mesa_shader_cache/index", oflag=524354) at 
../sysdeps/unix/sysv/linux/open64.c:47
#1  0x7f8f6ebeb4c1 in  () at /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#2  0x7f8f6ed2db72 in  () at /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#3  0x7f8f6ed5ca34 in  () at /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#4  0x7f8f6ecef304 in  () at /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#5  0x7f8f70975b47 in  () at /lib/x86_64-linux-gnu/libGLX_mesa.so.0
#6  0x7f8f7094995e in  () at /lib/x86_64-linux-gnu/libGLX_mesa.so.0
#7  0x7f8f70945134 in  () at /lib/x86_64-linux-gnu/libGLX_mesa.so.0
#8  0x7f8f70945fb5 in  () at /lib/x86_64-linux-gnu/libGLX_mesa.so.0
#9  0x7f8f77c5bb8f in  () at /usr/lib/thunderbird/libxul.so
#10 0x7f8f77c5be57 in  () at /usr/lib/thunderbird/libxul.so
#11 0x7f8f77c5161e in  () at /usr/lib/thunderbird/libxul.so
#12 0x7f8f77c56d2a in  () at /usr/lib/thunderbird/libxul.so
#13 0x7f8f77c575a2 in  () at /usr/lib/thunderbird/libxul.so
#14 0x5652e6558d6c in  ()
#15 0x5652e65584d9 in  ()
#16 0x7f8f8512fa87 in __libc_start_main (main=0x5652e6558470, argc=1, 
argv=0x7ffe2c3b9828, init=, fini=, 
rtld_fini=, stack_end=0x7ffe2c3b9818) at ../csu/libc-start.c:310
#17 0x5652e65587ea in _start ()

```

I guess some abstraction should be updated/created, as I got same error
with Firefox and Dragon Player local profiles.

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

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

Versions of packages thunderbird depends on:
ii  debianutils   4.8.6
ii  fontconfig2.13.0-5
ii  libatk1.0-0   2.28.1-1
ii  libc6 2.27-3
ii  libcairo-gobject2 1.15.10-3
ii  libcairo2 1.15.10-3
ii  libdbus-1-3   1.12.8-3
ii  libdbus-glib-1-2  0.110-2
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-8
ii  libfontconfig12.13.0-5
ii  libfreetype6  2.8.1-2
ii  libfribidi0   0.19.7-2
ii  libgcc1   1:8.1.0-5
ii  libgdk-pixbuf2.0-02.36.11-2
ii  libglib2.0-0  2.56.1-2
ii  libgtk-3-03.22.30-1
ii  libgtk2.0-0   2.24.32-1
ii  libhunspell-1.6-0 1.6.2-1+b1
ii  libjsoncpp1   1.7.4-3
ii  libnspr4  2:4.19-3
ii  libnss3   2:3.37.1-1
ii  libpango-1.0-01.42.1-1
ii  libpangocairo-1.0-0   1.42.1-1
ii  libpangoft2-1.0-0 1.42.1-1
ii  libsqlite3-0  3.24.0-1
ii  libstartup-notification0  0.12-5
ii  libstdc++68.1.0-5
ii  libvpx5   1.7.0-3
ii  libx11-6  2:1.6.5-1
ii  libx11-xcb1   2:1.6.5-1
ii  libxcb-shm0   1.13-1
ii  libxcb1   1.13-1
ii  libxext6  2:1.3.3-1+b2
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  psmisc23.1-1+b1
ii  x11-utils 7.7+4
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages thunderbird recommends:
ii  hunspell-ar [hunspell-dictionary] 3.2-1
ii  hunspell-en-gb [hunspell-dictionary]  1:6.0.3-3
ii  hunspell-en-us [hunspell-dictionary]  1:2018.04.16-1
ii  hunspell-lt [hunspell-dictionary] 1:6.0.3-3
ii  lightning 1:60.0~b6-1

Versions of packages thunderbird suggests:
ii  apparmor  2.13-1
pn  fonts-lyx 
ii  libgssapi-krb5-2  1.16-2

-- Configuration Files:
/etc/apparmor.d/usr.bin.thunderbird changed [not included]

-- no debconf information

Bug#848968: Bug#839162: marked as done (Enabled merged-/usr by default)

[Holger Levsen]

control: severity -1 important

On Wed, Jun 13, 2018 at 01:51:12PM +, Debian Bug Tracking System wrote:
> Changes:
>  debootstrap (1.0.102) unstable; urgency=medium
>  .
>* Enable merged-/usr by default (Closes: #839046)
>  This is applied for buster and later.

raising severity of this bug accordingly :)


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#901349: (no subject)

[Keverik]

Just as a note; it also requires the amdgpu raven firmware files to be 
added to the kernel-firmware.

Bug#901470: apparmor-utils: aa-logprof prints a lot of garbage with "Error: Unknown line found in file"

[Vincas Dargis]

Package: apparmor-utils
Version: 2.13-1
Severity: normal

Dear Maintainer,

This is what I get with `aa-logprof` after installing 2.13 from
experimental (no reboot yet):

```
ERROR: Syntax Error: Unknown line found in file 
cache.d/b64c78f3.0/usr.bin.dragon line 1455:
   version profile/usr/bin/dragonflagcaps64 
policydbaadfax=Pnotflex<▒▒▒ <   $▒"  $  .)7"▒/ ▒   
!*+,-%3546819:;3$!%-:68)41   ▒* %5 + ,"#$./  
&'()!02146-789aadfay}x=▒}xnotflex\udcd0\udc80 >\udc80\udc80  
>\udc80 0>\udc80\udc80>DD>D\udc91BEDDD  
>>>~\udc80D.  ^>>>DdDD>>>  $DD\udc80>>D  D > H\udc8`D  
D>D  DT .\udc80>DDD  ^  N\udc90BADD>D   .D>   D  > DD.  ^> 
DD. >  DDD. >  .DD. > DDD. > DDT .. >>DDT  ^  . uDDT   . DDTDDT DDT 
D.DDT >DDTDDT\udc80 .DD 
H\udc81DD\udc91^EDDD\udc91^E\udcd0 \udcc07 
\udc802 \udc80 \udc802 \udc802 \udc802 \udcc07 \udc802 \udc802 \udc802 \udc802 
\udc802 \udc802 \udc802 \udcc07 \udc802 \udc802 \udc802 \udcc07 \udcc07 \udc802 
\udcc07 \udc802 \udc802 \udc802 \udc802 \udc802 \udcc07 \udc802 \udc802 \udc802 
\udc802 \udc802 \udc802 \udc802 \udcc07 \udc802 \udc802 \udcc07 \udc802 \udcc07 
\udc802 \udcc07 \udc802@ \udcc07 \udc802@\udcd
 
```

Also, aa-logprof runs for ~30 seconds (on i7) before printing this.


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

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

Versions of packages apparmor-utils depends on:
ii  apparmor  2.13-1
ii  python3   3.6.5-3
ii  python3-apparmor  2.13-1

apparmor-utils recommends no packages.

Versions of packages apparmor-utils suggests:
pn  vim-addon-manager  

-- no debconf information

Bug#901194: jessie-pu: package openldap/2.4.40+dfsg-1+deb8u4

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2018-06-09 at 18:32 -0700, Ryan Tandy wrote:
> Please consider this openldap update for jessie. I apologize for the 
> late request and will understand if it doesn't make it.
> 
>   * Fix upgrade failure when olcSuffix contains a backslash. (Closes:
> #864719)
> 
[...]
>   * Import upstream patches to fix memory corruption caused by
> calling
> sasl_client_init() multiple times and possibly concurrently.
> (ITS#8648) (Closes: #860947)
> 

Please go ahead.

Regards,

Adam

Bug#901192: stretch-pu: package openldap/2.4.44+dfsg-5+deb9u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2018-06-09 at 18:01 -0700, Ryan Tandy wrote:
> Please consider this openldap update for stretch. I apologize for
> the 
> late request and will understand if it doesn't make it.
> 
> Both fixes have already had some time in testing and stretch-
> backports.
> 
>   * Import upstream patch to fix an out-of-sync issue with delta-
> syncrepl
> replication in multi-master environments, resulting from changes
> losing
> tracking information and being applied multiple times.
> (ITS#8) (Closes: #877166)
> 
> This issue impacts replication when the memberof overlay is used in
> a 
> multi-master setup. Sven Mäder (in X-D-CC) has tested the proposed 
> package on a stretch system and verified the fix.
> 
>   * Really fix upgrades when the config contains backslash-escaped
> special
> characters. The previous fix was incomplete and didn't fully fix
> upgrades
> involving a database reload. (Closes: #864719)
> 

Please go ahead.

Regards,

Adam

Bug#901469: mah-jong FTCBFS: uses the build architecture toolchain

[Helmut Grohne]

Source: mah-jong
Version: 1.11-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

mah-jong fails to cross build from source, because it uses the build
architecture toolchain. Using dh_auto_build mostly fixes that except for
bare pkg-config invocations in the upstream Makefile. After making them
substitutable as well, mah-jong cross builds successfully. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru mah-jong-1.11/debian/changelog 
mah-jong-1.11/debian/changelog
--- mah-jong-1.11/debian/changelog  2012-01-03 00:31:10.0 +0100
+++ mah-jong-1.11/debian/changelog  2018-06-13 20:10:04.0 +0200
@@ -1,3 +1,12 @@
+mah-jong (1.11-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_build pass cross tools to make.
++ cross.patch: Make pkg-config substitutable.
+
+ -- Helmut Grohne   Wed, 13 Jun 2018 20:10:04 +0200
+
 mah-jong (1.11-2) unstable; urgency=low
 
   * Switch to dpkg-source 3.0 (quilt) format.
diff --minimal -Nru mah-jong-1.11/debian/patches/cross.patch 
mah-jong-1.11/debian/patches/cross.patch
--- mah-jong-1.11/debian/patches/cross.patch1970-01-01 01:00:00.0 
+0100
+++ mah-jong-1.11/debian/patches/cross.patch2018-06-13 20:09:42.0 
+0200
@@ -0,0 +1,31 @@
+--- mah-jong-1.11.orig/Makefile
 mah-jong-1.11/Makefile
+@@ -67,6 +67,7 @@
+ 
+ # It's best to use gcc if you can.
+ CC = gcc
++PKG_CONFIG ?= pkg-config
+ 
+ # C debugging and optimization flags. 
+ # In development, we turn on all reasonable warnings.
+@@ -141,9 +142,9 @@
+ ifdef Win32
+ ifdef Gtk
+ # should be the same as unix, if it can find pkg-config
+-EXTRA_INCLUDES=$(shell pkg-config --cflags gtk+-$(Gtk))
++EXTRA_INCLUDES=$(shell $(PKG_CONFIG) --cflags gtk+-$(Gtk))
+ # We also add the flag that makes xmj.exe be a GUI program
+-GUILIBS=$(shell pkg-config --libs gtk+-$(Gtk)) -mwindows
++GUILIBS=$(shell $(PKG_CONFIG) --libs gtk+-$(Gtk)) -mwindows
+ else
+ # You'll need to say explicitly where they are, as here, which is
+ # a bit of a mess in my setup
+@@ -154,7 +155,7 @@
+ else
+ # Not Windows. If gtk+ is properly installed, this is all that's needed.
+ ifdef Gtk
+-EXTRA_INCLUDES=`pkg-config --cflags gtk+-$(Gtk)`
++EXTRA_INCLUDES=`$(PKG_CONFIG) --cflags gtk+-$(Gtk)`
+ GUILIBS=-lgtk-x11-2.0 -lgdk-x11-2.0 -lgobject-2.0 -lglib-2.0 -lm
+ else
+ EXTRA_INCLUDES=`gtk-config --cflags`
diff --minimal -Nru mah-jong-1.11/debian/patches/series 
mah-jong-1.11/debian/patches/series
--- mah-jong-1.11/debian/patches/series 2012-01-03 00:12:02.0 +0100
+++ mah-jong-1.11/debian/patches/series 2018-06-13 20:09:18.0 +0200
@@ -3,3 +3,4 @@
 extra_gui_libraries
 manpage_cleanup
 autogenerated_files
+cross.patch
diff --minimal -Nru mah-jong-1.11/debian/rules mah-jong-1.11/debian/rules
--- mah-jong-1.11/debian/rules  2012-01-03 00:29:08.0 +0100
+++ mah-jong-1.11/debian/rules  2018-06-13 20:10:02.0 +0200
@@ -25,7 +25,7 @@
 build-arch: build-stamp
 build-stamp:
dh_testdir
-   $(MAKE) CCOPTIONS=$(CCOPTIONS) CDEBUGFLAGS="-g" 
TILESETPATH=\""/usr/share/mah-jong"\"
+   dh_auto_build -- CCOPTIONS=$(CCOPTIONS) CDEBUGFLAGS="-g" 
TILESETPATH=\""/usr/share/mah-jong"\"
touch build-stamp
 
 clean:

Bug#887138: jessie-pu: package python-mimeparse/0.1.4-1+deb8u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2018-01-14 at 13:31 +0100, Andreas Beckmann wrote:
> Let's fix the python3 dependencies for jessie, too: #867439.
> 
> $ debdiff python3-mimeparse_0.1.4-1_all.deb python3-mimeparse_0.1.4-
> 1+deb8u1_all.deb
> File lists identical (after any substitutions)
> 
> Control files: lines which differ (wdiff format)
> 
> {+Depends: python3:any (>= 3.3.2-2~)+}
> Installed-Size: [-48-] {+13+}
> Version: [-0.1.4-1-] {+0.1.4-1+deb8u1+}
> 

Please go ahead.

Regards,

Adam

Bug#901468: madlib FTCBFS: abuses AC_CHECK_FILE

[Helmut Grohne]

Source: madlib
Version: 1.3.0-2.1
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

madlib fails to cross build from source, because it abuses AC_CHECK_FILE
to search for headers. The macro is meant for searching files on the
host system. Certainly madlib won't need any headers at runtime, so you
actually want to check headers on the build system. A simple "test -e"
is suitable for that. Please consider applying the attached patch.

Helmut
--- madlib-1.3.0.orig/configure.ac
+++ madlib-1.3.0/configure.ac
@@ -281,7 +281,7 @@
 
 dnl Check for gmm++ linear solver
 if test "x$enable_gmm" != "xno"; then
-  AC_CHECK_FILE(${srcdir}/Contrib/gmm/gmm.h,GMM="yes")
+  AS_IF([test -e "${srcdir}/Contrib/gmm/gmm.h"],[GMM="yes"])
   if test "x${GMM}" = "xyes"; then
 MAdLib_DEFS="${MAdLib_DEFS} -D_HAVE_GMM_"
 MAdLib_INCLUDES="${MAdLib_INCLUDES} -I\$(top_srcdir)/Contrib/gmm "
@@ -301,7 +301,7 @@
   if test "x${GMSH_PREFIX}" != "x"; then
 LDFLAGS="-L${GMSH_PREFIX}/lib ${LDFLAGS}"
   fi
-  AC_CHECK_FILE("${GMSH_PREFIX}/include/gmsh/Gmsh.h",GMSH="yes") 
+  AS_IF([test -e "${GMSH_PREFIX}/include/gmsh/Gmsh.h"],[GMSH="yes"])
 dnl  AC_CHECK_LIB(Gmsh,main,GMSH="yes",[],-lGmsh)
   if test "x${GMSH}" = "xyes"; then
 MAdLib_DEFS="${MAdLib_DEFS} -D_HAVE_GMSH_"
@@ -329,7 +329,7 @@
   if test "x${OCC_PREFIX}" != "x"; then
 LDFLAGS="-L${OCC_PREFIX}/lib ${LDFLAGS}"
   fi
-dnl  AC_CHECK_FILE("${OCC_PREFIX}/inc/Geom_Curve.hxx",OCC="yes") 
+dnl  AS_IF([test -e "${OCC_PREFIX}/inc/Geom_Curve.hxx"],[OCC="yes"])
   AC_CHECK_LIB(TKernel,main,OCC="yes",[],-lTKernel)
   if test "x${OCC}" = "xyes"; then
 MAdLib_DEFS="${MAdLib_DEFS} -D_HAVE_OCC_"
@@ -353,7 +353,7 @@
 
 dnl Check for ANN, the Approximate Nearest Neighbor library
 if test "x$enable_ann" != "xno"; then
-  AC_CHECK_FILE(${srcdir}/Contrib/ANN/include/ANN/ANN.h,ANN="yes") 
+  AS_IF([test -e "${srcdir}/Contrib/ANN/include/ANN/ANN.h"],[ANN="yes"])
   if test "x${ANN}" = "xyes"; then
 MAdLib_DEFS="${MAdLib_DEFS} -D_HAVE_ANN_"
 AC_DEFINE(_HAVE_ANN_)
@@ -372,7 +372,7 @@
 
 dnl Check for Mathex
 if test "x$enable_mathex" != "xno"; then
-  AC_CHECK_FILE(${srcdir}/Contrib/mathex/mathex.h,MATHEX="yes")
+  AS_IF([test -e "${srcdir}/Contrib/mathex/mathex.h"],[MATHEX="yes"])
   if test "x${MATHEX}" = "xyes"; then
 MAdLib_DEFS="${MAdLib_DEFS} -D_HAVE_MATHEX_"
 MAdLib_INCLUDES="${MAdLib_INCLUDES} -I\$(top_srcdir)/Contrib/mathex "

Bug#712451: Please support AppArmor network rules

[intrigeri]

intrigeri:
> Linux v4.17-rc1 now supports basic socket mediation, which will allow
> us to close this bug report:

> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=56974a6fcfef69ee0825bd66ed13e92070ac5224

… which made it into v4.17 final :)

We could start testing our policy locally with socket
mediation enabled. To do so:

 - run Linux from Debian experimental (it currently has 4.17~rc7-1~exp1)
 - disable feature-set pinning or update the feature-set to enable
   these new features

Also, it would be nice to test Linux 4.17 with the feature-sets we
ship in Stretch and testing/sid, in order to catch any bug like
#883703 ASAP.

I'll be very busy until DebCamp so it's unlikely I do much on this
front until then (best case I'll press the right buttons to enable
this on my own system once 4.17 is in sid, but I won't have time to
test software I don't use myself).

Anyone excited?

Bug#901467: libtecla: do not strip during make install

[Helmut Grohne]

Source: libtecla
Version: 1.6.3-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

libtecla strips during make install. Thus:
 * DEB_BUILD_OPTIONS=nostrip produces stripped packages.
 * No useful -dbgsym packages can be generated.
 * Cross compilation fails (by using the wrong strip).

Please disable such stripping e.g. using the attached patch.

Helmut
diff --minimal -Nru libtecla-1.6.3/debian/changelog 
libtecla-1.6.3/debian/changelog
--- libtecla-1.6.3/debian/changelog 2017-08-22 21:42:28.0 +0200
+++ libtecla-1.6.3/debian/changelog 2018-06-13 19:31:58.0 +0200
@@ -1,3 +1,10 @@
+libtecla (1.6.3-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Do not strip during make install. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 13 Jun 2018 19:31:58 +0200
+
 libtecla (1.6.3-2) unstable; urgency=medium
 
   * Moved packaging from SVN to Git
diff --minimal -Nru libtecla-1.6.3/debian/rules libtecla-1.6.3/debian/rules
--- libtecla-1.6.3/debian/rules 2017-08-22 21:42:28.0 +0200
+++ libtecla-1.6.3/debian/rules 2018-06-13 19:31:56.0 +0200
@@ -3,6 +3,7 @@
 export DH_VERBOSE=1
 
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all
+export STRIPPROG=true
 
 %:
dh $@ --no-parallel

Bug#900398: mariadb-server-10.1: postinst fails since official rebuild

[Faustin Lammler]

Paul,

> my guess is that the DB crashed so the 'tc.log' file was created and it
> prevent the mariadb-server to start again.
After a discussion with Elena Stepanova, here is some information on the
'tc.log' file:
[...] tc.log wouldn't prevent mariadb from starting, it's there
to help, not to obstruct. It's more likely that the tc.log is
invalid on whatever reason (e.g. got corrupt due to a disk
problem or lack of space, or as a result of a bug in the
previous installation, or is of an incompatible format). You can
very easily get the same effect if you stop the server, run
touch /tc.log (assuming you don't have one) and then
try to start the server.

Documentation on how this 'tc.log' file work is quite inexistent because:
[...] it has never been meaningfully documented, neither in
MariaDB nor in MySQL. Hopefully it will change soon [...].

There is a documentation request filed on 
https://jira.mariadb.org/browse/MDEV-16442

So regarding our issue, I guess that the DB crashed or the tc.log file
got corrupt (or both).

Do you know how to reproduce this? Do you have any steps that I could
try?

-- 
Faustin Lammler
MariaDB Foundation

Bug#901349: Acknowledgement (Kernel 4.16 has no display support for Raven Ridge)

[Keverik]

Hi Debian,

I have recompiled the kernel 4.16 with this configuration setting and it 
works for me.
Except that the lightdm was too fast to use the graphical driver during 
starting.
(The result was that the system sometimes freezes. depending on startup 
timing.)
I have solved this by the "logind-check-graphical=true" setting in 
lightdm.conf, but this might not be the general solution for debian.


Good luck,
Erik

Op 11-06-18 om 22:00 schreef Debian Bug Tracking System:

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 901349: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901349.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
  unknown-pack...@qa.debian.org

If you wish to submit further information on this problem, please
send it to 901...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

Bug#901465: ITP: driverctl -- device driver control utility for Linux

[Luca Boccassi]

Package: wnpp
Severity: wishlist
Owner: Luca Boccassi 

* Package name: driverctl
  Version : 0.95
  Upstream Author : Panu Matilainen 
* URL : https://gitlab.com/driverctl/driverctl
* License : LGPL-2.1
  Programming Lang: bash
  Description : device driver control utility for Linux

Upstream description:

"driverctl is a tool for manipulating and inspecting the system
device driver choices.

Devices are normally assigned to their sole designated kernel driver
by default. However in some situations it may be desireable to
override that default, for example to try an older driver to
work around a regression in a driver or to try an experimental
alternative
driver. Another common use-case is pass-through drivers and driver
stubs to allow userspace to drive the device, such as in case of
virtualization.

driverctl integrates with udev to support overriding
driver selection for both cold- and hotplugged devices from the
moment of discovery, but can also change already assigned drivers,
assuming they are not in use by the system. The driver overrides
created by driverctl are persistent across system reboots
by default."

This tool is being chosen as a preferred utility to manage drivers by a
few projects. In the case I care about, by DPDK - so it's useful to
have it alongside it and it might even become a dependency in the next
releases.
Unless there are strong objections, I plan to upload sometimes next
week.

-- 
Kind regards,
Luca Boccassi

signature.asc
Description: This is a digitally signed message part

Bug#901466: ices2 FTCBFS: m4/shout.m4 hard codes the build architecture pkg-config

[Helmut Grohne]

Source: ices2
Version: 2.0.2-2
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

ices2 fails to cross build from source, because it uses the build
architecture pkg-config. The cause is a bad macro in m4/shout.m4. After
fixing it, ices2 cross builds successfully. Please consider applying the
attached patch.

Note: I had to remove the setting of PKG_CONFIG_PATH, because Debian's
cross wrapper does not work when PKG_CONFIG_PATH is set. Anyway,
/usr/local/lib/pkgconfig is part of the default search path of
pkg-config, so that should not be a problem.

Helmut
--- ices2-2.0.2.orig/m4/shout.m4
+++ ices2-2.0.2/m4/shout.m4
@@ -19,22 +19,18 @@
 # NB: PKG_CHECK_MODULES exits if pkg-config is unavailable on the target
 # system, so we can't use it.
 
-# seed pkg-config with the default libshout location
-PKG_CONFIG_PATH=${PKG_CONFIG_PATH:-/usr/local/lib/pkgconfig}
-export PKG_CONFIG_PATH
-
 # Step 1: Use pkg-config if available
-AC_PATH_PROG([PKGCONFIG], [pkg-config], [no])
-if test "$PKGCONFIG" != "no" && `$PKGCONFIG --exists shout`
+PKG_PROG_PKG_CONFIG
+if test "x$PKG_CONFIG" != x && `$PKG_CONFIG --exists shout`
 then
-  SHOUT_CFLAGS=`$PKGCONFIG --variable=cflags_only shout`
-  SHOUT_CPPFLAGS=`$PKGCONFIG --variable=cppflags shout`
-  SHOUT_LIBS=`$PKGCONFIG --libs shout`
+  SHOUT_CFLAGS=`$PKG_CONFIG --variable=cflags_only shout`
+  SHOUT_CPPFLAGS=`$PKG_CONFIG --variable=cppflags shout`
+  SHOUT_LIBS=`$PKG_CONFIG --libs shout`
   xt_have_shout="maybe"
 else
-  if test "$PKGCONFIG" != "no"
+  if test "x$PKG_CONFIG" != x
   then
-AC_MSG_NOTICE([$PKGCONFIG couldn't find libshout. Try adjusting PKG_CONFIG_PATH.])
+AC_MSG_NOTICE([$PKG_CONFIG couldn't find libshout. Try adjusting PKG_CONFIG_PATH.])
   fi
   # pkg-config unavailable, try shout-config
   AC_PATH_PROG([SHOUTCONFIG], [shout-config], [no])

Bug#901464: inadyn: Temporary failure in name resolution - stuck in infinite loop when no internet connectio

[Wojciech Nizinski]

Package: inadyn
Version: 1.99.4-1+b1
Severity: important

I noticed that inadyn call block my script execution because it stuck in loop
of retries.
There is no commandline parameter to configure this behavior.

Invocation:

inadyn \
--forced-update 1 \
--system defa...@no-ip.com \
-u X \
-p Y \
-a ZZ.ddns.net \
--iterations 1


Wed Jun 13 17:51:24 2018: Inadyn version 1.99.4 -- Dynamic DNS update client.
Wed Jun 13 17:51:24 2018: Cached IP# xxx.xxx.xxx.xxx from previous invocation.
Wed Jun 13 17:51:24 2018: Failed resolving hostname ip1.dynupdate.no-ip.com:
Temporary failure in name resolution
Wed Jun 13 17:51:24 2018: Will retry again in 120 sec...
Wed Jun 13 17:53:24 2018: .
Wed Jun 13 17:53:24 2018: Failed resolving hostname ip1.dynupdate.no-ip.com:
Temporary failure in name resolution
Wed Jun 13 17:53:24 2018: Will retry again in 120 sec...
Wed Jun 13 17:55:24 2018: .
Wed Jun 13 17:55:24 2018: Failed resolving hostname ip1.dynupdate.no-ip.com:
Temporary failure in name resolution
Wed Jun 13 17:55:24 2018: Will retry again in 120 sec...
Wed Jun 13 17:57:24 2018: .
Wed Jun 13 17:57:24 2018: Failed resolving hostname ip1.dynupdate.no-ip.com:
Temporary failure in name resolution
Wed Jun 13 17:57:24 2018: Will retry again in 120 sec...


my current workaround is to run inadyn with --background flag, but this is not
a solution because after few hours it can produce multiple processess of
inadyn.



-- System Information:
Debian Release: 9.4
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-0.bpo.3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages inadyn depends on:
ii  adduser  3.115
ii  libc62.24-11+deb9u3

inadyn recommends no packages.

inadyn suggests no packages.

-- Configuration Files:
/etc/default/inadyn changed [not included]
/etc/inadyn.conf [Errno 13] Permission denied: '/etc/inadyn.conf'

-- no debconf information

Bug#900398: mariadb-server-10.1: postinst fails since official rebuild

[Paul Gevers]

Hi Faustin,

On 13-06-18 18:52, Faustin Lammler wrote:
> So regarding our issue, I guess that the DB crashed or the tc.log file
> got corrupt (or both).

All I can say is that that file was empty.

paul@testavoira ~ $ ll /var/lib/mysql/tc.log.org
-rw-rw 1 mysql mysql 0 apr  9 18:14 /var/lib/mysql/tc.log.org

Interesting to look at that date, it seems that MariaDB crashed before I
updated (which happened on 2018-05-18 20:56:49 according to my apt
history) and I just didn't notice.

> Do you know how to reproduce this? Do you have any steps that I could
> try?

I have no idea what happened on 9 April that would have caused this. I
don't rule out that I ran out of space on that disk (happens occasionally).

So I guess this bug should be re-titled to something like "during
startup mariadb-server should handle corrupt tc.log more gracefully". An
empty tc.log appears to me as save to ignore as it doesn't contain
useful information anyways apart from its timestamp.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#882047: [pkg-apparmor] Bug#882047: Bug#882047: Bug#882047: apparmor-utils: aa-complain thunderbird fails

[Vincas Dargis]

On 6/13/18 6:00 PM, intrigeri wrote:

For the record, with 2.13-1 I see a different error:

   # aa-complain thunderbird
   Setting /usr/bin/thunderbird to complain mode.

   ERROR: Path doesn't start with / or variable: gpg

i.e. aa-complain chokes on the "gpg" named child profile.

Cheers,



Same with gst_plugin_scanner when using 2.13:

$ sudo aa-enforce /etc/apparmor.d/*
< ...skipped... >
Setting /etc/apparmor.d/gst_plugin_scanner to enforce mode.

ERROR: Path doesn't start with / or variable: gst_plugin_scanner

Bug#901463: TITAN documentation is not packaged as part of eclipse-titan or eclipse-titan-doc

[Harald Welte]

Package: eclipse-titan
Version: 6.3.1-1+b2
Severity: wishlist

The eclipse-titan package for Debian unfortunately does not include the official
documentation.  Normally, I would assume documentation is installed under
/usr/share/doc/$package - but there's nothing but the changelog and the 
copyright
statement there.  Not even a README file that points to
https://www.eclipse.org/downloads/download.php?file=/titan/TitanDocuments_6_3_0.zip

I suggest that due to their size, the PDF files should be packaged as 
eclipse-titan-doc.

However, it still makes sense to package them from the same debian source 
package,
to make sure that there's always a matching eclipse-titan-doc package for each 
eclipse-titan
package.

See also https://www.eclipse.org/forums/index.php/m/1790623 where I describe 
that it's
actually quite hard to find the documentation today for a variety of reasons.

The binary tar-ball builds released by upstream TITAN for Ubuntu, SuSE and 
other distributions
(https://projects.eclipse.org/projects/tools.titan/downloads)
include the PDF files, btw.  It appears that just the Debian package isn't 
shipping them.

Thanks!

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

Kernel: Linux 4.16.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages eclipse-titan depends on:
ii  default-jdk   2:1.10-67
ii  expect5.45.4-2
ii  gcc   4:7.3.0-3
ii  libc6 2.27-3
ii  libgcc1   1:8.1.0-5
ii  libncurses6   6.1+20180210-4
ii  libpcap-dev   1.8.1-6
ii  libpcre3-dev  2:8.39-9
ii  libsctp-dev   1.0.17+dfsg-2
ii  libssl-dev1.1.0h-4
ii  libssl1.1 1.1.0h-4
ii  libstdc++68.1.0-5
ii  libtinfo6 6.1+20180210-4
ii  libxml2   2.9.4+dfsg1-7
ii  libxml2-dev   2.9.4+dfsg1-7
ii  make  4.2.1-1
ii  perl  5.26.2-6
ii  python2.7.15-3

eclipse-titan recommends no packages.

eclipse-titan suggests no packages.

-- no debconf information