Bug#913723: please confirm that dictionaries should move to section localization

[Chris Lamb]

Dear Jonas,

> But your notion (in an earlier post) that this is not for mere mortals 
> but (yet another) ftpmaster matter, defused my enthusiasm completely.
> 
> :-(

Aw, that seems a little premature to go that far at this stage.

I read Guillem's reference to the ftp-masters as merely a "well, just
to frame the rest of this paragraph in an easy-to-read way, this has
historically been the domain of the ftp-masters" rather than anything
approaching "we must absolutely leave it to FTP team."


Regards,

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

Bug#915267: [3dprinter-general] Bug#915267: libpolyclipping FTCBFS: does not pass cross flags to cmake

[Gregor Riepl]

I just found out that I previously worked on fixing this, but never finished.
There's a few other issues that make this more complicated than simply cutting
down d/rules to the bare minimum.

I'll prepare an upload once those are sorted out.

Bug#915207: gnudatalanguage: autopkgtests fail: test_bug_n000720, test_idlneturl, test_point_lun, test_save_restore, test_zip

[Ole Streicher]

Oops, I am deeply sorry that I have sent this under the wrong email
address. Especially sorry to you, Gilles. I have no idea how this
happened (Thunderbird with virtual_identity; I probably mixed up
something there), and it was not intentional.

Best

Ole

> Hi Sebastian,
> 
> On 03.12.18 00:15, Sebastiaan Couwenberg wrote:> Unfortunately the
> autopkgtests for 0.9.9-1 still fail [0], and since> it's blocking the
> migration of hdf5 it makes the package unsuitable for> release
> justifying the RC severity [1].
> Sorry, but I don't see this: gdl does not *break* hdf5 ("break" means
> IMO that a package that worked before does not work anymore -- but hdf5
> still works nicely, right?), and it also does not block the transition.
> 
> As far as I know, CI tests are currently setup in a non-blocking way.
> And when I look into the maintainer page of hdf5, it says
> 
> "Required age increased by 30 days because of autopkgtest".
> 
> This is not a block, this is just a delay. There never was a statement
> that failing CI tests are RC (or would become so before buster).
> 
> So, you you please be a bit more explicit how the RC policy applies here?
> 
> Best regards
> 
> Ole
> 

Bug#913801: stretch-pu: package mistral/3.0.0-4 CVE-2018-16849: std.ssh action may disclose presence of arbitrary files

[Thomas Goirand]

On 12/3/18 8:17 AM, Julien Cristau wrote:
> Control: tag -1 confirmed
> 
> On Thu, Nov 15, 2018 at 02:07:01PM +0100, Thomas Goirand wrote:
>> diff --git a/debian/changelog b/debian/changelog
>> index b2ce8602..06234034 100644
>> --- a/debian/changelog
>> +++ b/debian/changelog
>> @@ -1,3 +1,11 @@
>> +mistral (3.0.0-4+deb9u1) stretch-security; urgency=medium
> 
> Remove the -security bit.

Sure! This was made for the security team, and they asked to move to a
s-p-u instead (ie: no DSA).

>> +
>> +  * CVE-2018-16849: std.ssh action may disclose presence of arbitrary files,
>> +applied upstream patch: remove extra information from std.ssh action.
>> +(Closes: #912714).
>> +
>> + -- Thomas Goirand   Mon, 05 Nov 2018 14:38:44 +0100
>> +
>>  mistral (3.0.0-4) unstable; urgency=medium
>>  
>>* Add allow-sqla-1.1.patch to allow SQLA transition.
> 
> Other than that, looks ok to upload.

Uploaded. If it gets rejected because of a --force-orig-source, I'll
re-do it (I'm always confused on when to do it, though never mind if it
gets automatically rejected, it's easy to fix...).

Cheers,

Thomas Goirand (zigo)

Bug#914172: [debian-mysql] Bug#914172: mariadb-server-10.1: mariadb-server sec-update (10.1.37-0+deb9u1) uninstalls default-mysql-server, mysql-server, mariadb-server-10.1 & mariadb-client-10.1

[Otto Kekäläinen]

Hello!

This change was done by Ondrej Sury. I don't have any more information
about it other than what the commit messages say.

Bug#915147: [Pkg-swan-devel] Bug#915147: strongswan-charon: apparmor profile should allow writing to /etc/resolv.conf

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, 2018-11-30 at 19:03 -0800, Ximin Luo wrote:
> If the VPN one is connecting to wants to add additional DNS servers, charon
> needs
> write access to /etc/resolv.conf. Otherwise we get an error like the
> following:
> 
>   # ipsec up XXX
>   [..]
>   IKE_SA XXX{X} established between XXX...YYY
>   adding DNS server failed
>   adding DNS server failed
>   handling INTERNAL_IP4_DNS attribute failed
>   installing new virtual IP XXX
>   [..]
> 
> And in dmesg logs:
> 
>   audit: type=1400 audit(NNN): apparmor="DENIED" operation="open"
> profile="/usr/lib/ipsec/charon" name="/etc/resolv.conf" pid=ZZZ
> comm="charon" requested_mask="wc" denied_mask="wc" fsuid=0 ouid=0
>   audit: type=1400 audit(NNN): apparmor="DENIED" operation="unlink"
> profile="/usr/lib/ipsec/charon" name="/etc/resolv.conf" pid=ZZZ
> comm="charon" requested_mask="d" denied_mask="d" fsuid=0 ouid=0

Hi,

another solution would be looking at resolvconf. On my strongSwan setup the
gateway provides DNS and it seems to work just fine here with resolvconf
installed, so it might be worth trying it on your side.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlwE50oACgkQ3rYcyPpX
RFuBPQf+IITzxj1XHwSpzOmryralb9a7VEh7nL83L5GVbBMpyY/Z7NFg1mt5Zve5
dxyDT8KOCbVAGGMRaXCUQKqNRXIInKBBWOVhsFdVE8FYdn7eXqbuVtPO2GTGk6HY
8QvzzksRP3UtLu9FGktHaz8IJo8vK0xSc6W1YCvO1TdTyWevS4pp7LjTStZpCXvH
c/H5BIj7J6eGb0LyE7uwP1tck30ucRxJGTTWg6DA4WMNTmuqFHVug7sYnl0NElOR
aMM6G56w78eFdiAf8i5dF6/gW5Jx0fBKjQEa3aO6VK900eoEvXfyWsZ6VLWuw1ob
KUDIi+JOLSzLu8fqJqhC2LhpBo4/cQ==
=4PjS
-END PGP SIGNATURE-

Bug#914227: RFS: mako-notifier/1.1-1 ITP

[Birger Schacht]

There was a new release, i updated the package in git and on mentors.
The respective dsc file can be found at:
https://mentors.debian.net/debian/pool/main/m/mako-notifier/mako-notifier_1.2-1.dsc

cheers,
Birger

On 11/20/18 7:50 PM, Birger Schacht wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "mako-notifier"
> 
> * Package name : mako-notifier
>   Version  : 1.1-1
>   Upstream Author  : Simon Ser
> * Url  : https://wayland.emersion.fr/mako/
> * Licenses : Expat
>   Programming Lang : C
>   Section  : x11
> 
>  mako is a lightweight notification daemon for Wayland compositors that
>  support the layer-shell protocol.
> 
> It builds those binary packages:
> 
>   * mako-notifier
> 
> To access further information about this package, visit the following URL:
> 
> https://mentors.debian.net/package/mako-notifier
> 
> Alternatively, one can download the package with dget using this
> command: dget -x
> https://mentors.debian.net/debian/pool/main/m/mako-notifier/mako-notifier_1.1-1.dsc
> or clone the package repository from salsa at
> https://salsa.debian.org/bisco-guest/mako
> 
> Regards,
>   Birger Schacht
> 

Bug#898826: Re: stretch-pu: package profphd in strech unusable

[Andreas Tille]

Hi,

On Mon, Dec 03, 2018 at 08:15:26AM +0100, Julien Cristau wrote:
> 
> Please use 1.0.42-1+deb9u1 as version.  Looks fine to upload otherwise.

I tried to build

  https://salsa.debian.org/med-team/profphd/tree/debian/stretch-proposed-updates

in a stretch chroot, but got:

...
   dh_builddeb
dpkg-deb: building package 'profphd' in '../profphd_1.0.42-1+deb9u1_all.deb'.
 dpkg-genbuildinfo
 dpkg-genchanges -v >../profphd_1.0.42-1+deb9u1_amd64.changes
dpkg-genchanges: warning: 'since' option specifies non-existing version
dpkg-genchanges: warning: use newest entry that is earlier than the one 
specified
dpkg-genchanges: error:  is not a valid version
dpkg-buildpackage: error: dpkg-genchanges gave error exit status 255


Sorry for my ignorance since I'm very rarely upload to proposed-updates:
Is there something else I need to specify (please guide me to the Fine
Manual, thank you).
 
> You might want to consider build-time and/or autopkgtests to avoid this
> happening again?

The issue was detected when autopkgtests were added.

Kind regards

  Andreas. 

-- 
http://fam-tille.de

Bug#912583: simpleitk patch for Python 3.7

[Andreas Tille]

Control: tags -1 help

Hi,

thanks for the patch which was applied in Git.  I also bumped simpleitk
to latest upstream version. Unfortunately there seems to be an issue
with gdcm (gdcm Uploaders in CC):

...
-- Performing Test CXX_HAS-Wno-invalid-offsetof - Success
-- The imported target "vtkgdcmsharpglue" references the file
   "/usr/lib/x86_64-linux-gnu/libvtkgdcmsharpglue.so"
but this file does not exist.  Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
   "/usr/lib/x86_64-linux-gnu/gdcm-2.8/GDCMTargets.cmake"
but not all the files it references.

-- The imported target "vtkgdcmPython" references the file
   "/usr/lib/python/dist-packages/vtkgdcmPython.so"
but this file does not exist.  Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
   "/usr/lib/x86_64-linux-gnu/gdcm-2.8/GDCMTargets.cmake"
but not all the files it references.

-- Performing Test SITK_HAS_CXX11_STATIC_ASSERT
...


Any hint how to deal with this?

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#915370: Please drop anacron from task-desktop

[Michael Biebl]

Package: task-desktop
Version: 3.48
Severity: normal

anacron was added to the desktop-task a long time ago.
The changelog doesn't mention why it was added, but I assume it was to
support systems which are not running 24/7 and to ensure that cron jobs
have a chance to run.

Nowadays, we have systemd .timer units, which handle this issue much
nicer. I checked a default desktop installation, and all important cron
jobs have a corresponding .timer unit.
It thus seems safe to drop anacron from task-desktop.


-- 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.18.0-3-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

Versions of packages task-desktop depends on:
ii  desktop-base9.0.7
ii  tasksel 3.48
ii  xorg1:7.7+19
ii  xserver-xorg-input-all  1:7.7+19
ii  xserver-xorg-video-all  1:7.7+19

Versions of packages task-desktop recommends:
ii  alsa-utils  1.1.7-1
pn  anacron 
ii  avahi-daemon0.7-4+b1
ii  eject   2.1.5+deb1+cvs20081104-13.2
ii  firefox 63.0.3-1
ii  iw  4.14-1
ii  libnss-mdns 0.14.1-1
ii  libu2f-udev 1.1.6-1
ii  sudo1.8.26-2
pn  task-gnome-desktop | task-xfce-desktop | task-  
ii  xdg-utils   1.1.3-1

task-desktop suggests no packages.

-- no debconf information

Bug#915103:

[Cyr Bol]

For the record,

the patch Andreas is talking about was commited
in 69c00981a8970c3d6cff583a68c03b86040e721a

Bug#575265: Naléhavé./Urgent.

[Jojo Akpe]

[image: image.png]

Bug#914178: xmobar: after update, xmobar often segfaults

[Apollon Oikonomopoulos]

Control: reassign -1 ghc
Control: found -1 8.4.3+dfsg1-1
Control: fixed -1 8.4.4+dfsg1-1
Control: affects -1 xmobar

Hi,

On 09:07 Tue 20 Nov , Samuel Hym wrote:
> After updating xmobar to 0.28.1-1, it often segfaults. I don’t really
> know how to explore the cause. It seems to happen when some other
> process opens a window (in particular dunst showing a notification), I
> think.
> Reverting to 0.24.5-1 solves the problem.

Thanks for the report!

This is most likely GHC bug #15260[1], which has been fixed in GHC 
8.4.4. Hopefully, the next upload of xmobar will behave correctly.

[1] https://ghc.haskell.org/trac/ghc/ticket/15260

Regards,
Apollon

Bug#915207: gnudatalanguage: autopkgtests fail: test_bug_n000720, test_idlneturl, test_point_lun, test_save_restore, test_zip

[Sebastiaan Couwenberg]

On 12/3/18 8:59 AM, Ole Streicher wrote:
>>> autopkgtests for 0.9.9-1 still fail [0], and since it's blocking the
>>> migration of hdf5 it makes the package unsuitable for release
>>> justifying the RC severity [1].
>>
>> Sorry, but I don't see this: gdl does not *break* hdf5 ("break" means
>> IMO that a package that worked before does not work anymore -- but hdf5
>> still works nicely, right?), and it also does not block the transition.
>> 
>> As far as I know, CI tests are currently setup in a non-blocking way.
>> And when I look into the maintainer page of hdf5, it says
>>
>> "Required age increased by 30 days because of autopkgtest".
>>
>> This is not a block, this is just a delay. There never was a statement
>> that failing CI tests are RC (or would become so before buster).
>>
>> So, you you please be a bit more explicit how the RC policy applies here?

hdf5 is unable to migrate to testing because gnudatalanguage
autopkgtests fail. Test failures indicate that the package is broken,
and not suitable for release. It should be removed from testing until
the test failures are fixed, which also allows hdf5 and its rdeps to
migrate to testing.

As announced the autopkgtest delay is increased exponentially which will
block packages from getting into buster before the final freeze. We do
not want that to happen, but your package is not allowing hdf5 and its
rdeps to migrate even though there is nothing else preventing this part
of the transition.

Fix your failing autopkgtests or remove them. Not fixing failing
autopkgtests in your package that prevent its dependencies from (timely)
testing migration is very unfriendly (to phrase it very mildly).

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#915207: gnudatalanguage: autopkgtests fail: test_bug_n000720, test_idlneturl, test_point_lun, test_save_restore, test_zip

[Ole Streicher]

Control: forwarded -1 https://github.com/gnudatalanguage/gdl/issues/537

Hi Sebastiaan,

On 03.12.18 09:41, Sebastiaan Couwenberg wrote:
> hdf5 is unable to migrate to testing because gnudatalanguage
> autopkgtests fail. Test failures indicate that the package is broken,
> and not suitable for release. It should be removed from testing until
> the test failures are fixed, which also allows hdf5 and its rdeps to
> migrate to testing.

That is currently in the decision of the package maintainer. Neither the
policy nor the RC document you cited list CI test failures or migration
delays as a possible cause for severity "serious".

> As announced the autopkgtest delay is increased exponentially which will
> block packages from getting into buster before the final freeze. We do
> not want that to happen, but your package is not allowing hdf5 and its
> rdeps to migrate even though there is nothing else preventing this part
> of the transition.

> Fix your failing autopkgtests or remove them. Not fixing failing
> autopkgtests in your package that prevent its dependencies from (timely)
> testing migration is very unfriendly (to phrase it very mildly).

I totally agree, I am affected as well, and I am working on it. You
shouldn't think that an "important" bug does not get attention. But this
also does not reason the severity "serious".

Best regards

Ole

Bug#911830: FTBFS on multiple architectures

[Stuart Prescott]

Hi Yaroslav,

Thanks for the update!

I see that, as well as a possible race conditions in the build system, we've 
definitely got a race condition in me sending emails -- I missed that you had 
uploaded 0.20.1+dfsg-1 :) That probably makes my previous comments somewhat 
cryptic.

(To explain: I had been looking at why 0.20.0+dfsg-2 wasn't building. Looking 
through all the build-dependencies that had changed since the 0.20.0 upload 
made me think that the FTBFS was a regression since your upload, particularly 
since I couldn't build it on i386 or amd64 locally either, that's what led to 
'everywhere'.)

So... Let's start again knowing that you (and the buildd) can indeed build the 
packages and that it is not a question of changes to build-dependencies.

As I poke the 0.20.1 package some more, it looks like a substantial portion of 
the problem is the parallelisation:

- if I build with -j1, it fails to even try to build any of the Python 3.x 
versions

- if I build with -j2, it fails to even try to build the Python 3.7 version

- if I build with -j4, it mostly succeeds; it also sometimes fails because the 
config steps for each build is built at the same time and is trying to touch 
the ame files, e.g.:

i686-linux-gnu-gcc -pthread _configtest.o -L/usr/lib/i386-linux-gnu -lf77blas 
-lcblas -latlas -o _configtest
/bin/sh: 1: ./_configtest: Text file busy

