Bug#883750: RFS: dde-calendar/1.1.1-1 [ITP]

[Yangfl]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: pkg-deepin-de...@lists.alioth.debian.org

Dear mentors,

I am looking for a sponsor for my package "dde-calendar"

 * Package name: dde-calendar
   Version : 1.1.1-1
   Upstream Author : Deepin Technology Co., Ltd.
 * URL : https://github.com/linuxdeepin/dde-calendar
 * License : GPL-3+
   Section : utils


  It builds those binary packages:

dde-calendar - Deepin calendar

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

  https://mentors.debian.net/package/dde-calendar

  Git repo:

https://anonscm.debian.org/git/pkg-deepin/dde-calendar.git

Regards,
Yangfl

Bug#883256: apparmor-profiles-extra: Totem can't access files outside $HOME

[intrigeri]

Control: tag -1 + moreinfo

Hi Philip,

Philip Rinn:
> with the AppArmor profile enabled, I can't access any file outside my $HOME
> directory. While I understand the idea behind it, it's rather annoying with my
> setup (which is not too uncommon I think). I have a HDD for my media files
> while everything else is on a SSD thus my media files live outside my $HOME 
> directory.

> I know how to fix the problem for myself but I think the profile is too strict
> here.

The Totem profile allows common locations for media files outside of
$HOME, such as /{media,mnt,opt,srv}/**. Where are the files you're
trying to play located? If they are in one of the supposedly allowed
directories, please provide the AppArmor denial logs.

Thanks in advance!

Cheers,
-- 
intrigeri

Bug#883682: don't install features-file as conffile for easier overriding

[intrigeri]

Control: tag -1 - patch
Control: severity -1 normal

Hi,

Fabian Grünbichler:
> see attached patch.

Thanks!

> I didn't find a branch for the s-p-u upload (but
> that might just be my non-existing bzr skills failing me),

https://alioth.debian.org/scm/loggerhead/collab-maint/apparmor-stretch/changes
https://anonscm.debian.org/bzr/collab-maint/apparmor-stretch/

I'll update the Vcs-* fields on that branch if we ever do another
stretch-pu.

> for applying to master/unstable, an additional rm_conffile is probably a
> good idea to decruft /etc/apparmor.

Yes, absolutely ⇒ please update the patch (so I'm removing the "patch"
tag as I cannot apply it as-is).

> I decided to move the features file into /usr/share/apparmor-features
> because /usr/share/apparmor is already the default include search path.

Sounds good to me. No need to create that directory in the packaging?

> it would be possible to extend this further and e.g. provide multiple
> features files for different (Debian) kernel versions, and symlink the
> default one which is referenced in /etc/apparmor/parser.conf ?

Good idea for the future, let's not bother for now.

> it would be rather important for us to know whether you plan on applying
> and including this for the point release on Sunday (or postpone the
> feature pinning apparmor update until the next point release)

2.11.0-3+deb9u1 won't be part of the next point-release due to the
kernel bug you helped identify, that breaks mount operations when
pinning a feature set that supposedly disables mount mediation.

> I am not sure whether we are the only derivative/downstream/.. affected
> by this change, but it has the potential to break a lot of setups using
> their own (more recent / patched to support more of AA) kernel and AA
> profiles on top of Stretch..

With my AppArmor in Debian maintainer hat, I've never heard of people
running this kind of things in production until you reached out to me.
So these people might exist, but they're not talking to me. Thanks to
you I'm now aware of this use case and we can work together to support
it better :)

>> > intrigeri:
>> >> Understood. Ideally parser.conf would be complemented by
>> >> /etc/apparmor/parser.conf.d/*.conf, which could be sourced at the end
>> >> of parser.conf somehow. And then we can ship the default parser.conf
>> >> in /usr. TTBOMK we have no way to source such additional config
>> >> drop-in snippets though. I suspect upstream would be happy to consider
>> >> patches that add this feature :)
>> 
>> > yes, that would have been nice. alas, there is no such thing now, and
>> > getting one in time for the upcoming point release is not really an
>> > option.. maybe in time for buster?
>> 
>> >> If we had this drop-in snippet support for complementing the default
>> >> parser.conf, then both your use case and that one would be supported
>> >> nicely, right?
>> 
>> > yes.
>> 
>> Would you be willing to work on such a feature upstream so downstreams
>> & derivatives have a cleaner (than diversion) way to address
>> this problem?

> that should be do-able, but I won't have time to take a closer look this
> week.

Sure, no hurry. It would be good to have an upstream bug on Launchpad
about this, so we don't forget about it and we have a place to discuss
this with other upstream people :)

Cheers,
-- 
intrigeri

Bug#883018: Please make ocaml-nox provide ocamlopt (or not) depending on arch

[Ralf Treinen]

Hello,

On Tue, Nov 28, 2017 at 09:58:51PM +0100, Julien Puydt wrote:

> I just took the scilab package out of orphanage, and I'm having a
> problem : it has some caml code, but wants to compile it with ocamlopt,
> which is not available on all architectures.
> 
> If you look at:
> https://buildd.debian.org/status/package.php?p=scilab=experimental

I can't see any builds on this page.

> you'll see that the previous maintainer set a list of ok-arches and for
> some reason, armel went from ok to not-ok.

The up-to-date list of architectures for which ocaml provides
compilation to native code can be found in the file

/usr/lib/ocaml/native-archs

> Would it be possible to make ocaml-nox provide or not provide a virtual
> ocamlopt package depending on the arch? That way, I would make scilab
> depend on ocamlopt and things would go smoothly as you update the
> ocaml-nox package.

I don't think that is the right way to solve this problem. Instead, the
upstream Makefiles or ./configure should detect existence or not of
/usr/bin/ocamlopt, and then fall back to using ocamlc when this is not
case. The ./configure ofscilab seems already to do that, so maybe
some of the makefiles do not use this information properly.

-Ralf.

Bug#881941: Please consider to let live-build add file /.disk/mkisofs to the ISO

[Thomas Schmitt]

Hi,

I wrote:
> >   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881941

Daniel Reichelt wrote:
> He already merged the patch in live-build's git [1]

I missed the tagging mail of november 20th. Sorry for the noise.


> Do you have a conrete example of when the patch fails?

No. My proposal is a combination of the theoretical problem of bringing
/.disk/mkisofs file creation and xorriso run too far apart, and of the
misperception that Raphaël had not yet reacted on the bug report.
So i wanted to ping and offer a fix which keeps the architecture as is.


> the generated
> script initially was supposed to be a wrapper script around xorriso

Out of curiosity: Inhowfar is xorriso in need of a wrapper for the
debian-live use case ?
(This is no criticism. I just want to learn about the motivations of
 its users.)


Have a nice day :)

Thomas

Bug#883583: gnustep-gui-runtime: GSCUPS bundle crashes applications on CUPS client hosts

[Yavor Doganov]

Eric Heintzmann wrote:
> Le 05/12/2017 à 14:38, Yavor Doganov a écrit :
> > Eric, do we want to fix this now or we could delay it for 0.26?
> > Do we want to fix it in stretch?
> >
> Let's wait this week-end for the new -gui release.

OK.

> For stretch, I would like to fix this bug.

It has to be fixed in unstable first for SRMs to consider a pu for
stable, so that would be after the transition.

Do you have a 64-bit stretch machine with GNUstep installed?  Mine is
i386 and I can't reproduce the bug, most probably because the size of
a pointer is the same as the size of an int.

> (I just need to check if I have uploading rights on stable)

I don't think it's possible to restrict upload rights to a particular
suite, so you should have.

Bug#881715: alsa-utils: High CPU usage on the default device

[Andoru]

Yes, I was about to do that. Though those distros all have PulseAudio by
default, so I thought of installing Arch on a separate partition and test
ALSA there.

Bug#883749: ITP: dde-calendar -- Calendar software for Deepin OS

[Yangfl]

Package: wnpp
Severity: wishlist
Owner: Yangfl 
X-Debbugs-CC: pkg-deepin-de...@lists.alioth.debian.org

* Package name: dde-calendar
  Version : 1.1.1
  Upstream Author : Deepin Technology Co., Ltd.
* URL : https://www.deepin.org/
* License : GPLv3
  Programming Lang: C++
  Description : Calendar software for Deepin OS

I intend to co-maintain this package inside pkg-deepin team.

Bug#881715: alsa-utils: High CPU usage on the default device

[Elimar Riesebieter]

* Andoru  [2017-12-04 21:54 +0200]:

> > As you are the only one out of 60thsd Debian Alsa users who
> > reported a high cpu-usage running alsa apps and I can't reproduce
> > and don't know your system
> 
> What is there else that you'd like to know? What is it that I should be
> doing to diagnose this? That's what I've been asking for the entirety of
> this bug report!

You can try to boot a live-linux like Debian-live, Knoppix, Ubuntu
whatever and check whether your symptoms persist.

Elimar
-- 
  Obviously the human brain works like a computer.
  Since there are no stupid computers humans can't be stupid.
  There are just a few running with Windows or even CE ;-)


signature.asc
Description: PGP signature

Bug#883561: thunderbird: AppArmor profile is not applied after opting-in due to new binary path

[intrigeri]

This is now really "pending": I've merged the fix upstream and pushed
it to our Vcs-Git :)

Bug#883706: dolphin4 is still linked with libplasma3

[Pino Toscano]

Control: severity -1 important
Control: tag -1 - patch

In data mercoledì 6 dicembre 2017 19:33:10 CET, Adrian Bunk ha scritto:
> Package: dolphin4
> Version: 4:16.08.3-1
> Severity: serious
> Tags: patch buster sid
> 
> dolphin4 is still linked with libplasma3,
> which has to be removed for the qtwebkit removal.

NACK.

dolphin4 (which uses kdelibs4) is shipped only to provide file browsing
capabilities to konqueror (which uses kdelibs4).  In recent versions of
KDE Applications kde-baseapps does not exist anymore, replaced by split
tarballs (konqueror, kfind, keditbookmarks, kdialog).  Only konqueror
is available in experimental, the others are waiting in NEW.  Once all
are available, they will replace kde-baseapps in unstable (in a
coordinated upload with kde-l10n, since they ship translations), and
thus dolphin4 will be removed.

To be honest, it would be much easier if you could *wait* for the
completion of Applications 17.08 in unstable/testing, so there will be
few more kdelibs4-using sources either dropped (like dolphin4) or
ported to Frameworks.

-- 
Pino Toscano

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

Bug#883748: ITP: deepin-calculator -- Calculator for deepin

[Yangfl]

Package: wnpp
Severity: wishlist
Owner: Yangfl 
X-Debbugs-CC: pkg-deepin-de...@lists.alioth.debian.org

* Package name: deepin-calculator
  Version : 1.0.0
  Upstream Author : Deepin Technology Co., Ltd.
* URL : https://www.deepin.org/
* License : GPLv3
  Programming Lang: C++
  Description : Calculator for deepin

I intend to co-maintain this package inside pkg-deepin team.

Bug#883562: ejabberd suddenly take all cpu

[Joerg Dorchain]

Hello,

with the following version of erlang-p1 packages, ejabberd run
again as it should, i.e. not high-load, no error log entries.

erlang-p1-cache-tab 1.0.12-1
erlang-p1-iconv 1.0.5-1
erlang-p1-mysql 1.0.4-1
erlang-p1-pam   1.0.3-2
erlang-p1-pgsql 1.1.4-1
erlang-p1-sip   1.0.17-1
erlang-p1-stringprep1.0.10-1
erlang-p1-stun  1.0.16-1
erlang-p1-tls   1.0.17-1
erlang-p1-utils 1.0.10-1
erlang-p1-xml   1.1.25-1
erlang-p1-xmpp  1.1.14-2
erlang-p1-yaml  1.0.12-1
erlang-p1-zlib  1.0.2-1

Bye,

Joerg


signature.asc
Description: PGP signature

Bug#883747: php7.0-xmlrpc: Wrong numeric entities convertion in xmlrpc_encode_request

[Mathieu Petit-Clair]

Package: php7.0-xmlrpc
Version: 7.0.26-1
Severity: normal

Dear Maintainer,

There is bug in the xmlrpc extension, when calling xmlrpc_encode() with
a range of characters.

To reproduce using php -a :

echo xmlrpc_encode('Π');

Result in sid:




 
  
 



Expected:

The value in ... should be  (note the extra
zero).

The good value can also be found on http://graphemica.com/%CE%A0 as the
"URL Escape Code", as seen in this URL and by
converting 206 to 0xCE and 160 to 0xA0.

We got the expected result by compiling PHP ourselves, which makes this
look like a Debian specific bug.

PHP bug 28597 - https://bugs.php.net/bug.php?id=28597 - provides a
solution to this issue, but does not appear to prevent it in this case.

Thanks for your help,


-- Package-specific info:
 Additional PHP 7.0 information 

 PHP @PHP_VERSION SAPI (php7.0query -S): 

 PHP 7.0 Extensions (php7.0query -M -v): 

 Configuration files: 
 /etc/php/7.0/mods-available/xmlrpc.ini 
extension=xmlrpc.so


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

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

Versions of packages php7.0-xmlrpc depends on:
ii  libc6   2.25-3
ii  libxml2 2.9.4+dfsg1-5.1
ii  libxmlrpc-epi0  0.54.2-1.2
ii  php-common  1:56
ii  php7.0-common   7.0.26-1
ii  ucf 3.0036

php7.0-xmlrpc recommends no packages.

php7.0-xmlrpc suggests no packages.

Versions of packages php7.0-common depends on:
ii  libc6   2.25-3
ii  libssl1.1   1.1.0g-2
ii  php-common  1:56
ii  ucf 3.0036

Versions of packages php7.0-cli depends on:
ii  libc62.25-3
ii  libedit2 3.1-20170329-1
ii  libmagic11:5.32-1
ii  libpcre3 2:8.39-8
ii  libssl1.11.1.0g-2
ii  libxml2  2.9.4+dfsg1-5.1
ii  mime-support 3.60
ii  php7.0-common7.0.26-1
ii  php7.0-json  7.0.26-1
ii  php7.0-opcache   7.0.26-1
ii  php7.0-readline  7.0.26-1
ii  tzdata   2017c-1
ii  ucf  3.0036
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages php7.0-cli suggests:
ii  php-pear  1:1.10.5+submodules+notgz-1

Versions of packages libapache2-mod-php7.0 depends on:
ii  apache2-bin [apache2-api-20120211]  2.4.29-1
ii  libc6   2.25-3
ii  libmagic1   1:5.32-1
ii  libpcre32:8.39-8
ii  libssl1.1   1.1.0g-2
ii  libxml2 2.9.4+dfsg1-5.1
ii  mime-support3.60
ii  php7.0-cli  7.0.26-1
ii  php7.0-common   7.0.26-1
ii  php7.0-json 7.0.26-1
ii  php7.0-opcache  7.0.26-1
ii  tzdata  2017c-1
ii  ucf 3.0036
ii  zlib1g  1:1.2.8.dfsg-5

Versions of packages libapache2-mod-php7.0 recommends:
ii  apache2  2.4.29-1

Versions of packages libapache2-mod-php7.0 suggests:
ii  php-pear  1:1.10.5+submodules+notgz-1

-- no debconf information

Bug#883743: bzr: FTBFS on armel

[Vagrant Cascadian]

On 2017-12-06, Jelmer Vernooij wrote:
> On Wed, Dec 06, 2017 at 05:45:11PM -0800, Vagrant Cascadian wrote:
> Can you reproduce the issue once you set LC_ALL=C.UTF-8 ?
>
> The delta between -8 and -9 is minimal and not related to the test
> that failed, so I'm wondering if this is a spurious failure (timing?) of some
> sort or perhaps a regression introduced by a dependency.

Well, I managed to reproduce it on amd64 too, so I think this is a
different issue entirely than what caused the original armel build to
fail (which might have just been a transient failure)...

The following link should have two build logs, one with the C.UTF-8
patch applied to debian/rules, and one with without it, built with
sbuild:

  https://cascadia.debian.net/~vagrant/bzr/patched.build.gz
  https://cascadia.debian.net/~vagrant/bzr/unpatched.build.gz

The patched build succeeds, the unpatched build fails.

I'm guessing something in the toolchain changed the way it handles UTF-8
since the builds almost a month ago...

Hope that's helpful.


live well,
  vagrant

p.s. I noticed no almost no arch:all buildd logs, and very few recent
amd64 buildd logs... maybe save some bandwith for yourself and start
doing source-only uploads. :)


signature.asc
Description: PGP signature

Bug#883737: [Pkg-kde-extras] Bug#883737: gtk2-engines-oxygen: Please don't depend on gtk2

[Pino Toscano]

Control: tag -1 - patch

In data mercoledì 6 dicembre 2017 19:38:22 CET, Jeremy Bicha ha scritto:
> Package: gtk2-engines-oxygen
> Version: 1.4.6-1
> Tags: patch
> 
> In my next email, I am submitting a patch to drop the gtk2 dependency
> from this package. This is safe because the only thing that will
> actually use the theme or theme engine is a gtk2 app which will
> already depend on gtk2.

I do not see the logic in this change: this package contains only a gtk2
theme, so the only way in which this is useful is because you have a
gtk2 application installed, so the gtk2 dependency is already satisfied.

It looks to me this allows users to install gtk2-engine-oxygen without
actually pulling gtk2, which IMHO is the thing that needs to be fixed
instead.

-- 
Pino Toscano

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

Bug#837310: protobuf: FTBFS on !linux architectures: tests fail

[Petter Reinholdtsen]

[Andreas Beckmann]
> protobuf FTBFS on hurd-i386 and kfreebsd-* with testsuite failures:

The error seem to be related to mutex locking and the same on both hurd and 
kfreebsd.
This is the error on hurd:

[ FATAL ] /usr/include/gtest/internal/gtest-port.h:1928:: 
pthread_mutex_lock(_)failed with error 1073741846

This is the error on kfreebsd:

[ FATAL ] /usr/include/gtest/internal/gtest-port.h:1928:: 
pthread_mutex_lock(_)failed with error 22

Perhaps the mutex handling is wrong, and work by mistake on Linux?
-- 
Happy hacking
Petter Reinholdtsen

Bug#878498: snakemake FTBFS with Python 3.6 as default

[Andrey Rahmatullin]

On Wed, Dec 06, 2017 at 10:14:45PM +0100, Andreas Tille wrote:
> control: tags -1 help
> 
> Hi,
> 
> I've upgraded snakemake in Git to latest upstream but its featuring the
> same issue.  I'm pretty sure you Python people know a simple answer for
> this issue.
Did you see this part?

> > The problem is the the following line in debian/rules:
> > 
> >   export PATH:=$(CURDIR)/.pybuild/pythonX.Y_3.5/build/bin:$(PATH)


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#883746: chromium: secretly stores referer and url for downloaded files

[Adam Borowski]

Package: chromium
Version: 62.0.3202.89-1
Severity: important

Hi!
If you download and save a file with Chromium (even in incognito mode), it
saves potentially sensitive metadata in a way that's completely unknown to
almost all users, even highly technical ones:

user.xdg.referrer.url: https://angband.pl/tmp/
user.xdg.origin.url: https://angband.pl/tmp/20130210_001.jpg

This photo is embarassing, but not overwhelmingly so.  It also, on its own,
appears to include no way to tie to me in particular.  There's EXIF but,
coming from a sane camera, it has no GPS data or whatever.  Yet, once the
URL is smuggled, the link to me is obvious, and it's easy to distort the
image's story into something that could get someone fired or otherwise
publicly shamed (based on typical kitten behaviour).

And it can get worse: imagine (werewolf protection) a kiddie porn image,
or a secret government file ("Hillary and Donald, sitting in a tree,
K.I.S.S.I.N.G.jpg").

In this case, referer is uninteresting, but it can be as bad or worse than
the URL itself.

This is a concern when the file is copied to any xattr-preserving media,
such as an USB stick or a CIFS mount -- or, if your computer itself is
imaged/accessed.


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

Kernel: Linux 4.15.0-rc2-debug-00195-g50510b7395bf (SMP w/5 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages chromium depends on:
ii  chromium-common  62.0.3202.89-1
ii  libasound2   1.1.3-5
ii  libatk1.0-0  2.26.1-1
ii  libavcodec57 7:3.4-4
ii  libavformat577:3.4-4
ii  libavutil55  7:3.4-4
ii  libc62.25-3
ii  libcairo21.15.8-2
ii  libcups2 2.2.6-2
ii  libdbus-1-3  1.12.2-1.0nosystemd1
ii  libevent-2.1-6   2.1.8-stable-4
ii  libexpat12.2.3-2
ii  libflac8 1.3.2-1
ii  libfontconfig1   2.12.6-0.1
ii  libfreetype6 2.8.1-0.1
ii  libgcc1  1:7.2.0-17
ii  libgdk-pixbuf2.0-0   2.36.11-1
ii  libglib2.0-0 2.54.2-1
ii  libgtk2.0-0  2.24.31-4
ii  libharfbuzz0b1.7.1-1
ii  libicu57 57.1-8
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.8-4
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.16-1+b1
ii  libnss3  2:3.34-1
ii  libopus0 1.2.1-1
ii  libpango-1.0-0   1.40.13-2
ii  libpangocairo-1.0-0  1.40.13-2
ii  libpng16-16  1.6.34-1
ii  libpulse011.1-3.0nosystemd1
ii  libre2-3 20170101+dfsg-1
ii  libsnappy1v5 1.1.7-1
ii  libstdc++6   7.2.0-17
ii  libvpx4  1.6.1-3
ii  libwebp6 0.6.0-4
ii  libwebpdemux20.6.0-4
ii  libwebpmux3  0.6.0-4
ii  libx11-6 2:1.6.4-3
ii  libx11-xcb1  2:1.6.4-3
ii  libxcb1  1.12-1
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.1.14-3
ii  libxdamage1  1:1.1.4-3
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxml2  2.9.4+dfsg1-5.1
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxslt1.1   1.1.29-5
ii  libxss1  1:1.2.2-1+b2
ii  libxtst6 2:1.2.3-1
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages chromium recommends:
ii  fonts-liberation  1:1.07.4-5

Versions of packages chromium suggests:
pn  chromium-driver
pn  chromium-l10n  
pn  chromium-shell 
pn  chromium-widevine  

-- no debconf information

Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)

[Julien Aubin]

2017-12-07 5:43 GMT+01:00 Julien Aubin :

>
> 2017-12-06 21:50 GMT+01:00 Aurelien Jarno :
>
>> On 2017-12-06 19:39, Julien Aubin wrote:
>> > Weird... this time I re-upgraded libc6 and things work fine... looks
>> like
>> > something wrong went during the install. And I cannot reproduce the
>> issue
>> > anymore... :'( WTF ???
>>
>> Hmm, a bug has been introduced in libc6 version 2.24-11+deb9u2, which in
>> some conditions leave the /etc/ld.so.nohwcap file instead of removing it
>> just after the upgrade (see bug#883394). One of the condition is to have
>> libc6-i686 installed (while it can be safely removed), which seems to be
>> your case.
>>
>> I consider this bug harmless as it should not deactivate anything now
>> that the default libc is already i686 optimized. Also I don't see how it
>> could trigger the issue you described. Anyway better be safe than sorry,
>> could you please try to create this file with "touch /etc/ld.so.nohwcap"
>> as root and see if it makes the issue to reappear? Once the test is done
>> you can then remove it.
>>
>> Thanks,
>> Aurelien
>>
>
>
> Bingo ! It was exactly this !
>
> If I re-create the file for example it crashes glxgears. When I remove it
> glxgears works fine.
>
> With GDB, the stack trace for when I run glxgears :
>
> 0  0x76b311a4 in pthread_mutex_lock (mutex=0x7604e8c0) at
> forward.c:192
> #1  0x75de1308 in __glDispatchNewVendorID () from
> /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0
> #2  0x760793c2 in ?? () from /usr/lib/x86_64-linux-gnu/libGLX.so.0
>
> #3  0x7607a1ac in ?? () from /usr/lib/x86_64-linux-gnu/libGLX.so.0
>
> #4  0x76073170 in glXChooseVisual () from
> /usr/lib/x86_64-linux-gnu/libGLX.so.0
> #5  0x779f in ?? ()
> #6  0x5ae7 in ?? ()
> #7  0x76a5c2e1 in __libc_start_main (main=0x5970, argc=1,
> argv=0x7fffe638, init=,
>fini=, rtld_fini=,
> stack_end=0x7fffe628) at ../csu/libc-start.c:291
> #8  0x646a in ?? ()
>
>
>
To be clear it looks like this file also affects libc6-amd64 behaviour...

>
>> --
>> Aurelien Jarno  GPG: 4096R/1DDD8C9B
>> aurel...@aurel32.net http://www.aurel32.net
>>
>
>

Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)

[Julien Aubin]

2017-12-06 21:50 GMT+01:00 Aurelien Jarno :

> On 2017-12-06 19:39, Julien Aubin wrote:
> > Weird... this time I re-upgraded libc6 and things work fine... looks like
> > something wrong went during the install. And I cannot reproduce the issue
> > anymore... :'( WTF ???
>
> Hmm, a bug has been introduced in libc6 version 2.24-11+deb9u2, which in
> some conditions leave the /etc/ld.so.nohwcap file instead of removing it
> just after the upgrade (see bug#883394). One of the condition is to have
> libc6-i686 installed (while it can be safely removed), which seems to be
> your case.
>
> I consider this bug harmless as it should not deactivate anything now
> that the default libc is already i686 optimized. Also I don't see how it
> could trigger the issue you described. Anyway better be safe than sorry,
> could you please try to create this file with "touch /etc/ld.so.nohwcap"
> as root and see if it makes the issue to reappear? Once the test is done
> you can then remove it.
>
> Thanks,
> Aurelien
>


Bingo ! It was exactly this !

If I re-create the file for example it crashes glxgears. When I remove it
glxgears works fine.

With GDB, the stack trace for when I run glxgears :

0  0x76b311a4 in pthread_mutex_lock (mutex=0x7604e8c0) at
forward.c:192
#1  0x75de1308 in __glDispatchNewVendorID () from
/usr/lib/x86_64-linux-gnu/libGLdispatch.so.0
#2  0x760793c2 in ?? () from /usr/lib/x86_64-linux-gnu/libGLX.so.0
#3  0x7607a1ac in ?? () from /usr/lib/x86_64-linux-gnu/libGLX.so.0
#4  0x76073170 in glXChooseVisual () from
/usr/lib/x86_64-linux-gnu/libGLX.so.0
#5  0x779f in ?? ()
#6  0x5ae7 in ?? ()
#7  0x76a5c2e1 in __libc_start_main (main=0x5970, argc=1,
argv=0x7fffe638, init=,
   fini=, rtld_fini=,
stack_end=0x7fffe628) at ../csu/libc-start.c:291
#8  0x646a in ?? ()



>
> --
> Aurelien Jarno  GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://www.aurel32.net
>

Bug#875971: plasma-framework: Notification of 1 px

[Tim Sattarov]

Hi,

I have this issue as well, could you please package 5.38.0, as it seems to be 
fixed in there.

Thank you,
Tim

Bug#883745: packages.debian.org: unexpectedly render package desc in tag

[Boyuan Yang]

Package: www.debian.org
Severity: normal

Take a look at https://packages.debian.org/sid/go-dep ,

The raw package description is:

Description: Go dependency management tool
 dep is a prototype dependency management tool for Go. It is the
 official experiment, but not yet the official tool.
 .
 dep is safe for production use. That means two things:
 * Any valid metadata file (`Gopkg.toml` and `Gopkg.lock`) will be
   readable and considered valid by any future version of dep.
 * Generally speaking, it has comparable or fewer bugs than other
   tools out there.

The rendered HTML format is:



Go dependency management tool

dep is a prototype dependency management tool for Go. It is the
official experiment, but not yet the official tool.

dep is safe for production use. That means two things:
* Any valid metadata file (`Gopkg.toml` and `Gopkg.lock`) will be

  readable and considered valid by any future version of dep.

* Generally speaking, it has comparable or fewer bugs than other

  tools out there.



 

I'm not sure if it is an undocumented feature or a bug.

Regards,
Boyuan Yang



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

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

Bug#824904: bugs.debian.org: auto-fix common usertags mistakes

[Paul Wise]

On Thu, 07 Dec 2017 12:19:35 +0800 Paul Wise wrote:

> I found a whole bunch more user typos, new script attached.

There was a bug in one of the regexes, new script attached.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


debian-usertags-tests
Description: application/shellscript


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

Bug#824904: bugs.debian.org: auto-fix common usertags mistakes

[Paul Wise]

I found a whole bunch more user typos, new script attached.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


debian-usertags-tests
Description: application/shellscript


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

Bug#772718: adns: test failure on Ubuntu ppc64el, with -O3

[Jeremy Bicha]

Ian Jackson  wrote:
> I don't intend (with my Debian hat on) to upload this
> to Debian right now since
> - Debian is frozen for jessie
> - The actual library and binaries are fine
> - AFAIAA the test suite failure does not affect Debian itself
>
> When Debian unfreezes, I will fix this with a new upstream version.

Ping!

Thanks,
Jeremy Bicha

Bug#883016: ITP: isc-kea -- New upstream version 1.3.0 released

[Jason Guy]

Hi Adam,

Attached is a patch file with all the changes I made, which are documented
in the changelog. Please let me know if you have any questions.
I created a branch with the committed changes I made locally, and can push
that to the repo if that is easier.
I was not sure what the appropriate method was for contributing my changes.

Cheers,
Jason


On Wed, Dec 6, 2017 at 11:28 AM, Adam Majer  wrote:

>
>
> On 12/06/2017 03:09 PM, Jason Guy wrote:
>
>> Hi Adam,
>>
>> I emailed you and didn't get any response, so I guessed you were really
>> busy. My apologies for misusing the term "orphaned", I am trying to learn
>> about packaging, and contributing to debian packages. Perhaps I
>> misunderstood the procedure, but I found no ITP for the new Kea package, so
>> I opened the ITP assuming nobody was working on it.
>>
>> Anyway, I just completed the build of the isc-kea 1.3.0 package. I made a
>> lot of improvements (I think) and tried to clean up some of the lintian
>> errors/warnings. I would be happy to create a pull request or whatever with
>> my changes. I have a few other minor tweaks to do, but I can provide the
>> updates I made as well. Please let me know how you would like me to proceed.
>>
>
>
> https://packages.qa.debian.org/i/isc-kea.html
>
> No problem. There is a Git repository for packaging. If you would like,
> you can marge your package changes in there and send me the patches in
> email.
>
> I've had my "dinner plate full" with non-Debian things for some time. But
> I will try to find some time to update my packages this week.
>
> Sorry for delay on this.
>
> - Adam
>
> PS. I have a patch already to update to 1.3.0, but if you send me yours I
> can merge them.
>
>


kea-1.3.0.patch
Description: Binary data

Bug#883744: gtk-im-libthai: Please don't depend on gtk2

[Jeremy Bicha]

From a84e5b144cb0bdaf873d8560c98926a5a7e8d273 Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Wed, 6 Dec 2017 21:40:42 -0500
Subject: [PATCH] Don't depend on libgtk2.0-0

so that this package can provide GTK+ 2 support
without requiring that GTK+ 2 be installed

Closes: #883744
---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index c62223b..5d27a0a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -17,6 +17,9 @@ override_dh_makeshlibs:
 # Do not try to make shlibs file.
 # They're loadable modules, not to be linked against.
 
+override_dh_shlibdeps:
+	dh_shlibdeps -- -xlibgtk2.0-0
+
 binary-indep:
 # We have nothing to do.
 
-- 
2.14.1

Bug#883744: gtk-im-libthai: Please don't depend on gtk2

[Jeremy Bicha]

Package: gtk-im-libthai
Version: 0.2.1-6
Tags: patch

In my next email, I am submitting a patch to drop the gtk2 dependency
from gtk-im-libthai. I believe that the only thing that will actually
use gtk-im-libthai is a gtk2 app which will already depend on gtk2.
This allows gtk-im-libthai to be pre-installed regardless of whether
gtk2 is installed, making for a better experience when a gtk2 app is
installed.

This is part of a larger effort to not install gtk2 by default. See
https://bugs.debian.org/883440

Thanks,
Jeremy Bicha

Bug#881127: transition: xerces-c

[Andreas Beckmann]

Followup-For: Bug #881127

The build for hurd-i386 was now successful, please schedule binNMUs
there, too.


Thanks.

Andreas

Bug#883743: bzr: FTBFS on armel

[Jelmer Vernooij]

On Wed, Dec 06, 2017 at 05:45:11PM -0800, Vagrant Cascadian wrote:
> The last armel bzr build failed to build from source, and I've tried to
> reproduce the issue unsuccessfully.
> 
>   
> https://buildd.debian.org/status/fetch.php?pkg=bzr=armel=2.7.0%2Bbzr6622-9=1510195017=0
> 
> I tried building it on abel.debian.org, and it failed in a *different*
> way, complaining about unicode issues. Setting LC_ALL=C.UTF-8 seemed to
> fix that issue for me.
Thanks for reporting this.

Can you reproduce the issue once you set LC_ALL=C.UTF-8 ?

The delta between -8 and -9 is minimal and not related to the test
that failed, so I'm wondering if this is a spurious failure (timing?) of some
sort or perhaps a regression introduced by a dependency.

Jelmer


signature.asc
Description: PGP signature

Bug#883743: bzr: FTBFS on armel

[Jelmer Vernooij]

On Wed, Dec 06, 2017 at 05:45:11PM -0800, Vagrant Cascadian wrote:
> Package: bzr
> Version:  2.7.0+bzr6622-9
> Severity: serious
> Tags: patch
> 
> The last armel bzr build failed to build from source, and I've tried to
> reproduce the issue unsuccessfully.
> 
>   
> https://buildd.debian.org/status/fetch.php?pkg=bzr=armel=2.7.0%2Bbzr6622-9=1510195017=0
> 
> I tried building it on abel.debian.org, and it failed in a *different*
> way, complaining about unicode issues. Setting LC_ALL=C.UTF-8 seemed to
> fix that issue for me.
> 
> Forcing the test suite to run with the C.UTF-8 locale, available in all
> recent versions of Debian (and even some pretty old ones), at least
> fixed the unicode issues when run on abel.debian.org:
> 
> --- rules.orig2017-12-06 17:41:18.206442819 -0800
> +++ rules 2017-12-06 17:41:57.290537132 -0800
> @@ -24,6 +24,8 @@
>   BZR_PLUGIN_PATH=-site:-user \
>   BZR_DISABLE_PLUGINS=launchpad \
>   PYTHONPATH=$(wildcard $(CURDIR)/build/lib.*-$(PYVERSION)) \
> + LC_ALL=C.UTF-8 \
> + LANG=C.UTF-8 \
>   $(CURDIR)/build/scripts-$(PYVERSION)/bzr -Derror selftest -v 
> --parallel=fork
>  endif
>  
> 
> Maybe it's worth re-uploading with the above patch.
What failure do you get without LC_ALL=C.UTF-8 and LANG=C.UTF-8 set?

I'd rather avoid setting variables so that we can actually catch
and fix locale-related problems.


signature.asc
Description: PGP signature

Bug#883105: thunderbird crashes when started - 883105 resolved

[Heinrich Schuchardt]

The problem is resolved by Thunderbird 1:52.5.0-1.

Please, close the ticket.

Bug#883743: bzr: FTBFS on armel

[Vagrant Cascadian]

Package: bzr
Version:  2.7.0+bzr6622-9
Severity: serious
Tags: patch

The last armel bzr build failed to build from source, and I've tried to
reproduce the issue unsuccessfully.

  
https://buildd.debian.org/status/fetch.php?pkg=bzr=armel=2.7.0%2Bbzr6622-9=1510195017=0

I tried building it on abel.debian.org, and it failed in a *different*
way, complaining about unicode issues. Setting LC_ALL=C.UTF-8 seemed to
fix that issue for me.

Forcing the test suite to run with the C.UTF-8 locale, available in all
recent versions of Debian (and even some pretty old ones), at least
fixed the unicode issues when run on abel.debian.org:

--- rules.orig  2017-12-06 17:41:18.206442819 -0800
+++ rules   2017-12-06 17:41:57.290537132 -0800
@@ -24,6 +24,8 @@
BZR_PLUGIN_PATH=-site:-user \
BZR_DISABLE_PLUGINS=launchpad \
PYTHONPATH=$(wildcard $(CURDIR)/build/lib.*-$(PYVERSION)) \
+   LC_ALL=C.UTF-8 \
+   LANG=C.UTF-8 \
$(CURDIR)/build/scripts-$(PYVERSION)/bzr -Derror selftest -v 
--parallel=fork
 endif
 

Maybe it's worth re-uploading with the above patch.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#883742: developers-reference: §6.4: Please don't recommend to use "if [ -x /usr/bin/ ]; …" in maintainer scripts

[Axel Beckert]

Package: developers-reference
Version: 3.4.19
Severity: normal
Tags: patch

Hi,

§6.4 recommends:
> If you need to check for the existence of a command, you should use
> something like
>
> if [ -x /usr/sbin/install-docs ]; then ...

This has been proven to introduce technical debt (see
https://lists.debian.org/debian-devel/2014/11/msg00044.html and
https://bugs.debian.org/769845) if any of those paths is ever changed
like e.g. moved from /usr/sbin/ to /usr/bin/.

Since #769845 has been fixed, Lintian even emits a warning if such a
case is found.

Bascially there are two cases of "if [ -x /usr/bin/ ]; …" in
maintainer scripts:

A) The maintainer controls the checked path (and doesn't forget to
   update the maintainer script in case he ever changes the program's
   path).

B) The maintainer doesn't control the checked path. (See #769845 and
   https://lists.debian.org/debian-devel/2014/11/msg00044.html for real
   examples.)

Overriding this tag in case (A) is ok-ish if the maintainer indeed
doesn't forget to also update the maintainer scripts if he changes the
path.

But case (B) is a real issue and should be fixed and not overridden,
because the maintainer script definitely behaves worse if the wrong path
(e.g. a path only valid in earlier Debian releases) is used in the
check.

So in general, using "if [ -x /usr/bin/ ]; …" in maintainer
scripts should be avoided and definitely not recommended.

Leaves the question what should be recommended instead.

According to the discussion in https://bugs.debian.org/807695 the
current recommendation of a 12 lines shell script is unacceptable for
those developers who took part in the discussion and a simple "if which
$command > /dev/null; …" should be used instead.

(Note: Using "type" instead of "which" seems disputed or at least
unclear due to differences between bash and dash. See
https://bugs.debian.org/747320.)

So my suggestion is the following patch:

diff --git a/best-pkging-practices.dbk b/best-pkging-practices.dbk
index 27b5eca..51617ec 100644
--- a/best-pkging-practices.dbk
+++ b/best-pkging-practices.dbk
@@ -659,12 +659,7 @@ maintainer script.
 If you need to check for the existence of a command, you should use something
 like
 
-if [ -x /usr/sbin/install-docs ]; then ...
-
-If you don't wish to hard-code the path of a command in your maintainer script,
-the following POSIX-compliant shell function may help:
-
-
+if which install-docs > /dev/null; then ...
 
 You can use this function to search $PATH for a command
 name, passed as an argument.  It returns true (zero) if the command was found,
diff --git a/common.ent b/common.ent
index 1bbed6a..66e0e58 100644
--- a/common.ent
+++ b/common.ent
@@ -256,16 +256,3 @@ pool/non-free/f/firmware-nonfree/
 
 uudecode-file:
 perl -ne 'print(unpack u, $$_);' $(file).uuencoded  
$(file)">
-
-pathfind() {
-OLDIFS="$IFS"
-IFS=:
-for p in $PATH; do
-if [ -x "$p/$*" ]; then
-IFS="$OLDIFS"
-return 0
-fi
-done
-IFS="$OLDIFS"
-return 1
-}'>

I've pushed that patch into a new branch named "devref-vs-#769845" in
the git repository:

https://anonscm.debian.org/cgit/collab-maint/developers-reference.git/log/?h=devref-vs-%23769845

Feel free to continue to work on the fix for this bug in that branch
until there is a consent on merging the branch.

P.S.: I've taken the same severity as used in #769845 since I consider
this bug report equivalent to #769845, just against a different package.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), 
(500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 
'buildd-experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.13.0-rc7-amd64 (SMP w/8 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

developers-reference depends on no packages.

Versions of packages developers-reference recommends:
ii  debian-policy  4.1.2.0

Versions of packages developers-reference suggests:
ii  doc-base  0.10.7

-- no debconf information

Bug#883741: pyspread: Spreadsheet canvas won't show with newest update

[Lorenz Minder]

Package: pyspread
Version: 1.1-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

With the latest apt-get upgrade, the spreadsheet canvas of pyspread will
no longer show, instead it's just a white box without the grid.  This
makes the pyspread package unusable.  The console is full of error
messages like the following:

Traceback (most recent call last):
  File "/usr/share/pyspread/src/gui/_grid_renderer.py", line 340, in Draw
grid._view_frozen)
  File "/usr/share/pyspread/src/gui/_grid_renderer.py", line 263, in 
_get_cairo_bmp
context = wx.lib.wxcairo.ContextFromDC(mdc)
  File "/usr/lib/python2.7/dist-packages/wx-3.0-gtk2/wx/lib/wxcairo.py", line 
137, in ContextFromDC
ctx = pycairoAPI.Context_FromContext(ctxptr, pycairoAPI.Context_Type, None)
AttributeError: 'Pycairo_CAPI' object has no attribute 'Context_FromContext'

I am not sure what caused this problem, but am now seeing this on
several machines, and believe it to be universal.  To reproduce it,
simpy start pyspread (with no spreadsheet file at all).

Judging from the error messages, the bug might not be in the pyspread
package, but in some package it depends on.

I don't know a workaround for this problem.

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

Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages pyspread depends on:
ii  gir1.2-pango-1.0 1.40.12-1
ii  libcairo-gobject21.15.8-2
ii  libpangocairo-1.0-0  1.40.12-1
ii  python   2.7.14-1
ii  python-cairo 1.15.4-2
ii  python-gnupg 0.4.1-1
ii  python-gtk2  2.24.0-5.1+b1
ii  python-matplotlib2.0.0+dfsg1-2+b1
ii  python-numpy 1:1.13.3-2
ii  python-wxgtk3.0  3.0.2.0+dfsg-5

Versions of packages pyspread recommends:
ii  gpg-agent [gnupg-agent]  2.2.2-1
ii  python-jedi  0.10.2-1
ii  python-xlrd  1.1.0-1
ii  python-xlwt  0.7.5+debian1-1

Versions of packages pyspread suggests:
pn  python-mpltoolkits.basemap  
pn  ttf-mscorefonts-installer   

-- no debconf information

Bug#883735: Re: Bug#883735: initramfs-tools: automatic resume doesn't work for lvm swap partitions

[Ben Hutchings]

Control: reopen -1
Control: tag -1 patch moreinfo

On Thu, 2017-12-07 at 00:22 +, James Cowgill wrote:
> Hi,
> 
> On 07/12/17 00:06, Ben Hutchings wrote:
> > On Wed, 2017-12-06 at 23:48 +, James Cowgill wrote:
> > > Package: initramfs-tools
> > > Version: 0.130
> > > Severity: normal
> > > 
> > > Hi,
> > > 
> > > I had noticed this bug for quite a while now, but since I rarely turn my
> > > machine off I left investigating what the problem was until now.
> > 
> > [...]
> > > Is it possible (and a good idea) to store the /dev/mapper path instead
> > > of the blkid when the swap partition is on LVM?
> > > 
> > > I managed to solve my specific issue by manually setting RESUME to the
> > > correct /dev/mapper path.
> > 
> > This is the correct way to refer to LVs used as root, /usr or resume
> > partition.  The reason for this is that lvm2 only activates VGs that
> > are definitely needed, and there is no way to determine whether a
> > filesystem UUID or label refers to an LV (or which VG it's in).
> 
> Ok, but I don't understand why this can't be fixed. Why can't you
> convert the /dev/dm-* path from /proc/swaps into a /dev/mapper path when
> you generate the initramfs and store that instead?

Oh I see, I failed to parse 'automatic resume' as meaning automatic
selection of the resume device.

Does the attached patch fix this for you?

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein
diff --git a/hooks/resume b/hooks/resume
index 1032f7b19e77..3c0bef56a89f 100755
--- a/hooks/resume
+++ b/hooks/resume
@@ -46,11 +46,17 @@ else
 	# Try to autodetect the RESUME partition, using biggest swap?
 	resume_auto=$(grep ^/dev/ /proc/swaps | sort -rnk3 | head -n 1 | cut -d " " -f 1)
 	if [ -n "$resume_auto" ]; then
-		UUID=$(blkid -s UUID -o value "$resume_auto" || true)
+		if dm_name="$(dmsetup info -c --noheadings -o name "$resume_auto" 2>/dev/null)"; then
+			resume_auto_canon="/dev/mapper/$dm_name"
+		elif UUID=$(blkid -s UUID -o value "$resume_auto"); then
+			resume_auto_canon="UUID=$UUID"
+		else
+			resume_auto_canon=
+		fi
 		report_auto "The initramfs will attempt to resume from $resume_auto"
-		if [ -n "$UUID" ]; then
-			report_auto "(UUID=$UUID)"
-			resume_auto="UUID=$UUID"
+		if [ -n "$resume_auto_canon" ]; then
+			report_auto "($resume_auto_canon)"
+			resume_auto="$resume_auto_canon"
 		fi
 		report_auto "Set the RESUME variable to override this."
 	fi


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

Bug#883740: remind: Please change author's name from "David F. Skoll" to "Dianne Skoll" in /usr/share/doc/copyright

[Dianne Skoll]

Package: remind
Version: 03.01.15-1+b1
Severity: normal

Dear Maintainer,

Please fix debian/copyright in the source package so my name is correctly
shown as "Dianne Skoll" and not "David F. Skoll"

Thanks,

Dianne.

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/12 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages remind depends on:
ii  libc6  2.24-11+deb9u1

remind recommends no packages.

Versions of packages remind suggests:
pn  tkremind  
pn  wyrd  

Bug#883521: texlive-bin: FTBFS with poppler 0.61.1

[Norbert Preining]

> As soon as we know how to address 879801 a fix will be uploaded.

No need to wait for 879801. ICU is currently not uploaded to unstable so
this can be deferred a bit.

I have already prepared packages for this fix (poppler) only and will
upload soon after a round of testing (internet connection in China
permitting).

Best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#883738: systemd: RO Linux, systemd's link fail, links should not be created cross directory tree, use full paths

[Duncan Hare]

  From: Michael Biebl 
 To: Duncan Hare ; 883...@bugs.debian.org 
 Sent: Wednesday, December 6, 2017 4:49 PM
 Subject: Re: Bug#883738: systemd: RO Linux, systemd's link fail, links should 
not be created cross directory tree, use full paths
   
Control: tags -1 + moreinfo

Am 07.12.2017 um 01:41 schrieb Duncan Hare:
> Package: systemd
> Version: 232-25+deb9u1
> Severity: important
> 
> 
> 

This bug report is empty (again). Please describe your issues in much
more detail. Otherwise I'll close this bug report (again)

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
_
Errors based on fstab processing at startup:
This fstab works:
proc                    /proc                   proc    defaults                
        0 0/dev/mmcblk0p1          /boot                   vfat    defaults,ro  
                   0 2#PARTUUID=62bc0a1f-02   /                       ext4    
defaults,noatime                0 1192.168.1.10:/nfsroot/r.32.test /            
   nfs     defaults,rw                     0 0

When nounting the fs read only, and the var directory tree rw there are further 
entries, which appear tobe cross-diretory tree links.
It would be a good practice if one would:
- Refrain  symbolic cross tree links and use full file paths.- Choose a 
directory for systemd such as /var/systemd for dynamic data
proc                    /proc                   proc    defaults                
        0 0/dev/mmcblk0p1          /boot                   vfat    defaults,ro  
                   0 2#PARTUUID=62bc0a1f-02   /                       ext4    
defaults,noatime                0 1192.168.1.10:/nfsroot/r.32.test /            
   nfs     defaults,ro                     0 
0192.168.1.10:/nfsroot/b827eb/c23849 /var        nfs     defaults,rw            
         0 0
-- Logs begin at Thu 2016-11-03 10:16:43 PDT, end at Wed 2017-12-06 15:14:57 
PST. --Nov 03 10:16:43 b827ebc23849 systemd[1]: systemd 232 running in system 
mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP 
+LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD 
+IDN)Nov 03 10:16:43 b827ebc23849 systemd[1]: Detected architecture arm.Nov 03 
10:16:43 b827ebc23849 systemd[1]: Set hostname to .Nov 03 
10:16:43 b827ebc23849 systemd[1]: avahi-daemon.socket: Cannot add dependency 
job, ignoring: Unit avahi-daemon.socket is masked.Nov 03 10:16:43 b827ebc23849 
systemd[1]: avahi-daemon.service: Cannot add dependency job, ignoring: Unit 
avahi-daemon.service is masked.Nov 03 10:16:43 b827ebc23849 systemd[1]: 
var.mount: Found ordering cycle on var.mount/startNov 03 10:16:43 b827ebc23849 
systemd[1]: var.mount: Found dependency on network.target/startNov 03 10:16:43 
b827ebc23849 systemd[1]: var.mount: Found dependency on dhcpcd.service/startNov 
03 10:16:43 b827ebc23849 systemd[1]: var.mount: Found dependency on 
raspberrypi-net-mods.service/startNov 03 10:16:43 b827ebc23849 systemd[1]: 
var.mount: Found dependency on basic.target/startNov 03 10:16:43 b827ebc23849 
systemd-journald[114]: Journal startedNov 03 10:16:43 b827ebc23849 
systemd-journald[114]: Runtime journal 
(/run/log/journal/4edc017f487347deaf18f6407f2c0f5c) is 5.0M, max 40.0M, 35.0M 
free.Nov 03 10:16:43 b827ebc23849 systemd[1]: Started Create list of required 
static device nodes for the current kernel.Nov 03 10:16:43 b827ebc23849 
systemd[1]: Starting Create Static Device Nodes in /dev...Dec 06 14:56:47 
b827ebc23849 fake-hwclock[119]: Wed Dec  6 22:56:47 UTC 2017Dec 06 14:56:47 
b827ebc23849 systemd[1]: Time has been changedDec 06 14:56:47 b827ebc23849 
systemd[1]: Started Restore / save the current clock.Dec 06 14:56:47 
b827ebc23849 systemd[1]: Started Load Kernel Modules.Dec 06 14:56:47 
b827ebc23849 systemd[1]: Starting Apply Kernel Variables...Dec 06 14:56:47 
b827ebc23849 systemd[1]: Mounting Configuration File System...Dec 06 14:56:47 
b827ebc23849 systemd[1]: Mounted Configuration File System.Dec 06 14:56:47 
b827ebc23849 systemd[1]: Started Apply Kernel Variables.Dec 06 14:56:47 
b827ebc23849 systemd[1]: Started Remount Root and Kernel File Systems.Dec 06 
14:56:47 b827ebc23849 systemd[1]: Starting udev Coldplug all Devices...Dec 06 
14:56:47 b827ebc23849 systemd[1]: Started Create Static Device Nodes in 
/dev.Dec 06 14:56:47 b827ebc23849 systemd[1]: Starting udev Kernel Device 
Manager...Dec 06 14:56:47 b827ebc23849 systemd[1]: Started udev Coldplug all 
Devices.Dec 06 14:56:47 b827ebc23849 systemd[1]: Started udev Kernel Device 
Manager.Dec 06 14:56:47 b827ebc23849 systemd[1]: Started Set the console 
keyboard layout.Dec 06 14:56:47 b827ebc23849 systemd[1]: Reached target Local 
File Systems (Pre).Dec 06 14:56:47 b827ebc23849 systemd[1]: Starting Show 
Plymouth Boot Screen...Dec 06 14:56:47 b827ebc23849 systemd[1]: Received 
SIGRTMIN+20 from PID 180 

Bug#879801: ftbfs with icu from experimental

[Norbert Preining]

Hi Hilmar,

thanks for testing!

> XeTeX in the end fails due to missing symbols (last part of build log is

I don't see any libicu* in the linker run, though?

> hille@amd64-sid:~/...$ pkg-config --libs icu-uc
> -licuuc -licudata

I guess for security I would use
  pkg-config --libs icu-uc icu-io
?

> "-licuuc -licudata" are not handed over to the libtool command. So the
> options are lost somewhere.

Yes indeed, that is the problem. 

I need to investigate, too, after I'm back from by conference ..

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#868132: Needless build dependency on kdelibs5-dev

[Samuel Thibault]

Hello,

Alexander Volkov, on lun. 04 déc. 2017 13:50:59 +0300, wrote:
> Ah, sorry, nokde patch is really not enough.
> I maintain this package in AstraLinux and we don't support KDE4.

Just to make sure: do you support qt4? If not, you don't need qt-at-spi
at all: qt5 includes accessibility support already, qt-at-spi is only
for qt4.

> Here is our extended nokde patch.

Thanks, I have updated it in Debian.

Samuel

Bug#883738: systemd: RO Linux, systemd's link fail, links should not be created cross directory tree, use full paths

[Michael Biebl]

Control: tags -1 + moreinfo

Am 07.12.2017 um 01:41 schrieb Duncan Hare:
> Package: systemd
> Version: 232-25+deb9u1
> Severity: important
> 
> 
> 

This bug report is empty (again). Please describe your issues in much
more detail. Otherwise I'll close this bug report (again)

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#883739: cyphesis-cpp: README.Debian is out of date

[James Cowgill]

Package: cyphesis-cpp
Version: 0.6.2-2
Severity: normal

Hi,

When I attempted to test cyphesis-cpp, I tried to follow the
instructions in the README.Debian, but they seem to be out of date and
no longer work.

The username is now Cyphesis, not cyphesis (which was itself confusing).
You can't su to the cyphesis user because it is locked.
Running files in /etc/init.d directly should not be encouraged (use
invoke-rc.d instead).
The files /etc/cyphesis/*.xml don't exist.

James



signature.asc
Description: OpenPGP digital signature

Bug#883737: gtk2-engines-oxygen: Please don't depend on gtk2

[Jeremy Bicha]

From 5dfe778395410ef263884f781b74dce4ee4b3b45 Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Wed, 6 Dec 2017 19:36:26 -0500
Subject: [PATCH] Don't depend on libgtk2.0-0

so that themes can provide GTK+ 2 support
without requiring that GTK+ 2 be installed

Closes: #883737
---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index d0f71ac..96c59e2 100755
--- a/debian/rules
+++ b/debian/rules
@@ -16,4 +16,7 @@ override_dh_auto_configure:
 override_dh_makeshlibs:
 	dh_makeshlibs -X/usr/lib/$(DEB_HOST_MULTIARCH)/gtk-2.0
 
+override_dh_shlibdeps:
+	dh_shlibdeps -- -xlibgtk2.0-0
+
 .PHONY: override_dh_makeshlibs override_dh_auto_configure
-- 
2.14.1

Bug#883737: gtk2-engines-oxygen: Please don't depend on gtk2

[Jeremy Bicha]

Package: gtk2-engines-oxygen
Version: 1.4.6-1
Tags: patch

In my next email, I am submitting a patch to drop the gtk2 dependency
from this package. This is safe because the only thing that will
actually use the theme or theme engine is a gtk2 app which will
already depend on gtk2.

This is part of a larger effort to not install gtk2 by default. See
https://bugs.debian.org/883440

Thanks,
Jeremy Bicha

Bug#883735: Re: Bug#883735: initramfs-tools: automatic resume doesn't work for lvm swap partitions

[James Cowgill]

Hi,

On 07/12/17 00:06, Ben Hutchings wrote:
> On Wed, 2017-12-06 at 23:48 +, James Cowgill wrote:
>> Package: initramfs-tools
>> Version: 0.130
>> Severity: normal
>>
>> Hi,
>>
>> I had noticed this bug for quite a while now, but since I rarely turn my
>> machine off I left investigating what the problem was until now.
> [...]
>> Is it possible (and a good idea) to store the /dev/mapper path instead
>> of the blkid when the swap partition is on LVM?
>>
>> I managed to solve my specific issue by manually setting RESUME to the
>> correct /dev/mapper path.
>
> This is the correct way to refer to LVs used as root, /usr or resume
> partition.  The reason for this is that lvm2 only activates VGs that
> are definitely needed, and there is no way to determine whether a
> filesystem UUID or label refers to an LV (or which VG it's in).

Ok, but I don't understand why this can't be fixed. Why can't you
convert the /dev/dm-* path from /proc/swaps into a /dev/mapper path when
you generate the initramfs and store that instead?

James



signature.asc
Description: OpenPGP digital signature

Bug#883736: gtk2-engines-aurora: Please don't depend on gtk2

[Jeremy Bicha]

From 17c8ae6bbb1275cde12a77fc1e318f5ba1d0046e Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Wed, 6 Dec 2017 18:55:26 -0500
Subject: [PATCH 1/3] Update Vcs fields

---
 debian/control | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 4658e21..f066e4b 100644
--- a/debian/control
+++ b/debian/control
@@ -7,8 +7,8 @@ Build-Depends: debhelper (>= 9),
libgtk2.0-dev (>= 2.10.0)
 Standards-Version: 3.9.4
 Homepage: http://www.gnome-look.org/content/show.php?content=56438
-Vcs-Git: git://git.debian.org/git/collab-maint/gtk2-engines-aurora.git
-Vcs-Browser: http://git.debian.org/?p=collab-maint/gtk2-engines-aurora.git
+Vcs-Browser: https://anonscm.debian.org/git/collab-maint/gtk2-engines-aurora.git
+Vcs-Git: https://anonscm.debian.org/git/collab-maint/gtk2-engines-aurora.git
 
 Package: gtk2-engines-aurora
 Architecture: any
-- 
2.14.1

From 2b9f09d40b0d5e8a968cd55d8b4cb0bd724109d2 Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Wed, 6 Dec 2017 18:55:57 -0500
Subject: [PATCH 2/3] Bump debhelper compat to 10

---
 debian/compat  | 2 +-
 debian/control | 3 +--
 debian/rules   | 2 +-
 3 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/debian/compat b/debian/compat
index ec63514..f599e28 100644
--- a/debian/compat
+++ b/debian/compat
@@ -1 +1 @@
-9
+10
diff --git a/debian/control b/debian/control
index f066e4b..dd30bb1 100644
--- a/debian/control
+++ b/debian/control
@@ -2,8 +2,7 @@ Source: gtk2-engines-aurora
 Section: x11
 Priority: optional
 Maintainer: Chow Loong Jin 
-Build-Depends: debhelper (>= 9),
-   autotools-dev,
+Build-Depends: debhelper (>= 10),
libgtk2.0-dev (>= 2.10.0)
 Standards-Version: 3.9.4
 Homepage: http://www.gnome-look.org/content/show.php?content=56438
diff --git a/debian/rules b/debian/rules
index d1e0f0a..561abb3 100755
--- a/debian/rules
+++ b/debian/rules
@@ -22,6 +22,6 @@ override_dh_auto_install:
 	find debian/gtk2-engines-aurora -name '*.la' -delete
 
 %:
-	dh $@ --with=autotools_dev
+	dh $@
 
 .PHONY: get-orig-source
-- 
2.14.1

From 2302a592fc175f0e6c907bd3278867b96cbd4dc6 Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Wed, 6 Dec 2017 18:57:30 -0500
Subject: [PATCH 3/3] Don't depend on libgtk2.0-0

so that themes can provide GTK+ 2 support
without requiring that GTK+ 2 be installed

Closes: #883736
---
 debian/control | 3 +--
 debian/rules   | 3 +++
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index dd30bb1..366c6b3 100644
--- a/debian/control
+++ b/debian/control
@@ -11,8 +11,7 @@ Vcs-Git: https://anonscm.debian.org/git/collab-maint/gtk2-engines-aurora.git
 
 Package: gtk2-engines-aurora
 Architecture: any
-Depends: gtk2.0-binver-2.10.0,
- ${shlibs:Depends}, ${misc:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: Aurora gtk+-2.0 theme engine
  "Aurora" refers to the natural light displays in the sky in polar regions. This
  package contains the Aurora theme engine for the GTK+ toolkit, version 2.0.
diff --git a/debian/rules b/debian/rules
index 561abb3..272e2a9 100755
--- a/debian/rules
+++ b/debian/rules
@@ -21,6 +21,9 @@ override_dh_auto_install:
 	dh_auto_install
 	find debian/gtk2-engines-aurora -name '*.la' -delete
 
+override_dh_shlibdeps:
+	dh_shlibdeps -- -xlibgtk2.0-0
+
 %:
 	dh $@
 
-- 
2.14.1

Bug#883736: gtk2-engines-aurora: Please don't depend on gtk2

[Jeremy Bicha]

Package: gtk2-engines-aurora
Version: 1.5.1-4
Severity: minor
Tags: patch

In my next email, I am submitting a patch (and a few bonus patches) to
drop the gtk2 dependency from this package. This is safe because the
only thing that will actually use the theme or theme engine is a gtk2
app which will already depend on gtk2.

This is part of a larger effort to not install gtk2 by default. See
https://bugs.debian.org/883440

Thanks,
Jeremy Bicha

Bug#881730: grub2: Please clone debian/grub-ieee1275-bin.install.powerpc.in for ppc64

[Colin Watson]

On Thu, Dec 07, 2017 at 01:05:09AM +0100, John Paul Adrian Glaubitz wrote:
> I just noticed we might need to add powerpc and ppc64 in line 228 in
> debian/rules [1]:

Good point.  Committed, thanks.

-- 
Colin Watson   [cjwat...@debian.org]

Bug#881730: grub2: Please clone debian/grub-ieee1275-bin.install.powerpc.in for ppc64

[John Paul Adrian Glaubitz]

Hi Colin!

On 11/16/2017 10:12 AM, Colin Watson wrote:
>> But you're right, prep-bootdev should be present as well, also
>> on powerpc where we're also switching from Yaboot to GRUB. So,
>> please add it for both powerpc and ppc64.
> 
> OK, all done for my next upload.  Thanks.

I just noticed we might need to add powerpc and ppc64 in line 228 in
debian/rules [1]:

--- debian/rules.orig   2017-07-06 18:59:39.0 +0200
+++ debian/rules2017-12-07 01:03:49.931861163 +0100
@@ -225,7 +225,7 @@

 debian/stamps/build-grub-ieee1275: debian/stamps/configure-grub-ieee1275
dh_auto_build
-ifeq ($(DEB_HOST_ARCH_CPU),ppc64el)
+ifneq (,$(filter powerpc ppc64 ppc64el,$(DEB_HOST_ARCH_CPU)))
$(CC) $(HOST_CFLAGS) debian/prep-bootdev.c -o debian/prep-bootdev 
-lparted
 endif
touch $@

Otherwise prep-bootdev won't get build and the build might fail
if dh_install is configured to bail out for missing files.

Adrian

> [1] https://anonscm.debian.org/cgit/pkg-grub/grub.git/tree/debian/rules#n228

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#837513: obsolete

[Diederik de Haas]

On woensdag 6 december 2017 22:47:19 CET Wolfgang Rohdewald wrote:
> Why do I actively have to search for kajongg bug reports?
> 
> Is there some way you can setup automatic notification for kajongg bugs?

Hit the 'Subscribe' button on https://tracker.debian.org/pkg/kajongg

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

Bug#883735: initramfs-tools: automatic resume doesn't work for lvm swap partitions

[James Cowgill]

Package: initramfs-tools
Version: 0.130
Severity: normal

Hi,

I had noticed this bug for quite a while now, but since I rarely turn my
machine off I left investigating what the problem was until now.

Every time I boot my laptop, it prints a lot of messages like this,
before eventually giving up:

Begin: Waiting for suspend/resume device ...
Begin: Running /scripts/local-block ... done
[...]
Begin: Running /scripts/local-block ... done
Gave up waiting for suspend/resume device.

I traced this down to the swap device being on an LVM partition on my
laptop. The script which automatically determines which device to resume
from stores the blkid in the initramfs, but unfortunately the lvm2
local-block script does not know how to activate LVM partitions based on
blkid. This means the swap device is never created and the initramfs
will never be able to find it.

Is it possible (and a good idea) to store the /dev/mapper path instead
of the blkid when the swap partition is on LVM?

I managed to solve my specific issue by manually setting RESUME to the
correct /dev/mapper path.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#883734: libreoffice: Please consider hiding Math and Start Center .desktops

[Jeremy Bicha]

Source: libreoffice
Version: 1:6.0.0~beta1-2
Severity: wishlist

Test Case

>From GNOME Shell, open the Applications Overview and click the Show
Applications button to see the list of apps. Currently, LibreOffice
takes up a whole row on my computer (6 icons) which seems excessive
with GNOME Shell's current design.

Proposal
==
I suggest that we do like Fedora and hide the LibreOffice Start Center
and LibreOffice Math.

Instead of opening a Start Center, it makes more sense for a user to
just open the app they want directly.

I don't think users want to create a mathematical formula just to
create one, but to insert into a document so it makes more sense to
start Math from within the other app. (Obviously, with an app used by
as many people as LibreOffice, you can find a few people who use any
feature, but how common is it?)

If for some reason, you end up deciding to only make the change for
one of the two .desktops, please go ahead and do at least that.

Implementation
===
There are several ways to do this.

1. Add NoDisplay=true to both .desktops

2. Or, Add NotShowIn=GNOME; to both desktops

3. Or, Split the .desktop and associated AppStream metadata to a
separate binary package that can be optionally installed. Someone
would need to write the AppStream file for Start Center. This is
really nice because anyone can easily either have the .desktop
launcher or not without needing to manually edit any text files.

4. Or, Add an app folder for all the LibreOffice .desktops. This is
what Pop!_OS 17.10 did (Pop is a new Ubuntu flavor from System76). If
we wanted this, I think we'd want to implement this in the gnome-menus
package.

For reference, this issue was originally filed as
https://launchpad.net/bugs/1696250

Thanks,
Jeremy Bicha

Bug#883672: incorrect rendering of pdf using libpoppler68 backend

[Emilio Pozuelo Monfort]

Control: severity -1 normal

On 06/12/17 13:41, Adrian Bunk wrote:
> Control: reassign -1 src:poppler 0.57.0-2
> 
> Reassigning to the correct package.
> 
> On Wed, Dec 06, 2017 at 04:10:08PM +0530, Marcus Britanicus wrote:
>> Package: bugs.debian.org
>> Severity: serious
>>
>> All PDF viewers using libpoppler68 (0.57.0-2) backed do not render some PDFs
>> incorrectly. In most cases, some text is not rendered at all and symbols and
>> images only are rendered. This issue is seen in okular, evince, zathura,
>> qpdfview, and two custom pdf viewers (based on Qt4 and Qt5) written by me to
>> test issue. MuPDF and firefox do render the same PDF correctly.

You are going to have to attach or link to such a file. Also please try with
applications linked against poppler 0.61.1 (libpoppler72) first, which will soon
be available.

Cheers,
Emilio

Bug#883733: grep returns 0 even if there is no match

[Mathias Pietsch]

Package: grep
Version: 2.27-2
Severity: normal
Tags: upstream

when trying to test this famous regexp for matching non-prime numbers
(^1?$|^(11+?)\1+$) which works fine with 'grep -P', i wondered if it
also would work without the non-greedy quantifier so egrep or even
plain grep could use it, and found the following problem e.g., with the
prime number 13:

$ echo "1" | grep -E '^(11+)\1+$|^1?$' || echo prime
1

the expected output would have been 'prime' because '1'
doesn't match '^1?$' and is also no concatanation of two or more
'11', two or more '111', ... opposite to the orignal perl-style
non-greedy version, here the substrings should be tested for a match
beginning with the longest (13 x '1') down to the shortest ('11').

next i removed the empty line term from the regexp (i.e., the '?' from
the '^1?$' term):

$ echo "1" | grep -E '^(11+)\1+$|^1$' || echo prime
prime

now the result is correct. but since the input in not an empty line,
using '^(11+)\1+$|^1?$' or '^(11+)\1+$|^1$' should not make any
difference.

(making the empty line term a separate term '^(11+)\1+$|^1$|^$' doesn't
change anything. the same is true with using plain grep and
'^\(11\+\)\1\+$\|^1\?$' or '^\(11\+\)\1\+$\|^1$\|^$'.)

this bug also appears in the original upstream version 3.1
(http://ftp.gnu.org/gnu/grep/grep-3.1.tar.xz)


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

Kernel: Linux 4.9.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages grep depends on:
ii  dpkg  1.18.24
ii  install-info  6.3.0.dfsg.1-1+b2
ii  libc6 2.24-11+deb9u2
ii  libpcre3  2:8.39-3

grep recommends no packages.

Versions of packages grep suggests:
ii  libpcre3  2:8.39-3

-- no debconf information
--

_

Universitätsklinikum Hamburg-Eppendorf; Körperschaft des öffentlichen Rechts; 
Gerichtsstand: Hamburg | www.uke.de
Vorstandsmitglieder: Prof. Dr. Burkhard Göke (Vorsitzender), Prof. Dr. Dr. Uwe 
Koch-Gromus, Joachim Prölß, Martina Saurin (komm.)
_

SAVE PAPER - THINK BEFORE PRINTING

Bug#883022: Maybe we should rename this one?

[Lisandro Damián Nicanor Pérez Meyer]

I suffer from the same bug. But note that it tries to access /usr/local/sbin/ 
and that's why apparmor is complaining.

Maybe we should retitle this bug? Or should I open a new one?
Also I guess - moreinfo is in place.

Cheers!

-- 
2: Windows con las funciones que realiza se clasifica como:
* Un bug
Damian Nadales
http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#883725: transition: x265

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 06/12/17 21:58, Sebastian Ramacher wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> Control: forwarded -1 
> https://release.debian.org/transitions/html/auto-x265.html
> 
> It's this time of the year again. A new upstream release of x265 with a new
> SONAME bump has arrived. As usual, all reverse dependencies build fine against
> the new version.

Go ahead.

Emilio

Bug#883732: flask-migrate FTBFS: test failures

[Adrian Bunk]

Source: flask-migrate
Version: 2.1.1-1
Severity: serious

https://buildd.debian.org/status/fetch.php?pkg=flask-migrate=all=2.1.1-1=1512596402=0

...
I: pybuild base:184: python3.6 setup.py test 
running test
running egg_info
writing Flask_Migrate.egg-info/PKG-INFO
writing dependency_links to Flask_Migrate.egg-info/dependency_links.txt
writing entry points to Flask_Migrate.egg-info/entry_points.txt
writing requirements to Flask_Migrate.egg-info/requires.txt
writing top-level names to Flask_Migrate.egg-info/top_level.txt
reading manifest file 'Flask_Migrate.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
writing manifest file 'Flask_Migrate.egg-info/SOURCES.txt'
running build_ext
test_multidb_migrate_upgrade (tests.test_multidb_migrate_flaskcli.TestMigrate) 
... FAIL
test_alembic_version (tests.test_migrate_flaskcli.TestMigrate) ... ok
test_compare_type (tests.test_migrate_flaskcli.TestMigrate) ... FAIL
test_custom_directory (tests.test_migrate_flaskcli.TestMigrate) ... FAIL
test_migrate_upgrade (tests.test_migrate_flaskcli.TestMigrate) ... FAIL
test_multidb_migrate_upgrade (tests.test_multidb_migrate.TestMigrate) ... ok
test_alembic_version (tests.test_migrate.TestMigrate) ... ok
test_compare_type (tests.test_migrate.TestMigrate) ... ok
test_custom_directory (tests.test_migrate.TestMigrate) ... ok
test_migrate_upgrade (tests.test_migrate.TestMigrate) ... ok

==
FAIL: test_multidb_migrate_upgrade 
(tests.test_multidb_migrate_flaskcli.TestMigrate)
--
Traceback (most recent call last):
  File "/<>/tests/test_multidb_migrate_flaskcli.py", line 45, in 
test_multidb_migrate_upgrade
self.assertTrue(s == 0)
AssertionError: False is not true

==
FAIL: test_compare_type (tests.test_migrate_flaskcli.TestMigrate)
--
Traceback (most recent call last):
  File "/<>/tests/test_migrate_flaskcli.py", line 80, in 
test_compare_type
self.assertTrue(s == 0)
AssertionError: False is not true

==
FAIL: test_custom_directory (tests.test_migrate_flaskcli.TestMigrate)
--
Traceback (most recent call last):
  File "/<>/tests/test_migrate_flaskcli.py", line 68, in 
test_custom_directory
self.assertTrue(s == 0)
AssertionError: False is not true

==
FAIL: test_migrate_upgrade (tests.test_migrate_flaskcli.TestMigrate)
--
Traceback (most recent call last):
  File "/<>/tests/test_migrate_flaskcli.py", line 56, in 
test_migrate_upgrade
self.assertTrue(s == 0)
AssertionError: False is not true

--
Ran 10 tests in 19.206s

FAILED (failures=4)
Test failed: 
error: Test failed: 
E: pybuild pybuild:283: test: plugin distutils failed with: exit code=1: 
python3.6 setup.py test 
dh_auto_test: pybuild --test -i python{version} -p 3.6 returned exit code 13
debian/rules:10: recipe for target 'build-indep' failed
make: *** [build-indep] Error 25

Bug#826428: ITA: gcompris-qt -- Educational games for small children - Qt rewrite

[Simon Quigley]

Hello,

On 12/06/2017 08:18 AM, Sébastien Villemot wrote:
> Any progress on this?

Yep, I've been busy, but I've gotten to the point where I just have to
do a copyright sweep and it should be good.

Here's a link:
https://anonscm.debian.org/cgit/pkg-kde/qt-extras/gcompris-qt.git

> Also I think it would make sense to merge the gcompris and gcompris-qt
> source packages (the distinction is no longer relevant).

Sure, you're more than welcome to make any commits to that repo that you
feel would be relevant.

Thanks for checking in,
-- 
Simon Quigley
tsimo...@ubuntu.com
tsimonq2 on freenode and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4



signature.asc
Description: OpenPGP digital signature

Bug#883716: wrong patch, take the one upstream

[Thomas Goirand]

Hi,

After discussing with upstream, this is what should be done, and that's
deterministic:

https://bitbucket.org/zzzeek/changelog/commits/b06dfdeef1b5f26b5504b45168ad9c8c44b8bde9

Cheers,

Thomas Goirand (zigo)

Bug#878203: AA breaks libvirt when running with kernel 4.13

[Martin Pitt]

Control: tag -1 patch -unreproducible

Michael Biebl [2017-10-23 18:22 +0200]:
> This is what I get when I *shut down* a VM in virt-manager:
> $ journalctl -f | grep DENIED
> Okt 23 18:20:31 pluto audit[8603]: AVC apparmor="DENIED"
> operation="open" profile="libvirt-4e5a8920-a2a1-4c6b-b7f1-528c20878cdd"
> name="/proc/718/cmdline" pid=8603 comm="qemu-system-x86"
> requested_mask="r" denied_mask="r" fsuid=114 ouid=0
> Okt 23 18:20:31 pluto kernel: audit: type=1400 audit(1508775631.299:55):
> apparmor="DENIED" operation="open"
> profile="libvirt-4e5a8920-a2a1-4c6b-b7f1-528c20878cdd"
> name="/proc/718/cmdline" pid=8603 comm="qemu-system-x86"
> requested_mask="r" denied_mask="r" fsuid=114 ouid=0

I see something similar in the Cockpit integration tests, e. g. [1]

Error: audit: type=1400 audit(1512597807.993:50): apparmor="DENIED" 
operation="open" profile="libvirt-538b45d5-e9a6-4598-a140-ef5963e70191" 
name="/proc/521/cmdline" pid=828 comm="qemu-system-x86" requested_mask="r" 
denied_mask="r" fsuid=64055 ouid=0

Other reporters confirmed that it's relatively harmless, the Ubuntu package
already got a fix [2], and apparently several others reproduced it as well, so
updating tags.

Thanks,

Martin

[1] 
http://209.132.184.41/logs/pull-8219-20171206-214646-d2e9e141-verify-debian-testing/log.html#2
[2] 
https://git.launchpad.net/~libvirt-maintainers/ubuntu/+source/libvirt/commit/?h=ubuntu/artful=38ccdf8fe9a9d5


signature.asc
Description: PGP signature

Bug#881893: xwayland: FatalError() when I open the closed Laptop Lid in accident (not always triggered)

[toby cabot]

Package: xwayland
Version: 2:1.19.5-1
Followup-For: Bug #881893

Dear Maintainer,

I see the same crash on a desktop machine when I activate the screen
lock, or when I log back in from the screen lock, not sure which.  The
screen locks fine and appears to log in fine but all of the apps that
I ran are gone and there's a core file in my home directory.

It doesn't happen if I lock the screen and log back in very quickly
but if I wait for a few minutes then it does happen.

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

Kernel: Linux 4.14.0-1-amd64 (SMP w/4 CPU cores)
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)

Versions of packages xwayland depends on:
ii  libaudit1   1:2.8.1-2
ii  libbsd0 0.8.6-3
ii  libc6   2.25-3
ii  libdrm2 2.4.88-1
ii  libegl1 1.0.0-1
ii  libepoxy0   1.4.3-1
ii  libgbm1 17.2.5-1
ii  libgcrypt20 1.8.1-4
ii  libgl1  1.0.0-1
ii  libpixman-1-0   0.34.0-1
ii  libselinux1 2.7-2
ii  libsystemd0 235-3
ii  libwayland-client0  1.14.0-1+b1
ii  libxau6 1:1.0.8-1+b2
ii  libxdmcp6   1:1.1.2-3
ii  libxfont2   1:2.0.1-4
ii  libxshmfence1   1.2-1+b2
ii  xserver-common  2:1.19.5-1

xwayland recommends no packages.

xwayland suggests no packages.

-- no debconf information

Bug#883731: audacious: Debian packaging has incorrect license

[John Lindgren]

Package: audacious
Version: 3.9-2
Severity: serious

Per Debian policy 2.3:

"Every package must be accompanied by a verbatim copy of its copyright
information and distribution license in the file 
/usr/share/doc/package/copyright
(see Copyright information for further details)."

The file /usr/share/doc/audacious/copyright shipped in the Debian package
is out of date and does not match the current Audacious license (GPL3 vs.
BSD 2-clause).

Worse, the Debian package patches out[1] the upstream license file which
is normally installed under /usr/share/audacious/COPYING and visible in
the "About" window when running Audacious.

You are currently distributing Audacious in violation both of our license
and of Debian's own policy.  Please include the original upstream license,
verbatim, in the Debian package, or stop distributing Audacious.

Thank you,

John Lindgren
Audacious maintainer

[1] 
https://sources.debian.org/patches/audacious/3.9-2/use-system-licenses.patch/

Bug#845232: Maybe add README.Debian

[Lisandro Damián Nicanor Pérez Meyer]

On 6 December 2017 at 18:59, Lisandro Damián Nicanor Pérez Meyer
 wrote:
> Package: apparmor-notify
> Version: 2.11.1-3
> Followup-For: Bug #845232
>
> I had the same issue.
>
> = What did I do
>
> At first I found the .desktop file and run the
> command by hand. I learnt that I would nee dto read /var/log/kern.log,
> so I added my user to the adm group.
>
> After that I restarted my session and learn that I would need to be in
> the sudo group.
>
> = What I recommend
>
> Adding a README.Debian file explaining this details. That's the first
> thing I tried to find when I noticed aa-notify was not working.

Obviously I sent this mail without noticing the replies in the bug.
Yes, a README.Debian would be just great, although I would suggest to
at very least explain the sudo thing in there, because a user might
not have internet access.

Bug#883730: Remove invalid email from man page

[積丹尼 Dan Jacobson]

Package: at
Version: 3.1.20-3.1
Severity: minor
File: /usr/share/man/man1/at.1.gz

The man page lists i...@rz.uni-karlsruhe.de.

This gives
: host scc-mailin-cn-01.scc.kit.edu[141.52.226.150]
said: 550 Unrouteable address (in reply to RCPT TO command)

Bug#183583: a queue implies order

[積丹尼 Dan Jacobson]

Still consider ordering the results, in one way or another.
I mean that is what "queues" are about, order.

Bug#883729: glibc: CVE-2017-17426: malloc returns pointer from tcache_get when should return NULL

[Salvatore Bonaccorso]

Source: glibc
Version: 2.26-0experimental1
Severity: important
Tags: patch security upstream fixed-upstream
Forwarded: https://sourceware.org/bugzilla/show_bug.cgi?id=22375

Hi,

the following vulnerability was published for glibc (only affecting
experimental)

CVE-2017-17426[0]:
| The malloc function in the GNU C Library (aka glibc or libc6) 2.26
| could return a memory block that is too small if an attempt is made to
| allocate an object whose size is close to SIZE_MAX, potentially leading
| to a subsequent heap overflow. This occurs because the per-thread cache
| (aka tcache) feature enables a code path that lacks an integer overflow
| check.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-17426
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-17426
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=22375

Regards,
Salvatore

Bug#845232: Maybe add README.Debian

[Lisandro Damián Nicanor Pérez Meyer]

Package: apparmor-notify
Version: 2.11.1-3
Followup-For: Bug #845232

I had the same issue. 

= What did I do

At first I found the .desktop file and run the
command by hand. I learnt that I would nee dto read /var/log/kern.log,
so I added my user to the adm group.

After that I restarted my session and learn that I would need to be in
the sudo group.

= What I recommend

Adding a README.Debian file explaining this details. That's the first
thing I tried to find when I noticed aa-notify was not working.

Thanks!!

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

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

Versions of packages apparmor-notify depends on:
ii  libapparmor-perl  2.11.1-3
ii  libnotify-bin 0.7.7-2
ii  perl  5.26.1-3

apparmor-notify recommends no packages.

apparmor-notify suggests no packages.

-- no debconf information

Bug#883717: Oops, correct patch

[Tristan Seligmann]

On Wed, 6 Dec 2017 at 23:52 Thomas Goirand  wrote:

> The OpenStack team doesn't need this package anymore, and it'd be nice
> to have it within the DPMT instead. Would you like to do that work?
>

I'm still happy to adopt the package; it looks like upstream does not
actually support Python 3 and rather another fork is needed for this for
Electrum, but it would make sense to maintain both packages in the same
place.


> FYI, the new Git repo URL is currently:
> http://anonscm.debian.org/git/openstack/python/python-jsonrpclib.git


Thanks!

Bug#883717: Oops, correct patch

[Thomas Goirand]

On 12/06/2017 08:39 PM, Tristan Seligmann wrote:
> Oops. Actually correct patch attached this time.

Hi,

The OpenStack team doesn't need this package anymore, and it'd be nice
to have it within the DPMT instead. Would you like to do that work?
You'd be welcome to set yourself as an uploader too, and of course, add
Python 3 support to the package.

Your thoughts?

FYI, the new Git repo URL is currently:
http://anonscm.debian.org/git/openstack/python/python-jsonrpclib.git

And like all things in /git/openstack/python, it's to be moved to DPMT.

Cheers,

Thomas Goirand (zigo)

Bug#837513: obsolete

[Wolfgang Rohdewald]

version 16.04 is really old. Buster is on 16.08,
tomorrow 17.12 will be tagged.

I am upstream, and I will not fix such old
versions, so you may just as well close this bug.

Why do I actively have to search for kajongg bug reports?

Is there some way you can setup automatic notification for kajongg bugs?

Bug#183583: mention non-order on atq man page

[積丹尼 Dan Jacobson]

found 183583 3.1.20-3.1
thanks
The atq man page should say that the results are unordered.

The user might accidentally get ordered results one time and then build
a program with this assumption.

Thus it is important that you warn on the man page.

Bug#883521: texlive-bin: FTBFS with poppler 0.61.1

[Hilmar Preuße]

severity 883521 serious
tags 883521 +pending +patch
stop

On 04.12.2017 19:22, Emilio Pozuelo Monfort wrote:

Hi,

> Your package fails to build with poppler 0.61.1 from experimental. This
> version introduces some API changes to the Object class which cause
> some problems to a few packages. In some cases upstream has already
> adapted to these changes, so it'd be good if you can backport a
> patch to ease the transition.
> 
Emilio has uploaded poppler 0.61.1 to unstable so this bug is rc now.

As soon as we know how to address 879801 a fix will be uploaded.

H.
-- 
http://www.hilmar-preusse.de.vu/   #206401 http://counter.li.org

Bug#864965: current version does not need python-kde4

[Wolfgang Rohdewald]

Buster is on kajongg 16.08, tomorrow KDE 17.12 will be tagged.

Please consider updating.

The depencendy of python-kde4 has gone.

17.12 is ported to python3, python2 is not supported anymore.

17.12 is ported to qt5, qt4 is not supported anymore.

New dependency is twisted 16.6.0 but Buster already has 17.9.0

17.12 comes with a lot of cleanups, removing many bugs,
especially about unicode.

Bug#883724: mono FTBFS on ia64

[Jo Shields]

https://github.com/mono/mono/commit/e5552e6905fb7f3403e1d164e168eb2dc2a561f9

IA64 is dead upstream.


On 06/12/17 15:53, Jason Duerstock wrote:

Package: mono
Severity: normal
Tags: patch

Dear Maintainer,

Mono fails to build from source on ia64.  At least on initial glance, this 
appears to be because it does
not recognize libatomic-ops-dev on the platform.

See attached patch.

-- System Information:
Debian Release: buster/sid
Architecture: ia64

Kernel: Linux 3.14-0.bpo.2-mckinley (SMP w/2 CPU cores)
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: sysvinit (via /sbin/init)

Bug#826994: Updated Patch

[Chris Dos]

I've modified the diff to patch against 0.7.3-3 and it patches fine.  I also 
applied a fix for the zed binary location.  The /etc/zfs/zfs-functions was
looking for it in /sbin when it was actually in /usr/sbin.  I googled but could 
not find what the equivalent @sbindir@ for /usr/sbin would be so I just hard
coded /usr/sbin/zed.  The /etc/init.d/zfs-zed init script now starts zed just 
fine.

The patch compiles against Sid without problems and it seems to boot fine.

However, the base 0.7.3-3 package won't compile on Jessie so I cannot even test 
the patch.
I receive an error about missing files:

Error:
chmod a-x 
/var/temp/sdeb/zfs_0.7.3-3/zfs-linux-0.7.3/debian/tmp/etc/zfs/zfs-functions
chmod a-x /var/temp/sdeb/zfs_0.7.3-3/zfs-linux-0.7.3/debian/tmp/etc/default/zfs
make[1]: Leaving directory '/var/temp/sdeb/zfs_0.7.3-3/zfs-linux-0.7.3'
   debian/rules override_dh_install
make[1]: Entering directory '/var/temp/sdeb/zfs_0.7.3-3/zfs-linux-0.7.3'
find . -name lib*.la -delete
dh_install --fail-missing
dh_install: usr/share/zfs/zfs-helpers.sh exists in debian/tmp but is not 
installed to anywhere
dh_install: etc/zfs/vdev_id.conf.multipath.example exists in debian/tmp but is 
not installed to anywhere
dh_install: etc/zfs/vdev_id.conf.sas_direct.example exists in debian/tmp but is 
not installed to anywhere
dh_install: etc/zfs/vdev_id.conf.alias.example exists in debian/tmp but is not 
installed to anywhere
dh_install: etc/zfs/vdev_id.conf.sas_switch.example exists in debian/tmp but is 
not installed to anywhere
dh_install: etc/init.d/zfs-mount exists in debian/tmp but is not installed to 
anywhere
dh_install: etc/init.d/zfs-zed exists in debian/tmp but is not installed to 
anywhere
dh_install: etc/init.d/zfs-import exists in debian/tmp but is not installed to 
anywhere
dh_install: etc/init.d/zfs-share exists in debian/tmp but is not installed to 
anywhere
dh_install: etc/sudoers.d/zfs exists in debian/tmp but is not installed to 
anywhere
dh_install: missing files, aborting
debian/rules:175: recipe for target 'override_dh_install' failed
make[1]: *** [override_dh_install] Error 2
make[1]: Leaving directory '/var/temp/sdeb/zfs_0.7.3-3/zfs-linux-0.7.3'
debian/rules:34: recipe for target 'binary' failed
make: *** [binary] Error 2
dpkg-buildpackage: error: debian/rules binary gave error exit status 2

I'm still trying to track down what missing files it is looking for between 
Jessie and Sid.

    Chris
diff --git a/debian/rules b/debian/rules
index f445b58..ecb9448 100755
--- a/debian/rules
+++ b/debian/rules
@@ -112,6 +112,31 @@ override_dh_auto_install:
 	chmod a-x $(CURDIR)/debian/tmp/etc/zfs/zfs-functions
 	chmod a-x $(CURDIR)/debian/tmp/etc/default/zfs
 
+override_dh_installinit:
+	@# Install the /etc/init.d/zfs-import script.
+	dh_installinit -pzfsutils-linux --onlyscripts --name=zfs-import \
+	--no-restart-on-upgrade --no-start
+
+	@# Install the /etc/init.d/zfs-mount script.
+	dh_installinit -pzfsutils-linux --onlyscripts --name=zfs-mount \
+	--no-restart-on-upgrade --no-start
+
+	@# Install the /etc/init.d/zfs-share script.
+	# Disabled, as it does not start on install due to zfs-zed not
+	# being installed yet, and zfs-zed depends on zfsutils-linux.
+	# Error report:
+	# insserv: Service zfs-zed has to be enabled to start service zfs-share
+	# insserv: exiting now!
+	#dh_installinit -pzfsutils-linux --onlyscripts --name=zfs-share \
+	#  --no-restart-on-upgrade --no-start
+
+	@# Add a dummy (link to /dev/null) for zfs-import.service
+	ln -s /dev/null $(CURDIR)/debian/zfsutils-linux/lib/systemd/system/zfs-import.service
+
+	@# Install the ZED init file.
+	dh_installinit -pzfs-zed --onlyscripts --name=zfs-zed \
+	--no-restart-on-upgrade --no-start
+
 override_dh_dkms:
	dh_dkms -V $(DEB_VERSION_UPSTREAM)
 
diff --git a/debian/zfs-zed.install b/debian/zfs-zed.install
index a84fff7..f5a4a4e 100644
--- a/debian/zfs-zed.install
+++ b/debian/zfs-zed.install
@@ -1,4 +1,5 @@
 usr/sbin/zed
+etc/init.d/zfs-zed
 etc/zfs/zed.d/*
 usr/lib/*/zfs/zed.d/*
 lib/systemd/system/zfs-zed.service
diff --git a/debian/zfsutils-linux.install b/debian/zfsutils-linux.install
index b355ec4..183aed0 100644
--- a/debian/zfsutils-linux.install
+++ b/debian/zfsutils-linux.install
@@ -9,6 +9,8 @@ usr/lib/modules-load.d/ lib/
 lib/udev/
 etc/default/zfs
 etc/zfs/zfs-functions
+etc/init.d/zfs-import
+etc/init.d/zfs-mount
 etc/zfs/zpool.d/
 usr/lib/zfs-linux/zpool.d/
 sbin/fsck.zfs
diff --git a/etc/init.d/zfs-zed.in b/etc/init.d/zfs-zed.in
index d0086ee..a5bb2e3 100755
--- a/etc/init.d/zfs-zed.in
+++ b/etc/init.d/zfs-zed.in
@@ -10,6 +10,8 @@
 # Provides:  zfs-zed
 # Required-Start:zfs-mount
 # Required-Stop: zfs-mount
+# Required-Start:$local_fs zfs-mount
+# Required-Stop: $local_fs zfs-mount
 # Default-Start: 2 3 4 5
 # Default-Stop:  0 1 6
 # X-Stop-After:  zfs-share
diff --git a/etc/init.d/zfs-functions.in b/etc/init.d/zfs-functions.in
index 97f2ea0..589cb6d 100644
--- a/etc/init.d/zfs-functions.in

Bug#883728: designate: please make the build reproducible

[Chris Lamb]

Source: designate
Version: 1:5.0.0-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

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

Patch attached. :)

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


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/install-missing-files.patch2017-12-06 
21:11:41.986932617 +
--- b/debian/patches/install-missing-files.patch2017-12-06 
21:21:04.175034871 +
@@ -3,8 +3,8 @@
 Forwarded: not-needed
 Last-Update: 2016-03-25
 
 /dev/null  2016-03-15 18:18:48.046095192 +0100
-+++ b/MANIFEST.in  2016-03-25 11:24:52.877037638 +0100
+--- /dev/null
 designate-5.0.0/MANIFEST.in
 @@ -0,0 +1,5 @@
 +recursive-include designate/tests *
 +recursive-include designate/pool_manager *
--- a/debian/patches/reproducible_build.patch   1970-01-01 01:00:00.0 
+0100
--- b/debian/patches/reproducible_build.patch   2017-12-06 21:19:17.986261217 
+
@@ -0,0 +1,35 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2017-12-06
+
+--- designate-5.0.0.orig/designate/__init__.py
 designate-5.0.0/designate/__init__.py
+@@ -32,8 +32,7 @@ designate_opts = [
+help='Name of this node'),
+ cfg.StrOpt(
+ 'pybasedir',
+-default=os.path.abspath(os.path.join(os.path.dirname(__file__),
+- '../')),
++default='',
+ help='Directory where the designate python module is installed'
+ ),
+ cfg.StrOpt('state-path', default='/var/lib/designate',
+--- designate-5.0.0.orig/designate/utils.py
 designate-5.0.0/designate/utils.py
+@@ -86,11 +86,13 @@ def find_config(config_path):
+ :param config_path: Full or relative path to the config.
+ :returns: List of config paths
+ """
++pybasedir = cfg.CONF.pybasedir or \
++os.path.abspath(os.path.join(os.path.dirname(__file__), '../'))
+ possible_locations = [
+ config_path,
+-os.path.join(cfg.CONF.pybasedir, "etc", "designate", config_path),
+-os.path.join(cfg.CONF.pybasedir, "etc", config_path),
+-os.path.join(cfg.CONF.pybasedir, config_path),
++os.path.join(pybasedir, "etc", "designate", config_path),
++os.path.join(pybasedir, "etc", config_path),
++os.path.join(pybasedir, config_path),
+ "/etc/designate/%s" % config_path,
+ ]
+ 
--- a/debian/patches/series 2017-12-06 21:11:41.986932617 +
--- b/debian/patches/series 2017-12-06 21:18:41.773997294 +
@@ -1 +1,2 @@
 install-missing-files.patch
+reproducible_build.patch

Bug#883727: kajongg: man page shows unsupported options

[Wolfgang Rohdewald]

Package: kajongg
Version: 4:16.12.3-0ubuntu1
Severity: normal

Dear Maintainer,

man kajongg

most options under GENERIC, QT and KDE are not supported, the only exception 
being --help.

I found this bug while browsing sources.debian.org, so it is also
valid for version 16.08 which you currently install


-- System Information:
Debian Release: stretch/sid
  APT prefers artful-updates
  APT policy: (500, 'artful-updates'), (500, 'artful-security'), (500, 
'artful'), (100, 'artful-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages kajongg depends on:
ii  kdegames-mahjongg-data  4:14.12.3-3
ii  libqt4-sql-sqlite   4:4.8.7+dfsg-7ubuntu1
ii  python  2.7.14-2ubuntu1
ii  python-kde4 4:4.14.2-0ubuntu8
ii  python-qt4-sql  4.11.4+dfsg-2build2
ii  python-twisted-core 16.6.0-2ubuntu3
ii  vorbis-tools1.4.0-10

Versions of packages kajongg recommends:
ii  khelpcenter  4:17.04.3-0ubuntu1

kajongg suggests no packages.

-- no debconf information

Bug#878498: snakemake FTBFS with Python 3.6 as default

[Andreas Tille]

control: tags -1 help

Hi,

I've upgraded snakemake in Git to latest upstream but its featuring the
same issue.  I'm pretty sure you Python people know a simple answer for
this issue.

Any help would be welcome

  Andreas.

On Sat, Oct 14, 2017 at 05:33:22AM +0300, Adrian Bunk wrote:
> Source: snakemake
> Version: 3.10.0-1
> Severity: serious
> Tags: buster sid
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/snakemake.html
> 
> ...
> ==
> ERROR: Failure: Exception (snakemake not in PATH. For testing, install 
> snakemake with 'pip install -e .'. You should do this in a separate 
> environment (via conda or virtualenv).)
> --
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/nose/failure.py", line 39, in runTest
> raise self.exc_val.with_traceback(self.tb)
>   File "/usr/lib/python3/dist-packages/nose/loader.py", line 418, in 
> loadTestsFromName
> addr.filename, addr.module)
>   File "/usr/lib/python3/dist-packages/nose/importer.py", line 47, in 
> importFromPath
> return self.importFromDir(dir_path, fqname)
>   File "/usr/lib/python3/dist-packages/nose/importer.py", line 94, in 
> importFromDir
> mod = load_module(part_fqname, fh, filename, desc)
>   File "/usr/lib/python3.6/imp.py", line 235, in load_module
> return load_source(name, filename, file)
>   File "/usr/lib/python3.6/imp.py", line 172, in load_source
> module = _load(spec)
>   File "", line 684, in _load
>   File "", line 665, in _load_unlocked
>   File "", line 678, in exec_module
>   File "", line 219, in _call_with_frames_removed
>   File 
> "/build/1st/snakemake-3.10.0/.pybuild/pythonX.Y_3.6/build/tests/tests.py", 
> line 21, in 
> raise Exception("snakemake not in PATH. For testing, install snakemake 
> with "
> Exception: snakemake not in PATH. For testing, install snakemake with 'pip 
> install -e .'. You should do this in a separate environment (via conda or 
> virtualenv).
> 
> --
> Ran 4 tests in 0.535s
> 
> FAILED (errors=1)
> E: pybuild pybuild:283: test: plugin distutils failed with: exit code=1: cd 
> /build/1st/snakemake-3.10.0/.pybuild/pythonX.Y_3.6/build; python3.6 -m nose 
> tests
> dh_auto_test: pybuild --test --test-nose -i python{version} -p 3.6 returned 
> exit code 13
> debian/rules:18: recipe for target 'build' failed
> make: *** [build] Error 25
> 
> 
> 
> The problem is the the following line in debian/rules:
> 
>   export PATH:=$(CURDIR)/.pybuild/pythonX.Y_3.5/build/bin:$(PATH)
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
> 

-- 
http://fam-tille.de

Bug#845498: /usr/bin/fpc-3.0.0: Provide cross-compilers

[Paul Gevers]

Hi Abou,

On 06-12-17 10:26, Abou Al Montacir wrote:
> So for example
> /usr/lib/i386-linux-gnu/fpc/3.0.4/units/fpmkunit
> It is now quite easy to do this after my recent changes.
> 
> Is that OK or do we need to do it other way, maybe in a simpler manner?

For whatever it is worth, that sounds correct to me.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#881941: Please consider to let live-build add file /.disk/mkisofs to the ISO

[Daniel Reichelt]

On 12/06/2017 09:04 PM, Thomas Schmitt wrote:
> Raphaël, are you aware that the change in live-build
>   
> https://anonscm.debian.org/cgit/debian-live/live-build.git/commit/?id=ff71712590a809d0f7ba680e787a9f091ed853b2
> did not work and caused
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881941
> ?

He already merged the patch in live-build's git [1]



> Depending on when "binary.sh" gets finally executed
> this architectural change might cause undesired effects.

Do you have a conrete example of when the patch fails?



>  DISK_MKISOFS="$(echo "xorriso -as mkisofs ${XORRISO_OPTIONS} -o ${IMAGE} 
> binary" | sed -e s"/'/'"'"'"'"'"'"'/g")"

That's illegible, difficult to understand and therefore impractical to
maintain.


I moved the HERE-document back to binary_iso because the generated
script initially was supposed to be a wrapper script around xorriso and
I didn't see a specific need for the creation of the cmdline file to be
wrapped as well. If that change causes trouble, I'd deem it much more
practical to move the generation back into the wrapper script, sticking
with the HERE-document.


Cheers
Daniel

(CC'ing #881941)


[1]
https://anonscm.debian.org/cgit/debian-live/live-build.git/commit/?id=9f3e5fe8d968f79fbd1f4c60fb6b020758fe8510



signature.asc
Description: OpenPGP digital signature

Bug#883726: RFS: budgie-extras/0.3.0-1 [ITP]

[foss.freedom]

Package: sponsorship-requests
Severity:  wishlist

  Dear mentors,

  I am looking for a sponsor for my package "budgie-extras"

 * Package name: budgie-extras
   Version : 0.3.0-1
   Upstream Author : Ubuntu Budgie Developers
 * URL : https://github.com/ubuntubudgie/budgie-extras
 * License : GPL-3+
   Section : misc

  It builds those binary packages:

budgie-countdown-applet - Applet providing a countdown capability
on the Budgie Desktop
 budgie-hotcorners-applet - Applet providing hotcorners capabilities
for the Budgie Desktop
 budgie-keyboard-autoswitch-applet - Applet adding the ability to set
a different keyboard layout per
 budgie-previews-applet - Applet providing window previews
capabilities for the Budgie Desk
 budgie-quicknote-applet - Applet providing simple notes capability
for the Budgie Desktop
 budgie-showtime-applet - Applet displaying date and time on the Budgie Desktop
 budgie-window-mover-applet - Applet allows moving windows between
workspaces for the Budgie De
 budgie-workspace-overview-applet - Applet providing quick access to
workspaces for the Budgie Deskto
 budgie-workspace-wallpaper-applet - Applet providing per workspace wallpaper

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

  https://mentors.debian.net/package/budgie-extras


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

dget -x 
https://mentors.debian.net/debian/pool/main/b/budgie-extras/budgie-extras_0.3.0-1.dsc

Notes:

Budgie Desktop is the flagship desktop system for Solus. Budgie
Desktop can be extended through applets - LibPeas based applications
that provide extra capabilities not available through the core
product.

For this sponsorship request, myself as the project lead of the
GNU/Linux distro Ubuntu Budgie have been working with my team to
develop a series of additional Budgie Desktop applets that we believe
give the end user additional optional capabilities to enhance their
user experience.  These applets are distro agnostic and we believe
would benefit Debian users of the Budgie Desktop.

Viability: The Ubuntu Budgie team have a direct interest in developing
and maintaining these applets.  These are already available to Ubuntu
Budgie users via its backports PPA.

Maintainership: I maintain all budgie related packages for both Debian
and Ubuntu.

Packaging:

We have made each applet available as individual binary packages -
this allows users the flexibility to choose specific applets rather
than having to install everything.

For this release (and moving forward) I have signed with my 4K based
key. The package was verfied through a `uscan -v --force-download` and
unpacked & built & uploaded to mentors

check-all-the-things has been run on the source and where appropriate
we have tidied up both the source and debian packaging.

lintian -i -I --pedantic on the built changes file has been run and is
lintian free.

We include a pep8 based autopkgtest that has been tested on an schroot
for both unstable and also Ubuntu's bionic series.  The test has
passed successfully.

The package itself runs with an autotest -  the same pep8 test for
autopkgtests (see tools/run_pep8)

Testing:

The minimal XFCE based Debian Buster was upgraded to unstable and
budgie-desktop was installed.

The package was built and each individual binary package was installed
and tested to confirm that they work correctly - this importantly
caught all the necessary runtime dependencies that have been captured
in debian/control

  Changes since the last upload:

 * Initial Release (Closes: #883720)

  Regards,
   David Mohammed

Bug#882697: stretch-pu: package apparmor/2.11.0-3+deb9u1

[Adam D. Barratt]

On Wed, 2017-12-06 at 19:13 +0100, intrigeri wrote:
> intrigeri:
> > At first glance this very much looks like a bug in the custom
> > kernel
> > you're using.
> 
> According to #883703 this bug affects the mainline Linux kernel as
> well so this stretch-pu may break as many use cases at it'll repair
> when running Linux 4.13+ on Stretch :/
> 
> Dear release team, how can we revert this s-p-u? Should I upload
> 2.11.0-3+deb9u2 that reverts to what we had in 2.11.0-3?

I don't think there's a particular need for that currently (and it
wouldn't get accepted until after the point release anyway). We'll ask
ftp-master not to include the package during the point release at the
weekend and in the meantime affected users still have the possibility
to downgrade the package to its current stable version.

Regards,

Adam

Bug#883668: thunderbird: Can't start thunderbird through an ssh tunnel

[Christophe Lohr]

Le 06/12/2017 à 13:49, Carsten Schoenert a écrit :
>> I can't run thunderbird through an ssh tunnel.
> You have AppArmor installed, please deactivate the AppArmor profile of
> thunderbird or remove the installed apparmor package to check the
> existence of this behavior. 

I looked at the logs:
    # tail -f /var/log/syslog | grep 'DENIED'

Unfortunately I get no messages, despite thunderbird fails to start.


However, you'r right!   The issue is now fixed with:
    # aa-disable /etc/apparmor.d/usr.bin.thunderbird

Best regards
Christophe

Bug#883725: transition: x265

[Sebastian Ramacher]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Control: forwarded -1 https://release.debian.org/transitions/html/auto-x265.html

It's this time of the year again. A new upstream release of x265 with a new
SONAME bump has arrived. As usual, all reverse dependencies build fine against
the new version.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#883724: mono FTBFS on ia64

[Jason Duerstock]

Package: mono
Severity: normal
Tags: patch

Dear Maintainer,

Mono fails to build from source on ia64.  At least on initial glance, this 
appears to be because it does
not recognize libatomic-ops-dev on the platform.

See attached patch.

-- System Information:
Debian Release: buster/sid
Architecture: ia64

Kernel: Linux 3.14-0.bpo.2-mckinley (SMP w/2 CPU cores)
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: sysvinit (via /sbin/init)
--- configure.ac.orig   2017-12-06 15:41:00.654825611 -0500
+++ configure.ac2017-12-06 15:41:17.758945149 -0500
@@ -3194,7 +3194,7 @@
 dnl Use GCC atomic ops if they work on the target.
 if test x$GCC = "xyes"; then
case $TARGET in
-   X86 | AMD64 | ARM | ARM64 | POWERPC | POWERPC64 | MIPS | S390X | SPARC 
| SPARC64)
+   X86 | AMD64 | ARM | ARM64 | POWERPC | POWERPC64 | MIPS | S390X | SPARC 
| SPARC64 | IA64)
AC_DEFINE(USE_GCC_ATOMIC_OPS, 1, [...])
;;
esac

Bug#883722: release-notes: document transitions from revelation to other password managers

[Olivier Berger]

Package: release-notes
Severity: normal

Dear Maintainer,

May I suggest to document the fact that revelation is (likely) going to
vanish from Debian, leaving users with a potential problem retrieving
"locked" password databases.

I think keepass2 offers a replacement solution, in that it can import a
passwords XML file previously exported from revelation.

I tried to get advice from revelation's maintainer, with no luck so far
(see #790601).

I think it would be safer to warn users in advance, provided they have a
look at the release notes before upgrading to buster.

Hope this helps,

Best regards.

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

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

Bug#882372: Wheezy update of ohcount?

[Peter Degen-Portnoy]

Dear Raphaël Hertzog;

Peter Degen-Portnoy of the Black Duck Open Hub development team here.  We 
maintain Ohcount and are aware of the defect. An issue has been opened in the 
GitHub repository for Ohcount: 
https://github.com/blackducksoftware/ohcount/issues/57

Work is currently underway to address the defect.

Sincerely,


Peter Degen-Portnoy


---

Black Duck Software

Peter Degen-Portnoy

Software Engineering Manager / Open Hub Team Lead
Black Duck Software
Black Duck Open Hub



On Thu, 23 Nov 2017 11:40:11 +0100 Raphael Hertzog wrote:
> Hello Sylvestre,
>
> The Debian LTS team would like to fix the security issues which are
> currently open in the Wheezy version of ohcount:
> https://security-tracker.debian.org/tracker/CVE-2017-16926
>
> Would you like to take care of this yourself?
>
> I tried to file an upstream bug as a first step (since there is not patch
> available yet) but there is no upstream bug tracker apparently... and last
> upstream activity dates back to 2010. I pinged the project owner on
> sourceforge with its integrated messaging feature but I'm not sure that I
> will get any reply back.
>
> Do you have contacts with the upstream authors ?
>
> In any case, if you want to handle the wheezy upload, then
> please follow the workflow we have defined here:
> https://wiki.debian.org/LTS/Development
>
> If that workflow is a burden to you, feel free to just prepare an
> updated source package and send it to debian-...@lists.debian.org
> (via a debdiff, or with an URL pointing to the source package,
> or even with a pointer to your packaging repository), and the members
> of the LTS team will take care of the rest. Indicate clearly whether you
> have tested the updated package or not.
>
> If you don't want to take care of this update, it's not a problem, we
> will do our best with your package. Just let us know whether you would
> like to review and/or test the updated package before it gets released.
>
> You can also opt-out from receiving future similar emails in your
> answer and then the LTS Team will take care of ohcount updates
> for the LTS releases.
>
> Thank you very much.
>
> Raphaël Hertzog,
> on behalf of the Debian LTS team.
>
> PS: A member of the LTS team might start working on this update at
> any point in time. You can verify whether someone is registered
> on this update in this file:
> https://anonscm.debian.org/viewvc/secure-testing/data/dla-needed.txt?view=markup
> --
> Raphaël Hertzog ◈ Debian Developer
>
> Support Debian LTS: https://www.freexian.com/services/debian-lts.html
> Learn to master Debian: https://debian-handbook.info/get/
>
>

Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)

[Aurelien Jarno]

On 2017-12-06 19:39, Julien Aubin wrote:
> Weird... this time I re-upgraded libc6 and things work fine... looks like
> something wrong went during the install. And I cannot reproduce the issue
> anymore... :'( WTF ???

Hmm, a bug has been introduced in libc6 version 2.24-11+deb9u2, which in
some conditions leave the /etc/ld.so.nohwcap file instead of removing it
just after the upgrade (see bug#883394). One of the condition is to have
libc6-i686 installed (while it can be safely removed), which seems to be
your case.

I consider this bug harmless as it should not deactivate anything now
that the default libc is already i686 optimized. Also I don't see how it
could trigger the issue you described. Anyway better be safe than sorry,
could you please try to create this file with "touch /etc/ld.so.nohwcap"
as root and see if it makes the issue to reappear? Once the test is done
you can then remove it.

Thanks,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#883723: openstack-deploy: undocumented

[Wouter Verhelst]

Package: openstack-deploy
Version: 0.15
Severity: minor

After running "openstack-deploy all-in-one", I find that I do have
something resembling a working openstack installation. Thanks for that!

Unfortunately, however, after all that has happened, one sits there with
a "now what" feeling:

- The installation asks for a number of things. What do these things
  mean? (just hitting "enter" to everything *seems* to work, except for
  the "keystone endpoint IP, for which I just entered 127.0.0.1 in this
  test environment).
- Something is running, but where? (localhost:80, it turns out, with
  non-SSL HTTP redirected to its SSL version)
- After fiddling with apache SSL settings so that those work (this was
  on a pristine VM to test with), I need to log on. What with? (the
  value of RC_KEYSTONE_ADMINPASS in /root/osinstallrc, it turns out)

I realize that the goal of openstack-deploy is probably to support
openstack-tempest-ci rather than to support users; but since it's
packaged in Debian, and since it seems to have several modes, all of
which should support larger installations too, it seems like a prime
candidate for "look at this if you want to build your own cloud"

If only it were a bit better documented.

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

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

Versions of packages openstack-deploy depends on:
ii  ipcalc 0.41-5
pn  openstack-pkg-tools
pn  python-keystoneclient  

openstack-deploy recommends no packages.

openstack-deploy suggests no packages.

Bug#883721: ITP: helpman -- quick & easy access to 4000+ manuals / guides / tutorials

[Nathan SR]

Package: wnpp
Severity: wishlist
Owner: Nathan SR 

* Package name: helpman
  Version : 1.0
  Upstream Author :
* URL : https://sourceforge.net/projects/helpman-1/
* License : GPL
  Programming Lang: Python
  Description : quick & easy access to 4000+ manuals / guides /
tutorials

Helpman provides a classified access to the manuals,
installed by user / system programs, automatically.
It also supports typing a program / manual name,
in the Select Manual: text / combo box directly,
to display it quickly. Error Messages will be shown
below, if a manual is not found.

The Manual Type list box, shows sections 1 to 8,
useful for specific display of a version of the
manual. Say for example, if you see, CRON(8) in
a manual, it means the CRON manual in the
8th section. So a user should choose appropriately.

Please click the info button for more details.

Bug#790601: revelation: depends on python-gnome2 which is deprecated

[Olivier Berger]

Hi.

Just for the records, it's keepass2, not keypass2, sorry.

Best regards,

Olivier Berger  writes:

> Responding to myself,
>
> On Sun, Dec 03, 2017 at 03:50:57PM +0100, Olivier Berger wrote:
>> 
>> I think that it would be great to have some migration options to other 
>> password managers.
>> 
>> Would you have any suggestion ?
>> 
>
> It seems that keypass2 could be an option, importing from the Revelation XML 
> (which can be exported from Revelation before upgrade/switch).
>
> Hope this helps,
> -- 
> Olivier BERGER 
> http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
> Ingenieur Recherche - Dept INF
> Institut Mines-Telecom, Telecom SudParis, Evry (France)
>
>

-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

Bug#883621: CVE-2017-17051 not fixed?

[Salvatore Bonaccorso]

Control: reopen -1
Control: found -1 2:16.0.3-1
Control: forwarded -1 https://launchpad.net/bugs/1732976

Hi Thomas,

CVE-2017-17051 was not fixed afaics, only the regression which was
introduced by OSSA-2017-005.

See http://www.openwall.com/lists/oss-security/2017/12/05/5 for
CVE-2017-17051.

Could you relook?

Regards,
Salvatore

Bug#883719: lintian: false positive spelling-error-in-description (duplicate word) on 'ORA (ORA Recursive Acronym)'

[Chris Lamb]

Hi Andreas,

> I thought these should be fixed since 2.5.59 which closed #822504 with
> "Don't warn about duplicate words when separated by punctuation.", but I
> still get
> 
> W: foo: spelling-error-in-description FOO FOO (duplicate word) FOO

Thanks for the report.

Am just brain-dumping for a future contributor here. A Lintian-based
testcase that triggers this for me is:

  --- a/t/tests/description-general/debian/debian/control.in
  +++ b/t/tests/description-general/debian/debian/control.in
  @@ -155,3 +155,5 @@ Description: test for spelling - debian developement
Some more stuff about this Debian test package. (dummy)
.
Duplicate: Duplicate (false positive due to colon)
  + .
  + FOO (FOO Owsome Object) is a recursive acronym.

We currently strip out all parenthesis prior to running the spellcheck
which is the cause of this problem:

  
https://anonscm.debian.org/git/lintian/lintian.git/tree/lib/Lintian/Check.pm#n287

I'm a little hesitant to simply remove that, obviously.


Regards,

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

Bug#883720: ITP: budgie-extras -- applets providing optional extra user capabilities

[foss.freedom]

Package: wnpp
Severity: wishlist

Owner: David Mohammed 

Package name   : budgie-extras
Version  : 0.3.0
Upstream Author: Ubuntu Budgie Developers
URL  : https://github.com/UbuntuBudgie/budgie-extras
License : GPL-3+
Programming Lang : Python3
Description: additional Budgie Desktop enhancements to the
user experience

Bug#883583: [Debian GNUstep maintainers] Bug#883583: gnustep-gui-runtime: GSCUPS bundle crashes applications on CUPS client hosts

[Eric Heintzmann]

Le 05/12/2017 à 14:38, Yavor Doganov a écrit :
> Unfortunately stable is also affected because gnustep-gui/0.25.0-4 was
> rebuilt for the imagemagick transition in January 2017 and was built
> against recent cups which has the function deprecated.
>
> Eric, do we want to fix this now or we could delay it for 0.26?  Do we
> want to fix it in stretch?
>
Let's wait this week-end for the new -gui release.

For stretch, I would like to fix this bug. (I just need to check if I
have uploading rights on stable)

Bug#883615: sarah,your recent order31716173

[Sarah Bell]

I havent made any purchases

On Dec 6, 2017 10:50 AM, "Thank you"  wrote:

Please confirm receipt

































































Okay found the culprit : libc6 Issue appears with the one from 9.3 but not
9.2 2017-12-06 11:56 GMT+01:00 Julien Aubin : > > > Le 6 déc. 2017 11:51,
"Luca Boccassi" a écrit : > > On Wed, 2017-12-06 at 11:37 +0100, Andreas
Beckmann wrote: > > On 2017-12-06 10:53, Julien Aubin wrote: > > > Okay I
will try it. Could you please provide me the build guide and > > > install
> > > guide ? > > > > From README.source: > > > > Building "bleeding edge"
from SVN for users > > > > As new upstream versions of the proprietary
driver are released, > > upload > > might not happen immediately. This
might be for various reasons, > > including > > waiting for new binary
packages to clear the NEW queue. > > Users wishing to try to build new
version locally can follow the > > instructions on the Debian wiki: > > > >
https://wiki.debian.org/NvidiaGraphicsDrivers#Building_newer_rele > >
ases_from_SVN > > > > WARNING: these will most likely be work in progress,
and the > > final upload > > may be different and may not support clean
upgrades from/to the > > versions > > uploaded in the archive. > > > > > >
In your case, it is branches/384-stretch-backports. > > > > Please let us
know about any issues you encounter with these > > instructions. > > > > >
> Andreas > > 375.82 has been in sid/buster for months now, it's very
strange that it > wasn't reported before - a GLX crash is not a subtle
problem that might > get overlooked > > > Yup but not sure people use a
Pascal GPU. What is granted is that the > issue appeared after last update
to stretch-proposed-updates, but only on > my box with a Pascal GPU. > > I
suspect the code paths used are not the same per GPU... > > If you wish I
can send you my sources.list, my /etc and the list of > installed packages.
I do not have weird things, only additional repos for > marginal packages
like deb-multimedia or virtualbox. > > > -- > Kind regards, > Luca Boccassi
> > >

Bug#881703: Please package Electrum 3.0.2 -- updates after segwit softfork

[Tristan Seligmann]

Hi all,

I am currently doing final testing on an Electrum 3.0.2 package for Debian;
however I will need to wait for python3-jsonrpclib-pelix to go through NEW
before I can upload (upstream is using a jsonrpclib fork to get Python 3
support) so it may still be a little while before this lands in unstable.

Bug#883719: lintian: false positive spelling-error-in-description (duplicate word) on 'ORA (ORA Recursive Acronym)'

[Andreas Beckmann]

Package: lintian
Version: 2.5.61
Severity: normal

Hi,

I thought these should be fixed since 2.5.59 which closed #822504 with
"Don't warn about duplicate words when separated by punctuation.", but I
still get

W: foo: spelling-error-in-description FOO FOO (duplicate word) FOO

on this package:

Package: foo
Architecture: all
Description: short description
 FOO (FOO Owsome Object) is a recursive acronym.


Andreas