(the 2.7 build failed in that particular case). 

It looks like setting up the parallel builds is pretty racy and under some 
circumstances it manages to succeed, unless you happen to not have enough jobs 
available or if they happen to be too quick.

I'm not really sure where to take this next. Perhaps d/rules is fixable 
easily, or perhaps ripping out a pile of stuff is necessary. Hopefully those 
who understand how it is supposed to work can help here.


> > There's no visible progress on this problem in git -- is there progress
> > elsewhere?
> 
> you could find some traces of the progress which lead to i386 fixes on
> https://github.com/scikit-learn/scikit-learn/issues?utf8=%E2%9C%93&q=is%3Ais
> sue+author%3Ayarikoptic+
> 
> I welcome you to review/analyze failures on other platforms and/or just
> report them upstream.  or I would do it whenever I get a chance

Thanks! I'll see what I can learn, although I think at least some of the 
current problems are actually with the Debian packaging and not upstream.

> s390x (and also arm64) issue is here upstream
> https://github.com/scikit-learn/scikit-learn/issues/10561
> 
> if you care to help, please try to figure out WTF with ppc64el:
> https://buildd.debian.org/status/fetch.php?pkg=scikit-learn&arch=ppc64el&ver
> =0.20.1%2Bdfsg-1&stamp=1543512601&raw=0 where it even doesn't build... might
> be a cython issue

That failure looks the same as what I see on amd64 and i386.

It's excessively difficult to extract the right lines from the parallel build, 
but I think the final failure is the same both with -j1 or -j2:


PYBUILD_INTERPRETERS=python{version} PYBUILD_VERSIONS=3.6 dh build-arch --with 
python3 --buildsystem pybuild
touch debian/build-stamp-python3.6
PYBUILD_INTERPRETERS=python{version} PYBUILD_VERSIONS=3.7 dh build-arch --with 
python3 --buildsystem pybuild
touch debian/build-stamp-python3.7
:
# urllib.error.URLError -- have to ignore
# hotfix SPHINXOPTS -- remove in next release
\
PYTHONPATH=`/bin/ls -d /<>/scikit-
learn-0.20.1+dfsg/.pybuild/*python*_3.7/build`:$(python3 -c 'import 
sys;print(":".join(sys.path))') \
SPHINXBUILD="python3.7 -m sphinx -j 1 -D mathjax_path=MathJax.js" \
SPHINXOPTS="-j 1 -D mathjax_path=MathJax.js" \
/usr/bin/make -C doc html
/bin/ls: cannot access '/<>/scikit-learn-0.20.1+dfsg/.pybuild/
*python*_3.7/build': No such file or directory
make[2]: Entering directory '/<>/scikit-learn-0.20.1+dfsg/doc'
# These two lines make the build a bit more lengthy, and the
# the embedding of images more robust
rm -rf _build/html/_images
#rm -rf _build/doctrees/
python3.7 -m sphinx -j 1 -D mathjax_path=MathJax.js -b html -d _build/doctrees  
  
. _build/html/stable
Running Sphinx v1.7.9

Configuration error:
There is a programable error in your configuration file:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/sphinx/config.py", line 161, in 
__init__
execfile_(filename, config)
  File "/usr/lib/python3/dist-packages/sphinx/util/pycompat.py", line 150, in 
execfile_
exec_(code, _globals)
  File "conf.py", line 18, in 
from sklearn.externals.six import u
ModuleNotFoundError: No module named 'sklearn'



(i.e. the build is not attempted and the build does not fail because of that 
error, but fails later because building the documentation fails)

Cheers
Stuart




-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#915207: gnudatalanguage: autopkgtests fail: test_bug_n000720, test_idlneturl, test_point_lun, test_save_restore, test_zip

[Sebastiaan Couwenberg]

On 12/3/18 9:54 AM, Ole Streicher wrote:
> On 03.12.18 09:41, Sebastiaan Couwenberg wrote:
>> hdf5 is unable to migrate to testing because gnudatalanguage
>> autopkgtests fail. Test failures indicate that the package is broken,
>> and not suitable for release. It should be removed from testing until
>> the test failures are fixed, which also allows hdf5 and its rdeps to
>> migrate to testing.
> 
> That is currently in the decision of the package maintainer. Neither the
> policy nor the RC document you cited list CI test failures or migration
> delays as a possible cause for severity "serious".
> 
>> As announced the autopkgtest delay is increased exponentially which will
>> block packages from getting into buster before the final freeze. We do
>> not want that to happen, but your package is not allowing hdf5 and its
>> rdeps to migrate even though there is nothing else preventing this part
>> of the transition.
> 
>> Fix your failing autopkgtests or remove them. Not fixing failing
>> autopkgtests in your package that prevent its dependencies from (timely)
>> testing migration is very unfriendly (to phrase it very mildly).
> 
> I totally agree, I am affected as well, and I am working on it. You
> shouldn't think that an "important" bug does not get attention. But this
> also does not reason the severity "serious".

Yes, it is. Your package is broken and needs to be removed from testing
as soon as possible, as it negatively affects its dependencies.

important severity does not trigger autoremoval, serious does.

The RC policy hasn't been updated for autopkgtests yet, but I expect
failing tests to become an official reason for RC severity as that
removal from testing of that package will be the only way to let its
dependencies migrate to testing (without release team hints).

If a fix is forthcoming, why not let gnudatalanguage be autoremoved from
testing, and let it migrate again when it has been fixed?

Do you think that keeping your package in testing is more important than
all the other ~100 packages involved in the hdf5 transitions? According
to popcon it's not.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#915371: pivy: Coin3 cmake transition

[Leopold Palomo-Avellaneda]

Source: pivy
Severity: grave
Justification: renders package unusable

Dear Maintainer,

coin3 is doing a transition to 4.0.0 using CMake as build system.

During the test the package FTBFS using the version that is in experimental. 
Please, check this version.



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

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

Bug#900160: closed by Didier Raboud (Bug#900160: fixed in ruby-eventmachine 1.0.7-4.1)

[Emilio Pozuelo Monfort]

On 03/12/2018 00:09, Kurt Roeckx wrote:
> On Sun, Dec 02, 2018 at 11:36:06PM +0100, gregor herrmann wrote:
>> On Sun, 02 Dec 2018 23:18:38 +0100, Sebastian Andrzej Siewior wrote:
>>
>>> On 2018-12-02 13:06:04 [+], Debian Bug Tracking System wrote:
 #900160: ruby-eventmachine: FTBFS against openssl 1.1.1
  ruby-eventmachine (1.0.7-4.1) unstable; urgency=medium
  .
* Non-maintainer upload.
* Build-Depend against libssl1.0-dev; aka OpenSSL << 1.1
  (Closes: #900160)
>>>
>>> Please revert that one. We don't want more dependencies on
>>> libssl1.0-dev. We want it actually out of testing and are down to one
>>> package.
>>> I wouldn't care much but since ruby-eventmachine is a key package it
>>> might migrate to testing…
>>
>> Raising the severity of the cloned #915287 which tracks this problem
>> should prevent the migration.
> 
> It won't, since it affects also the version in testing, it can
> just migrate.

That metadata needs to be updated because it no longer reflects reality. Then it
will block testing migration. I have done that.

Cheers,
Emilio

Bug#915103:

[Cyr Bol]

Silly me!

the actual number of the commit that Andreas referring to is
da1d372d0d58474f2f5a71b9acd301abf9b11bc0

this commit's message is : "New upstream version 2.4.34"

Bug#887768: Steps to reproduce mouse freeze

[Elimar Riesebieter]

* Susan Cragin  [2018-12-02 17:10 -0500]:

>On my machine F6 doesn't work at all. Nothing happens to alsamixer.
>I am aware that alsamixer is not mouse-friendly, and I do not try to
>control alsamixer with the mouse. On the other hand, alsamixer seems
>to interfere with my mouse.
>Steps to reproduce mouse freeze:
>(1) open terminal
>(2) start alsamixer
>(3) press the F6 key
>That's it. After that the mouse freezes into whatever position it is
>in on the screen and cannot be moved.
>Pressing ESC to get out of alsamixer does not make the mouse able to
>move. Neither does closing the terminal where alsamixer was running.
>The mouse is frozen into position, and I can do nothing to make the
>mouse active again but reboot.

There is no relation between alsamixer and the Xserver. But hey,
maybe you put a shortcut to ? Hit  without starting
alsamixer and test your mouse.

Else you can change to a vt with  login and start
alsamixer. Does it work like you want to?

>If this problem were more universal, I imagine there would be lots of
>complaints. Since I seem to be the only one, I understand the
>skepticism.
>Susan Cragin

Elimar

-- 
  Never make anything simple and efficient when a way
  can be found to make it complex and wonderful ;-)


signature.asc
Description: PGP signature

Bug#915372: RFP: grab-site — The archivist's web crawler: WARC output, dashboard for all crawls, dynamic ignore patterns

[emma.wts]

Package: wnpp
Severity: wishlist

Upstream-Dev: https://github.com/ludios/grab-site/

Programming Language: Python

License: MIT license

Description: grab-site is an easy preconfigured web crawler designed for 
backing up websites. Give grab-site a URL and it will recursively crawl the 
site and write WARC files. Internally, grab-site uses a fork of wpull for 
crawling.

Bug#915373: RFP: Ultimate-Facebook-Scraper — A bot which scrapes almost everything about a facebook user's profile

[emma.wts]

Package: wnpp
Severity: wishlist

Upstream Dev: https://github.com/harismuneer/Ultimate-Facebook-Scraper

Description:

A bot which scrapes almost everything about a facebook user's profile including 
uploaded photos, tagged photos, videos, friends list and their profile photos 
(including Followers, Following, Work Friends, College Friends etc) and all 
public posts/statuses available on the user's timeline.

The best thing about this scraper is that the data is scraped in an organized 
format so that it can be used for educational/research purpose by researchers. 
Moreover, this scraper does not use Facebook's Graph API so there are no rate 
limiting issues as such.

Programming Language: Python3

License: MIT license (2018)

Comment: I think we need more archiving and research tools like these in the 
debian repositories.

Bug#913942: stretch-pu: package espeakup/1:0.80-5+deb9u3

[Cyril Brulebois]

Hi,

Julien Cristau  (2018-12-03):
> > +espeakup (1:0.80-5+deb9u3) stretch; urgency=high
> > +
> > +  * debian/espeakup.service: Fix compatibility with older versions of 
> > systemd
> > +(Closes: Bug#913453). Also fix starting with empty voice language.
> > +
> > + -- Samuel Thibault   Sun, 11 Nov 2018 17:43:08 +0100
> > +
> >  espeakup (1:0.80-5+deb9u2) stretch; urgency=medium
> >  
> >* debian/espeakup.service: Automatically load speakup_soft on daemon
> 
> Go ahead, thanks.  This will need a d-i ack.

No objections, thanks.


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


signature.asc
Description: PGP signature

Bug#913723: please confirm that dictionaries should move to section localization

[Jonas Smedegaard]

Quoting Chris Lamb (2018-12-03 09:01:56)
> > But your notion (in an earlier post) that this is not for mere 
> > mortals but (yet another) ftpmaster matter, defused my enthusiasm 
> > completely.
> > 
> > :-(
> 
> Aw, that seems a little premature to go that far at this stage.
> 
> I read Guillem's reference to the ftp-masters as merely a "well, just 
> to frame the rest of this paragraph in an easy-to-read way, this has 
> historically been the domain of the ftp-masters" rather than anything 
> approaching "we must absolutely leave it to FTP team."

I believe I have shared my opinion on this matter already.

Thanks for encouraging me that there is a chance my opinion matters.  
Sorry, but I have lost faith in that myself - would certainly appreciate 
being proven wrong.

Feel free - anyone - to ask if you need clairification of my opinion.


 - 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#915207: gnudatalanguage: autopkgtests fail: test_bug_n000720, test_idlneturl, test_point_lun, test_save_restore, test_zip

[Ole Streicher]

On 03.12.18 10:02, Sebastiaan Couwenberg wrote:
> On 12/3/18 9:54 AM, Ole Streicher wrote:
>> On 03.12.18 09:41, Sebastiaan Couwenberg wrote:
>>> hdf5 is unable to migrate to testing because gnudatalanguage
>>> autopkgtests fail. Test failures indicate that the package is broken,
>>> and not suitable for release. It should be removed from testing until
>>> the test failures are fixed, which also allows hdf5 and its rdeps to
>>> migrate to testing.
>>
>> That is currently in the decision of the package maintainer. Neither the
>> policy nor the RC document you cited list CI test failures or migration
>> delays as a possible cause for severity "serious".
>>
>>> As announced the autopkgtest delay is increased exponentially which will
>>> block packages from getting into buster before the final freeze. We do
>>> not want that to happen, but your package is not allowing hdf5 and its
>>> rdeps to migrate even though there is nothing else preventing this part
>>> of the transition.
>>
>>> Fix your failing autopkgtests or remove them. Not fixing failing
>>> autopkgtests in your package that prevent its dependencies from (timely)
>>> testing migration is very unfriendly (to phrase it very mildly).
>>
>> I totally agree, I am affected as well, and I am working on it. You
>> shouldn't think that an "important" bug does not get attention. But this
>> also does not reason the severity "serious".
> 
> Yes, it is. Your package is broken and needs to be removed from testing
> as soon as possible, as it negatively affects its dependencies.

The package works well, with a few things that do not work. This is what
we call "normal" or "important" bugs. "negative effects" is not
"breaks". Migration delays are not breakages.

> important severity does not trigger autoremoval, serious does.

Sure, so what?

> The RC policy hasn't been updated for autopkgtests yet, but I expect
> failing tests to become an official reason for RC severity as that
> removal from testing of that package will be the only way to let its
> dependencies migrate to testing (without release team hints).

Unless this is the case you can't cite that as an argument for being RC.
Also not the policy.

> If a fix is forthcoming, why not let gnudatalanguage be autoremoved from
> testing, and let it migrate again when it has been fixed?

> Do you think that keeping your package in testing is more important than
> all the other ~100 packages involved in the hdf5 transitions? According
> to popcon it's not.

About 30-40 of those are mine, BTW. And I am still unsure whether hdf5
is not really the cause of the problem yet, since it is the HDF5 test
case in gnudatalanguage is the only one where I don't see a reason for
the failure yet. Just "let us migrate" is the wrong way here -- the CI
migration delays are to find out where the problem is before.

Best regards

Ole

Bug#915374: Updated Russian translation

[Sergey Alyoshin]

Package: apt-listbugs
Version: 0.1.26
Priority: wishlist
Tags: l10n


ru.po.gz
Description: application/gzip

Bug#915181: dak shouldn't accept changes in components directly in upstream

[Ansgar Burchardt]

Hi,

please explain what components you are talking about and why they
shouldn't be allowed in Debian.

Ansgar

Bug#915376: ITP: r-bioc-zlibbioc -- (Virtual) zlibbioc Bioconductor package

[Dylan Aïssi]

Package: wnpp
Owner: Dylan Aïssi 
Severity: wishlist

Package name: r-bioc-zlibbioc
Version: 1.28.0
Upstream Author: Martin Morgan
URL: https://bioconductor.org/packages/zlibbioc/
License: Artistic-2.0
Programming Lang: GNU R
Description: (Virtual) zlibbioc Bioconductor package
 zlibbioc provides the zlib library to the Bioconductor environment.
 This is useless on Debian as we have a packaged zlib. So, to avoid to patch
 all Bioconductor packages which required zlibbioc, zlibbioc is packaged as an
 empty shell depending on zlib1g-dev (similar mechanism to r-cran-bh).

This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-bioc-zlibbioc

Bug#915375: RFS: gexiv2/0.10.9-1

[Jason Crain]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 Package name: gexiv2
 Version : 0.10.9-1
 Upstream Author : Jens Georg 
 URL : https://wiki.gnome.org/Projects/gexiv2
 License : GPL-2+
 Section : libs

It builds those binary packages:

gir1.2-gexiv2-0.10 - GObject-based wrapper around the Exiv2 library - 
introspection da
libgexiv2-2 - GObject-based wrapper around the Exiv2 library
libgexiv2-dev - GObject-based wrapper around the Exiv2 library - development 
file
libgexiv2-doc - GObject-based wrapper around the Exiv2 library - documentation

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

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


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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gexiv2/gexiv2_0.10.9-1.dsc

More information about gexiv2 can be obtained from 
https://wiki.gnome.org/Projects/gexiv2.

Changes since the last upload:

  [ Ondřej Nový ]
  * d/tests: Use AUTOPKGTEST_TMP instead of ADTTMP

  [ Jason Crain ]
  * New upstream version 0.10.9
- Avoids absolute build path in header file to make the build
  reproducible. (Closes: #891897)
  * Update d/copyright
  * Use static d/libgexiv2-2.symbols file.
This was generated at build-time to automatically mark leaked C++
symbols as optional. Changes to the build system have stopped leaking
these symbols, so this is no longer necessary.
  * Bump Standards-Version to 4.2.1
  * Disable debhelper's autoreconf sequence.
The upstream tarball was built without full autotools support, causing
debhelper's autoreconf step to fail. The autoreconf is unnecessary since
we build through meson, so disable it.
  * Remove d/source/options.
The high compression level specified in this file causes a lintian
warning stating that a high compression level may cause excessive memory
usage.
  * Update d/upstream/metadata.
Update URLs for GNOME's transition to gitlab.

Regards,
 Jason Crain

Bug#915377: ITP: r-cran-generics -- GNU R common S3 generics not provided by base R methods

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-generics
  Version : 0.0.2
  Upstream Author : Max Kuhn, Hadley Wickham, Davis Vaughan, RStudio
* URL : https://cran.r-project.org/package=generics
* License : GPL-2
  Programming Lang: GNU R
  Description : GNU R common S3 generics not provided by base R methods
 This GNU R package provides a number of commonly used S3 generics that
 are not provided by base R methods related to model fitting in order to
 reduce potential package dependencies and conflicts,

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-generics
This package is needed to upgrade r-cran-recipes to latest upstream version.

Bug#915378: pidgin-sipe: Please consider packaging 1.24

[Gregor Riepl]

Package: pidgin-sipe
Version: 1.23.3-1
Severity: normal

Dear Maintainer,

A new version of the OCS/LCS plugin for pidgin has been released. Please
consider packaging it.

Among other things, it would allow screen sharing sessions, which is still
unsupported in 1.23.

Thanks!



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

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

Versions of packages pidgin-sipe depends on:
ii  libc6   2.27-8
ii  libcom-err2 1.44.4-2
ii  libdbus-1-3 1.12.10-1
ii  libfarstream-0.2-5  0.2.8-4
ii  libglib2.0-02.58.1-2
ii  libgssapi-krb5-21.16.1-1
ii  libgstreamer-plugins-base1.0-0  1.14.4-1
ii  libgstreamer1.0-0   1.14.4-1
ii  libk5crypto31.16.1-1
ii  libkrb5-3   1.16.1-1
ii  libnice10   0.1.14-1
ii  libnspr42:4.20-1
ii  libnss3 2:3.39-1
ii  libpurple0  2.13.0-2+b1
ii  libxml2 2.9.4+dfsg1-7+b2

Versions of packages pidgin-sipe recommends:
ii  gstreamer1.0-libav 1.15.0.1+git20180723+db823502-2
ii  gstreamer1.0-plugins-ugly  1.14.4-1
ii  gstreamer1.0-x 1.14.4-1
ii  remmina-plugin-rdp 1.2.32.1+dfsg-1

pidgin-sipe suggests no packages.

-- no debconf information

Bug#915379: anacron.service: should probably use KillMode=process

[Ansgar Burchardt]

Package: anacron
Version: 2.3-26
Severity: normal

anacron.service currently uses KillMode=mixed.  It probably should
not.

KillMode=mixed sends SIGTERM to anacron and then SIGKILL to any
processes started by anacron.  The default (KillMode=control-group)
would send SIGTERM to all processes which is probably what one wantes
if processes started by anacron should be stopped when anacron is (for
example during upgrades).

More likely, anacron should probably use KillMode=process.  Then
stopping anacron would only send SIGTERM to anacron itself and leave
the jobs anacron might have started untouched.  (This is what
cron.service uses.)

Ansgar

Bug#914340: [DAViCal-devel] Bug#914340: webserver sometimes needs to be restarted

[Daniel Pocock]

On 22/11/2018 23:25, Florian Schlichting wrote:
> Hi Daniel,
> 
> On Thu, Nov 22, 2018 at 12:35:59PM +0100, Daniel Pocock wrote:
>> Warning: CalDAV: No response status doing webdav sync for calendar foo
>> Warning: CalDAV: Error doing webdav sync: undefined
>> Warning: There has been an error reading data for calendar: foo.
>> However, this error is believed to be minor, so the program will attempt
>> to continue. Error code: DAV_REPORT_ERROR. Description: There has been
>> an error reading data for calendar:
>> https://foo.example.org/davical/caldav.php/foo/home/. It has been
>> disabled until it is safe to use it.
>> Warning: There has been an error reading data for calendar: foo.
>> However, this error is believed to be minor, so the program will attempt
>> to continue. Error code: READ_FAILED. Description:
> 
> I don't remember ever seeing this from Thunderbird for calendars on a
> DAViCal server.
> 


On DAVdroid, this is the error:

12-03 10:36:59.599  2613   471 W davdroid: [syncadapter.SyncManager] I/O
exception during sync, trying again later
12-03 10:36:59.599  2613   471 W davdroid: EXCEPTION
java.io.IOException: unexpected end of stream on
Connection{dav.example.org:443, proxy=DIRECT
hostAddress=dav.example.org/10.1.2.3:443
cipherSuite=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 protocol=http/1.1}




>> Simply logging into the web server and doing
>>
>>   systemctl restart apache2
>>
>> resolves the issue and all the clients work again for another week or so.
>>
>> Has anybody else observed this?
>>
>> Where should I look for additional logging or clues next time this
>> happens?  Should I enable any extra logging options in DAViCal, Apache
>> or PostgreSQL?
>
> Well I'd start with the Apache logs: when TB says "no response status",
> what does Apache think happened with the request, which status did it
> log, anything in the error log?
>
> A default install of the davical package pulls in mod_php, which AFAIK
> doesn't keep state between requests; do you use a different PHP
> interpreter, or something like a Zend server or memcached? Nothing in
> the way davical processes or responds to a request should change from a
> webserver restart, really...
>
> If you still think davical may be at fault and want to dig deeper, have
> a look at https://wiki.davical.org/index.php/Debugging - I'd recommend
> setting $c->dbg["ALL"] = 1; and perhaps limiting things to a single
> remote IP. The result is fairly verbose but should show you what the
> requests and responses look like, and will provide enough detail to pin
> down where things go south on the server side.




There is nothing in Apache access.log or error.log for this particular
virtual host.

I press sync once in DAVdroid and this appears 3 times in the main
error.log:

[Mon Dec 03 09:42:19.538805 2018] [core:notice] [pid 13779] AH00052:
child pid 5106 exit signal Segmentation fault (11)
[Mon Dec 03 09:42:19.538919 2018] [core:notice] [pid 13779] AH00052:
child pid 5113 exit signal Segmentation fault (11)
[Mon Dec 03 09:42:19.538945 2018] [core:notice] [pid 13779] AH00052:
child pid 5115 exit signal Segmentation fault (11)

Nothing from journalctl

I made a capture with tcpdump as well, I notice the server has sent "New
Session Ticket" and the client has sent three "Application Data" packets
and then the server closes the connection

I did

  apt install systemd-coredump

and used prlimit to set core size unlimited for the running process but
I can't find any core dumps yet, maybe the apache2 needs to be
restarted, but then the problem will not happen again for another week.

I also tried connecting to the main process with

   gdb /usr/sbin/apache2 13779

but that doesn't show any output when the seg fault happens.


Then I tried guessing which child process would crash next and connected
to it with gdb, looks like an issue in pdo_pgsql.so with PHP 7, stack is
below.

Should the bug be reassigned to the php-pgsql package?  As we have a
reproducible stack trace I feel it is now an RC issue too.

Is there any other data I should gather before restarting the Apache
process again?  I can leave it like this for a couple of hours maximum.


Thread 1 "apache2" received signal SIGSEGV, Segmentation fault.
0x7fa662662ed4 in ERR_clear_error () from
target:/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
(gdb) bt
#0  0x7fa662662ed4 in ERR_clear_error () from
target:/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
#1  0x7fa66267dfe9 in ?? () from
target:/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
#2  0x7fa66bdf5739 in __pthread_once_slow
(once_control=0x7fa6629a72d4, init_routine=0x7fa66267dfe0) at
pthread_once.c:116
#3  0x7fa6626d3f59 in CRYPTO_THREAD_run_once () from
target:/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
#4  0x7fa66267e75b in OPENSSL_init_crypto () from
target:/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
#5  0x7fa6625faffe in ?? () from
target:/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
#6  0x7fa66267e080 in ?? () from
target:/u

Bug#915088: multipath-tools: installing multipath-tools will force dracut to be removed while it shouldn't.

[LAHAYE Olivier]

I understand, I don't want to break things for sure.

In the meantime, I think that dracut native multipath module has the logic to 
handle stackable storage, though, of course, on Debian nobody can test as both 
dracut and multiupath-tools can't be installed together for further testing 
debugging.

On my side, (Systemimager), I made multipath-tools optional (dracut generates a 
warning telling it can't load the multipath module because multipathd binary is 
not found), and that's ok for those who don't need multipath)

It's up to you to decide what is the best for Debian.

My though (outside this bug reporting) is that it would be a good step forward 
for Debian to switch from old initramfs-tools to modern dracut.

Cheers,

Le 01/12/2018 05:55, « Ritesh Raj Sarraf »  a écrit :

Hi Olivier,

I am not denying any of what you have said below. Dracut may be a great
tool. But unfortunately, it does not have the uptake in Debian, that
initramfs-tools has. Just look at the popcon stats.

multipath-tools needs tight integration with the plumbing layer to
ensure you have a stackable storage. For Debian, the work so far has
been done integrating it with initramfs-tools.


I am not opposed to adding dracut as an option. It is just that I have
never worked on it. Nor have any users/developers ever reported about
its integration here.

If dracut can serve as a drop-in replacement, I don't have any problem
adding it as an OR dependency in `sg3-utils-udev` package.


On Fri, 2018-11-30 at 16:13 +, LAHAYE Olivier wrote:
> Dracut is the only tool to create initramfs on many distros and it
> works fine with multipath so far. Dracut is to initramfs-tools what
> systemd is to basic initscripts.
> Dracut is modular and event driven while initramfs-tools is
> monolithic and linear static.
> 
> If you look at /usr/lib/dracut/modules.d you'll notice that a module
> already exists for multipathd. (/usr/lib/dracut/modules.d/90multipath
> and /usr/lib/dracut/modules.d/90multipath-hostonly)
> 
> man dracut
> man dracut.modules
> man dracut.cmdline
> 
> See also the module-setup.sh in both 90multipath and 90multipath-
> hostonly modules
> 
> Dracut is really a wonderful piece of code that is really easy to
> understand and that can create really powerful ramfs images.
-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System

Bug#915088: multipath-tools: installing multipath-tools will force dracut to be removed while it shouldn't.

[Ritesh Raj Sarraf]

On Mon, 2018-12-03 at 10:22 +, LAHAYE Olivier wrote:
> My though (outside this bug reporting) is that it would be a good
> step forward for Debian to switch from old initramfs-tools to modern
> dracut.

In 2015, at Debconf, there was a BoF session about kernel and userland.
There dracut was mentioned. Back then too, we had the same problem.

We (different package maintainers as well as the dracut package
maintainer) agreed that the way forward to have better integration is
to make more people use it. But, for Debian, that usually only happens
when someone puts that effort. And for a core piece like initramfs,
there's quite some work.

Back then, initramfs-tools was unmaintained if I remember correct.
Because we did discuss for some time on how to maintain it ahead. And
dracut was vetted as an alternative.

But sadly, not much seems to have progressed from then to now. Instead,
it seems, initramfs-tools got an active maintainer.


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


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

Bug#914340: system details

[Daniel Pocock]

Here are some of the package versions that are installed:

ii  apache22.4.25-3+deb9u6

ii  davical1.1.7-1~bpo9+1

ii  dbconfig-pgsql 2.0.8

ii  libapache2-mod-php 1:7.0+49

ii  libapache2-mod-php7.0  7.0.30-0+deb9u1

ii  openssl1.1.0f-3+deb9u2

ii  libssl1.1:amd641.1.0f-3+deb9u2

ii  php1:7.0+49

ii  php-pgsql  1:7.0+49

ii  php7.0 7.0.30-0+deb9u1

ii  php7.0-pgsql   7.0.30-0+deb9u1


The pdo_pgsql module comes from package php7.0-pgsql:


# grep pdo_pgsql /var/lib/dpkg/info/*.list
/var/lib/dpkg/info/davical-doc.list:/usr/share/doc/davical-doc/api/function-check_pdo_pgsql.html
/var/lib/dpkg/info/davical-doc.list:/usr/share/doc/davical-doc/api/source-function-check_pdo_pgsql.html
/var/lib/dpkg/info/libphp-adodb.list:/usr/share/php/adodb/drivers/adodb-pdo_pgsql.inc.php
/var/lib/dpkg/info/php7.0-pgsql.list:/usr/lib/php/20151012/pdo_pgsql.so
/var/lib/dpkg/info/php7.0-pgsql.list:/usr/share/php7.0-pgsql/pgsql/pdo_pgsql.ini

Bug#915207: gnudatalanguage: autopkgtests fail: test_bug_n000720, test_idlneturl, test_point_lun, test_save_restore, test_zip

[Gilles Filippini]

Hi,

Ole Streicher a écrit le 03/12/2018 à 11:02 :
> About 30-40 of those are mine, BTW. And I am still unsure whether hdf5
> is not really the cause of the problem yet, since it is the HDF5 test
> case in gnudatalanguage is the only one where I don't see a reason for
> the failure yet. Just "let us migrate" is the wrong way here -- the CI
> migration delays are to find out where the problem is before.

Please read the bugreport: I've done my homework and rebuilt
gnudatalanguage against HDF5 1.10.0 and netcdf 4.6.1 to check whether
the current HDF5 transition could be the cause of the failures. The
answer is no: autopkgtest still fails in that case.
BTW test_hdf5 is in d/tests/test-gdl.xfail. It is not the cause of the
current autopkgtest failure.

About the bug severity, I don't care actually, as soon as it doesn't
block the HDF5 transition.

Thanks,

_g.

Bug#900160: closed by Didier Raboud (Bug#900160: fixed in ruby-eventmachine 1.0.7-4.1)

[Didier 'OdyX' Raboud]

Le dimanche, 2 décembre 2018, 23.18:38 h CET Sebastian Andrzej Siewior a écrit 
:
> On 2018-12-02 13:06:04 [+], Debian Bug Tracking System wrote:
> > #900160: ruby-eventmachine: FTBFS against openssl 1.1.1
> > 
> >  ruby-eventmachine (1.0.7-4.1) unstable; urgency=medium
> >  .
> >  
> >* Non-maintainer upload.
> >* Build-Depend against libssl1.0-dev; aka OpenSSL << 1.1
> >
> >  (Closes: #900160)
> 
> Please revert that one. We don't want more dependencies on
> libssl1.0-dev. We want it actually out of testing and are down to one
> package.

Which one?

> I wouldn't care much but since ruby-eventmachine is a key package it
> might migrate to testing…

That's exactly the point: porting ruby-eventmachine to work with OpenSSL 1.1 
is not easy and not done upstream.  An apparently it is not easily removable 
from Debian testing either.  Sure, removing OpenSSL 1.0 is important, but 
specifically for ruby-eventmachine, it's better to have one that builds (and 
works) instead of one that doesn't, especially as it's a dependency for lots 
of other software.

With these updated Build-Dependencies, at some point, the Release Team could 
"just" remove libssl1.0-dev (and all the reverse dependencies tree) from 
testing, thereby forcing the update of the concerned packages to depend (and 
work) on OpenSSL 1.1.

(Also, I can't revert the NMU, the package would not build :-) )

Cheers,
OdyX

Bug#654830: (no subject)

[gustavo panizzo]

One year after my last comment and after finding tuptime I think uptimed
should be removed.

Package is widely used so I'm not so sure how to procced, I really want
to remove it and get people to use tuptime (which is superior in every
way IMHO) 


--
IRC: gfa
GPG: 0X44BB1BA79F6C6333

Bug#915381: Shouldn't nvidia-persistenced be daemonized (using Debian standard way to do so) ?

[Cédric Dufour - Idiap Research Institute]

Package: nvidia-persistenced
Version: 390.25-1


Hello,

nVidia made it clear to us that nvidia-persistenced *really* should be running 
on (headless/no X server) CUDA nodes, because it does *more* than just keep the 
driver "up" (in particular, it fixes erroneous outputs from nvidia-smi; e.g. 
wrong GPU perf-state/load/memory accross multi-GPU setups).

I see the current (Stretch) and latest (Unstable) Debian packaging of 
nvidia-persistenced does not enable the binary as a daemon (but merely provides 
example sysv/systemd/upstart scripts, in /usr/share/doc).

Is there a reason the Debian package does not enable this binary as a 
(sysv+systemd) daemon, along creating the ad-hoc system user (e.g. "nvpd") for 
it ?
If not, could this be looked into (I can provide input based on my own 
re-packaging of the daemon) ?

Thanks for your work and best regards,

Cédric

-- 
Cédric Dufour @ Idiap Research Institute

Bug#617664: meanwhile...

[Gürkan Myczko]

lix is not c++ but D, here's an updated almost ready package for 
testing:

http://phd-sid.ethz.ch/debian/lix/

Bug#915181: dak shouldn't accept changes in components directly in upstream

[Xavier]

Le 03/12/2018 à 11:10, Ansgar Burchardt a écrit :
> Hi,
> 
> please explain what components you are talking about and why they
> shouldn't be allowed in Debian.
> 
> Ansgar

Hello,

Thanks for looking this issue.

For example, node-mongodb uses uscan components to embed some
node-modules [1]. DD can update his debian/watch to add a new component.

When a DD adds a binary entry in debian/control, update isn't accepted
directly in unstable but routed to NEW queue.

It could be safe to apply the same policy when a component is added.

Cheers,
Xavier

[1]: https://salsa.debian.org/js-team/node-mongodb/blob/master/debian/watch

Bug#914150: pcmanfm: Loader SEGFAULT

[Nicola]

Package: pcmanfm
Version: 1.3.0-1
Followup-For: Bug #914150

Dear Maintainer,

opening a folder, with some subfolders and file make pcmanfm crash.
The folder is a Dropbox folder, already tried to remove it and download it
again, problem remains.

In dmesg:
[ 4049.174559] loader[31144]: segfault at 0 ip 7fdfa1f2c2c0 sp
7fdfa1670990 error 4 in libpixbufloader-svg.so[7fdfa1f2c000+1000]
[ 4049.174566] Code: d9 4c 89 ee e8 c1 fd ff ff 89 c5 85 c0 74 1b bd 01 00 00
00 48 83 c4 08 89 e8 5b 5d 41 5c 41 5d c3 66 0f 1f 84 00 00 00 00 00 <48> 8b 3b
48 c7 03 00 00 00 00 48 85 ff 74 05 e8 0c fe ff ff 48 89





-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (950, 'testing'), (400, 'unstable'), (300, 'experimental'), (10, 
'stable')
Architecture: amd64 (x86_64)

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

Versions of packages pcmanfm depends on:
ii  libatk1.0-0  2.30.0-1
ii  libc62.27-8
ii  libcairo21.16.0-1
ii  libfm-gtk4   1.3.0.2-1
ii  libfm4   1.3.0.2-1
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.8.1-2
ii  libfribidi0  1.0.5-3
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-6
ii  libglib2.0-0 2.58.1-2
ii  libgtk2.0-0  2.24.32-3
ii  libpango-1.0-0   1.42.4-4
ii  libpangocairo-1.0-0  1.42.4-4
ii  libpangoft2-1.0-01.42.4-4
ii  libx11-6 2:1.6.7-1
ii  shared-mime-info 1.10-1

Versions of packages pcmanfm recommends:
ii  gnome-icon-theme3.12.0-3
ii  gvfs-backends   1.38.1-1
pn  gvfs-fuse   
pn  lxpolkit | polkit-1-auth-agent | policykit-1-gnome  

pcmanfm suggests no packages.

-- no debconf information

Bug#915381: Shouldn't nvidia-persistenced be daemonized (using Debian standard way to do so) ?

[Andreas Beckmann]

Control: tag -1 help

On 2018-12-03 11:27, Cédric Dufour - Idiap Research Institute wrote:
> Is there a reason the Debian package does not enable this binary as a 
> (sysv+systemd) daemon, along creating the ad-hoc system user (e.g. "nvpd") 
> for it ?

Yes. Nobody has done it so far. :-)
Maybe nobody actually used it until you came around. (I don't use it.)

> If not, could this be looked into (I can provide input based on my own 
> re-packaging of the daemon) ?

Patches welcome! (Or a pull request against the repo on salsa.)
We will probably not "fix" this for stretch (but stretch-backports),
unless someone gets this approved by the release team (but let's have
this in sid first.)

And it should work with both systemd and legacy sysv.


Andreas

Bug#915181: dak shouldn't accept changes in components directly in upstream

[Mattia Rizzolo]

On Mon, Dec 03, 2018 at 11:24:46AM +0100, Xavier wrote:
> For example, node-mongodb uses uscan components to embed some
> node-modules [1]. DD can update his debian/watch to add a new component.
> 
> When a DD adds a binary entry in debian/control, update isn't accepted
> directly in unstable but routed to NEW queue.
> 
> It could be safe to apply the same policy when a component is added.

I disagree with this position, for at least because they have been
around for a very long time (the fact that uscan now can deal with this
weird versioning to track different projects is just a detail, really),
but I don't think anybody ever thought there were reasons to gate them
through NEW.

I understand there are fair risks of people adding a new component
referring to an entirely different project without updating d/copyright,
but it's a risk we have always had (see vlc, it sometimes embeds
ffmpeg), and I don't think the ftp-team have the resources to start
reviewing also these.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#900821: vers=2.1 won't solve it

[Santiago Garcia Mantinan]

Hi!

I have tested vers=2.1 parameter on a current Buster installation and at
least if the server is a Samba (samba as in Buster with a standard setup)
the version of the protocol won't solve anything, the wget still breaks:

Saving to: 'STDOUT'

-16%[>  ]   1.01M  --.-KB/s 
   in 0.008s  

2018-12-03 13:55:39 (124 MB/s) - Read error at byte 1056768/6538880 (Bad 
address). Retrying.

The only working solution still is EnableSendFile On

This was tested with:

ii  linux-image-4.18.0-2-amd644.18.10-2+b1amd64
Linux 4.18 for 64-bit PCs
ii  samba 2:4.9.2+dfsg-2  amd64
SMB/CIFS file, print, and login server for Unix
ii  apache2   2.4.37-1amd64
Apache HTTP Server

Regards.
-- 
Santiago García Mantiñán

Bug#653738: Configuration routine not run if a package specified on first run

[Kay McCormick]

Package: reportbug
Followup-For: Bug #653738

This seems fixed to me - there is a warning printed when the configuration
is skipped. The user can elect to ^C and re-run reportbug at this time.

--
if utils.first_run():
if not self.args and not self.options.searchfor:
offer_configuration(self.options)
main()
sys.exit(0)
else:
ewrite('Warning: no reportbug configuration found.  Proceeding in 
%s mode.\n' % self.options.mode)
--

-- Package-specific info:
** Environment settings:
INTERFACE="text"

** /home/user/j/jade/.reportbugrc:
reportbug_version "7.5.1"
mode standard
ui text
realname "Kay McCormick"

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

Kernel: Linux 4.18.0-2-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Enforcing - Policy name: default

Versions of packages reportbug depends on:
ii  apt1.8.0~alpha2
ii  python33.6.7-1
ii  python3-reportbug  7.5.1
ii  sensible-utils 0.0.12

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
pn  debconf-utils  
pn  debsums
ii  dlocate1.07+nmu1
pn  emacs24-bin-common | emacs25-bin-common
ii  exim4-daemon-light [mail-transport-agent]  4.91-8+b1
ii  file   1:5.34-2
ii  gnupg  2.2.11-1
ii  python3-urwid  2.0.1-2+b1
pn  reportbug-gtk  
ii  xdg-utils  1.1.3-1

Versions of packages python3-reportbug depends on:
ii  apt1.8.0~alpha2
ii  file   1:5.34-2
ii  python33.6.7-1
ii  python3-apt1.7.0
ii  python3-debian 0.1.33
ii  python3-debianbts  2.7.2
ii  python3-requests   2.20.0-2

python3-reportbug suggests no packages.

-- no debconf information

Bug#821884: [nano] please provide a shortcut to delete previous/next word

[Arturo Borrero Gonzalez]

Control: fixed -1 3.2-1

On 12/2/18 8:34 PM, Benno Schulenberg wrote:
> 
> Since nano-3.0,  deletes the word to the right of the cursor,
> and  deletes the word to the left.
> 
> If you never use ^H, on some terminals you can also make 
> delete the word to the left of the cursor when you add in your ~/.nanorc:
> 
>   bind ^H cutwordleft main
> 
> Benno
> 

Thanks!

Bug#879249: http/2

[folkert]

This problem is now especially worse since prefork no longer allows
http/2.


Folkert van Heusden

-- 
--
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

Bug#858937: kde4libs: Please migrate to openssl1.1 in buster

[Didier 'OdyX' Raboud]

Le samedi, 1 décembre 2018, 15.33:37 h CET Sebastian Andrzej Siewior a écrit :
> On December 1, 2018 2:02:42 PM UTC, Didier 'OdyX' Raboud  
wrote:
> >So; to get the ball rolling on this RC bug:
> >
> >* I've prepared a Debian patch with it
> 
> If you switch to openssl-dev with this upload, please make it depend on
> libssl1.1 (which does not happen because it does not depend on any symbols)
> and the you could also close
> 
> #913959 [S|  |  ] [src:kde4libs] kde4libs: Build-Depends on libssl1.0-dev

I've checked thoroughly, and didn't find any package from src:kde4libs which 
has a relationship with libssl*; so I think this upload at least is no 
regression in that regard.

Cheers,
OdyX

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

Bug#913987: policycoreutils-python-utils: audit2allow -R cant open "interface info"

[Laurent Bigonville]

On Sat, 17 Nov 2018 17:00:30 -0800 Jade McCormick 
 wrote:


> Dear Maintainer,
>
> audit2allow -R is supposed to generate allow rules that incorporate M4
> interface macros from the reference policy. However, this does not 
appear to work

> on debian. When I run audit2allow -b -R, for instance:
>
> could not open interface info [/var/lib/sepolgen/interface_info]
>
> I had to run "sepolgen-ifgen" in order for this command to work.
>
> Is it possible to ship this file in the package, or to run this 
command upon

> package installation?

sepolgen-ifgen is called from the postinst script from the 
selinux-policy-dev package already.


As you can have multiple policy installed on your system, I'm not too 
sure how to handle this as you would need to re-run sepolgen-ifgen 
manually when switching policy anyway.


So I would say, if you are using the debian policy everything is already 
working automatically, if you are using a custom policy you are on your own.

Bug#915181: dak shouldn't accept changes in components directly in upstream

[Xavier]

Le 03/12/2018 à 12:11, Mattia Rizzolo a écrit :
> On Mon, Dec 03, 2018 at 11:24:46AM +0100, Xavier wrote:
>> For example, node-mongodb uses uscan components to embed some
>> node-modules [1]. DD can update his debian/watch to add a new component.
>>
>> When a DD adds a binary entry in debian/control, update isn't accepted
>> directly in unstable but routed to NEW queue.
>>
>> It could be safe to apply the same policy when a component is added.
> 
> I disagree with this position, for at least because they have been
> around for a very long time (the fact that uscan now can deal with this
> weird versioning to track different projects is just a detail, really),
> but I don't think anybody ever thought there were reasons to gate them
> through NEW.
> 
> I understand there are fair risks of people adding a new component
> referring to an entirely different project without updating d/copyright,
> but it's a risk we have always had (see vlc, it sometimes embeds
> ffmpeg), and I don't think the ftp-team have the resources to start
> reviewing also these.

OK, so perhaps could we think to add some lintian errors?
 - require debian/README.source
 - detect missing "Files: /..." in debian/copyright

Bug#875186: New version in salsa

[Leopold Palomo-Avellaneda]

There's a new version of the package in

https://salsa.debian.org/science-team/soqt/tree/Qt5


it builds soqt with qt5 and coin3 cmake version.


-- 
--
Linux User 152692 GPG: 05F4A7A949A2D9AA
Catalonia
-
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?



signature.asc
Description: OpenPGP digital signature

Bug#915181: dak shouldn't accept changes in components directly in upstream

[Mattia Rizzolo]

On Mon, Dec 03, 2018 at 12:38:52PM +0100, Xavier wrote:
> OK, so perhaps could we think to add some lintian errors?
>  - require debian/README.source

This I'm not convinced: the whole distribution is trying to standardize
as much as possible, README.source originally is to explain non-standard
stuff.

>  - detect missing "Files: /..." in debian/copyright

That sounds like a good idea… except what if the component comes from
the same developer and with the same license of the main package?  Do
you think forcing duplicating the paragraph in that case is not
important enough, or with too few cases?
I think you should open this as a lintian bug :)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#821397: ITP: sway -- i3-compatible Wayland compositor

[Mattia Rizzolo]

On Sun, Dec 02, 2018 at 10:10:33PM +0100, Birger Schacht wrote:
> but i'm not a DM so i can not upload it. Should i create an RFS and go
> through mentors?
> (also, i'm still not sure if its oke to just take the package from nicoo)

Usually it's not quite ok, and at the very least it's considered rude.

Note sure, do you have some kind of agreement with nicoo?  If so then I
guess you can go ahead…

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#915181: dak shouldn't accept changes in components directly in upstream

[Xavier]

Le 03/12/2018 à 12:45, Mattia Rizzolo a écrit :
> On Mon, Dec 03, 2018 at 12:38:52PM +0100, Xavier wrote:
>> OK, so perhaps could we think to add some lintian errors?
>>  - require debian/README.source
> 
> This I'm not convinced: the whole distribution is trying to standardize
> as much as possible, README.source originally is to explain non-standard
> stuff.
> 
>>  - detect missing "Files: /..." in debian/copyright
> 
> That sounds like a good idea… except what if the component comes from
> the same developer and with the same license of the main package?  Do
> you think forcing duplicating the paragraph in that case is not
> important enough, or with too few cases?

A simple entry in lintian-overrides could be a good workaround. DD will
be forced to consider this point.

  Severity: important, Certainty: wild-guess

> I think you should open this as a lintian bug :)

May be reassign+retitle this issue is enough or on a separate issue ?

Bug#915181: dak shouldn't accept changes in components directly in upstream

[Mattia Rizzolo]

On Mon, Dec 03, 2018 at 12:52:13PM +0100, Xavier wrote:
> > I think you should open this as a lintian bug :)
> 
> May be reassign+retitle this issue is enough or on a separate issue ?

I'd open a new issue with a cleaner history and description (of course
referring to this one), but that's up to you.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#915382: python-ruffus FTBFS: test failure

[Adrian Bunk]

Source: python-ruffus
Version: 2.8.1-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=python-ruffus&arch=all&ver=2.8.1-1&stamp=1543767274&raw=0

...
   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
dh_auto_test -- --test --system=custom \
--test-args='set -e; \
cd {build_dir}/ruffus/test ; \
if [ "{version.major}" = 2 ] ; then \
ln -s /build/python-ruffus-*/ruffus/test/Makefile ; \
cp -a run_all_unit_tests.cmd 
/tmp/run_all_unit_tests.cmd ; \
else \
sed "s/^python3/python{version}/" 
run_all_unit_tests3.cmd > /tmp/run_all_unit_tests.cmd ; \
fi ;\
PYTHONPATH={build_dir} HOME=`mktemp -d` bash 
/tmp/run_all_unit_tests.cmd'
I: pybuild base:217: set -e; \
cd 
/<>/.pybuild/cpython2_2.7_ruffus/build/ruffus/test ; \
if [ "2" = 2 ] ; then \
ln -s /build/python-ruffus-*/ruffus/test/Makefile ; \
cp -a run_all_unit_tests.cmd 
/tmp/run_all_unit_tests.cmd ; \
else \
sed "s/^python3/python2.7/" run_all_unit_tests3.cmd > 
/tmp/run_all_unit_tests.cmd ; \
fi ;\

PYTHONPATH=/<>/.pybuild/cpython2_2.7_ruffus/build HOME=`mktemp -d` 
bash /tmp/run_all_unit_tests.cmd
make[2]: Entering directory 
'/<>/.pybuild/cpython2_2.7_ruffus/build/ruffus/test'
make[2]: Makefile: No such file or directory
make[2]: *** No rule to make target 'Makefile'.
make[2]: Failed to remake makefile 'Makefile'.
make[2]: *** No rule to make target 'all'.
make[2]: Leaving directory 
'/<>/.pybuild/cpython2_2.7_ruffus/build/ruffus/test'
E: pybuild pybuild:338: test: plugin custom failed with: exit code=2: set -e; \
cd 
/<>/.pybuild/cpython2_2.7_ruffus/build/ruffus/test ; \
if [ "2" = 2 ] ; then \
ln -s /build/python-ruffus-*/ruffus/test/Makefile ; \
cp -a run_all_unit_tests.cmd 
/tmp/run_all_unit_tests.cmd ; \
else \
sed "s/^python3/python2.7/" run_all_unit_tests3.cmd > 
/tmp/run_all_unit_tests.cmd ; \
fi ;\

PYTHONPATH=/<>/.pybuild/cpython2_2.7_ruffus/build HOME=`mktemp -d` 
bash /tmp/run_all_unit_tests.cmd
dh_auto_test: pybuild --test --test-pytest -i python{version} -p 2.7 --test 
--system=custom "--test-args=set -e; \\\
cd {build_dir}/ruffus/test ; \\\
if [ \"{version.major}\" = 2 ] ; then \\\
ln -s /build/python-ruffus-*/ruffus/test/Makefile ; \\\
cp -a run_all_unit_tests.cmd 
/tmp/run_all_unit_tests.cmd ; \\\
else \\\
sed \"s/^python3/python{version}/\" 
run_all_unit_tests3.cmd > /tmp/run_all_unit_tests.cmd ; \\\
fi ;\\\
PYTHONPATH={build_dir} HOME=\`mktemp -d\` bash 
/tmp/run_all_unit_tests.cmd" returned exit code 13
make[1]: *** [debian/rules:24: override_dh_auto_test] Error 25

Bug#914616: Fixed by latest binNMU

[Petter Reinholdtsen]

Despite being closed and flagged with the approriate version numbers, this
RC bug is causing ring to be flagged for automatic removal.

Anyone got any idea how to clean up the mess?
-- 
Happy hacking
Petter Reinholdtsen

Bug#913645: Oldstable also affected

[Bastian Neuburger]

Hi Carsten,

I forgot to report back, but I also created Upstream bug 1510212 
(https://bugzilla.mozilla.org/show_bug.cgi?id=1510212). As I stated 
there it might take a while until I can test migration again, since I 
reinstalled my test machine with Buster and thus have no test 
environment with Jessie or Stretch right now.


I'll report back to upstream how this goes.

Cheers,

Bastian

On 11/30/18 6:50 AM, Carsten Schoenert wrote:

Control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1505038

Hello Bastian,

Am 20.11.18 um 17:44 schrieb Bastian Neuburger:

Hi,


I have however not yet tested what happens if you start thunderbird
aftter the upgrade and close it right away (i.e. not trying to sign
anything but also not entering the master password). I will try to test
this later but now I need a working mail client.



I also tested this variant now:

1. Have berkeley DB based profile that works fine with thunderbird 52 in
Jessie
2. Upgrade thunderbird
3. Start thunderbird
4. Close it without doing anything (I am not prompted for the master
password)
5. Start thunderbird again

Expected results:
Either key3.db is still there or I am getting prompted for a master
password during step 4.

Actual results:
Everything under "Your certificates" and "People" in the Certificate
Manager gone, all saved passwords gone.

So the problem we encountered did not only wipe private keys, but also
certificates of other people I already corresponded with AND stored
passwords.

How should reporting with upstream be handled? Should I take care of it
myself or would you like to forward it?


I haven't forwarded that all into a new upstream bug report, but I was
able to talk about that issue with upstream.
Initially upstream (in that case the NSS/Firefox team) has decided about
6 years ago to stop using the old database option [1] and use the newer
NSS implementations for storing stuff within a database.

Your are not the only person who is experience such problems. There is
the report 1505038 [2] which is from a user with the same problems. The
issue has some workaround mentioned in comment #25 which should be
"solve" your current problem, could you please test this suggestion?

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=783994
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1505038



--
Neuburger, Bastian
 Telefon: +49-6159-71 1740
 Abteilung: IT-Security

GSI Helmholtzzentrum für Schwerionenforschung GmbH
Planckstraße 1, 64291 Darmstadt, Germany, www.gsi.de

Commercial Register / Handelsregister: Amtsgericht Darmstadt, HRB 1528
Managing Directors / Geschäftsführung:
Professor Dr. Paolo Giubellino, Ursula Weyrich, Jörg Blaurock
Chairman of the Supervisory Board / Vorsitzender des GSI-Aufsichtsrats:
State Secretary / Staatssekretär Dr. Georg Schütte

Bug#912799: doxygen switch to llvm-toolchain-7

[Paolo Greppi]

Hi, in preparation for this switch I am building doxygen from source with:

sudo apt install llvm-7-dev # for 
/usr/lib/llvm-7/lib/cmake/llvm/LLVMConfig.cmake
sudo apt install clang-7 # for /usr/lib/llvm-7/lib/cmake/clang/ClangConfig.cmake
git clone https://github.com/doxygen/doxygen
cd doxygen
mkdir build
cd build
LLVM_DIR=/usr/lib/llvm-7/lib/cmake/llvm/ 
Clang_DIR=/usr/lib/llvm-7/lib/cmake/clang/ cmake -Duse_libclang=ON -G "Unix 
Makefiles" ..
make

It builds, but the resulting binary fails to start with:
./bin/doxygen 
: CommandLine Error: Option 'help-list' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options

Further info, output of ldd ./bin/doxygen:
linux-vdso.so.1 (0x7ffd9b9a6000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f197e18e000)
libclang-7.so.1 => /usr/lib/llvm-7/lib/libclang-7.so.1 
(0x7f197c652000)
libLLVM-7.so.1 => /usr/lib/llvm-7/lib/libLLVM-7.so.1 
(0x7f197872a000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f197850c000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f1978502000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f19784fd000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 
(0x7f19784cd000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f197834a000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f19781b6000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f197819c000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f1977fdf000)
/lib64/ld-linux-x86-64.so.2 (0x7f19804b5000)
libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 
(0x7f1977dd6000)
libedit.so.2 => /usr/lib/x86_64-linux-gnu/libedit.so.2 
(0x7f1977b9c000)
libncurses.so.6 => /lib/x86_64-linux-gnu/libncurses.so.6 
(0x7f1977b73000)
libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x7f197795c000)

Link command:
cd /tmp/doxygen.upstream/build/src && /usr/bin/cmake -E cmake_link_script 
CMakeFiles/doxygen.dir/link.txt --verbose=1
/usr/lib/ccache/c++-rdynamic CMakeFiles/doxygen.dir/main.cpp.o  -o 
../bin/doxygen -Wl,-rpath,/usr/lib/llvm-7/lib: ../lib/lib_doxygen.a 
../lib/libdoxycfg.a ../lib/libqtools.a ../lib/libmd5.a ../lib/libvhdlparser.a 
-lpthread /usr/lib/llvm-7/lib/libclang-7.so.1 
/usr/lib/llvm-7/lib/libclangTooling.a /usr/lib/llvm-7/lib/libLLVMSupport.a 
/usr/lib/llvm-7/lib/libLLVMCore.a /usr/lib/llvm-7/lib/libLLVMOption.a 
/usr/lib/llvm-7/lib/libclangASTMatchers.a /usr/lib/llvm-7/lib/libclangFormat.a 
/usr/lib/llvm-7/lib/libclangToolingInclusions.a 
/usr/lib/llvm-7/lib/libclangFrontend.a /usr/lib/llvm-7/lib/libclangDriver.a 
/usr/lib/llvm-7/lib/libclangParse.a /usr/lib/llvm-7/lib/libclangSerialization.a 
/usr/lib/llvm-7/lib/libclangSema.a /usr/lib/llvm-7/lib/libclangEdit.a 
/usr/lib/llvm-7/lib/libclangAnalysis.a 
/usr/lib/llvm-7/lib/libclangToolingCore.a /usr/lib/llvm-7/lib/libclangAST.a 
/usr/lib/llvm-7/lib/libclangRewrite.a /usr/lib/llvm-7/lib/libclangLex.a 
/usr/lib/llvm-7/lib/libclangBasic.a /usr/lib/llvm-7/lib/libLLVM-7.so.1 
/usr/lib/llvm-7/lib/libLLVMBinaryFormat.a /usr/lib/llvm-7/lib/libLLVMSupport.a 
-lz -lrt -ldl -ltinfo -lpthread -lm /usr/lib/llvm-7/lib/libLLVMDemangle.a 

Thanks,

Paolo

Bug#915383: freecad: Freecad using new version of coin3 with cmake

[Leopold Palomo-Avellaneda]

Package: freecad
Severity: grave
Justification: renders package unusable

Dear Maintainer,

coin3 is in experimental and is in the beginning of a transition to a new 
version built with cmake.
freecad will need to use this version.



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

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

Versions of packages freecad depends on:
ii  libboost-atomic1.62.0   1.62.0+dfsg-4
ii  libboost-chrono1.62.0   1.62.0+dfsg-4
ii  libboost-date-time1.62.01.62.0+dfsg-4
ii  libboost-filesystem1.62.0   1.62.0+dfsg-4
ii  libboost-program-options1.62.0  1.62.0+dfsg-4
ii  libboost-python1.62.0   1.62.0+dfsg-4
ii  libboost-regex1.62.01.62.0+dfsg-4
ii  libboost-signals1.62.0  1.62.0+dfsg-4
ii  libboost-system1.62.0   1.62.0+dfsg-4
ii  libboost-thread1.62.0   1.62.0+dfsg-4
ii  libc6   2.24-11+deb9u3
pn  libcoin80v5 
ii  libfreeimage3   3.17.0+ds1-5
ii  libfreetype62.6.3-3.2
ii  libgcc1 1:6.3.0-18+deb9u1
ii  libgl1-mesa-glx [libgl1]13.0.6-1+b2
ii  libglu1-mesa [libglu1]  9.0.0-2.1
ii  liboce-foundation10 0.17.2-2
ii  liboce-modeling10   0.17.2-2
ii  liboce-ocaf-lite10  0.17.2-2
ii  liboce-ocaf10   0.17.2-2
ii  liboce-visualization10  0.17.2-2
ii  libpyside1.21.2.2-2+b1
ii  libpython2.72.7.13-2+deb9u3
ii  libqt4-network  4:4.8.7+dfsg-11
ii  libqt4-opengl   4:4.8.7+dfsg-11
ii  libqt4-svg  4:4.8.7+dfsg-11
ii  libqt4-xml  4:4.8.7+dfsg-11
ii  libqtcore4  4:4.8.7+dfsg-11
ii  libqtgui4   4:4.8.7+dfsg-11
ii  libqtwebkit42.3.4.dfsg-9.1
ii  libshiboken1.2v51.2.2-3.1
ii  libsoqt4-20 1.6.0~e8310f-3
ii  libspnav0   0.2.3-1
ii  libstdc++6  6.3.0-18+deb9u1
ii  libx11-62:1.6.4-3+deb9u1
ii  libxerces-c3.1  3.1.4+debian-2+deb9u1
ii  libxext62:1.3.3-1+b2
ii  libzipios++0v5  0.1.5.9+cvs.2007.04.28-6
ii  pyside-tools0.2.15-1+b1
ii  python  2.7.13-2
ii  python-collada  0.4-2
ii  python-matplotlib   2.0.0+dfsg1-2
pn  python-pivy 
ii  python-ply  3.9-1
ii  python-pyside   1.2.2-2
ii  python2.7   2.7.13-2+deb9u3
ii  zlib1g  1:1.2.8.dfsg-5

freecad recommends no packages.

Versions of packages freecad suggests:
ii  graphviz  2.38.0-17
pn  povray

Bug#915384: lintian: check that debian/copyright has an entry for each component

[Xavier Guimard]

Package: lintian
Version: 2.5.114
Severity: wishlist

Hi all,

uscan allows DD to embed components in their packages. Initially this
feature was written for split upstream. Some packages like vlc,
node-mongodb, node-yarn,... use it to include some external components.
It could be safe in this case to add a lintian warning if there is no
entry in debian/copyright like:

  Files: ...

Tags could then be:

  Severity: normal, Certainty: wild-guess

This point has been discussed in [#915181].

Cheers,
Xavier

#915181: https://bugs.debian.org/915181

Bug#887768: F6

[Susan Cragin]

Thank you for your patience. 
You are correct. F6 freezes the mouse (the touchpad) in all applications, and 
the command is built into the F6 key. (It was not added by me.) 
I'd never noticed. 
Susan Cragin
The bug can be closed. 

Bug#915385: aptitude: manually installed flag set in the UI not preserved

[Vincent Lefevre]

Package: aptitude
Version: 0.8.11-6
Severity: normal

Package pdftk has been replaced by pdftk-java. Thus in the upgrade
from the aptitude curses UI, pdftk was selected as upgraded and
pdftk-java was selected as newly installed (as a dependency of
pdftk). Since I did not want to keep the transitional dummy package
pdftk, I marked pdftk-java as manually installed by typing 'm'
(thus the 'A' disappeared as expected) and marked pdftk to be
purged by typing '_'. Then I did the upgrade with 'gg'.

But after quitting aptitude, "apt install -f" said:

The following packages were automatically installed and are no longer required:
  libcommons-lang3-java pdftk-java
Use 'apt autoremove' to remove them.

and when I ran aptitude again, aptitude proposed to remove pdftk-java.

-- Package-specific info:
Terminal: xterm-debian
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.11
Compiler: g++ 8.2.0
Compiled against:
  apt version 5.0.2
  NCurses version 6.1
  libsigc++ version: 2.10.1
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.1.20181013
  cwidget version: 0.5.17
  Apt version: 5.0.2

aptitude linkage:
linux-vdso.so.1 (0x7fff11375000)
libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 
(0x7fae1cdf4000)
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 
(0x7fae1cdba000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 
(0x7fae1cd8c000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7fae1cd83000)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 
(0x7fae1cc7d000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7fae1cb5c000)
libboost_iostreams.so.1.67.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.67.0 (0x7fae1cb3c000)
libboost_system.so.1.67.0 => 
/usr/lib/x86_64-linux-gnu/libboost_system.so.1.67.0 (0x7fae1cb35000)
libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30 
(0x7fae1c90a000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7fae1c8e9000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7fae1c766000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fae1c5e3000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7fae1c5c7000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fae1c406000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 
(0x7fae1c3ec000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fae1c1ce000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7fae1c1bb000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7fae1bf95000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7fae1bd76000)
libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 
(0x7fae1bcdb000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7fae1bcbb000)
/lib64/ld-linux-x86-64.so.2 (0x7fae1d427000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fae1bcb6000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7fae1bcac000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7fae1bca1000)

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

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

Versions of packages aptitude depends on:
ii  aptitude-common   0.8.11-6
ii  libapt-pkg5.0 1.8.0~alpha2
ii  libboost-iostreams1.67.0  1.67.0-11
ii  libboost-system1.67.0 1.67.0-11
ii  libc6 2.28-1
ii  libcwidget3v5 0.5.17-11
ii  libgcc1   1:8.2.0-10
ii  libncursesw6  6.1+20181013-1
ii  libsigc++-2.0-0v5 2.10.1-1
ii  libsqlite3-0  3.26.0-1
ii  libstdc++68.2.0-10
ii  libtinfo6 6.1+20181013-1
ii  libxapian30   1.4.9-1

Versions of packages aptitude recommends:
ii  libparse-debianchangelog-perl  1.2.0-13
ii  sensible-utils 0.0.12

Versions of packages aptitude suggests:
pn  apt-xapian-index
ii  aptitude-doc-en [aptitude-doc]  0.8.11-6
pn  debtags 
ii  tasksel 3.48

-- no debconf information

Bug#915247: cabextract: Cabinet files are not extracted properly

[Eric Sharkey]

severity 915247 normal
merge 915247 914263
stop

On Sat, Dec 1, 2018 at 11:45 PM Davide Beatrici 
wrote:

> Package: cabextract
> Version: 1.9-1
> Severity: grave
> Justification: renders package unusable
>
> Dear Maintainer,
>
> During the extraction of any .cab files which are extracted from a .exe
> file by the tool, the operation fails with the following error: "no valid
> cabinets found".
> I encountered the issue because Winetricks uses the tool for Microsoft
> Visual C++ Redistributable 2010 to workaround a bug involving the
> installation of 64 bit DLLs.
> With the Microsoft DirectX setup, instead, nearly half of the cabinets are
> extracted correctly, as I can open them with Ark, and the other half is
> corrupted.
>
> I tried to compile the tool from source code, version 1.9, and it works as
> expected.
>
> Best regards,
> Davide
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing-debug
>   APT policy: (500, 'testing-debug'), (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages cabextract depends on:
> ii  libc6   2.27-8
> ii  libmspack0  0.8-1
>
> cabextract recommends no packages.
>
> cabextract suggests no packages.
>
> -- no debconf information
>

Bug#914918: gnome-shell uses huge amount of memory

[Eduardo Barros]

Package: gnome-shell
Version: 3.30.1-2
Followup-For: Bug #914918

Dear Maintainer,

after filling the bug report i restarted my machine and after few hours gnome-
shell was using more than 1GB of memory. the next day more than 3GB.
after that i restarted gnome-shell and now with Xorg backend. to my surprise
since then gnome-shell is using a minimal amount of memory (265MB for an uptime
of 3 days). the same happened on another machine with distinct hardware.
it seems to be an issue with wayland or gnome-shell/wayland related.
if you need i can put one of those machines to test.
thank you.

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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



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

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-1
ii  evolution-data-server3.30.2-2+b1
ii  gir1.2-accountsservice-1.0   0.6.45-1
ii  gir1.2-atspi-2.0 2.30.0-5
ii  gir1.2-freedesktop   1.58.1-1
ii  gir1.2-gcr-3 3.28.0-1
ii  gir1.2-gdesktopenums-3.0 3.28.1-1
ii  gir1.2-gdm-1.0   3.30.1-1
ii  gir1.2-geoclue-2.0   2.5.1-1
ii  gir1.2-glib-2.0  1.58.1-1
ii  gir1.2-gnomebluetooth-1.03.28.2-2
ii  gir1.2-gnomedesktop-3.0  3.30.2-1
ii  gir1.2-gtk-3.0   3.24.1-2
ii  gir1.2-gweather-3.0  3.28.2-1
ii  gir1.2-ibus-1.0  1.5.19-1
ii  gir1.2-mutter-3  3.30.2-1
ii  gir1.2-nm-1.01.14.4-4
ii  gir1.2-nma-1.0   1.8.18-2
ii  gir1.2-pango-1.0 1.42.4-4
ii  gir1.2-polkit-1.00.105-22
ii  gir1.2-rsvg-2.0  2.44.9-1
ii  gir1.2-soup-2.4  2.64.1-3
ii  gir1.2-upowerglib-1.00.99.9-2
ii  gjs  1.52.4-1
ii  gnome-backgrounds3.30.0-1
ii  gnome-settings-daemon3.30.1.2-1
ii  gnome-shell-common   3.30.1-2
ii  gsettings-desktop-schemas3.28.1-1
ii  libatk-bridge2.0-0   2.30.0-2
ii  libatk1.0-0  2.30.0-1
ii  libc62.27-8
ii  libcairo21.16.0-1
ii  libcanberra-gtk3-0   0.30-6
ii  libcanberra0 0.30-6
ii  libcroco30.6.12-2
ii  libecal-1.2-19   3.30.2-2+b1
ii  libedataserver-1.2-233.30.2-2+b1
ii  libgcr-base-3-1  3.28.0-1
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-6
ii  libgirepository-1.0-11.58.1-1
ii  libgjs0g 1.52.4-1
ii  libglib2.0-0 2.58.1-2
ii  libglib2.0-bin   2.58.1-2
ii  libgstreamer1.0-01.14.4-1
ii  libgtk-3-0   3.24.1-2
ii  libical3 3.0.4-1+b1
ii  libjson-glib-1.0-0   1.4.4-1
ii  libmutter-3-03.30.2-1
ii  libnm0   1.14.4-4
ii  libpango-1.0-0   1.42.4-4
ii  libpangocairo-1.0-0  1.42.4-4
ii  libpolkit-agent-1-0  0.105-22
ii  libpolkit-gobject-1-00.105-22
ii  libpulse-mainloop-glib0  12.2-2
ii  libpulse012.2-2
ii  libsecret-1-00.18.6-3
ii  libstartup-notification0 0.12-5
ii  libsystemd0  239-13
ii  libx11-6 2:1.6.7-1
ii  libxfixes3   1:5.0.3-1
ii  mutter   3.30.2-1
ii  python3  3.6.7-1

Versions of packages gnome-

Bug#821397: ITP: sway -- i3-compatible Wayland compositor

[Birger Schacht]

hi,

On 12/3/18 12:52 PM, Mattia Rizzolo wrote:
> On Sun, Dec 02, 2018 at 10:10:33PM +0100, Birger Schacht wrote:
>> but i'm not a DM so i can not upload it. Should i create an RFS and go
>> through mentors?
>> (also, i'm still not sure if its oke to just take the package from nicoo)
> 
> Usually it's not quite ok, and at the very least it's considered rude.
oh, in that case i definitly won't ask for an upload ;)

> Note sure, do you have some kind of agreement with nicoo?  If so then I
> guess you can go ahead…

i sent him and guido an email about the sway status because they were
the swaywm-team on salsa a month ago, but didn't hear back from nicoo.
guido then gave me permission to push to the repo.

i'd propose to wait for nicoo, i can keep the repo uptodate in the meantime.

cheers,
Birger

Bug#915386: libfdk-aac-dev: New upstream version 2.0.0 available

[Petter Reinholdtsen]

Package: libfdk-aac-dev
Version: 0.1.6-1
Severity: wishlist

Hi.  There is a new upstream version available.  Are there any plans to
update to version 2.0.0?

-- 
Happy hacking
Petter Reinholdtsen

Bug#858937: kde4libs: Please migrate to openssl1.1 in buster

[Sebastian Andrzej Siewior]

On 2018-12-03 12:30:53 [+0100], Didier 'OdyX' Raboud wrote:
> > If you switch to openssl-dev with this upload, please make it depend on
> > libssl1.1 (which does not happen because it does not depend on any symbols)
> > and the you could also close
> > 
> > #913959 [S|  |  ] [src:kde4libs] kde4libs: Build-Depends on libssl1.0-dev
> 
> I've checked thoroughly, and didn't find any package from src:kde4libs which 
> has a relationship with libssl*; so I think this upload at least is no 
> regression in that regard.

The package loads libssl's symbols dynamically and has to dependencies
on libssl1.1 / libssl1.0.2 and I miss it on  a regular basis during
testing.

> Cheers,
> OdyX

Sebastian

Bug#915387: ITP: ratchet-pawl -- Asynchronous WebSocket client for RatchetPHP

[Dominik George]

Package: wnpp
Severity: wishlist
Owner: Dominik George 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: ratchet-pawl
  Version : 0.3.2
  Upstream Author : Chris Boden
* URL : https://github.com/ratchetphp/Pawl
* License : MIT
  Programming Lang: PHP
  Description : Asynchronous WebSocket client for RatchetPHP

Pawl is a WebSocket client for the RatchetPHP framework. It can
be used both as a standalone app, or as a library. While implementing
the standard WebSocket protocol, it can best be used with ratchet-rfc6455,


To be used in the next upload of the movim package.

-BEGIN PGP SIGNATURE-

iQKJBAEBCABzFiEEPJ1UpHV1wCb7F/0mt5o8FqDE8pYFAlwFIKMxGmh0dHBzOi8v
d3d3LmRvbWluaWstZ2VvcmdlLmRlL2dwZy1wb2xpY3kudHh0LmFzYyMcZG9taW5p
ay5nZW9yZ2VAaXQucGlyYXRlbnBhcnRlaS5kZQAKCRC3mjwWoMTylmK5D/9xiG7F
nPdtP5Go15zSE2tWMcseqDiq7Scr6y334xTXXqj8HXyn/cdlwLCWP/0P41KxR+7A
WxU14lNI4F9jR5k5Q0cIEdXe3g++GfJk8elYY7LcfTcG3tZo00LOwrJROC7dZ+NL
VGc7jK4PsroBsdFrKtHnYZj4rP+4gdtARkeNhOHYaYx/4n8gReZP++6wFH1oVrD2
JsHOnRR+BK+ppaTxtTK88KRTQmTcDcFVuTVz2iLXzKRx8tbH2DfH7fetN+aWuir9
i4Nlgtx0Mt9aW163VbiB38GIbxia1Y3b/frfLV+WEBQKa/MEr3E0q1XJ1RARuq4V
OlbCQPs6y0u+ZHAZzd80FL35WRUZwmTQdel9P9mY06KfGtKv3xhxCcd0YhZUnTxd
tFBBSR68NtGY4GsaUJPxdyCEQ4zCeyFD6JVwIk/u/NH9klxZcma1xLd6TuHm1hbM
2udf5+737EKnPWvTtmAZ9Pvr2OdyyYmFcji3/8+Pt4ALk8G35XFwl9UTUeJIqiTG
L0/ClmDRUGaidOe/JilTOBLe/HNWTdlVRl6E3SuT/KhKRvgGKafO+KLTWa3TGv8N
YK8nuJVIeQNbtWwaX5lxoofLjTK4fCNao2PjWQ3PqUXkm4G15hhjlvmrzsautI9B
/ZDY6zNF7xDRnXm1+arWYfGpjiqPdSznw8LrgQ==
=UwVF
-END PGP SIGNATURE-

Bug#915384: lintian: check that debian/copyright has an entry for each component

[Chris Lamb]

tags 915384 + moreinfo
thanks

Hi Xavier,

> It could be safe in this case to add a lintian warning if there is no
> entry in debian/copyright like:
> 
>   Files: ...

I don't 100% understand what would be the problem here if an entry is
missing, what "it could be safe" means and whether the "<" etc are
part of the name etc... 

But to save some back-and-forth, it might be easier to provide:

 * An example "good" case.

 * A "bad" case.

 * A short paragraph explaining why this is bad (for me and for the
   eventual tag description).

Thanks in advance.


Regards,

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

Bug#879803: Please use pkg-config to detect icu

[Kartik Mistry]

On Mon, Dec 3, 2018 at 5:30 PM Hugh McMaster  wrote:
> dee must build-depend on pkg-config as well.

Thanks a lot. I'll update package soon!

-- 
Kartik Mistry | IRC: kart_
{0x1f1f, kartikm}.wordpress.com

Bug#914897: debating the wrong thing

[Ian Jackson]

Ansgar Burchardt writes ("Bug#914897: debating the wrong thing"):
> It is very demotivating to have discussed and implemented something
> mostly years ago, for people then to come and complain "let's not do
> this at all" years later.

We were told it would be optional.  Unfortunately it turns out that
the design is broken and it cannot sensibly be made optional.
It is not the responsibility of the wider community to review your
design for an optional feature.

Nor does a failure to review and object to your design of an optional
feature mean that you are entitled to assume consent for making the
feature default or mandatory.

Debian is full of optional features.  I'm sure many of them are broken
in one way or another.  Obviously one can't spend one's life going
round trying to abolish everything one thinks is somehow broken, or
foolish.  That would be really nasty.

The problem comes when a niche optional feature, with wide-ranging
implications, is suddenly promoted to the default, without proper
consultation and without a proper transition plan.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#915388: vtk-dicom unsatisfiable Build-Depends(-Arch) on armel/armhf: libvtk7-qt-dev

[Matthias Klose]

Package: src:vtk-dicom
Version: 0.8.8-1
Severity: serious
Tags: sid buster

vtk-dicom unsatisfiable Build-Depends(-Arch) on armel/armhf: libvtk7-qt-dev

Either request removal of these binaries or don't b-d on libvtk7-qt-dev.

Bug#858823: check: version 0.12.0 is available

[Guus Sliepen]

Package: check
Version: 0.10.0-3+b3
Followup-For: Bug #858823

Version 0.12.0 has been released upstream last year. Unless there are
objections, given the lack of package maintenance activity, I will
prepare a new package and upload it to DELAYED/7.

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

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

Versions of packages check depends on:
ii  dpkg1.19.2
ii  install-info6.5.0.dfsg.1-4+b1
ii  libsubunit-dev  1.3.0-1
ii  mawk1.3.3-17+b3

check recommends no packages.

check suggests no packages.

-- debconf-show failed

Bug#914897: debating the wrong thing

[Ansgar Burchardt]

On Mon, 2018-12-03 at 12:38 +, Ian Jackson wrote:
> Ansgar Burchardt writes ("Bug#914897: debating the wrong thing"):
> > It is very demotivating to have discussed and implemented something
> > mostly years ago, for people then to come and complain "let's not
> > do
> > this at all" years later.
> 
> We were told it would be optional.  Unfortunately it turns out that
> the design is broken and it cannot sensibly be made optional.

There is no indication of that.  So I'll assume the design isn't
broken.

You aren't entitled to just claim that.

> Nor does a failure to review and object to your design of an optional
> feature mean that you are entitled to assume consent for making the
> feature default or mandatory.

Making the feature default was discussed years ago which you are surely
aware of. It's not mandatory.

> The problem comes when a niche optional feature, with wide-ranging
> implications, is suddenly promoted to the default, without proper
> consultation and without a proper transition plan.

It wasn't made "suddenly" the default.

Ansgar

Bug#439805: xsnow: [MOREINFO] xsnow:Not display when using OpenGL compositor.

[Kyuma Ohta]

Package: xsnow
Version: 1:1.42-9
Followup-For: Bug #439805

Dear Maintainer,

This issue seems to be reproduced when using OpenGL compisitor to
composite desktop environment.
For example, I'm using MATE desktop environment.
When using MARCO or Compiz with OpenGL compositor feature (this
enables by MATE-TWEAK-TOOL), display nothing by xsnow.
But, when using MARCO with disabled comoposite feature, xsnow
works well.All of items are displayed well.

I wish this report will assist to fix this issue.
Regards,
Ohta.

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

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

Versions of packages xsnow depends on:
ii  libc6 2.28-1
ii  libx11-6  2:1.6.7-1
ii  libxext6  2:1.3.3-1+b2
hi  libxpm4   1:3.5.12-1
ii  procps2:3.3.15-2

xsnow recommends no packages.

xsnow suggests no packages.

-- debconf-show failed

Bug#915390: clazy: Segmentation fault compiling any file

[Alberto Luaces]

Package: clazy
Version: 1.4-3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

attempting to compile any file on my system results in a segfault.
Could it be that a runtime dependency is missing from d/control?

Steps to reproduce:

> touch a.cpp
> clazy a.cpp 
#0 0x7f825a95352a llvm::sys::PrintStackTrace(llvm::raw_ostream&) 
(/usr/lib/x86_64-linux-gnu/libLLVM-6.0.so.1+0x92152a)
#1 0x7f825a95164e llvm::sys::RunSignalHandlers() 
(/usr/lib/x86_64-linux-gnu/libLLVM-6.0.so.1+0x91f64e)
#2 0x7f825a9517dd (/usr/lib/x86_64-linux-gnu/libLLVM-6.0.so.1+0x91f7dd)
#3 0x7f825dc2b8e0 __restore_rt 
(/lib/x86_64-linux-gnu/libpthread.so.0+0x128e0)
#4 0x7f8254bc6ac4 (/usr/lib/x86_64-linux-gnu/libLLVM-7.so.1+0x106dac4)
#5 0x7f82543e9c78 
llvm::WebAssemblyTargetWasmStreamer::emitGlobalImport(llvm::StringRef) 
(/usr/lib/x86_64-linux-gnu/libLLVM-7.so.1+0x890c78)
#6 0x7f825dca90ca (/lib64/ld-linux-x86-64.so.2+0xf0ca)
#7 0x7f825dca91d6 (/lib64/ld-linux-x86-64.so.2+0xf1d6)
#8 0x7f825dcad253 (/lib64/ld-linux-x86-64.so.2+0x13253)
#9 0x7f8259a41adf _dl_catch_exception 
(/lib/x86_64-linux-gnu/libc.so.6+0x133adf)
#10 0x7f825dcacb1a (/lib64/ld-linux-x86-64.so.2+0x12b1a)
#11 0x7f82594a0276 __asprintf (/lib/x86_64-linux-gnu/libdl.so.2+0x1276)
#12 0x7f8259a41adf _dl_catch_exception 
(/lib/x86_64-linux-gnu/libc.so.6+0x133adf)
#13 0x7f8259a41b6f _dl_catch_error 
(/lib/x86_64-linux-gnu/libc.so.6+0x133b6f)
#14 0x7f82594a0975 (/lib/x86_64-linux-gnu/libdl.so.2+0x1975)
#15 0x7f82594a0331 dlopen (/lib/x86_64-linux-gnu/libdl.so.2+0x1331)
#16 0x7f825a93dc53 llvm::sys::DynamicLibrary::HandleSet::DLOpen(char 
const*, std::__cxx11::basic_string, 
std::allocator >*) (/usr/lib/x86_64-linux-gnu/libLLVM-6.0.so.1+0x90bc53)
#17 0x7f825a93def2 llvm::sys::DynamicLibrary::getPermanentLibrary(char 
const*, std::__cxx11::basic_string, 
std::allocator >*) (/usr/lib/x86_64-linux-gnu/libLLVM-6.0.so.1+0x90bef2)
#18 0x55d0d6d7daba 
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) 
(/usr/lib/llvm-6.0/bin/clang+0x8e9aba)
#19 0x55d0d68d8678 cc1_main(llvm::ArrayRef, char const*, 
void*) (/usr/lib/llvm-6.0/bin/clang+0x444678)
#20 0x55d0d68c8117 main (/usr/lib/llvm-6.0/bin/clang+0x434117)
#21 0x7f8259930b17 __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x22b17)
#22 0x55d0d68d665a _start (/usr/lib/llvm-6.0/bin/clang+0x44265a)
Stack dump:
0.  Program arguments: /usr/lib/llvm-6.0/bin/clang -cc1 -triple 
x86_64-pc-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier 
-discard-value-names -main-file-name a.cpp -mrelocation-model static 
-mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose 
-mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 
-dwarf-column-info -debugger-tuning=gdb -resource-dir 
/usr/lib/llvm-6.0/lib/clang/6.0.1 -internal-isystem 
/usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8 
-internal-isystem 
/usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/x86_64-linux-gnu/c++/8
 -internal-isystem 
/usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/x86_64-linux-gnu/c++/8
 -internal-isystem 
/usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/backward 
-internal-isystem /usr/include/clang/6.0.1/include/ -internal-isystem 
/usr/local/include -internal-isystem /usr/lib/llvm-6.0/lib/clang/6.0.1/include 
-internal-externc-isystem /usr/include/x86_64-linux-gnu 
-internal-externc-isystem /include -internal-externc-isystem /usr/include 
-fdeprecated-macro -fdebug-compilation-dir /home/alberto/tmp/biolim/build_clazy 
-ferror-limit 19 -fmessage-length 190 -fobjc-runtime=gcc -fcxx-exceptions 
-fexceptions -fdiagnostics-show-option -fcolor-diagnostics -load ClangLazy.so 
-add-plugin clang-lazy -o /tmp/a-239fc9.o -x c++ a.cpp 
clang: error: unable to execute command: Segmentation fault
clang: error: clang frontend command failed due to signal (use -v to see 
invocation)
clang version 6.0.1-9.2 (tags/RELEASE_601/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
clang: note: diagnostic msg: PLEASE submit a bug report to 
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and 
associated run script.
clang: error: unable to execute command: Bus error
clang: note: diagnostic msg: Error generating preprocessed source(s).

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

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

Versions of packages clazy depends on:
ii  libc6   2.27-8
ii  libgcc1 1:8.2.0-9
ii  libllvm71:7-6
ii  libstdc++6  8.2.0-9

clazy recommends no packages.

clazy suggests no packages.

--

Bug#909475: task jbd2 blocked for more than 120seconds

[Russell Mosemann]

Package: src:linux
Version: 4.18.6-1~bpo9+1
Severity: important

 
Dec 03 06:04:09 vhost032 kernel: INFO: task jbd2/sdc1-8:644 blocked for more 
than 120 seconds.
Dec 03 06:04:09 vhost032 kernel:   Not tainted 4.18.0-0.bpo.1-amd64 #1 
Debian 4.18.6-1~bpo9+1
Dec 03 06:04:09 vhost032 kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Dec 03 06:04:09 vhost032 kernel: jbd2/sdc1-8 D0   644  2 0x8000
Dec 03 06:04:09 vhost032 kernel: Call Trace:
Dec 03 06:04:09 vhost032 kernel:  ? __schedule+0x3f5/0x880
Dec 03 06:04:09 vhost032 kernel:  ? remove_wait_queue+0x60/0x60
Dec 03 06:04:09 vhost032 kernel:  schedule+0x32/0x80
Dec 03 06:04:09 vhost032 kernel:  jbd2_journal_commit_transaction+0x25d/0x1870 
[jbd2]
Dec 03 06:04:09 vhost032 kernel:  ? __switch_to_asm+0x40/0x70
Dec 03 06:04:09 vhost032 kernel:  ? __switch_to_asm+0x34/0x70
Dec 03 06:04:09 vhost032 kernel:  ? __switch_to_asm+0x40/0x70
Dec 03 06:04:09 vhost032 kernel:  ? __switch_to_asm+0x34/0x70
Dec 03 06:04:09 vhost032 kernel:  ? __switch_to_asm+0x40/0x70
Dec 03 06:04:09 vhost032 kernel:  ? __switch_to_asm+0x34/0x70
Dec 03 06:04:09 vhost032 kernel:  ? __switch_to_asm+0x40/0x70
Dec 03 06:04:09 vhost032 kernel:  ? __switch_to_asm+0x40/0x70
Dec 03 06:04:09 vhost032 kernel:  ? __switch_to_asm+0x34/0x70
Dec 03 06:04:09 vhost032 kernel:  ? __switch_to_asm+0x40/0x70
Dec 03 06:04:09 vhost032 kernel:  ? remove_wait_queue+0x60/0x60
Dec 03 06:04:09 vhost032 kernel:  ? __switch_to_asm+0x40/0x70
Dec 03 06:04:09 vhost032 kernel:  ? lock_timer_base+0x74/0x90
Dec 03 06:04:09 vhost032 kernel:  ? kjournald2+0xc1/0x260 [jbd2]
Dec 03 06:04:09 vhost032 kernel:  kjournald2+0xc1/0x260 [jbd2]
Dec 03 06:04:09 vhost032 kernel:  ? remove_wait_queue+0x60/0x60
Dec 03 06:04:09 vhost032 kernel:  kthread+0xf8/0x130
Dec 03 06:04:09 vhost032 kernel:  ? commit_timeout+0x10/0x10 [jbd2]
Dec 03 06:04:09 vhost032 kernel:  ? kthread_create_worker_on_cpu+0x70/0x70
Dec 03 06:04:09 vhost032 kernel:  ret_from_fork+0x35/0x40

 

Bug#887768: F6

[Elimar Riesebieter]

* Susan Cragin  [2018-12-03 07:09 -0500]:

> 
> Thank you for your patience.

You are welcome ;-)

> You are correct. F6 freezes the mouse (the touchpad) in all
> applications, and the command is built into the F6 key. (It was
> not added by me.)
> I'd never noticed.
> Susan Cragin
> The bug can be closed.

Done hereby

Elimar
-- 
  Alles, was viel bedacht wird, wird bedenklich!;-)
 Friedrich Nietzsche


signature.asc
Description: PGP signature

Bug#915391: Regression: KDE's Kio fails to build on i386 and armhf with cmake >= 3.13

[Rik Mills]

Package: cmake
Version: 3.13.1-1

With cmake >= 3.13 the KDE Framework Kio fails to build on i386 and
armhf with the error shown below:

Confirmed on current debian unstable rebuilding kio from source. Also
confirmed in Ubuntu with 3.13.1-1 (now removed) synced to 19.04.

Report upstream: https://gitlab.kitware.com/cmake/cmake/issues/18669

and Ubuntu bug: https://bugs.launchpad.net/ubuntu/+source/cmake/+bug/1806276


*** build error ***

In file included from /build/kio-5.51.0/src/core/slaveinterface.cpp:441:
/build/kio-5.51.0/obj-i686-linux-gnu/src/core/KF5KIOCore_autogen/include/moc_slaveinterface.cpp:
In static member function 'static void
KIO::SlaveInterface::qt_static_metacall(QObject*, QMetaObject::Call,
int, void**)':
/build/kio-5.51.0/obj-i686-linux-gnu/src/core/KF5KIOCore_autogen/include/moc_slaveinterface.cpp:171:22:
error: 'class KIO::SlaveInterface' has no member named 'open64'; did you
mean 'open'?
 case 10: _t->open64(); break;
  ^~
  open
/build/kio-5.51.0/obj-i686-linux-gnu/src/core/KF5KIOCore_autogen/include/moc_slaveinterface.cpp:280:84:
error: 'open64' is not a member of 'KIO::SlaveInterface'
 if (*reinterpret_cast<_t *>(_a[1]) ==
static_cast<_t>(&SlaveInterface::open64)) {

   ^~
/build/kio-5.51.0/obj-i686-linux-gnu/src/core/KF5KIOCore_autogen/include/moc_slaveinterface.cpp:
At global scope:
/build/kio-5.51.0/obj-i686-linux-gnu/src/core/KF5KIOCore_autogen/include/moc_slaveinterface.cpp:475:6:
error: no declaration matches 'void KIO::SlaveInterface::open64()'
 void KIO::SlaveInterface::open64()
  ^~~
/build/kio-5.51.0/obj-i686-linux-gnu/src/core/KF5KIOCore_autogen/include/moc_slaveinterface.cpp:475:6:
note: no functions named 'void KIO::SlaveInterface::open64()'
In file included from /build/kio-5.51.0/src/core/slaveinterface.cpp:19:
/build/kio-5.51.0/src/core/slaveinterface.h:102:22: note: 'class
KIO::SlaveInterface' defined here
 class KIOCORE_EXPORT SlaveInterface : public QObject
  ^~
make[3]: *** [src/core/CMakeFiles/KF5KIOCore.dir/build.make:517:
src/core/CMakeFiles/KF5KIOCore.dir/slaveinterface.cpp.o] Error 1
make[3]: *** Waiting for unfinished jobs
make[3]: Leaving directory '/build/kio-5.51.0/obj-i686-linux-gnu'
make[2]: *** [CMakeFiles/Makefile2:9841:
src/core/CMakeFiles/KF5KIOCore.dir/all] Error 2
make[2]: Leaving directory '/build/kio-5.51.0/obj-i686-linux-gnu'
make[1]: *** [Makefile:144: all] Error 2
make[1]: Leaving directory '/build/kio-5.51.0/obj-i686-linux-gnu'
dh_auto_build: cd obj-i686-linux-gnu && make V=1 -j4 "INSTALL=install
--strip-program=true" returned exit code 2
make: *** [debian/rules:7: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit
status 2

Bug#898006: stretch-pu: package pcl/1.8.0+dfsg1-3

[Jochen Sprickerhof]

Hi Julien,

* Julien Cristau  [2018-12-03 08:16]:

On Sat, May 05, 2018 at 06:38:25PM +0200, Jochen Sprickerhof wrote:

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

Dear release team,

in #894656 I was asked to add libvtk6-qt-dev as a dependency to
libpcl-dev in stretch. I would like to do this, except for armel and
armhf which fails due to OpenGLES, cf. #835292.


Is there anything different about libpcl itself that makes it not need
vtk on arm{el,hf}?  If not that smells fishy to me.


pcl wasn't compiled against libvtk6-qt-dev on armel/hf:

https://sources.debian.org/src/pcl/stable/debian/control/#L27

That's bug #835292 I mentioned above.

Cheers Jochen


signature.asc
Description: PGP signature

Bug#915392: devel/tech-ctte is outdated on the list of decided matters

[Mattia Rizzolo]

Package: www.debian.org

on https://www.debian.org/devel/tech-ctte - under "Formal technical
decisions, including recommendations and advice", the latest decision
reported is from 2015, but I'm sure the ctte also did something else
since then.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#834736: [buildd-tools-devel] Bug#834736: sbuild: Use basic format for ISO 8601 timestamps (for build logs filenames)

[Johannes Schauer]

Quoting Santiago Vila (2018-11-29 16:55:53)
> > > I'd like those three logs to have the same timestamp.
> > Okay. Why?
> Because that way I can use the timestamp as an "id" for everything which
> happened in the build. For example, when I "expire" a build log because the
> package used to ftbfs but not anymore, I would also expire the log storing
> memory usage.

[see below]

> > > Also, because some packages FTBFS randomly and in those cases I want to
> > > know how randomly they fail, sometimes I tell my autobuilders to build
> > > the same package over and over again.
> > > 
> > > Because of this I'd also like to use sub-second precision, to avoid
> > > several build logs to have the same filename.
> > 
> > I think I don't understand something here. How would two build logs have
> > the same file name with second-precision but not the same file name with
> > sub-second-precision?
> Good question :-)
> 
> I have a "poor's man" client-server setup where autobuilders ask for build
> jobs and they receive a tuple containing package, version, distribution and
> "build mode" (A or B) as a result.
> 
> I have recently changed the setup so that they also receive the timestamp to
> be used from the central server. Currently I have an ugly "sleep 1.5" in the
> coordination server (between succesive jobs) which I would like to either
> reduce or remove.

[see below]

> > > So, what I would really need is a way to provide the timestamp
> > > externally.
> > Do you? Why not just put the build logs into two distinct directories?
> In my setup all the build logs are sent to the central server to be stored
> there in a single directory for every distribution and build mode. For
> example, In ~/logs/A/buster have around 8 build logs for build logs of
> type "dpkg-buildpackage -A" in buster.
> 
> I could perhaps add the hostname as a suffix, but the filename is already
> long enough and I would prefer not to make it even longer.

As far as I now understand it, you are requesting this change in sbuild because
you have your tools and scripts which you want to work in a certain way
("abuse" timestamps as an id, ugly sleep, single directory) and as a result of
these design choices of your tools, you need sbuild to change.

What you have to convince me of now is:

Why does sbuild need to change because of design choices that you made in your
scripts and why should not your scripts change to accommodate for the sbuild
behaviour?

As I see it, you could simply put all build logs with the same "id" in the same
directory and thus have one directory per "id". Then you could drop your "ugly
sleep", sbuild could keep its build log filenames and no special suffix would
be needed.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#915393: /usr/bin/debchange: [debchange] NMU detection not compatible with wrap-and-sort -s

[Stuart Prescott]

Package: devscripts
Version: 2.18.9
Severity: normal
File: /usr/bin/debchange
Tags: patch

Dear Maintainer,

Running "wrap-and-sort -as" on debian/control will generate an indented
Uploaders field like:

Uploaders:
 Stuart Prescott ,
 J Smith 

The auto-nmu detection code in dch doesn't cope with the initial blank line,
with @uploaders (line 918) incorrectly containing a "\n " within the first
entry. Stripping leading whitespace seems sufficient; allowing whitespace
before the comma might also be better, like so:

$uploader =~ s/^\s*//;
my @uploaders  = split(/\s*,\s*/, $uploader);

Note that splitting Uploaders on commas is probably also not the right thing
to do (#401452) but since we've not been able to define the correct syntax for
Uploaders in over a decade, we probably shouldn't block fixing this bug with
that quibble.

cheers
Stuart

-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
DEBEMAIL="stu...@debian.org"
DEBFULLNAME="Stuart Prescott"
DEBCHANGE_RELEASE_HEURISTIC=changelog
DEVSCRIPTS_CHECK_DIRNAME_REGEX="PACKAGE(-.*)?|trunk|git"
DEBUILD_LINTIAN_OPTS="--info --display-info --display-experimental --pedantic 
--show-overrides --checksums --color auto"
DEBSIGN_KEYID=90E2D2C1AD146A1B7EBB891DBBC17EBB1396F2F7
DEBCHANGE_FORCE_SAVE_ON_RELEASE=no

-- System Information:
Debian Release: 9.6
  APT prefers stable-updates
  APT policy: (550, 'stable-updates'), (550, 'proposed-updates'), (550, 
'stable'), (500, 'stable-debug'), (500, 'stable'), (60, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.18.25
ii  fakeroot  1.21-3.1
ii  file  1:5.30-1+deb9u2
ii  gnupg 2.1.18-8~deb9u3
ii  gnupg22.1.18-8~deb9u3
ii  gpgv  2.1.18-8~deb9u3
ii  gpgv2 2.1.18-8~deb9u3
ii  libc6 2.24-11+deb9u3
ii  libfile-homedir-perl  1.00-1
ii  libfile-which-perl1.21-1
ii  libipc-run-perl   0.94-1+deb9u1
ii  libmoo-perl   2.002005-1
ii  libwww-perl   6.15-1
ii  patchutils0.3.4-2
ii  perl  5.24.1-3+deb9u5
ii  python3   3.5.3-1
ii  sensible-utils0.0.9+deb9u1
ii  wdiff 1.2.2-2

Versions of packages devscripts recommends:
ii  apt 1.4.8
ii  at  3.1.20-3
ii  curl7.52.1-5+deb9u8
ii  dctrl-tools 2.24-2+b1
ii  debian-keyring  2018.11.25
ii  dput-ng [dput]  1.21
ii  equivs  2.0.9+nmu1
ii  libdistro-info-perl 0.14
ii  libdpkg-perl1.18.25
ii  libencode-locale-perl   1.05-1
ii  libgit-wrapper-perl 0.047-1
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.06-2
ii  libsoap-lite-perl   1.20-1
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.28-1
ii  liburi-perl 1.71-1
ii  licensecheck3.0.31-2
ii  lintian 2.5.113~bpo9+1
ii  man-db  2.7.6.1-2
ii  patch   2.7.5-1+deb9u1
ii  python3-apt 1.4.0~beta3
ii  python3-debian  0.1.30
ii  python3-magic   1:5.30-1+deb9u2
ii  python3-requests2.12.4-1
ii  python3-unidiff 0.5.4-1
ii  python3-xdg 0.25-4
ii  strace  4.15-2
ii  unzip   6.0-21
ii  wget1.18-5+deb9u2
ii  xz-utils5.2.2-1.2+b1

Versions of packages devscripts suggests:
ii  adequate   0.15.1
ii  autopkgtest4.4
pn  bls-standalone 
ii  bsd-mailx [mailx]  8.1.2-0.20160123cvs-4
ii  build-essential12.3
pn  check-all-the-things   
pn  cvs-buildpackage   
pn  devscripts-el  
ii  diffoscope 78
pn  disorderfs 
ii  dose-extra 5.0.1-8+deb9u1
pn  duck   
pn  faketime   
ii  gnuplot5.0.5+dfsg1-6+deb9u1
ii  how-can-i-help 15
ii  libauthen-sasl-perl2.1600-1
pn  libdbd-pg-perl 
ii  libfile-desktopentry-perl  0.22-1
pn  libnet-smtps-perl  
ii  libterm-size-perl  0.207-1+b4
ii  libtimedate-perl

Bug#832558: [Pkg-dkms-maint] Bug#832558: Fix dkms mkdeb / mkdsc / mkbmdeb

[drake763]

Hi,

I'd also second the request to patch this bug. This bug is not present
in upstream but only in debian and thus ubuntu. It was introduced in
debian specific patch [1].

The part of Pierre's patch mentioned in this thread would fix this and
it would be highly appreciated if at least the relevant part of the
patch could be applied.

Thanks a lot!

[1]
https://salsa.debian.org/debian/dkms/blob/master/debian/patches/0004-mkbmdeb-support-for-lean-binary-package-with-only-th.patch

Bug#911371: antlr4: package for v4.7.1 prepared

[Andrius Merkys]

Hello,

I have prepared package for v4.7.1 in salsa.debian.org and opened merge 
requests [1][2][3]. Please review them and let me know about any shortcomings.

Best wishes,
Andrius

[1] https://salsa.debian.org/java-team/antlr4/merge_requests/1
[2] https://salsa.debian.org/java-team/antlr4/merge_requests/2 (pristine-tar 
branch)
[3] https://salsa.debian.org/java-team/antlr4/merge_requests/3 (upstream branch)

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania

Bug#915384: lintian: check that debian/copyright has an entry for each component

[Chris Lamb]

Xavier wrote:

>   # debian/watch
>   https://main/ main-(\d[\d\.]+)\.tar\.gz
>   opts="component=comp1" \
>https://comp/ comp-(\d[\d\.]+)\.tar\.gz
> 
> In this example, a debian tool like gbp will unpack comp_1.0.orig.tar.gz
> into "comp1/" directory
^
And this comes from parsing the `opts="component=comp1"` bit, not from
anywhere else?

> In the last case, no entry matches explicitly "comp1/" directory. It
> might be a missing exam of sources.

Thanks.


Regards,

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

Bug#915384: lintian: check that debian/copyright has an entry for each component

[Xavier]

Le 03/12/2018 à 14:22, Chris Lamb a écrit :
> Xavier wrote:
> 
>>   # debian/watch
>>   https://main/ main-(\d[\d\.]+)\.tar\.gz
>>   opts="component=comp1" \
>>https://comp/ comp-(\d[\d\.]+)\.tar\.gz
>>
>> In this example, a debian tool like gbp will unpack comp_1.0.orig.tar.gz
>> into "comp1/" directory
> ^
> And this comes from parsing the `opts="component=comp1"` bit, not from
> anywhere else?

~Yes, for gdb DD must either add some "--component" in command-line *or*
set it in gbp.conf:

  [DEFAULT]
  component = [ 'bson', 'mongodb-core', 'requireoptional' ]

So only debian/watch is reliable. There are no other files that rely on
this except debian/rules but in many ways...

>> In the last case, no entry matches explicitly "comp1/" directory. It
>> might be a missing exam of sources.
> 
> Thanks.
> 
> Regards,
> 

Bug#915384: lintian: check that debian/copyright has an entry for each component

[Chris Lamb]

tags 915384 - moreinfo
thanks

Hi Xavier,

> So only debian/watch is reliable. There are no other files that rely on
> this except debian/rules but in many ways...

Thanks again.

(This is not straightforward to implement as it requires parsing both
debian/watch and the DEP-5 copyright, one of which will need
refactoring out, so please don't expect it within a few days.)


Regards,

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

Bug#915396: odil ftbfs, syntax error in the build target

[Matthias Klose]

Package: src:odil
Version: 0.10.0-1
Severity: serious
Tags: sid buster patch

odil ftbfs, there is a syntax error in the build target (missing semicolon).  No
idea why it's not seen on the Debian builds.  Also made the targets a bit more
verbose to see which Python bindings are build/tested/installed.

patch at
http://launchpadlibrarian.net/400045913/odil_0.10.0-1_0.10.0-1ubuntu1.diff.gz

Bug#915395: firefox-esr: Improper use of *printf causes problems with Gtk CSS parsing

[Łukasz Stelmach]

Package: firefox-esr
Version: 60.3.0esr-1~deb9u1
Severity: normal
File: /usr/lib/firefox-esr/libxul.so

Dear Maintainer,

When I am starting Firefox with locale set to pl_PL.utf-8 two Gtk
warnings are displayed

--8<---cut here---start->8---
(firefox-esr:9981): Gtk-WARNING **: Theme parsing error: :1:34: Expected 
')' in col
or definition   


(firefox-esr:9981): Gtk-WARNING **: Theme parsing error: :1:77: Expected 
')' in col
or definition   

--8<---cut here---end--->8---

They are caused by improperly formatted CSS string passed to
gtk_css_provider_load_from_data function from code within libxul.so
(I uesd ltrace+gdb). The CSS string is


:selected{color:rgba(255,255,255,1,00);background-color:rgba(74,144,217,1,00);

Note that the fourth argument to rgba() is a real number with comma as a
decimal point according to my locale. Running with LC_NUMERIC=C

LC_NUMERIC=C firefox -ProfileManager

makes the problem dissapear. The format strings used to build the CSS
data are in Debian sources in file
firefox-esr-60.3.0esr/widget/gtk/IMContextWrapper.cpp in lines 228 and
239. AppendPrintf() method is implemented in 
firefox-esr-60.3.0esr/xpcom/string/nsTSubstring.cpp

Please forward the problem upstream, as it seems the implementation
hasn't changed[1][2] since 60.3.0.

[1] 
https://hg.mozilla.org/mozilla-central/file/01d0813d8203/widget/gtk/IMContextWrapper.cpp#l260
[2] 
https://hg.mozilla.org/mozilla-central/file/01d0813d8203/xpcom/string/nsTSubstring.cpp#l1203

-- Package-specific info:


-- Addons package information

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


-- System Information:
Debian Release: 9.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: armel, arm64

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

Versions of packages firefox-esr depends on:
ii  debianutils   4.8.1.1
ii  fontconfig2.11.0-6.7+b1
ii  libasound21.1.3-5
ii  libatk1.0-0   2.22.0-1
ii  libc6 2.24-11+deb9u3
ii  libcairo-gobject2 1.14.8-1
ii  libcairo2 1.14.8-1
ii  libdbus-1-3   1.10.26-0+deb9u1
ii  libdbus-glib-1-2  0.108-2
ii  libevent-2.0-52.0.21-stable-3
ii  libffi6   3.2.1-6
ii  libfontconfig12.11.0-6.7+b1
ii  libfreetype6  2.6.3-3.2
ii  libgcc1   1:6.3.0-18+deb9u1
ii  libgdk-pixbuf2.0-02.36.5-2+deb9u2
ii  libglib2.0-0  2.50.3-2
ii  libgtk-3-03.22.11-1
ii  libjsoncpp1   1.7.4-3
ii  libpango-1.0-01.40.5-1
ii  libstartup-notification0  0.12-4+b2
ii  libstdc++66.3.0-18+deb9u1
ii  libvpx4   1.6.1-3+deb9u1
ii  libx11-6  2:1.6.4-3+deb9u1
ii  libx11-xcb1   2:1.6.4-3+deb9u1
ii  libxcb-shm0   1.12-1
ii  libxcb1   1.12-1
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-2+b3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  procps2:3.3.12-3+deb9u1
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages firefox-esr recommends:
ii  libavcodec-extra57  7:3.2.12-1~deb9u1
ii  libavcodec546:9.13-1~bpo70+1
ii  libavcodec556:10.1-1~bpo70+1

Versions of packages firefox-esr suggests:
ii  fonts-lmodern  2.004.5-3
ii  fonts-stix [otf-stix]  1.1.1-4
ii  libcanberra0   0.30-3
ii  libgssapi-krb5-2   1.15-1+deb9u1
ii  libgtk2.0-02.24.31-2
ii  pulseaudio 10.0-1+deb9u1

-- no debconf information

-- 
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics


signature.asc
Description: PGP signature

Bug#915384: lintian: check that debian/copyright has an entry for each component

[Mattia Rizzolo]

On Mon, Dec 03, 2018 at 02:27:05PM +0100, Xavier wrote:
> Le 03/12/2018 à 14:22, Chris Lamb a écrit :
> > Xavier wrote:
> > 
> >>   # debian/watch
> >>   https://main/ main-(\d[\d\.]+)\.tar\.gz
> >>   opts="component=comp1" \
> >>https://comp/ comp-(\d[\d\.]+)\.tar\.gz
> >>
> >> In this example, a debian tool like gbp will unpack comp_1.0.orig.tar.gz
> >> into "comp1/" directory
> > ^
> > And this comes from parsing the `opts="component=comp1"` bit, not from
> > anywhere else?
> 
> ~Yes, for gdb DD must either add some "--component" in command-line *or*
> set it in gbp.conf:
> 
>   [DEFAULT]
>   component = [ 'bson', 'mongodb-core', 'requireoptional' ]
> 
> So only debian/watch is reliable. There are no other files that rely on
> this except debian/rules but in many ways...

You are missing that this feature comes from dpkg-source, so the list of
components can be naturally gathered from the .dsc.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#915384: lintian: check that debian/copyright has an entry for each component

[Xavier]

Le 03/12/2018 à 14:31, Chris Lamb a écrit :
> This is not straightforward to implement as it requires parsing both
> debian/watch and the DEP-5 copyright, one of which will need
> refactoring out, so please don't expect it within a few days

No worries, this feature is little used at the moment, but might be
recommended for some node-* packages.

Many thanks, have a good day !

Bug#915103: Info received ()

[Cyr Bol]

i'm still wrong:

da1d372d0d58474f2f5a71b9acd301abf9b11bc0 is the commit on the master branch

On the stretch branch, the commit
is bee2facd9343beda10677b139cd9b2e49e986f01

(though, they both relate to the following upstream commit:
https://github.com/apache/httpd/commit/808a94d0ccb3203702bdc86e2fc8961f68398fc7
)

On Mon, Dec 3, 2018 at 10:30 AM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Thank you for the additional information you have supplied regarding
> this Bug report.
>
> 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):
>  Debian Apache Maintainers 
>
> If you wish to submit further information on this problem, please
> send it to 915...@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.
>
> --
> 915103: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915103
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#915109: apt upgrade needs limit or date cap

[Roland Hughes]

To be honest


>So, there's an easy way to achieve a cut off/reproduction. Run
update, record the SHA256 of the InRelease files and specify them
as documented / requested in bug 886745.


That sounds like more of a kludge than what we do now. What we have to do now 
is configure one machine at one point in time, uninstall or disable apt then 
make a sacred ISO of it. That's at least easily explainable and reproducable by 
out of house testing companies which tend to hire people who are "priced right."


>PS. I'd spent some time learning how to quote emails, wrap your
lines, and express yourself as short as possible, so things are
understandable. This email is a good example in general, but a
bit verbose. It will be appreciated. Also get rid of the disclaimer
when posting to public audiences.


By "spent" I assume you mean spend. I did explain it as concisely as possible. 
As to verbosity, well . . . I've been at this a long time.


http://theminimumyouneedtoknow.com/

[http://www.theminimumyouneedtoknow.com/book_covers/openvms_book_cover_small.jpg]

The Minimum You Need to Know
theminimumyouneedtoknow.com
Roland Hughes is the author of The Minimum You Need to Know book series.




If there is a disclaimer at the end of this it is because the email system at 
client site puts it on all emails.


From: Julian Andres Klode  on behalf of Julian Andres 
Klode 
Sent: Sunday, December 2, 2018 5:18:32 PM
To: Roland Hughes
Cc: 915...@bugs.debian.org
Subject: Re: Bug#915109: apt upgrade needs limit or date cap

On Sun, Dec 02, 2018 at 10:28:00PM +, Roland Hughes wrote:
> What I rather clearly stated multiple times is that apt needs an
> -asof=yyymmdd:hhmm parameter. The purpose of this parameter is to only
> allow apt to apply updates pushed to the repository prior to that
> timestamp. Anything later is ignored.

So, there's an easy way to achieve a cut off/reproduction. Run
update, record the SHA256 of the InRelease files and specify them
as documented / requested in bug 886745.

This works fine for Ubuntu at least. Another approach, considered
for image building in Ubuntu is to use a proxy that figures that
hash out by date using Launchpad API and injects itself into the build
process:

 https://code.launchpad.net/~tobijk/livecd-rootfs/magic-proxy/+merge/357643

- this does not translate directly to arbitrary repositories, though.

That said, there is of course a caveat: Archive space is not unlimited,
so only a limited number of generations are kept. This lasts a few hours
maybe, but not a span of days.

A cut off date is imprecise and gives you less properties than the
existing solution, as the data can easily change with the same cut-off
date, for example, you run at 20:00, get the 18:00 archive state,
and then you run at 21:00 and your mirror has the 19:00 archive
state. Using concrete hashes of InRelease files allows you to produce
an exact state of a given repository. You'd have to contact a centralized
master instance to get the real "current" one.

PS. I'd spent some time learning how to quote emails, wrap your
lines, and express yourself as short as possible, so things are
understandable. This email is a good example in general, but a
bit verbose. It will be appreciated. Also get rid of the disclaimer
when posting to public audiences.

--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en





Disclaimer The information in this email and any attachments may contain 
proprietary and confidential information that is intended for the addressee(s) 
only. If you are not the intended recipient, you are hereby notified that any 
disclosure, copying, distribution, retention or use of the contents of this 
information is prohibited. When addressed to our clients or vendors, any 
information contained in this e-mail or any attachments is subject to the terms 
and conditions in any governing contract. If you have received this e-mail in 
error, please immediately contact the sender and delete the e-mail.

Bug#906813: stretch-pu: package ganeti-os-noop/0.2-1+deb9u1

[Mike Gabriel]

Hi Julien,

On  Mo 03 Dez 2018 08:16:55 CET, Julien Cristau wrote:


Control: tag -1 confirmed

On Tue, Aug 21, 2018 at 04:12:11PM +0200, Mike Gabriel wrote:
diff -Nru ganeti-os-noop-0.2/debian/changelog  
ganeti-os-noop-0.2/debian/changelog

--- ganeti-os-noop-0.2/debian/changelog 2016-04-11 22:31:50.0 +0200
+++ ganeti-os-noop-0.2/debian/changelog 2018-08-21 16:00:41.0 +0200
@@ -1,3 +1,17 @@
+ganeti-os-noop (0.2-1+deb9u1) stretch; urgency=medium
+
+  * debian/control:
++ Update Vcs-*: fields. VCS repo has been migrated to salsa.debian.org.
++ Priority extra -> optional.
++ Update Maintainer: field to 'Debian Ganeti Team
+  '
+  * debian/patches:
++ Add 1001_fix-export-script-for-non-block-devices.patch. Fix size
+  detection for non-block devices. Thanks to Bastian Blank for
+  providing the patch. (Closes: #895602).
+
+ -- Mike Gabriel   Tue, 21 Aug 2018 16:00:41 +0200
+
 ganeti-os-noop (0.2-1) unstable; urgency=medium

   * Initial release. (Closes: #794482).


Looks ok to upload, thanks.

Cheers,
Julien


Package upload just got ACCEPTed.

Mike
--

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



pgpkgTIlozZNC.pgp
Description: Digitale PGP-Signatur

Bug#915384: lintian: check that debian/copyright has an entry for each component

[Xavier]

Le 03/12/2018 à 13:28, Chris Lamb a écrit :
> tags 915384 + moreinfo
> thanks
> 
> Hi Xavier,
> 
>> It could be safe in this case to add a lintian warning if there is no
>> entry in debian/copyright like:
>>
>>   Files: ...
> 
> I don't 100% understand what would be the problem here if an entry is
> missing, what "it could be safe" means and whether the "<" etc are
> part of the name etc... 
> 
> But to save some back-and-forth, it might be easier to provide:
> 
>  * An example "good" case.
> 
>  * A "bad" case.
> 
>  * A short paragraph explaining why this is bad (for me and for the
>eventual tag description).
> 
> Thanks in advance.
> 
> Regards,

Hello,

thanks for looking at this. Here is an example:

  # debian/watch
  https://main/ main-(\d[\d\.]+)\.tar\.gz
  opts="component=comp1" \
   https://comp/ comp-(\d[\d\.]+)\.tar\.gz

In this example, a debian tool like gbp will unpack comp_1.0.orig.tar.gz
into "comp1/" directory

Presumed good debian/copyright:

  Files: *
  Copyright: foo
  License: GPL-2+

  Files: comp1/*
  Copyright: bar
  License: Expat

Suspicious debian/copyright:

  Files: *
  Copyright: foo
  License: GPL-2+

In the last case, no entry matches explicitly "comp1/" directory. It
might be a missing exam of sources. If both main and component have the
same copyright, DD can insert a lintian-overrides but then we're sure
that he didn't miss to examine component directory.

I didn't propose "Certainty: certain": component were introduced in
uscan to group sources when upstream provided source in multiple tarballs.

Severity should be "important" but during a transitional time, I think
it could stay "normal" until all valid packaged fixes their
lintian-overrides.
I don't know also if "important" makes sense with "Certainty: wild-guess"

Cheers,
Xavier