Bug#919641: transition: readline (7 -> 8)

[Matthias Klose]

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

readline is in experimental for some time, the changes are API compatible, and
afaics there are no build failures caused by readline. I filed some RC issues
for unrelated ftbfs.

A handful of packages need sourceful uploads, like d-shlibs and readline-perl6.

Bug#919640: mu-editor: Fail to start because matlotlib==2.2.2 is not found

[Petter Reinholdtsen]

Package: mu-editor
Version: 1.0.1+dfsg-1

Running mu-editor in Buster today result in a DistributionNotFound
exception stating that "The 'matplotlib==2.2.2' distribution was not
found and is required by mu-editor".

Checking dependencies, I notice python3-matplotlib version 3.0.2-2 is
installed.

-- 
Happy hacking
Petter Reinholdtsen

Bug#919207: squashfs-tools: Please apply frag_deflator_thread removal patch

[GCS]

Control: reopen -1

Hi Chris and Alexander,

On Sun, Jan 13, 2019 at 8:33 PM Chris Lamb  wrote:
> Re.  and similar, please find
> attached the following patch that I have rebased against
> squashfs-tools 4.3-9:
>
> From: Alexander Couzens 
> Date: Tue, 8 Jan 2019 10:57:00 +0100
> Subject: remove frag_deflator_thread
[...]
 I've applied this and uploaded to -10, but it breaks lzo compression.
You can test it with the following:
$ mksquashfs dir/with/some/files/ files.shfs -noappend -no-recovery
-no-xattrs -no-exports -comp lzo
It segfaults or print 'double free or corrupt' but always fail soon.
May you check this patch please?

Thanks,
Laszlo/GCS

Bug#916400: lzo compression is broken in squashfs-tools 1:4.3-10

[GCS]

Control: tags -1 +confirmed

On Thu, Jan 17, 2019 at 11:03 AM Jordi Pujol  wrote:
> after updating squashfs-tools,
>
> # mksquashfs /tmp/live-net-remaster-e1jKOJ/chroot/
> 00filesystem.squashfs.new2  -noappend -no-recovery -no-xattrs
> -no-exports -comp lzo
> Parallel mksquashfs: Using 8 processors
> Creating 4.0 filesystem on 00filesystem.squashfs.new2, block size 131072.
> [/
> ] 8/78279   0%Segmentation
> fault
 Indeed, it's buggy ATM caused by the remove frag_deflator_thread
patch. Once fixed, would you volunteer for a package checking before
its upload?

Cheers,
Laszlo/GCS

Bug#918027: needs d3 v5

[Alexandre Rossi]

upstream uses d3 v5 and d3.arc appeared in d3 v4. So the webui seems
to require libjs-d3 >=4 or perhaps libjs-d3 >=5.
Then there's #839961 (only d3 v3 is in Debian).

downloading d3 latest and:
$ sudo cp d3.min.js /usr/share/rspamd/www/js/lib/d3.min.js
fixes the problem.

Also the current packaging does not use symlinks for the d3
dependency, because the webui does not seem to support symlinks.
Instead, it copies the js files at install time. This means that
updates of js deps would not be taken into account when updated. I
suggest using upstream files instead which is not ideal but means used
versions are reproductible and not function of when the package was
installed.

Alex

Bug#919639: libsasl2-dev: man pages are (gzipped) empty files

[Ryan Tandy]

Package: libsasl2-dev
Version: 2.1.27~rc8-1
Severity: important

Dear Maintainer,

The man pages shipped in libsasl2-dev are all zero-byte files, gzipped.

>From the amd64 build log:

https://buildd.debian.org/status/fetch.php?pkg=cyrus-sasl2&arch=amd64&ver=2.1.27~rc8-1&stamp=1538479977&raw=1

touch man/.sphinx-build.stamp
warning: missing documentation dependencies. man pages will be empty
touch man/sasl.3
[...]

and indeed the man pages are just empty files:

-rw-r--r-- root/root20 2018-10-02 08:05 ./usr/share/man/man3/sasl.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_authorize_t.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_auxprop.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_auxprop_getctx.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_auxprop_request.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_callbacks.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_canon_user_t.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_chalprompt_t.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_checkapop.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_checkpass.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_client_init.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_client_new.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_client_start.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_client_step.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_decode.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_dispose.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_done.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_encode.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_encodev.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_errdetail.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_errors.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_errstring.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_getconfpath_t.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_getopt_t.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_getpath_t.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_getprop.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_getrealm_t.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_getsecret_t.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_getsimple_t.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_global_listmech.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_idle.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_listmech.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_log_t.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_server_init.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_server_new.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_server_start.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_server_step.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_server_userdb_checkpass_t.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_server_userdb_setpass_t.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_setpass.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_setprop.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_user_exists.3.gz
-rw-r--r-- root/root20 2018-10-02 08:05 
./usr/share/man/man3/sasl_verifyfile_t.3.gz

Bug#908783: ITP: firmware-microbit-micropython -- MicroPython runtime for the BBC micro:bit

[Petter Reinholdtsen]

Hi.  Any news on getting the micropython firmware into Debian?

I notice the code is waiting in
https://salsa.debian.org/python-team/applications/firmware-microbit-micropython 
>
and its build dependencies entered unstable recently.  Any hope to get
it into testing in time for Buster?

-- 
Happy hacking
Petter Reinholdtsen

Bug#919637: RFS: elinks/0.13~20190114-1 [ITA]

[أحمد المحمودي]

Package: sponsorship-requests
Severity: normal

Hello,

 I am adopting elinks. I have worked on the fork that Moritz has 
 mentioned: https://github.com/rkd77/felinks
 I have emailed previous upstream maintainers,asking them if they are 
 still maintaining elinks. Two emails bounced back, and I still got no 
 reply from the others.
 Anyways, this upload is targetting experimental, as I have enabled 
 several features like Bittorrent and Javascript.

This upload fixes the following bugs
#740981 (normal): elinks: doesn't check if hostname matches certificate's 
CN/SAN (CWE-297)
#757631 (normal): elinks: HTML5 source element display missing
#797931 (normal): elinks: Does not support SSL rehandshakes
#797934 (wishlist): elinks: Support for SSL authentication using client certs
#797968 (wishlist): elinks: Please add support for TLS SNI
#856852 (normal): cert_verify is disabled by default
#866015 (important): elinks: SSL error with some websites
#879539 (minor): elinks: contains code related to gnutls pgp supprt
#891575 (important): elinks: CVE-2012-6709
#917406 (normal): ITA: elinks -- advanced text-mode WWW browser

Last changelog entry is:
elinks (0.13~20190114-1) experimental; urgency=medium

  * New upstream release (Closes: #891575, #797931, #797934, #757631,
#866015, #797968, #740981, #865852)
  * Add git-buildpackage conf file
  * Refreshed patches & removed patches that were includes upstream.
Removed patches:
08-drop-deprecated-gnutls-functions.diff (Closes: #879539)
08_524696_fix_imdb_urls.diff
09-Switch-to-use-lua-5.1.diff
  * Add libgcrypt20-dev to build deps
  * Re-added 14_debug_disable_Werror.diff to enable development versions debug
support
  * Added 16_POST_BUFFER_SIZE.diff patch which to enable  uploading large files
over https:// connections.
  * Add ascii-replacement-utf8-console.diff patch to print ASCII replacement
for characters not found in current codepage in utf8 mode
  * Enable LZMA support
  * Enable BitTorrent
  * Enable NNTP Support
  * Enable Unicode combining characters support
  * Enable EX mode support
  * Enable SpiderMonkey support
  * Enable terminfo support
  * Build documentation
  * Build with libev
  * Bumped to compat level 12.
No need to have dh-autoreconf, autotools-dev from build deps
Also no need to explicitly call the respective sequences in rules
  * Remove old upstream gpg key.
  * Remove whitespaces
  * Renamed elinks.config to elinks.conf, old name confused build scrips
  * debian/rules: Override dh_installexamples to exclude .gitignore
  * Add typos.diff patch to fix spelling mistakes
  * debian/control:
+ Replace Conflicts with Breaks+Replaces
+ Update standards version to 4.3.0
+ New maintainer (Closes: #917406)
+ Add Vcs-* fields
  * Add upstream metadata
  * Switch to DEP-5 copyright format
  * Disable pristine-tar, since we are getting the release from upstream git


There is one lintian warning:
W: elinks-data: manpage-has-errors-from-man usr/share/man/man5/elinks.conf.5.gz 
1166: warning [p 14, 7.0i]: can't break line

The package is on: g...@salsa.debian.org:aelmahmoudy-guest/elinks.git , 
felinks branch

To access further information about this package, please visit the following 
URL:
https://mentors.debian.net/package/elinks

Alternatively, one can download the package with dget using this command:
  dget -x 
https://mentors.debian.net/debian/pool/main/e/elinks/elinks_0.13~20190114-1.dsc

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#919638: solr-tomcat: Permission problems after update to tomcat9

[Michael Welsh Duggan]

Package: solr-tomcat
Version: 3.6.2+dfsg-16
Severity: important

Dear Maintainer,

After updating tomcat to tomcat9 and solr-tomcat to 3.6.2+dfsg-16, it
seems to be having problems writing to its index directory.  The
problem surfaced when using dovecot to look up messages.  Attached is
the error from the catalina log.

/var/lib/solr/index does look like it has the right permissions:
/var/lib/solr/data and /var/lib/solr/data/index are owned by
tomcat:tomcat, permissions 770, and tomcat seems to be running as user
tomcat.  I have verified that I can write to the directory as root,
and as such it's not on a read-only filesystem.  I have no idea why it
fails to write the lock file.


17-Jan-2019 23:27:24.199 INFO [http-nio-8080-exec-6] 
org.apache.solr.update.processor.LogUpdateProcessor.finish 
{add=[173976/7e5de009f991854df72612cf7b9c/md5i]} 0 1002
17-Jan-2019 23:27:24.200 SEVERE [http-nio-8080-exec-6] 
org.apache.solr.common.SolrException.log 
org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: 
NativeFSLock@/var/lib/solr/data/index/write.lock: 
java.io.FileNotFoundException: /var/lib/solr/data/index/write.lock (Read-only 
file system)
at org.apache.lucene.store.Lock.obtain(Lock.java:84)
at org.apache.lucene.index.IndexWriter.(IndexWriter.java:1098)
at 
org.apache.solr.update.SolrIndexWriter.(SolrIndexWriter.java:84)
at 
org.apache.solr.update.UpdateHandler.createMainIndexWriter(UpdateHandler.java:101)
at 
org.apache.solr.update.DirectUpdateHandler2.openWriter(DirectUpdateHandler2.java:171)
at 
org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:219)
at 
org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:61)
at 
org.apache.solr.update.processor.LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:115)
at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:157)
at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:79)
at 
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:58)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1376)
at 
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:365)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:260)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:490)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
at 
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:668)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
at 
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:408)
at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:834)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1417)
at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.io.FileNotFoundException: /var/lib/solr/data/index/write.lock 
(Read-only file system)
at java.base/java.io.RandomAccessFile.open0(Native Method)
at java.base/java.io.RandomAccessFile.open(RandomAccessFile.java:345)
at java.base/java.io.RandomAccessFile.(RandomAccessFile.java:259)
at java.base/java.io.RandomAccessFile.(RandomAccessFile.java:214)
at 
org.apache.lucene.store.NativeFSLock.obtain(NativeFSLockFactory.java:203)
at org.apache.lucene.store.Lock.obtain(Lock.java:95)
... 33 more

17-Jan-2019 23:27:24.201 INFO [http-nio-8080-exec-6] 
org.apache.solr.core.SolrCore.execute [] webapp=/solr path=/update params={} 
sta

Bug#919636: pelican: "make publish" with Atom feed yields "CRITICAL: TypeError: not all arguments converted during string formatting"

[Daniel Kahn Gillmor]

Package: pelican
Version: 4.0.1+dfsg-1
Severity: normal

With a simple pelican installation with Atom category feeds enabled,
running "make publish" yields:

0 dkg@alice:/tmp/cdtemp.afhJme$ make publish
pelican /tmp/cdtemp.afhJme/content -o /tmp/cdtemp.afhJme/output -s 
/tmp/cdtemp.afhJme/publishconf.py 
CRITICAL: TypeError: not all arguments converted during string formatting
make: *** [Makefile:77: publish] Error 1
2 dkg@alice:/tmp/cdtemp.afhJme$ 


As a workaround, i can bypass this error either by removing this line
from publishconf.py:

CATEGORY_FEED_ATOM = 'feeds/{slug}.atom.xml'

or by changing "CATEGORY_FEED_ATOM|format(category.slug)" to either
"CATEGORY_FEED_ATOM" or "category.slug" in
/usr/lib/python3/dist-packages/pelican/themes/simple/templates/base.html

so the problem has something to do with that jinja format string, but
i don't understand pelican's use of jinja well enough to pinpoint
it. Maybe it's just that jinja isn't processing the |format(xxx)
filter for some reason?

Below is the output of "make DEBUG=1 publish" showing the jinja
traceback to the error:

0 dkg@alice:/tmp/cdtemp.afhJme$ make DEBUG=1 publish
pelican /tmp/cdtemp.afhJme/content -o /tmp/cdtemp.afhJme/output -s 
/tmp/cdtemp.afhJme/publishconf.py  -D
DEBUG: Pelican version: 4.0.1
DEBUG: Python version: 3.7.2
DEBUG: Temporarily adding PLUGIN_PATHS to system path
DEBUG: Restoring system path
DEBUG: Template list: ['!simple/archives.html', '!simple/article.html', 
'!simple/author.html', '!simple/authors.html', '!simple/base.html', 
'!simple/categories.html', '!simple/category.html', '!simple/gosquared.html', 
'!simple/index.html', '!simple/page.html', '!simple/pagination.html', 
'!simple/period_archives.html', '!simple/tag.html', '!simple/tags.html', 
'!simple/translations.html', '!theme/archives.html', '!theme/article.html', 
'!theme/author.html', '!theme/authors.html', '!theme/base.html', 
'!theme/categories.html', '!theme/category.html', '!theme/gosquared.html', 
'!theme/index.html', '!theme/page.html', '!theme/pagination.html', 
'!theme/period_archives.html', '!theme/tag.html', '!theme/tags.html', 
'!theme/translations.html', 'archives.html', 'article.html', 'author.html', 
'authors.html', 'base.html', 'categories.html', 'category.html', 
'gosquared.html', 'index.html', 'page.html', 'pagination.html', 
'period_archives.html', 'tag.html', 'tags.html', 'translations.html']
DEBUG: Deleted directory /tmp/cdtemp.afhJme/output/feeds
DEBUG: Read file test.md -> Article
DEBUG: Signal article_generator_preread.send(ArticlesGenerator)
DEBUG: Successfuly imported extension module "markdown.extensions.codehilite".
DEBUG: Successfully loaded extension 
"markdown.extensions.codehilite.CodeHiliteExtension".
DEBUG: Successfuly imported extension module "markdown.extensions.extra".
DEBUG: Successfully loaded extension 
"markdown.extensions.fenced_code.FencedCodeExtension".
DEBUG: Successfully loaded extension 
"markdown.extensions.footnotes.FootnoteExtension".
DEBUG: Successfully loaded extension 
"markdown.extensions.attr_list.AttrListExtension".
DEBUG: Successfully loaded extension 
"markdown.extensions.def_list.DefListExtension".
DEBUG: Successfully loaded extension 
"markdown.extensions.tables.TableExtension".
DEBUG: Successfully loaded extension "markdown.extensions.abbr.AbbrExtension".
DEBUG: Successfully loaded extension "markdown.extensions.extra.ExtraExtension".
DEBUG: Successfuly imported extension module "markdown.extensions.meta".
DEBUG: Successfully loaded extension "markdown.extensions.meta.MetaExtension".
DEBUG: Signal article_generator_context.send(ArticlesGenerator, )
-> Writing /tmp/cdtemp.afhJme/output/feeds/all.atom.xml
-> Writing /tmp/cdtemp.afhJme/output/feeds/misc.atom.xml
CRITICAL: TypeError: not all arguments converted during string formatting
Traceback (most recent call last):
  File "/usr/bin/pelican", line 11, in 
load_entry_point('pelican==4.0.1', 'console_scripts', 'pelican')()
  File "/usr/lib/python3/dist-packages/pelican/__init__.py", line 623, in main
pelican.run()
  File "/usr/lib/python3/dist-packages/pelican/__init__.py", line 190, in run
p.generate_output(writer)
  File "/usr/lib/python3/dist-packages/pelican/generators.py", line 689, in 
generate_output
self.generate_pages(writer)
  File "/usr/lib/python3/dist-packages/pelican/generators.py", line 598, in 
generate_pages
self.generate_articles(write)
  File "/usr/lib/python3/dist-packages/pelican/generators.py", line 470, in 
generate_articles
url=article.url, blog=True)
  File "/usr/lib/python3/dist-packages/pelican/writers.py", line 254, in 
write_file
override_output)
  File "/usr/lib/python3/dist-packages/pelican/writers.py", line 186, in 
_write_file
output = template.render(localcontext)
  File "/usr/lib/python3/dist-packages/jinja2/asyncsupport.py", line 76, in 
render
return original_render(self, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 1008, in 
render
return 

Bug#919635: RM: node-groove -- ROM; FTBFS + unmaintained upstream

[Xavier Guimard]

Package: ftp.debian.org
Severity: normal

Hi all,

Please remove node-groove from unstable/testing:
 - node-groove isn't compatible with nodejs ≥ 10
 - upstream seems abandoned (no response to bugs for more than one year)
 - reverse dependencies:
   - groovebasin is orphaned
   - multimedia-broadcasting recommends groovebasin
   - multimedia-players recommends groovebasin
 - https://qa.debian.org/popcon.php?package=node-groove shows that
   node-groove is useless

At least, could you unlock nodejs migration ? This package is now the
only remaining FTBFS "regression" that blocks this migration.

Cheers,
Xavier

Bug#919634: wiki.debian.org: https://wiki.debian.org/ down

[Howard Johnson]

Package: wiki.debian.org
Severity: grave
Justification: renders package unusable

wiki web server is mis-configured.

When I browse to:

https://wiki.debian.org/

The web page returned says:

Forbidden

You are not allowed to access this!"


OR when viewed as source, I see this:



403 Forbidden
Forbidden
You are not allowed to access this!



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

Kernel: Linux 4.9.0-8-amd64 (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: systemd (via /run/systemd/system)

Bug#907946:

[HuangKaiXiang]

I’m interested in this. Do you still help

HuangKaiXiang

Bug#919467: steam: data loss when switching from Valve's steam package

[Michael Gilbert]

On Fri, Jan 18, 2019 at 12:31 AM Michael Gilbert wrote:
> Two, Valve moves completely to XDG_DATA_HOME.

I intended to say that Valve completely follows the XDG base directory
specification, which is of course more than just XDG_DATA_HOME.

Best wishes,
Mike

Bug#919633: Backport of 1.16.x to stretch

[Jerome Charaoui]

Package: sssd
Version: 1.15.0-3
Severity: wishlist

Dear Maintainer,

Please provide a backport of SSSD 1.16.x for the stretch stable release.
Several bugs in 1.15.0 prevent SSSD from being usable in certain
conditions.

I have been running a self-built backport of SSSD for months now without
any issues.

Thank you,

-- Jerome

Bug#919467: steam: data loss when switching from Valve's steam package

[Michael Gilbert]

control: tag -1 - patch pending

On Wed, Jan 16, 2019 at 6:33 AM Simon McVittie wrote:
> This is basically my earlier patch from #916303, except that the default
> is swapped: it will continue to use ~/.steam as the $STEAMDIR for new
> installations, and only use ~/.local/share/Steam (or any other $STEAMDIR)
> if that was already set up. This reduces the solution to #916303 to
> "swap the default".

I'm don't yet see what use case would require more than one steam
installations per user, so I don't see the value of the links Valve
dumps in ~/.steam.

I am not yet on board with moving the steam dir to XDG_DATA_HOME.
These are concerns that have already been mentioned.  One, the user
can seem to break their installation by changing the value of
XDG_DATA_HOME.  Second, this will cause clutter to both ~ and
XDG_DATA_HOME.  Right now the clutter is at least self contained to ~.

The two viable solutions I see are.  One, use a debian specific dir in
~/.steam.  Two, Valve moves completely to XDG_DATA_HOME.

Best wishes,
Mike

Bug#919343: tdom FTCBFS: hard codes the wrong pkg-config,version graph

[Helmut Grohne]

Hi Rolf,

On Thu, Jan 17, 2019 at 11:03:26PM +0100, Rolf Ade wrote:
> Could you please be a bit more specific about the problem: tDOM with
> which configure flags cross-compilied on what platform for which
> target platform does not build? If only to give me a chance to check
> that your patch fixes the problem.

The configure flags are selected by the Debian package. You can find
them in debian/rules:
https://sources.debian.org/src/tdom/0.9.1-1/debian/rules/#L29
I perform all such QA builds on amd64. The target architecture is left
unspecified, because tdom does not evaluate it as it is not a compiler.
 
> If I patch tDOM with your code it still builds correct for me (with
> --enable-html5, which, from your patch, do you use and is the culprit,
> and without and so on). So I'm somewhat tempted to check-in, if I have
> evidence that this does otherwise good.

That's intended. The patch is written in a w way to minimize the
potential to affect native builds. Unless you perform a cross build,
it'll continue to use plain pkg-config like before.

> I've to confess that for the build system I mostly cargo cult TEA.
> Could you please explain in short how "tdom confuses the meaning of
> aclocal.m4 and acinclude.m4 and therefore [you] cannot run aclocal"?

aclocal.m4 and acinclude.m4 serve different needs. The former is meant
to be generated by aclocal. It scans macro archives from upstream
projects and embeds those macros that tdom needs into a long aclocal.m4.
acinclude.m4 is meant as an additional file, which is not replaced by
aclocal, but rather included by aclocal. tdom's aclocal.m4 doesn't look
like it was generated by aclocal to me. The autoconf manual has a few
words along the same lines:
https://www.gnu.org/software/automake/manual/html_node/Complete.html
For using macros like PKG_CHECK_MODULES or PKG_PROG_PKG_CONFIG from
pkg-config's pkg.m4, we need aclocal to copy them to aclocal.m4 as far
as I understand. Using PKG_CHECK_MODULES is particularly useful, because
it condenses a lot of functionality in a single call:

PKG_CHECK_MODULES([HTML5],[gumbo],[AC_DEFINE(TDOM_HAVE_GUMBO)],[])

For the static case, a similar call to PKG_CHECK_MODULES_STATIC can be
used. The call above will create variables HTML5_CFLAGS and HTML5_LIBS
and will automatically AC_SUBST them considerably shortening your m4
code in addition to just working correctly for cross compilation.

Hope this helps

Helmut

Bug#728523: re

[Saranya Boonyawattana]

I have a proposal for you kindly email me at : karenwea...@gmail.com

Bug#919632: "New" firmware instantly crashes on QCA9377

[Kevin Price]

Package: firmware-atheros
Version: 20180518-1
Severity: important
Tags: upstream

Dear Maintainer,

I observed this while upgrading non-free firmware from stretch
(20161130-4) to stretch-backports (20180825+dfsg-1~bpo9+1) my QCA9377
quit working. Whether during boot or manually: When modprobing
ath10k_pci, the device either appears in my network stack, or it does
not, depending on the firmware version. In the latter case, that is
because its firmware instantly crashes, according to dmesg. I pinned
that down to: up to 20170823-1 works, 20180518-1 and after does not,
including 20190114-1. Looking at changelog.Debian, the break seems to
have been caused by this change:
"
firmware-nonfree (20180518-1) unstable; urgency=medium
 * New upstream version:
   - atheros:
 + QCA9377 rev 1.0 firmware version WLAN.TF.1.0-2-QCATFSWPZ-5
"
According to dmesg, this "upgrade" replaced WLAN.TF.1.0-00267-1, which
was at least partially working for me. (only crashing occasionally as
described in #885846, and having trouble with big packet sizes, but
generally working) Comparing these QC firmware version numbers, they
look to me like the debian package upgrade actually included an upstream
downgrade. That of course would be the culprit, and a reason to rename
this bug report. You might want to check this hunch with upstream, and
with their versioning scheme. I suspect that #903437 might have the same
cause. And if there is a better QC-firmware than WLAN.TF.1.0-00267-1,
that might even resolve #885846 as well.

I'd love to see at least stretch-backports not breaking device
functionality. Please let me know about how else I may assist you in
that. FWIW, I'll attach the dmesg of when it's crashing, and my lspci
(-v and -vv) in (half-)working condition. My kernel is
linux-image-4.9.0-8-amd64_4.9.130-2 from stretch.

Best regards
Kevin Price

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

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

firmware-atheros depends on no packages.

firmware-atheros recommends no packages.

Versions of packages firmware-atheros suggests:
ii  initramfs-tools  0.130

-- no debconf information
[ 3077.895506] ath10k_pci :05:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 
reset_mode 0
[ 3078.170210] ath10k_pci :05:00.0: firmware: failed to load 
ath10k/pre-cal-pci-:05:00.0.bin (-2)
[ 3078.170220] ath10k_pci :05:00.0: Direct firmware load for 
ath10k/pre-cal-pci-:05:00.0.bin failed with error -2
[ 3078.170244] ath10k_pci :05:00.0: firmware: failed to load 
ath10k/cal-pci-:05:00.0.bin (-2)
[ 3078.170250] ath10k_pci :05:00.0: Direct firmware load for 
ath10k/cal-pci-:05:00.0.bin failed with error -2
[ 3078.170990] ath10k_pci :05:00.0: firmware: direct-loading firmware 
ath10k/QCA9377/hw1.0/firmware-5.bin
[ 3078.171004] ath10k_pci :05:00.0: qca9377 hw1.1 target 0x05020001 chip_id 
0x003821ff sub 17aa:0901
[ 3078.171010] ath10k_pci :05:00.0: kconfig debug 0 debugfs 0 tracing 0 dfs 
0 testmode 0
[ 3078.172806] ath10k_pci :05:00.0: firmware ver 
WLAN.TF.1.0-2-QCATFSWPZ-5 api 5 features ignore-otp crc32 c3e0d04f
[ 3078.235794] ath10k_pci :05:00.0: board id is not exist in otp, ignore it
[ 3078.235979] ath10k_pci :05:00.0: board_file api 2 bmi_id N/A crc32 
8aedfa4a
[ 3080.516566] ath10k_pci :05:00.0: firmware crashed! (uuid n/a)
[ 3080.516581] ath10k_pci :05:00.0: qca9377 hw1.1 target 0x05020001 chip_id 
0x003821ff sub 17aa:0901
[ 3080.516584] ath10k_pci :05:00.0: kconfig debug 0 debugfs 0 tracing 0 dfs 
0 testmode 0
[ 3080.517097] ath10k_pci :05:00.0: firmware ver 
WLAN.TF.1.0-2-QCATFSWPZ-5 api 5 features ignore-otp crc32 c3e0d04f
[ 3080.517288] ath10k_pci :05:00.0: board_file api 2 bmi_id N/A crc32 
8aedfa4a
[ 3080.517292] ath10k_pci :05:00.0: htt-ver 0.0 wmi-op 4 htt-op 3 cal otp 
max-sta 32 raw 0 hwcrypto 1
[ 3080.519299] ath10k_pci :05:00.0: firmware register dump:
[ 3080.519304] ath10k_pci :05:00.0: [00]: 0x05020001 0x 0x00A0F774 
0x
[ 3080.519306] ath10k_pci :05:00.0: [04]: 0x00A0F774 0x00060130 0x0010 
0xE000
[ 3080.519309] ath10k_pci :05:00.0: [08]: 0x0042136C 0x00420660 0x0040 
0x0040
[ 3080.519311] ath10k_pci :05:00.0: [12]: 0x 0x 0x00952CD0 
0x00952CE6
[ 3080.519313] ath10k_pci :05:00.0: [16]: 0x0002 0x01010101 0x0003 
0x000A
[ 3080.519315] ath10k_pci :05:00.0: [20]: 0x0328 0x00429880 0x009A37AC 
0x0032
[ 3080.519318] ath10k_pci :05:00.0: [24]: 0x800A0D0A 0x0040EA88 0x00420170 
0x004173B0
[ 3080.519320] ath10k_pci :05:00.0: [28]: 0x00401F64 0x00401F68 0x 
0x00417550
[ 3080.519322] ath10k_pci :05:00.0: [32]: 0x00401FC0 

Bug#898863: debian/watch doesn't work properly

[Sergio Durigan Junior]

On Wednesday, January 16 2019, Joel Cross wrote:

> On Thu, 20 Dec 2018, at 3:49 AM, Sergio Durigan Junior wrote:
>> While checking my maintainer's dashboard (),
>> I noticed that we still haven't solved this problem.  I realize life
>> sometimes gets in the way and it's hard to commit time to packaging, but
>> I decided to send this friendly ping anyway and see if you had the
>> chance to solve the issues I pointed out below.
>
> Hi Sergio,

Hey Joel,

> Well, I've finally got there! Please take a look at the latest upload 
> (https://mentors.debian.net/package/python-cerberus) and let me know what you 
> think.

Thanks, and sorry for the delay, I've been fighting a cold.

The modifications look good, even though I prefer to have them pushed to
the salsa git repo with proper comments and all.  Can you please do
that?

One minor nit: the current Standards-Version is 4.3.0.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#919631: dsniff patches change libdir, misplacing config files

[Hank Leininger]

Package: dsniff
Version: 2.4b1+debian-29
Severity: minor

The Debian patch 35_Add_CPPFLAGS.patch, here for reference:

  
https://salsa.debian.org/pkg-security-team/dsniff/blob/debian/master/debian/patches/35_Add_CPPFLAGS.patch

with this as the original, it seems:

  
https://salsa.debian.org/pkg-security-team/dsniff/blob/51bae4fcbaec532409e0c8a1bed7c450cca57d2b/debian/patches/34_Add_CPPFLAGS.patch

...changes Makefile.in's libdir from $(prefix)/share/dsniff to @libdir@,
among other things.

That 'libdir' does not do what one would expect: it is the destination
path for some config files, specifically dnsspoof.hosts, dsniff.magic,
and dsniff.services, _not_ for shared libraries.  So currently those
config files get put into /usr/lib/x86_64-linux-gnu/ or similar.

Ironically, patch 20_debian_dirs.patch sets libdir to
$(prefix)/share/dsniff, so this particular hunk of 35 undoes that.

I'd suggest changing back to $(prefix)/share/dsniff, and renaming libdir
to avoid confusion; perhaps use 'sharedir' so that it doesn't get
accidentally fixed again in the future.  Below is a patch that does
that.

Note, I'm not actually a Debian user; I encountered this when working to
borrow Debian's patches to dsniff for OpenSSL 1.1.x compatibility for
Gentoo (thanks!), and found the config files had moved.  There may be
some line number fuzz in the below as a result.


diff -urP dsniff-2.4.orig/Makefile.in dsniff-2.4/Makefile.in
--- dsniff-2.4.orig/Makefile.in 2019-01-17 16:11:25.546048937 -0700
+++ dsniff-2.4/Makefile.in  2019-01-17 16:56:37.218243360 -0700
@@ -11,12 +11,12 @@
 install_prefix  =
 prefix  = @prefix@
 exec_prefix= @exec_prefix@
-libdir = @libdir@
+sharedir   = $(prefix)/share/dsniff
 sbindir = @sbindir@
 mandir = @mandir@
 
 CC = @CC@
-CFLAGS = @CFLAGS@ -DDSNIFF_LIBDIR=\"$(libdir)/\"
+CFLAGS = @CFLAGS@ -DDSNIFF_LIBDIR=\"$(sharedir)/\"
 CPPFLAGS = @CPPFLAGS@
 LDFLAGS= @LDFLAGS@
 
@@ -157,10 +157,10 @@
for file in $(PROGS); do \
   $(INSTALL_PROGRAM) -m 755 $$file $(install_prefix)$(sbindir); \
done
-   test -d $(install_prefix)$(libdir) || \
-  $(INSTALL) -d $(install_prefix)$(libdir)
+   test -d $(install_prefix)$(sharedir) || \
+  $(INSTALL) -d $(install_prefix)$(sharedir)
for file in $(CONFIGS); do \
-  $(INSTALL_DATA) $$file $(install_prefix)$(libdir); \
+  $(INSTALL_DATA) $$file $(install_prefix)$(sharedir); \
done
test -d $(install_prefix)$(mandir)/man8 || \
   $(INSTALL) -d $(install_prefix)$(mandir)/man8



signature.asc
Description: Digital signature

Bug#834270: xorg: logging out of shell on vt2 crashes X on vt1

[Simon Heimberg]

according to [1], any the following fixes the bug:
* removing the call to /usr/bin/clear_console from ~/.bash_logout 
(console is cleared anyway nowadays)
* replacing the call to /usr/bin/clear_console with /usr/bin/reset in 
~/.bash_logout


The discussion in [1] shows more information, the bug [2] at xorg is 
related or a duplicate


[1] https://groups.google.com/forum/#!topic/linux.debian.user/2G71U8P8c3Q
[2] https://gitlab.freedesktop.org/xorg/xserver/issues/492

Bug#919630: usbmuxd segfaults on startup

[James Henried]

Package: usbmuxd
Version: 1.1.1~git20181007.f838cf6-1
Severity: important

Dear Maintainer,

Have been running into trouble mounting an iPhone with ifuse. Noticed that 
usbmuxd segfaults on startup:

# usbmuxd
Segmentation fault
# usbmuxd
free(): double free detected in tcache 2
Aborted
# usbmuxd
Segmentation fault
# usbmuxd
free(): double free detected in tcache 2
Aborted
#

When running ifuse, I get similar errors:

# ifuse /media/iphone/
No device found, is it connected?
If it is make sure that your user has permissions to access the raw usb device.
If you're still having issues try unplugging the device and reconnecting it.
double free or corruption (fasttop)
Aborted
#

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

Kernel: Linux 4.18.0-2-amd64 (SMP w/12 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)
LSM: AppArmor: enabled

Versions of packages usbmuxd depends on:
ii  adduser3.118
ii  libc6  2.28-5
ii  libimobiledevice6  1.2.1~git20181030.92c5462-1
ii  libplist3  2.0.1~git20190104.3f96731-1
ii  libusb-1.0-0   2:1.0.22-2

usbmuxd recommends no packages.

usbmuxd suggests no packages.

-- no debconf information

Bug#656750: [monkeysphere] Bug#656750: monkeysphere: wrongly preserves TMPDIR across accounts

[Daniel Kahn Gillmor]

On Wed 2019-01-16 18:40:06 -0800, Sunil Mohan Adapa wrote:
> tags 656750 + patch

Thanks for this, Sunil!  I'll try to review it soon.  Feel free to ping
if i haven't moved on it in a few days.

   --dkg


signature.asc
Description: PGP signature

Bug#865624: (no subject)

[sch0rsch]

Might I ask to have this fix backported to Debian stable (Stretch)?

Currently the issue completely breaks certain Transmission usage 
scenarios on Debian stable branch.


At best, the fix it is applied directly within the "stretch" branch, 
otherwise "stretch-backports".


Thanks in advance,
Micha

Bug#919598: zlib: copyright file needs updating

[Stephen Kitt]

Hi Kai,

On Thu, 17 Jan 2019 19:14:00 +0100, "Kai Pastor, DG0YT"  wrote:
> The win32 directory is how I came here: I'm building for Mingw from the 
> Debian sources, which now fails. Is the removal of the win32 directory 
> neccessary? I do see the restrictions established in win32/DLL_FAQ.txt. 
> However, I don't think these restrictions are removed by removing this 
> file. They may apply to the DFSG sources as well, even with the win32 
> dir removed.

You might find https://tracker.debian.org/libz-mingw-w64 interesting.

Regards,

Stephen


pgpHgRwWRtWNv.pgp
Description: OpenPGP digital signature

Bug#919326: msmtp: account default not found: no configuration file available

[Emmanuel Bouthenot]

forcemerge 919323 919326
thanks

Hi,

On Mon, Jan 14, 2019 at 04:40:36PM -0600, Sergio Mendoza wrote:
[...]

>   A few days ago, msmtp fails to work.  It all seems to be related to the
> inability to read ~/.msmtprc file.  In other words it seems that

Merging and closing this bug as it is fixed with the last upload.

Regards,

-- 
Emmanuel Bouthenot
  mail: kolter@{openics,debian}.orggpg: 4096R/0x929D42C3
  xmpp: kol...@im.openics.org  irc: kolter@{freenode,oftc}

Bug#919593: julia: Please use LLVM 6.0 packages

[M. Zhou]

Hi Sylvestre,

Thanks for offering help. Julia ships embedded LLVM because we want to
apply all the upstream patches (although I don't care about the portion
of patches for windows). I've filed an bug against LLVM 6 and pointed
out the location of upstream patches.

Another issue we encountered about LLVM is it's emitting NEON code on armv7,
which resulted in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919183

Recently in discussions with ginggs we reached an agreement to ignore
the NEON code problem on armhf ... and I've found no solution for it.
Upstream encountered similar problem long time ago[1], but I think
we don't have to completely disable NEON now ... since julia compiles
multiple code branches.

[1] https://github.com/JuliaLang/julia/pull/19022

Bug#919384: python-matplotlib: The Gtk3 backend requires PyGObject or pgi

[Sandro Tosi]

On Wed, Jan 16, 2019 at 8:39 AM Marius Mikučionis  wrote:
>
> 2019-01-16, Wed, 14:16 Sandro Tosi  wrote:
>>
>> > It would be so much better if one would read the report in full.
>>
>> it would be even so much better if you can provide a code snippet to
>> replicate the issue.
>
>
> I am sorry:
> 1) the program is too big (many files and thousands of LOC per file)
> 2) I do not know enough python to make a meaningful slice (many features 
> jumbled into one spaghetti),
>
> The code is available here:
> http://www.compass-toolset.org/tools-download/
>
> Unpack and try running:
> python scripts/compassw.py

i dont think it's appropriate to expect any maintainer to test
"random" applications available on the internet, in particular when
they ask you personal information before sending you back a mail with
a download link (??). in particular when it has written all over the
place that this app is targeting specifically ubuntu 16.04 and if you
dont use that you're on your own.

you may want to ask for assistance to a user support forum, such as
the debian-users mailing list

> I would not bother you if not for the bug 889137 which says that Gtk2 is not 
> supported in python.
> Because of this issue, I need to install Ubuntu (or something else).

i mean, there's nothing wrong with deprecating backends and support
only newer versions, the problem now is in applications to keep up,
which in this case has not happened (yet). For example, did you open a
ticket with the compass developers asking for guidance on how to
deploy that application with a newer version of matplotlib?

there's nothing wrong with matplotlib in Debian, as far as i can tell,
just compass (a third party app) needs updating

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#919629: firefox-esr: crash on loading meet.google.com video conference

[Benjamin Moody]

Package: firefox-esr
Version: 60.3.0esr-1~deb9u1
Severity: normal

Dear Maintainer,

Firefox crashes when trying to join a Google video conference.

Upon loading the URL (https://meet.google.com/xxx--xxx), the page
is briefly displayed, and a dialog pops up asking for permission to
access the microphone.  After perhaps half a second, it gives
"Gah. Your tab just crashed."

As best I can figure from the Firefox crash report, it crashes at
0x33e12c0 in libxul.so
 = media/webrtc/trunk/webrtc/base/task_queue_libevent.cc:320

The crash report is at
https://crash-stats.mozilla.com/report/index/e4db2583-c89f-4f0b-95fc-e5ac30190117

(okay, apparently it automatically uploads all of this to mozilla,
that's a little disturbing...)

I can try to dig deeper, but any tips on how to diagnose the problem
would be welcome.  Note I am not the meeting organizer, and you
apparently need to be a "G Suite Administrator" to organize meetings.

Bug#919628: Apply Julia's LLVM patches

[M. Zhou]

Package: llvm-6.0-dev
Version: 1:6.0.1-9.2
X-Debbugs-CC: gin...@debian.org

Dear LLVM maintainers,

Please check and apply Julia's LLVM patches to Debian's LLVM 6.0.1:

https://github.com/JuliaLang/julia/blob/master/deps/llvm.mk#L390-L432
https://github.com/JuliaLang/julia/tree/master/deps/patches

I don't quite understand what these patches are doing. So in order to
use upstream's LLVM patches, the most straightforward way is to
ship an embedded LLVM in Julia's source package.

Bug#919627: kodi: Segfault at startup on computer that has been working with Kodi

[Stephen Paul Weber]

Package: kodi
Version: 2:17.1+dfsg1-3
Severity: important

Dear Maintainer,

I have been running kodi on this system under Debian 9 for at least a
year with no issue.  Today, it will not run, either under the user I
normally run it as, or my user, either in standalone mode or as a window
on my normal LXDE desktop.  It segfaults during startup and I never even
see the Kodi UI.  Included here is the debug log file it manages to
write before crashing:

## Kodi CRASH LOG ###

 SYSTEM INFO 
 Date: Thu Jan 17 22:31:57 EST 2019
 Kodi Options: 
 Arch: x86_64
 Kernel: Linux 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27)
 Release: Debian GNU/Linux 9 (stretch)
## END SYSTEM INFO ##

### STACK TRACE #
=>  Core file: /home/kodi/core (2019-01-17 22:31:56.562352814 -0500)
=
[New LWP 1603]
[New LWP 1604]
[New LWP 1609]
[New LWP 1606]
[New LWP 1607]
[New LWP 1608]
[New LWP 1610]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/lib/x86_64-linux-gnu/kodi/kodi.bin'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x55fd51428382 in CWinSystemX11GLContext::IsExtSupported(char const*) ()
[Current thread is 1 (Thread 0x7f805f015b40 (LWP 1603))]

Thread 7 (Thread 0x7f8034c84700 (LWP 1610)):
#0  pthread_cond_timedwait@@GLIBC_2.3.2 () at 
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:180
#1  0x55fd51747e66 in XbmcThreads::CEventGroup::wait(unsigned int) ()
#2  0x55fd5141253d in ?? ()
#3  0x55fd51749cef in CThread::Action() ()
#4  0x55fd51749faf in CThread::staticThread(void*) ()
#5  0x7f805d888494 in start_thread (arg=0x7f8034c84700) at 
pthread_create.c:333
#6  0x7f8054fb8acf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Thread 6 (Thread 0x7f8035c86700 (LWP 1608)):
#0  pthread_cond_timedwait@@GLIBC_2.3.2 () at 
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:180
#1  0x55fd50e2fb0d in ActiveAE::CActiveAESink::Process() ()
#2  0x55fd51749cef in CThread::Action() ()
#3  0x55fd51749faf in CThread::staticThread(void*) ()
#4  0x7f805d888494 in start_thread (arg=0x7f8035c86700) at 
pthread_create.c:333
#5  0x7f8054fb8acf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Thread 5 (Thread 0x7f8036487700 (LWP 1607)):
#0  pthread_cond_timedwait@@GLIBC_2.3.2 () at 
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:180
#1  0x55fd50e2b387 in ActiveAE::CActiveAE::Process() ()
#2  0x55fd51749cef in CThread::Action() ()
#3  0x55fd51749faf in CThread::staticThread(void*) ()
#4  0x7f805d888494 in start_thread (arg=0x7f8036487700) at 
pthread_create.c:333
#5  0x7f8054fb8acf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Thread 4 (Thread 0x7f8036e9c700 (LWP 1606)):
#0  pthread_cond_timedwait@@GLIBC_2.3.2 () at 
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:180
#1  0x55fd514a3c3c in CJobManager::GetNextJob(CJobWorker const*) ()
#2  0x55fd514a3dea in CJobWorker::Process() ()
#3  0x55fd51749cef in CThread::Action() ()
#4  0x55fd51749faf in CThread::staticThread(void*) ()
#5  0x7f805d888494 in start_thread (arg=0x7f8036e9c700) at 
pthread_create.c:333
#6  0x7f8054fb8acf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Thread 3 (Thread 0x7f8035485700 (LWP 1609)):
#0  0x7f8054faf67d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x7f8059ac1c91 in ?? () from /usr/lib/x86_64-linux-gnu/libpulse.so.0
#2  0x7f8059ab34a1 in pa_mainloop_poll () from 
/usr/lib/x86_64-linux-gnu/libpulse.so.0
#3  0x7f8059ab3b3e in pa_mainloop_iterate () from 
/usr/lib/x86_64-linux-gnu/libpulse.so.0
#4  0x7f8059ab3bf0 in pa_mainloop_run () from 
/usr/lib/x86_64-linux-gnu/libpulse.so.0
#5  0x7f8059ac1bd9 in ?? () from /usr/lib/x86_64-linux-gnu/libpulse.so.0
#6  0x7f805191a2c8 in ?? () from 
/usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-10.0.so
#7  0x7f805d888494 in start_thread (arg=0x7f8035485700) at 
pthread_create.c:333
#8  0x7f8054fb8acf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Thread 2 (Thread 0x7f803769d700 (LWP 1604)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at 
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:143
#1  0x55fd50ffc1a9 in ANNOUNCEMENT::CAnnouncementManager::Process() ()
#2  0x55fd51749cef in CThread::Action() ()
#3  0x55fd51749faf in CThread::staticThread(void*) ()
#4  0x7f805d888494 in start_thread (arg=0x7f803769d700) at 
pthread_create.c:333
#5  0x7f8054fb8acf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Thread 1 (Thread 0x7f805f015b40 (LWP 1603)):
#0  0x55fd51428382 in CWinSystemX11GLContext::IsExtSupported(char const*) ()
#1  0x55fd516e5680 in CRenderSystemGL::ResetRenderSystem(

Bug#907318: [Pkg-samba-maint] Bug#907318: pam-configs/winbind is erroneously handling account section.

[Mathieu Parent]

Le dim. 26 août 2018 à 14:39, Maurizio Cimaschi  a écrit :
>
> Package: libpam-winbind
> Version: 2:4.5.12+dfsg-2+deb9u3
>
> Dear package maintainer(s),

Hi,

> the "winbind" file has an issue so that the "account" part will never be
> executed because the pam_unix usually return success due the presence of the
> nss-winbind library.
>
> Have a look at this fragment from the file:
>
> Account-Type: Primary
> Account:
> [success=end new_authtok_reqd=done default=ignore]  pam_winbind.so
>
> from: 
> https://salsa.debian.org/samba-team/samba/blob/stretch/debian/winbind.pam-config
>
> The pam-auth-config will put the winbind library immediatly after the pam_unix
> line in the "common-account" file. The pam_unix is configured so that its
> success (which usually happens because the winbind nss library will make 
> domain
> users apper as local ones) will terminate the "Primary" section. So the
> pam_winbind will (almost) never touch the ball.
>
> See for example how this thing is sorted out in the sssd package:
>
> Account-Type: Additional
> Account:
> sufficient  pam_localuser.so
> [default=bad success=ok user_unknown=ignore]pam_sss.so
>
> from: 
> https://salsa.debian.org/sssd-team/sssd/blob/debian/1.15.0-3/debian/libpam-sss.pam-auth-update
>
> Here the "additional" property will put the pam_sss at the end of the
> "commoun-account" file, so it will be executed even if the pam_unix had
> previusly succceded. It is also interesting the use of the pam_localuser
> library to prevent unnecessary network lookups.

Thanks for your bug report. Would you mind creating a merge request
for this feature?

I'm not sure this could go in buster.

Regards
-- 
Mathieu Parent

Bug#919626: Emits NEON code on armv7a due to wrong CPU detection

[M. Zhou]

Package: llvm-6.0-dev
Version: 1:6.0.1-9.2
X-Debbugs-CC: gin...@debian.org

Dear LLVM maintainers,

Recently Julia FTBFS on armhf due to SIGILL from NEON instruction.
(ginggs digged into the SIGILL and confirmed it's due to NEON)
However, julia is supposed to compile multiple code branches where
one of them involves no NEON instruction. Emulation based on QEMU's
cortex-a7 CPU proves this point.

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

Neither Debian's LLVM, nor Julia's patched LLVM, has fixed this issue.

The incorrect CPU detection can be reproduced on abel, LLVM
also emits NEON code to abel's CPU.

Bug#919625: neutron-fwaas-common: fails to remove: neutron-plugin-manage disable: error: argument --service-plugin: invalid choice: 'firewall_v2'

[Andreas Beckmann]

Package: neutron-fwaas-common
Version: 1:13.0.1-4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to remove.

>From the attached log (scroll to the bottom...):

  Removing neutron-fwaas-common (1:13.0.1-4) ...
  usage: neutron-plugin-manage disable [-h]
   [--service-plugin 
{auto_allocate,dummy,flavors,log,loki,metering,network_ip_availability,port_forwarding,qos,revisions,router,segments,tag,timestamp,trunk}]
   [--l3-extension 
{fip_qos,port_forwarding}]
   {enable,disable} ...
  neutron-plugin-manage disable: error: argument --service-plugin: invalid 
choice: 'firewall_v2' (choose from 'auto_allocate', 'dummy', 'flavors', 'log', 
'loki', 'metering', 'network_ip_availability', 'port_forwarding', 'qos', 
'revisions', 'router', 'segments', 'tag', 'timestamp', 'trunk')
  dpkg: error processing package neutron-fwaas-common (--remove):
   installed neutron-fwaas-common package post-removal script subprocess 
returned error exit status 2


cheers,

Andreas


neutron-fwaas-common_1:13.0.1-4.log.gz
Description: application/gzip

Bug#919402: devscripts: [salsa] documentation mentions both SALSA_TOKEN and SALSA_PRIVATE_TOKEN

[Daniel Kahn Gillmor]

On Thu 2019-01-17 07:07:02 +0100, Xavier wrote:
> Is this better?
>
> diff --git a/scripts/salsa.pl b/scripts/salsa.pl
> index 6cc9a234..e1084b20 100755
> --- a/scripts/salsa.pl
> +++ b/scripts/salsa.pl
> @@ -43,11 +43,17 @@ or
>
>SALSA_TOKEN_FILE=~/.dpt.conf
>
> -If you choose to link another file, it must contain a line with
> something like:
> +If you choose to link another file using SALSA_TOKEN_FILE, it must contain a
> +line with something like:
>
>SALSA_PRIVATE_TOKEN=
>SALSA_TOKEN=
>
> +This allows for example to use dpt(1) configuration file (~/.dpt.conf) which
> +contains:
> +
> +  DPT_SALSA_PRIVATE_TOKEN=abcdefghi
> +
>  =head1 COMMANDS
>
>  =head2 Managing users and groups

well, i understand it now, but that's maybe thanks to your earlier
explanation -- so i'm tainted :P  I do like that you included the
example for users of dpt.  i'm not a user of dpt myself, but the example
alone makes it a lot clearer what  means (i'd earlier thought
that i needed the literal angle brackets, for example, which struck me
as odd, but hey people do odd stuff).

If you're trying to write documentation that works for someone who
doesn't already understand what's going on here, it would be good to
explain that these two strings (SALSA_PRIVATE_TOKEN and SALSA_TOKEN) do
exactly the same thing.  otoh, is there a reason to support them both,
rather than having one be the expected+supported mechanism, and the
other be deprecated?

If you're willing to deprecate one of them, you could offer a warning if
the deprecated form is found, along with a recommendation of how to fix
it. then, over the course of a debian release, you could simply drop the
deprecated variant.

i know it's nice to be clever and just magically work for everyone, but
it makes explaining what's going on a lot harder.  Simplicity makes for
clearer explanations.

Thanks for maintaining this tool!

   --dkg


signature.asc
Description: PGP signature

Bug#919623: Remote code execution in scp support

[Russ Allbery]

Package: rssh
Version: 2.3.4-8
Severity: grave
Tags: security upstream

https://sourceforge.net/p/rssh/mailman/message/36519118/ is the upstream
report.  The reporter indicated they asked for a CVE but didn't include it
in the message.

scp allows remote code execution inside the server environment via several
methods due to inadequate command-line verification.  This bug has been
present since the beginning of rssh.

I have a completely untested patch but haven't had time to test it yet.
Attaching it to this report for whatever it's worth.

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

Kernel: Linux 4.19.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)
LSM: AppArmor: enabled

Versions of packages rssh depends on:
ii  debconf [debconf-2.0]  1.5.69
ii  libc6  2.28-4
ii  openssh-server 1:7.9p1-4

rssh recommends no packages.

Versions of packages rssh suggests:
ii  cvs 2:1.12.13+real-26
pn  makejail
pn  rdist   
ii  rsync   3.1.3-1
ii  subversion  1.10.3-1+b1

-- Configuration Files:
/etc/logcheck/ignore.d.server/rssh [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.server/rssh'
/etc/rssh.conf changed [not included]

-- debconf information excluded
diff --git a/util.c b/util.c
index 56f67ad..4dde1a0 100644
--- a/util.c
+++ b/util.c
@@ -268,6 +268,45 @@ static int rsync_e_okay( char **vec )
 }
 
 
+/*
+ * scp_okay() - take the command line and check that it is a hopefully-safe scp
+ * server command line, accepting only very specific options.
+ * Returns FALSE if the command line should not be allowed, TRUE
+ * if it is okay.
+ */
+static int scp_okay( char **vec )
+{
+   int saw_file = FALSE;
+   int saw_end  = FALSE;
+
+   for ( ; vec && *vec; vec++ ){
+   /* Allowed options. */
+   if ( !saw_end ) {
+   if ( strcmp(*vec, "-v") == 0 ) continue;
+   if ( strcmp(*vec, "-r") == 0 ) continue;
+   if ( strcmp(*vec, "-p") == 0 ) continue;
+   if ( strcmp(*vec, "-d") == 0 ) continue;
+   if ( strcmp(*vec, "-f") == 0 ) continue;
+   if ( strcmp(*vec, "-t") == 0 ) continue;
+   }
+
+   /* End of arguments.  One more argument allowed after this. */
+   if ( !saw_end && strcmp(*vec, "--") == 0 ){
+   saw_end = TRUE;
+   continue;
+   }
+
+   /* No other options allowed, but allow file starting with -. */
+   if ( *vec[0] == '-' && !saw_end ) return FALSE;
+   if ( saw_file ) return FALSE;
+   saw_file = TRUE;
+   }
+
+   /* We must have seen a single file. */
+   return saw_file;
+}
+
+
 /*
  * check_command_line() - take the command line passed to rssh, and verify
  *   that the specified command is one the user is
@@ -283,8 +322,11 @@ char *check_command_line( char **cl, ShellOptions_t *opts )
return PATH_SFTP_SERVER;
 
if ( check_command(*cl, opts, PATH_SCP, RSSH_ALLOW_SCP) ){
-   /* filter -S option */
-   if ( opt_filter(cl, 'S') ) return NULL;
+   if ( !scp_okay(cl) ){
+   fprintf(stderr, "\ninsecure scp option not allowed.");
+   log_msg("insecure scp option in scp command line");
+   return NULL;
+   }
return PATH_SCP;
}
 

Bug#919624: ITP: daps -- DocBook-based authoring and publishing system

[Filippo Rusconi]

Package: wnpp
Severity: wishlist
Owner: Filippo Rusconi 

* Package name: daps
 Version : 3.0.0
 Upstream Author : Frank Sundermeyer 
* URL : http://opensuse.github.io/daps
* License : GPL-3.0
 Programming Lang: Shell, Python 
Description: DocBook Authoring and Publishing Suite (DAPS)

DAPS contains a set of stylesheets, scripts and makefiles that enable
you to create HTML, PDF, EPUB and other formats from DocBook XML with a
single command. It also contains tools to generate profiled source
tarballs for distributing your XML sources for translation or review.
.
DAPS also includes tools that assist you when writing DocBook XML:
linkchecker, validator, spellchecker, editor macros and stylesheets for
converting DocBook XML.

I was looking for some integrated solution to author the user manuals of my
msXpertSuite software and I tried publican, but felt it was a bit rough. Then I
discovered daps and I found it really well documented, really
well-functioning. In no time I had a workflow that worked flawlessly.

DocBook is now getting more and more traction even amongs non-technical writers.
I feel that having a bit of competition in Debian is useful.

When DAPS will be in Debian, I'll build the user manuals of mineXpert and
massXpert during package build.

Thanks
Filippo
--

⢀⣴⠾⠻⢶⣦⠀  Filippo Rusconi, PhD
⣾⠁⢠⠒⠀⣿⡁   Scientist at CNRS
⢿⡄⠘⠷⠚⠋⠀   Debian Developer
⠈⠳⣄  http://msxpertsuite.org
 http://www.debian.org

Bug#918966: new(?) backlight brightness script

[Thorsten Glaser]

On Sat, 12 Jan 2019, Dmitry Bogatov wrote:

> Sure. Your contribution would be welcome.

I pushed it to a branch “tg-brightness” in the sysvinit
packaging on Salsa.

I decided to rework the init script, so it can even work
on multiple backlight brightness knobs, and added the
Intel one from my Thinkpad, keeping the ACPI one compatible.

(Also, quite some shell scripting cleanup. As developer of
a shell, I know what I’m doing there ☺)

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#916468: whitedune: diff for NMU version 0.30.10-2.2

[Andreas Beckmann]

Control: clone -1 -2
Control: reassign -2 dune 1.6.2-1
Control: retitle -2 dune: needs Breaks+Replaces: whitedune (<< 0.30.10-2.2)
Control: tags -2 =

On Tue, 15 Jan 2019 21:16:00 +0100 Paul Gevers  wrote:
> I've prepared an NMU for whitedune (versioned as 0.30.10-2.2) and

If whitedune is going to drop the symlink, and dune is not getting renamed,
dune needs to add appropriate Breaks+Replaces.


Andreas

Bug#919559: picard-tools: autopkgtest regression

[Olivier Sallou]

- Andreas Tille  a écrit :
> On Thu, Jan 17, 2019 at 06:49:14PM +0100, Olivier Sallou wrote:
> > 
> > 
> > I tested against a local build of the package though local build (which
> > runs tests) works fine. (both are run on the same machine)!
> > 
> > autopkgtest does not keep the tempory directory used, so I cannot look
> > at test report (testng) to find failing tests.
> 
> Why not uncommenting line
> 
>  trap "rm -rf $ADTTMP" 0 INT QUIT ABRT PIPE TERM

I had not seen this, thanks, will try!
> 
> and may be also add
> 
>  set -x
> 
> for debugging?
> 
> Kind regards
> 
>  Andreas.
> 
> -- 
> http://fam-tille.de
> 

Bug#919411: orca: CapsLock isn't disabled though being used as Orca modifier

[Robert Schindler]

I copied complete OS over to another laptop model, same behaviour there.

Best regards
Robert


signature.asc
Description: PGP signature

Bug#919621: lvm2: Update unexpectedly activates system ID check, bypassing impossible

[Andreas Bombe]

Package: lvm2
Version: 2.03.02-1
Severity: important

There are possibly 2 different bugs in here, please clone as needed.

This computer has multiple VGs and had last been updated on Dec 13
before I ran an update on Jan 13. After this update it wouldn't complete
boot because one VG would not be activated due to system ID mismatch.

It dropped me into a root/rescue shell where I had full access to lvm
tools since the root filesystem was not in the affected VG.

The affected VG is ancient and has moved between computers and disks. It
has a system ID set from way back when (it includes a hostname I haven't
used for possibly more than a decade) while the newer, unaffected VGs
have blank system IDs. The system is configured to have no system ID
(system_id_source = "none").


Bug 1:

This has worked for all these years until the update, which rejects the
VG with system ID without advance warning during package upgrade. Systems
may become unbootable after upgrade if these VGs contain filesystems
that are mounted in /etc/fstab.


Bug 2:

Overriding system IDs does not work. I have tried setting
local/extra_system_ids as described in lvmsystemid(7) but this appears
to have no effect whatsoever. I could neither access the VG nor use
vgchange to clear its system ID, access was still rejected. I tried both
setting the variable in /etc/lvmlocal.conf and on the command line, and
confirmed with lvmconfig that the option is seen.

The only way to get access was to set global/system_id_source =
"lvmlocal" and set local/system_id to the affected VG's system ID.


I found this thread on the debian-user list where someone else appears
to have exactly the same problems:
https://lists.debian.org/msgid-search/20190113161023.ge10...@zaphod.galacticempire.org.us
 

-- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages lvm2 depends on:
ii  dmeventd  2:1.02.155-1
ii  dmsetup   2:1.02.155-1
ii  libaio1   0.3.111-1
ii  libblkid1 2.33.1-0.1
ii  libc6 2.28-5
ii  libdevmapper-event1.02.1  2:1.02.155-1
ii  libdevmapper1.02.12:1.02.155-1
ii  libreadline5  5.2+dfsg-3+b2
ii  libselinux1   2.8-1+b1
ii  libsystemd0   240-4
ii  libudev1  239-15
ii  lsb-base  10.2018112800

Versions of packages lvm2 recommends:
ii  thin-provisioning-tools  0.7.6-2

lvm2 suggests no packages.

-- Configuration Files:
/etc/lvm/lvm.conf changed [not included]
/etc/lvm/lvmlocal.conf changed [not included]

-- no debconf information

Bug#916468: Conflict over /usr/bin/dune

[Andreas Beckmann]

On Tue, 18 Dec 2018 17:48:06 + Ian Jackson
 wrote:
> Ian Jackson writes ("Re: Conflict over /usr/bin/dune"):
> >  https://www.google.com/search?q=dune+software
> >  https://en.wikipedia.org/wiki/Dune_(software)
> >  https://www.google.com/search?q=%2Fusr%2Fbin%2Fdune
> > 
> > Under the circumstances it seems obvious that, at the very least, the
> > ocaml build tool should not be allowed the name /usr/bin/dune.
> 
> Perhaps I should have stated this explicitly, since it was not obvious
> unless you follow the links.
> 
> `Dune' is not, as a piece of software, primarily either the ocaml
> build tool, or the 3D modeller.
> 
> Mostly it is DUNE, a "modular C++ library for the solution of partial
> differential equations using grid-based methods".  That's what you get
> if you visit the Wikipedia link I provided - not even a disambiguation
> link.  The others don't rate a mention.

That C++ library is also something I was expecting to have this
(meta-)package called dune.

If the ocaml build system wants to stay within the theme, what about
"camel" ? And once they find out that there is already camel.apache.org,
rename it again to "hump" (which seems to be available).


Andreas

Bug#836852: updated link

[Jeffrey Cliff]

here's an official non NSA/Microsoft link :

https://gitlab.com/synctext/tribler/

( tribler has continued to be under active development all this time,
and has grown considerably as a project since 6.5 release )

Bug#917898: libvisual-0.4-dev: Broken include path in pkg-config file

[Eriberto]

Hi Tim,

Em seg, 31 de dez de 2018 às 11:54, Tim Müller  escreveu:
>
> $ pkg-config --cflags libvisual-0.4
> -I/usr/include/libvisual-0.4
>
> $ ls /usr/include/libvisual-0.4
> ls: cannot access '/usr/include/libvisual-0.4': No such file or directory
>
> Only /usr/include/libvisual exists. It's not clear to me why it was renamed, 
> having the major/API version in the subdirectory name is good practice, so 
> that in case a new version with a different API/ABI is made it can be 
> installed in parallel.


I adopted libvisual some years ago. Originally, it was installing
include files in '/usr/include/libvisual-0.4'. In november 2018, I
created a test for autopkgtest (debian/tests/). The test called all .h
files and failed because these headers called
'/usr/include/libvisual'. So, I "fixed" the path for include files in
0.4.0-13 revision. I will revert this action and add a symlink to fix
the problem without more noising.

> In any case, this will cause everyone who uses this package via pkg-config 
> (e.g. gst-plugins-base) to FTBFS.
>
> Cheers
>  Tim

Thanks!

Cheers,

Eriberto

Hi Tim,

I adopted

Bug#919619: network-manager: should support iwd as wpasupplicant alternative

[Jonas Smedegaard]

Package: network-manager
Version: 1.14.4-4
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

network-manager is compiled with support for iwd,
but the package declares an absolute dependency on wpasupplicant.

Please add iwd as alternative to wpasupplicant.

Also, please consider relaxing to only recommend this combo,
as network-manager is certainly usable without those available, only
(as described when seemingly this was tightened in 0.6.0-1)
"necessary for all encrypted connections."


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlxA7v4ACgkQLHwxRsGg
ASEFFg/+ONg0Gc6d0G8CeXdVc+AbPfRoVeHUr743lx+fWi80sJU0OkyIvdaoYFZr
haXcQmkyCTiGggBud3FRcokPUk30NZqZ7i6h8TfTEzK7YGTx+6eKJCIb1r1D6jIh
Mxar8flDDPlz0/tlFybZJdwQlEPxaKNQlC8IuuOC6BtRyjs6Ri5LnV/AJ1HVPoPs
XqLvRaMUXlES0Q2I3vEgNSc9+toISfX2bzVNt/5+uWATgZyjdlwWNBhy6WhSKGol
hkd/7LLEB1Dmcc2IH+bUZ/Zvz0mZJzhqcHfEY7nDvzkoq9r+IQQslmc0QIqHHKml
O2B4oSujp6KyfYdmT+M5mMVzv9dePYyFd4qlR8/J7bqORprWhVZ2mvvN7bwKyJu7
/DGnNMGlWu4nCbPfHtQSG1T0JGK1/R/PadLJVUx3DmIrCK1fF5WEOu3Et2pllafx
z/NZn5m/C+4D4IE3y2X78mj81t8m2UVST1IWOWDuS7d3XA7O1nZOF3QDFE5lceta
mtD14RFgDa8p9EjQ2YGftptZguUzCM3gahpm9zhTyVnxfIBUNdkBLYo20gCsPbMt
B/aiwixnc2Lust+oFYMPcbXFJJObNH8zC7bASzUw3E7otY14SFNYdmU0CtWttNNi
SXLwiszcvimbb0HAxwyab0NLuMvjFP/mdBvXylcCo733omGX8pU=
=5fu+
-END PGP SIGNATURE-

Bug#919620: python-gpiozero typo in package description.

[peter green]

Package: python-gpiozero
Version: 1.3.1.post1-1
Severity: minor

In the long descriptions for the python-gpiozero and python3-gpiozero packages 
Raspberry is misspelled as Raspoberry

Bug#919536: surf: Warnings and AppError audit messages about GPU

[Reiner Herrmann]

Hi Leo,

On Thu, Jan 17, 2019 at 12:13:56AM +, Leo Singer wrote:
> My apologies for spamming you with a bunch of different AppArmor issues.
> I am trying to understand and differentiate the issues myself; please
> let me know if it would be better for me just to send you a list of all
> of the errors.

your reports are very appreciated! Thank you for doing that.

> There are several error messages related to GL and Mesa, which I'm
> trying to understand better because of broader GPU stability issues
> on my Raspberry Pi 3B+. When I start surf, I see the following warnings:
> 
> libGL error: MESA-LOADER: failed to retrieve device information
> MESA-LOADER: failed to retrieve device information
> MESA-LOADER: failed to retrieve device information

Do you notice any issues (e.g. degraded performance) because of this?

> [ 6898.198526] audit: type=1400 audit(1547682794.480:160): apparmor="DENIED" 
> operation="open" profile="/usr/bin/surf" name="/sys/class/video4linux/" 
> pid=6003 comm="gst-plugin-scan" requested_mask="r" denied_mask="r" fsuid=1000 
> ouid=0

There is an "abstractions/video" that I can include to allow access to
this directory.

> [ 6906.716855] audit: type=1400 audit(1547682802.996:161): apparmor="DENIED" 
> operation="open" profile="/usr/bin/surf" 
> name="/sys/devices/platform/soc/soc:gpu/uevent" pid=5984 
> comm="ositorWorkQueue" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
> [ 6906.720022] audit: type=1400 audit(1547682802.996:162): apparmor="DENIED" 
> operation="open" profile="/usr/bin/surf" 
> name="/sys/devices/platform/soc/soc:gpu/uevent" pid=5984 
> comm="ositorWorkQueue" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
> [ 6906.720086] audit: type=1400 audit(1547682802.996:163): apparmor="DENIED" 
> operation="open" profile="/usr/bin/surf" 
> name="/sys/devices/platform/soc/soc:gpu/uevent" pid=5984 
> comm="ositorWorkQueue" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
> [ 6906.720111] audit: type=1400 audit(1547682802.996:164): apparmor="DENIED" 
> operation="open" profile="/usr/bin/surf" 
> name="/sys/devices/platform/soc/soc:gpu/uevent" pid=5984 
> comm="ositorWorkQueue" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
> [ 6908.851155] audit: type=1400 audit(1547682805.132:165): apparmor="DENIED" 
> operation="open" profile="/usr/bin/surf" 
> name="/sys/devices/platform/soc/soc:gpu/uevent" pid=5984 
> comm="ositorWorkQueue" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
> [ 6908.852661] audit: type=1400 audit(1547682805.132:166): apparmor="DENIED" 
> operation="open" profile="/usr/bin/surf" 
> name="/sys/devices/platform/soc/soc:gpu/uevent" pid=5984 
> comm="ositorWorkQueue" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
> [ 6908.852715] audit: type=1400 audit(1547682805.132:167): apparmor="DENIED" 
> operation="open" profile="/usr/bin/surf" 
> name="/sys/devices/platform/soc/soc:gpu/uevent" pid=5984 
> comm="ositorWorkQueue" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
> [ 6908.852745] audit: type=1400 audit(1547682805.132:168): apparmor="DENIED" 
> operation="open" profile="/usr/bin/surf" 
> name="/sys/devices/platform/soc/soc:gpu/uevent" pid=5984 
> comm="ositorWorkQueue" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

Does it help if /sys/devices/platform/soc/soc:gpu/* is allowed for reading?
Or will there be additional errors?

Regards,
  Reiner


signature.asc
Description: PGP signature

Bug#919618: [shutter] Error while adding the file monitor.

[Marco Righi]

Package: shutter
Version: 0.93.1-1.3
Severity: important

--- Please enter the report below this line. ---
A discussion of the bug is  here

https://bugs.launchpad.net/debian/+bug/1003185



--- System information. ---
Architecture: Kernel:   Linux 4.9.0-8-amd64

Debian Release: 9.6
  500 xenial  updates.signal.org   500 stable-updates
ftp.it.debian.org   500 stable  security.debian.org   500 stable
 repo.skype.com   500 stable  packages.microsoft.com
500 stable  ftp.it.debian.org   500 stable
dl.google.com   500 stable  deb.debian.org   500 cosmic
 ppa.launchpad.net   100 stretch-backports ftp.it.debian.org
--- Package information. ---
Depends  (Version) | Installed
==-+-===
libgtk2-perl   | 2:1.2499-1
libglib-perl   | 3:1.324-1
libgnome2-perl | 1.046-3+b1
libgnome2-vfs-perl | 1.082-1+b3
libgnome2-wnck-perl| 0.16-3+b3
libgnome2-gconf-perl   | 1.044-6+b1
liblocale-gettext-perl | 1.07-3+b1
libxml-simple-perl | 2.22-1
libwww-mechanize-perl  | 1.83-1
libwww-perl| 6.15-1
perlmagick | 8:6.9.7.4+dfsg-11+deb9u6
libx11-protocol-perl   | 0.56-7
librsvg2-common| 2.40.16-1+b1
libfile-basedir-perl   | 0.07-1
libfile-copy-recursive-perl| 0.38-1
libproc-simple-perl| 1.32-1
libfile-which-perl | 1.21-1
libsort-naturally-perl | 1.03-1
libgtk2-imageview-perl | 0.05-2+b3
libnet-dbus-perl   | 1.1.0-4+b1
libgnome2-canvas-perl  | 1.002-4+b1
imagemagick| 8:6.9.7.4+dfsg-11+deb9u6
libgtk2-unique-perl| 0.05-2+b3
libproc-processtable-perl  | 0.53-2
procps | 2:3.3.12-3+deb9u1
xdg-utils  | 1.1.1-1+deb9u1
libpath-class-perl | 0.37-1
libjson-perl   | 2.90-1
libjson-xs-perl| 3.030-1
libnet-dropbox-api-perl| 1.9-1
libx11-protocol-other-perl | 29-2


Recommends (Version) | Installed
-+-===
libgoo-canvas-perl   | 0.06-2+b3
libgtk2-appindicator-perl| 0.15-1+b4


Suggests(Version) | Installed
=-+-===
gnome-web-photo   | 0.10.6-1+b1
nautilus-sendto   | 3.8.4-2+b1
libimage-exiftool-perl| 10.40-1
libnet-dbus-glib-perl | 0.33.0-2+b1
-- 
--
Think Marco, think different

Bug#915248: Done in sid

[Mathieu Parent]

Control; fixed -1 2:4.8.5+dfsg-1
Control: notfound -1 4.5.12
Control: found -1 2:4.5.12+dfsg-1

This bug is fixed in sid. I'm preparing a fix for stretch.

Regards
-- 

Mathieu Parent

Bug#919617: python-gpiozero file conflict with python3-gpiozero

[Peter Green]

Package: python-gpiozero
Version: 1.4.1-1
Severity: serious

The 1.4.1-1 upload of gpiozero added the "pinout" utility, unfortunately it 
added it to both the python-gpiozero and python3-gpiozero packages. The result is a file 
conflict between the two packages.

I see two possible solutions.

1. Drop the utility from one of the packages, if going down this road I would 
probablly drop it from the python-gpiozero package since python 2 is deprecated.
2. Install the utility with a different name or path in each package and then 
use the alternatives mechanism to select between them.

Bug#919507: Reboot required patch for Debian policy

[Karl O. Pinc]

Hi,

Attached is: reboot_required_v2.patch

On Thu, 17 Jan 2019 09:10:16 -0600
"Karl O. Pinc"  wrote:

> Documents /var/run/reboot-required and
> /var/run/reboot-required.pkgs.

Like v1 of the patch but adds index entries.
It's not clear if this is desirable because
they would be the only index entries.

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein
diff --git a/policy/ch-maintainerscripts.rst b/policy/ch-maintainerscripts.rst
index 707f2d4..5942123 100644
--- a/policy/ch-maintainerscripts.rst
+++ b/policy/ch-maintainerscripts.rst
@@ -92,6 +92,32 @@ for failure, since the package management system looks for the exit
 status of these scripts and determines what action to take next based on
 that datum.
 
+.. index::
+   pair: signaling; reboot
+
+.. _s-signalingreboot
+
+Signaling that a reboot is required
+---
+
+.. index::
+   single: reboot-required
+   single: reboot-required.pkgs
+
+Maintainer scripts can signal that a reboot is required to fully apply
+the changes to the system by touching ``/var/run/reboot-required`` and
+adding the package name to
+``/var/run/reboot-required.pkgs``. Maintainer scripts should not add
+the package name to ``/var/run/reboot-required.pkgs`` if it is already
+present there.
+
+The appropriate place to do this is expected to be when the
+``postinst`` script is called as ``postinst configure
+most-recently-configured-version``.
+
+Ordinary programs may manipulate these files to signal that a reboot
+is required.
+
 .. _s-mscriptsinstact:
 
 Summary of ways maintainer scripts are called

Bug#919616: Does pxz still make sense?

[Adrian Bunk]

Package: pxz
Severity: normal

Since version 5.2.0 released in 2014 (and shipped in stretch)
xz also supports -T, which makes me wonder whether there is
any usecase left for pxz.

Bug#919537: surf: fails to download files due to AppArmor profile

[Reiner Herrmann]

On Wed, Jan 16, 2019 at 07:50:56PM -0500, Leo Singer wrote:
> I am unable to download files with surf. When I follow a link that
> should trigger a download, such as a link to a .tar.gz file, I see this
> error message in the terminal:
> 
> surf: execvp x-terminal-emulator failed: Permission denied
> 
> And I see this AppArmor audit message:
> 
> [10250.579596] audit: type=1400 audit(1547686146.856:308): apparmor="DENIED" 
> operation="exec" profile="/usr/bin/surf" name="/usr/bin/lxterm" pid=17839 
> comm="surf" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0

Hm, I think this is a case for a local addition in 
/etc/apparmor.d/local/usr.bin.surf.
I don't think it makes much sense to whitelist all terminal emulators
available in Debian.
I have added st(term) to the profile as it is likely also used by people
using surf (as it's also a "suckless" project).

Would a local profile addition be acceptable for you?
Do you think it needs additional documentation in surf, or is the
avilable apparmor documentation sufficient for that?

Regards,
  Reiner


signature.asc
Description: PGP signature

Bug#919395: mysql_time.h

[Faustin Lammler]

Otto,
here are the issues opened to notify upstream devs about Sergei's
analysis:
https://github.com/OpenSIPS/opensips/issues/1589
https://github.com/keplerproject/luasql/issues/108
https://github.com/jabberd2/jabberd2/issues/193
https://redmine.kannel.org/issues/795

In addition, as requested, every maintainer was notified through BR
platform.

Regarding 919375 and 919408, can you @Sergei confirm this
https://github.com/monitoring-plugins/monitoring-plugins/pull/1522 and
this https://github.com/monitoring-plugins/monitoring-plugins/pull/1522?

Faustin

Bug#919615: Please release a new version of python-apt to solve software-properties-gtk issues in buster

[Andrew Hayzen]

Package: python-apt
Version: 1.7.0

When using software-properties-gtk on Debian Buster the repositories
list (to enable or disable main, contrib, and non-free) remains
unchecked even though I have main enabled in /etc/apt/sources.list .

I have been informed that a future unreleased commit in python-apt [0]
resolves this issue.

Would it be possible to make a release of python-apt so that this issue
can be fixed into Debian Buster?


This bug was found after installing the 2019-01-16 weekly testing live
image [1].

0 - 
https://salsa.debian.org/apt-team/python-apt/commit/0b49cb9467fa9cecec1ff654549e003be506ea0b
1 - 
https://get.debian.org/images/weekly-live-builds/amd64/iso-hybrid/debian-live-testing-amd64-gnome.iso

Bug#856413: gpiozero: please provide python module on all architectures

[peter green]

tags 856413 +patch
thanks

As part of preparing for opening up the architecture lists for gpiozero I 
researched what there is in the way of raspberry pi detection.

If no backend is explicitly specified gpiozero tries the following four 
backends in-order. 'rpigpio', 'rpio', 'pigpio', 'native'

'rpigpio' relies on the rpi.gpio library which is packaged in Debian but only 
for arm*, it has some attempt at rpi detection but it looks like it could 
suffer from false positives in some cases. I will file a bug report about that 
with rpigpio upstream.
'rpio' relies on the rpio library which is not Packaged in Debian, so it's 
unlikely it would get installed on non-pi hardware. It looks to be a basically 
dead project anyway. I will bring this up with upstream.
'pigpio' is a client-server set-up. If the server is running on something other 
than a Pi you probablly already have big problems whether gpiozero talks to it 
or not. In practice though the server is almost certain to bail out on anything 
other than a Pi running a foundation kernel because of the lack of the broadcom 
mailbox interface.

So that leaves the "native" backend. Since this is pure python and part of gpiozero it is 
likely to attempt to load on any system. I was struggling to trace through the code, so I decided 
to actually try running it on an x86-64 system. It failed with "unable to determine peripheral 
base". Searching the code found.

try:
with io.open('/proc/device-tree/soc/ranges', 'rb') as f:
f.seek(4)
return struct.unpack(nstr('>L'), f.read(4))[0]
except IOError:
with io.open('/proc/cpuinfo', 'r') as f:
for line in f:
if line.startswith('Hardware'):
try:
return 
self.PERI_BASE_OFFSET[line.split(':')[1].strip()]
except KeyError:
raise IOError('unable to determine RPi revision')
raise IOError('unable to determine peripheral base')

The second part of this code is reasonably robust. It will almost certainly 
produce an error unless one of the known raspberry pi SoC names shows up.

The first part is more concerning. It basically assumes that if it can read 
from a certain offset /proc/device-tree/soc/ranges that the device in question 
is a Pi. This is not a good assumption but it is far more likely to be a 
problem on other arm devices than it is other architectures.

Overall I think while there are improvements to Raspberry pi detection that can 
and should be made, opening up the architecture list will not significantly 
increase the risk. So such improvements should not be a blocker for doing so.

This brings us on to the next issue, package metadata.

I have kept the rpi.gpio dependencies, but architecture qualified them with a 
list of arm architectures. You may wish to downgrade these to a Recommends but 
I will leave that up to you.

I made python{3}-pigpio a recommends on non-arm architectures and a suggests on 
arm architectures since the main use of gpiozero on non-arm architectures is 
remote gpio control.

I was sucessfully able to use the python3-gpiozero package built with these 
changes in conjunction with python3-pigpio to remotely control the GPIO of a pi 
over the network.

While I was working on this I discovered that the rpi.gpio dependencies were 
bogus, they were depending on the -common package, not the actually python 
packages. So I fixed that at the same time as adding the architecture lists.

Debdiff attatched, no immediate intent to NMU.

diff -Nru gpiozero-1.4.1/debian/changelog gpiozero-1.4.1/debian/changelog
--- gpiozero-1.4.1/debian/changelog 2019-01-13 14:13:03.0 +
+++ gpiozero-1.4.1/debian/changelog 2019-01-17 15:34:15.0 +
@@ -1,3 +1,14 @@
+gpiozero (1.4.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Open up architecture list.
+  * Change nonsensical rpi.gpio-common dependency to 
python-rpi.gpio/python3-rpi.gpio
+and limit it's architecture list to arm*
+  * Recommend python-pigpio/python3-pigpio on non-arm architectures.
+  * Suggest python-pigpio/python3-pigpio on arm architectures.
+
+ -- Peter Michael Green   Thu, 17 Jan 2019 15:34:15 +
+
 gpiozero (1.4.1-1) unstable; urgency=medium
 
   * Move to Salsa.
diff -Nru gpiozero-1.4.1/debian/control gpiozero-1.4.1/debian/control
--- gpiozero-1.4.1/debian/control   2019-01-13 14:12:32.0 +
+++ gpiozero-1.4.1/debian/control   2019-01-17 15:34:15.0 +
@@ -21,11 +21,15 @@
 Vcs-Browser: https://salsa.debian.org/raspi-team/gpiozero
 
 Package: python-gpiozero
-Architecture: arm64 armel armhf
+Architecture: any
 Depends:
- rpi.gpio-common,
+ python-rpi.gpio [armel armhf arm64],
  ${misc:Depends},
  ${python:Depends},
+Recommends:
+ python-pigpio [!armel !armhf !arm64]
+Suggests:
+ python-pigpio [armel armhf arm64]
 Description: simple interface to ev

Bug#919609: minetest-mod-pycraft: FTBFS in sid (module 'socket.cx64' not found)

[Santiago Vila]

Package: src:minetest-mod-pycraft
Version: 0.20+git20180331.0376a0a+dfsg-1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in sid but it failed:


[...]
 debian/rules build-indep
dh build-indep
   dh_update_autotools_config -i
   dh_autoreconf -i
   debian/rules override_dh_auto_test
make[1]: Entering directory 
'/<>/minetest-mod-pycraft-0.20+git20180331.0376a0a+dfsg'
busted .
*
0 successes / 0 failures / 1 error / 0 pending : 0.002579 seconds

Error -> ./socket.lua @ 21
suite ./tests/pycraft_spec.lua
./socket.lua:21: module 'socket.cx64' not found:
no field package.preload['socket.cx64']
no file '../socket/cx64.lua'
no file './src/socket/cx64.lua'
no file './src/socket/cx64/socket/cx64.lua'
no file './src/socket/cx64/init.lua'
no file '/usr/local/share/lua/5.2/socket/cx64.lua'
no file '/usr/local/share/lua/5.2/socket/cx64/init.lua'
no file '/usr/local/lib/lua/5.2/socket/cx64.lua'
no file '/usr/local/lib/lua/5.2/socket/cx64/init.lua'
no file '/usr/share/lua/5.2/socket/cx64.lua'
no file '/usr/share/lua/5.2/socket/cx64/init.lua'
no file './socket/cx64.lua'
no file 'some/path/socket/cx64.lua'
no file './csrc/socket/cx64.so'
no file './csrc/socket/cx64/socket/cx64.so'
no file '/usr/local/lib/lua/5.2/socket/cx64.so'
no file '/usr/lib/x86_64-linux-gnu/lua/5.2/socket/cx64.so'
no file '/usr/lib/lua/5.2/socket/cx64.so'
no file '/usr/local/lib/lua/5.2/loadall.so'
no file './socket/cx64.so'
no file 'some/path/socket/cx64.so'
no file './csrc/socket.so'
no file './csrc/socket/socket.so'
no file '/usr/local/lib/lua/5.2/socket.so'
no file '/usr/lib/x86_64-linux-gnu/lua/5.2/socket.so'
no file '/usr/lib/lua/5.2/socket.so'
no file '/usr/local/lib/lua/5.2/loadall.so'
no file './socket.so'
no file 'some/path/socket.so'
make[1]: *** [debian/rules:14: override_dh_auto_test] Error 1
make[1]: Leaving directory 
'/<>/minetest-mod-pycraft-0.20+git20180331.0376a0a+dfsg'
make: *** [debian/rules:4: build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


The build was made in my autobuilder with "dpkg-buildpackage -A"
and it also fails here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/minetest-mod-pycraft.html

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#919395: mysql_time.h

[Faustin Lammler]

Faustin Lammler ,
17/01/2019 - 19:23:00 (-0300):

> Regarding 919375 and 919408, can you @Sergei confirm this
> https://github.com/monitoring-plugins/monitoring-plugins/pull/1522 and
> this https://github.com/monitoring-plugins/monitoring-plugins/pull/1522?
And this
https://github.com/monitoring-plugins/monitoring-plugins/issues/1508#issuecomment-334528542

Bug#917758: jabberd2: FTBFS: mysql-related errors

[Faustin Lammler]

Control: forwarded -1 https://github.com/jabberd2/jabberd2/issues/193

Hi Lucas,
please see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919395#36:
> error: 'MYSQL' {aka 'struct st_mysql'} has no member named 'reconnect'
> 
> This is not a bug. MYSQL.reconnect was not part of the API, even in 5.5
> https://dev.mysql.com/doc/refman/5.5/en/c-api-auto-reconnect.html

Your relevant error seems to be (without terminal coloration ;-)):

authreg_mysql.c: In function 'ar_init':
authreg_mysql.c:631:9: error: 'MYSQL' {aka 'struct st_mysql'} has no member 
named 'reconnect'
 conn->reconnect = 1;

Regards,
Faustin

Bug#919373: kannel: FTBFS with mariadb-10.3: gwlib/utils.c:602:14:

[Faustin Lammler]

Control: forwarded -1 https://redmine.kannel.org/issues/795

Hi,
This seems to be a bug (see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919395#36):

> error: 'MYSQL_SERVER_VERSION' undeclared
> 
> this looks like a bug. MYSQL_SERVER_VERSION is documented here:
> https://dev.mysql.com/doc/refman/5.5/en/c-api-server-client-versions.html

Regards,
Faustin

Bug#918393: opensips FTBFS with MariaDB 10.3

[Faustin Lammler]

Hi Adrian,
in case you did not saw this:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919395#36

> error: 'MYSQL' {aka 'struct st_mysql'} has no member named 'reconnect'
> 
> This is not a bug. MYSQL.reconnect was not part of the API, even in 5.5
> https://dev.mysql.com/doc/refman/5.5/en/c-api-auto-reconnect.html

Regards,
Faustin

Bug#919535: surf: AppArmor profile forbids access to publicsuffix data

[Reiner Herrmann]

Hi Leo,

On Thu, Jan 17, 2019 at 12:06:38AM +, Leo Singer wrote:
> surf is not able to access the following two files due to its apparmor
> profile:
> 
> [ 5565.325749] audit: type=1400 audit(1547681461.606:127): apparmor="DENIED" 
> operation="open" profile="/usr/bin/surf" 
> name="/usr/share/publicsuffix/public_suffix_list.dafsa" pid=29897 
> comm="WebKitNetworkPr" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
> [ 5565.328420] audit: type=1400 audit(1547681461.610:128): apparmor="DENIED" 
> operation="open" profile="/usr/bin/surf" 
> name="/usr/share/publicsuffix/public_suffix_list.dat" pid=29897 
> comm="WebKitNetworkPr" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

Interesting, I didn't see those on my system at first.
But after installing the publicsuffix package I can see them as well.

> I have included a patch.

Thanks! I will apply it in the next upload.

Regards,
  Reiner


signature.asc
Description: PGP signature

Bug#919534: surf: AppArmor profile forbids creation of ~/.cache directory

[Reiner Herrmann]

Hi Leo,

On Thu, Jan 17, 2019 at 12:01:54AM +, Leo Singer wrote:
> The AppArmor profile for surf prevents it from creating the ~/.cache
> directory. This might be a rare corner case since it is only likely
> to occur if surf is almost the first program that the user runs after
> they create the account. There is a simple workaround of just creating
> the ~/.cache directory before running surf.

thanks for the report.
I will allow creation of ~/.cache in the profile.

Regards,
  Reiner


signature.asc
Description: PGP signature

Bug#919614: RFS: note/1.3.26-2 [ITA]

[eamanu15]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: note
 Version : 1.3.26-2
 Upstream Author : Thomas von Dein 
* URL : http://www.daemon.de/NOTE
* License : Gnu Public License(GPL)
 Section : utils

It builds those binary packages:

  note  - small program managing notes from commandline

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

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


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

  dget -x
https://mentors.debian.net/debian/pool/main/n/note/note_1.3.26-2.dsc

More information about note can be obtained from http://www.daemon.de/NOTE

Changes since the last upload:

* New Maintainer (Closes: 900663).
  - Add me to Maintainer Field on d/control.
  - Update Vcs-* field to my own repo.
  - Add me to Copyright field for debian/* files.


Regards,
 Emmanuel Arias

-- 
Arias Emmanuel
http://eamanu.com
Github/Gitlab; @eamanu
Debian: @eamanu-guest

Bug#907072: lintian: verify AppStream metainfo metadata_license matches debian/copyright

[Chris Lamb]

tags 907072 - moreinfo
tags 907072 + pending
thanks

Hi Daniel,

> Sorry, i'm confused by this question.  The source file
> debian/org.gnupg.scdaemon.metainfo.xml itself is what shows up in
> /usr/share/metainfo/.  this file states that its own license is CC0-1.0,
> as does debian/copyright.  What information is missing?
> 
> sorry to be dense,

No, it was me being dense.

I was thinking that because it is somewhat unrealistic for Lintian
to reliably work out where an *installed* XML file came from in the
source tree (dh_install isn't the only way to install files, after
all) then it would be difficult to reverse-map them back and do the
check.

However, this is not required if we simply check all such files.
Implemented in 0324556c2, pending upload.


Best wishes,

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

Bug#918387: lua-sql FTBFS with MariaDB 10.3

[Faustin Lammler]

Control: forwarded -1 https://github.com/keplerproject/luasql/issues/108

Hi,
in case you did not saw this:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919395#36

> this looks like a bug. MYSQL_SERVER_VERSION is documented here:
> https://dev.mysql.com/doc/refman/5.5/en/c-api-server-client-versions.html

Regards,
Faustin

Bug#919162: lintian.d.o apears to report many failures twice

[Chris Lamb]

Ian Campbell wrote:

> > aapt 1:8.1.0+r23-3 (binary) ($maintainer)
> > 
> > * usr/lib/android-sdk/build-tools/debian/aapt [amd64, i386]
> > * usr/lib/android-sdk/build-tools/debian/aapt2
> 
> That's what I was thinking for the ideal case too.

(This is probably the same effort as the separate "[amd64]" and
"[i386]" lines; its the duplicate detection and updating the data
structures that will be problematic, if anything.)

Niels, any tips/pointers on how I get a very very simple reporting
framework running locally? Perhaps even just one package? I've been
previously just making my changes here blind...


Regards,

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

Bug#911329: add .libretro metadata for better integration with gnome-games

[Jeremy Bicha]

Hi Sérgio,

It's been a while since we last discussed GNOME Games integration with
libretro cores.

I would like to add the Appstream metadata and .libretro files to 9
libretro cores in Debian. 4 of these have already been done in Ubuntu
and would have been done in Debian too except you objected previously.
Would you be willing to reconsider? Currently, gnome-games-app is a
lot more useful on Ubuntu than on Debian because of this issue.

Also, I think it would be useful if we had a git repository for the
Debian packaging for these libretro cores.

Thanks,
Jeremy Bicha

Bug#132542: sysvinit: please make /etc/init.d/rcS a conffile

[Adam Borowski]

On Thu, Jan 17, 2019 at 09:28:38PM +, Dmitry Bogatov wrote:
> > [Pierre Ynard]
> > My personal feelings here would be similar to Thorsten's, but what I
> > would put forward is that considering how critical a component of the
> > system init is, perhaps it's best to strive for robustness for now.
> 
> Wow. So strong reaction. Fine. Collegues, I understand your attitude.
> You have some setup, with separate / and /usr, without initramfs, and
> you do not want change anything.

That ship has long since sailed.  What's the point of making sysv-rc support
non-/usr early boot if the rest of the system doesn't?  It may still work on
some simple installs, but even that quite rapidly degrades as random
packages get changed to simplify this away.

>   Okay. I moved {rc, rcS} to /lib (see commit 51170798), change will be
>   in 2.93-4 (due in few days). Sysvinit will *not* assume, that /usr is
>   mounted at /sbin/init invocation in Buster. I promise.

That's a waste of your time.  Both for and after Buster.

If someone insists to pretend / vs /usr on separate fs without initramfs
would be supported for Buster, I strongly recommend to revert that commit
for now, then move to a final position after Buster.  Any such transition is
risky, failures causing a machine to be unbootable, thus the cost of moving
twice is nasty.

> But what next? Assumption of mounted /usr simplify things.  You can take
> a look at #551555, but I do not think this is singular case. Two-part
> mount process complicates initscripts for, well, what?

I have yet to hear any use case.

> I do understand dislike of initramfs, but I do not understand why
> separate / and /usr. So,
> 
>  * what are benefits of setup without initramfs *and* with separate /usr
>partition on *fresh installation*?

That you may hop onto a time machine with a modern install media but no
modern hardware?  I'm not aware of any widespread machines that have ~2GB of
fast local storage with the rest separate.  If there's a separate boot
media, it tends to have up to ~256MB tops, fit only for the kernel and
bootloader.  / can then sit on the same place as /usr.

Around a decade ago, Nokia installed _tiny_ boot disk and large eMMC into
N{7,8,9}00, but even then they found / vs /usr to be useless, and concocted
their own scheme.  Same happens for other setups from this millenium.

Another case: this cookie box I'm typing these words on:
https://angband.pl/tmp/rockcipa/cookies.jpg

It needs a SD card to boot before the NVME can be accessed.  You don't
really get SD cards below 16GB these days (and if you do, they're really
slow).  The whole system can comfortably fit on the SD card, but then, I
for some reason prefer /bin and /var to sit on the NVME rather than SD.

If someone could show us a case when early non-/usr boot makes sense, I'm
all ears.

>  * what are your arguments aganist usrmerge?

I'd reverse the question: what are your arguments _for_ usrmerge?  On the
lengthy flamewars on debian-devel I haven't heard any.  It moves files
around for no gain, actively breaking important things like building
packages.  Its proponents tend to conflate dropping early non-/usr boot
with symlinking /bin + /sbin + /lib.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands
⢿⡄⠘⠷⠚⠋⠀ for Privacy.
⠈⠳⣄

Bug#919613: python-apt: Please release a new version of python-apt to solve software-properties-gtk issues in buster

[Andrew Hayzen]

Package: python-apt
Version: 1.7.0

When using software-properties-gtk on Debian Buster the repositories
list (to enable or disable main, contrib, and non-free) remains
unchecked even though I have main enabled in /etc/apt/sources.list .

I have been informed that a future unreleased commit in python-apt [0]
resolves this issue.

Would it be possible to make a release of python-apt so that this issue
can be fixed into Debian Buster?


This bug was found after installing the 2019-01-16 weekly testing live
image [1].

0 - 
https://salsa.debian.org/apt-team/python-apt/commit/0b49cb9467fa9cecec1ff654549e003be506ea0b
1 - 
https://get.debian.org/images/weekly-live-builds/amd64/iso-hybrid/debian-live-testing-amd64-gnome.iso

Bug#919343: tdom FTCBFS: hard codes the wrong pkg-config,version graph

[Rolf Ade]

Could you please be a bit more specific about the problem: tDOM with
which configure flags cross-compilied on what platform for which
target platform does not build? If only to give me a chance to check
that your patch fixes the problem.

If I patch tDOM with your code it still builds correct for me (with
--enable-html5, which, from your patch, do you use and is the culprit,
and without and so on). So I'm somewhat tempted to check-in, if I have
evidence that this does otherwise good.

I've to confess that for the build system I mostly cargo cult TEA.
Could you please explain in short how "tdom confuses the meaning of
aclocal.m4 and acinclude.m4 and therefore [you] cannot run aclocal"?

Bug#919500: golang-github-grpc-ecosystem-grpc-gateway: build dependency on golang-google-genproto-dev must be bumped to (>= 0.0~git20190111.db91494)

[Dr. Tobias Quathamer]

Am 17.01.2019 um 06:09 schrieb Arnaud Rebillout:
>   Dear Go team,
> 
> I pushed a fix on Salsa, can you please review and upload these changes?
> Thanks!

Hi Arnaud,

thanks for your fix, it's uploaded now with a minor change
(I've removed the Debian version "-1" from the build dependency
golang-goprotobuf-dev).

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#918163: Broken in Stretch

[Moritz Mühlenhoff]

On Thu, Jan 17, 2019 at 12:39:26PM +, Martín Ferrari wrote:
> tags 918163 stretch
> thanks
> 
> 
> On 03/01/2019 22:18, Moritz Muehlenhoff wrote:
> 
> > The plugin is broken with Thunderbird 60 in stretch, after installation
> > it's disabled and only prints "Sieve is incompatible with Thunderbird 60.4".
> 
> There is something I only realise now about this.. The version already
> in buster works OK, I thought I needed to update to 3.0 (which I will do
> anyway for sid), what would be preferred for stable-updates?

For stable-proposed-updates such Xul extensions are usually bumped to the
latest version, see the release.debian.org pseudo bug for some examples.

Cheers,
Moritz

Bug#919529: CVE-2019-6256

[Moritz Mühlenhoff]

On Thu, Jan 17, 2019 at 12:00:13AM +0100, Sebastian Ramacher wrote:
> Control: found -1 2016.11.28-1
> 
> On 2019-01-16 23:19:45, Moritz Muehlenhoff wrote:
> > Source: liblivemedia
> > Severity: grave
> > Tags: security
> > 
> > Please see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6256
> > 
> > Cheers,
> > Moritz
> 
> Not sure if I'm missing something, but the PoC does not seem to work on
> buster/sid.

Quite possible, I hadn't reproduced it myself yet and upstream homepage
wasn't that obvious wrt existing fixes.

Cheers,
Moritz

Bug#919611: Memory leak in ntlm_auth

[Mathieu Parent]

Package: winbind
Version: 2:4.5.12+dfsg-1
Control: forwarded -1 https://bugzilla.samba.org/show_bug.cgi?id=12736
Control: fixed -1 2:4.7.0+dfsg-1
Control: found -1 2:4.2.14+dfsg-0+deb8u9

Hello,

I plan to fix this bug in Debian stretch.

See https://bugzilla.samba.org/show_bug.cgi?id=12736

Regards
-- 
Mathieu Parent

Bug#898689: ITP: golang-github-ostreedev-ostree-go -- Golang bindings for httt://github.com/ostreedev/ostree

[Reinhard Tartler]

Hi Juan,

Thank you for your work on the package. I'm happy to sponsor uploads to
Debian for you as necessary.

Did you see my question in my previous email regarding whether skopeo also
works with the sjoerdsimons fork that we currently have in Debian? If it
would, I think Debian would be better of with a single copy in the archive.

Let me know what you think.

On Thu, Jan 17, 2019 at 9:39 AM Juan Picca  wrote:

> Hi Reinhard.
>
> As commented previously, I update the package to the version currently
> used by skopeo (56f3a63).
> If you can upload the files tell me and i send you the build results.
> If not please give me some time to find a sponsor to upload the package.
>
> Regards,
> JMPC
>


-- 
regards,
Reinhard

Bug#919610: insserv.8: Corrections of formatting and macro use in the manual

[Bjarni Ingi Gislason]

Package: insserv
Version: 1.18.0-1
Severity: minor
Tags: patch

Dear Maintainer,

Input file is insserv.8

mandoc: insserv.8:104:28: STYLE: whitespace at end of input line
mandoc: insserv.8:127:46: STYLE: whitespace at end of input line
mandoc: insserv.8:21:15: STYLE: normalizing date format to: July 29, 2008
mandoc: insserv.8:52:2: WARNING: skipping paragraph macro: PP empty
mandoc: insserv.8:331:2: WARNING: empty block: RS

###

:291 (macro IR): only 1 argument, but more are expected
:304 (macro IR): only 1 argument, but more are expected
:306 (macro IR): only 1 argument, but more are expected
:335 (macro BR): only 1 argument, but more are expected



Change '-' (\-) to '\(en' (en-dash) for a numeric range.

insserv.8:410:2000\-2009 Werner Fink,
insserv.8:414:2000\-2003 SuSE GmbH Nuernberg, Germany,
insserv.8:416:2007\-2009 SuSE Linux Products GmbH Nuernberg, Germany.
insserv.8:418:2018\- Jesse Smith

#


Use "\e" to print the escape character instead of "\\" (which gets
interpreted in copy mode).

360:$.#%_+-\\*[]^:()~

#

Split a punctuation mark from a single argument for a two-fonts marco

335:.BR insserv:

#

Do'nt use ".in +7", as the default indent is different in nroff and groff.
The default unit is 'm', while 'n' is used in the man-macros.

#

Adjust space between sentences to two space characters (default in
roff).  This space can be changed in the output with the '.ss' request
in "groff".

Patch:

--- insserv.8   2018-12-12 22:32:47.0 +
+++ insserv.8.new   2019-01-17 22:50:06.0 +
@@ -18,7 +18,7 @@
 .\" along with this program; if not, write to the Free Software
 .\" Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
USA
 .\"
-.TH INSSERV 8 "Jul 29, 2008" "Version 1.11"
+.TH INSSERV 8 "July 29, 2008" "Version 1.11"
 .UC 8
 .SH NAME
 insserv \- boot sequence organizer using LSB init.d script dependency 
information
@@ -32,11 +32,15 @@ insserv \- boot sequence organizer using
 .RB [ \-f ]
 .RI [[ / ] path/to/init.d/ ] script \ ...
 .PP
+.\" avoid excessive space between words in troff caused by a long text string
+.nr AD \n(.j
+.ad l
 .B insserv
 .RB [ \-v ]
 .RB [ \-c\  ]
 .RB [ \-p\  ]
 .RI [[ / ] path/to/init.d/ ] script [ 
,start=,stop= ]
+.ad \n(AD
 .PP
 .B insserv
 .RB [ \-v ]
@@ -49,7 +53,6 @@ insserv \- boot sequence organizer using
 .PP
 .B insserv
 .B \-h
-.PP
 .SH DESCRIPTION
 .B insserv
 is a low level tool used by
@@ -76,7 +79,7 @@ init script (`boot script') by reading t
 .fi
 .in -1l
 .sp 1
-and calculating the dependencies between all scripts. It is not recommended to
+and calculating the dependencies between all scripts.  It is not recommended to
 execute insserv directly unless you know exactly what you're doing, doing so
 may render your boot system inoperable.
 .B update\-rc.d
@@ -101,9 +104,9 @@ tag.  Same holds true for
 .in -1l
 .sp 1
 which declares facilities which should be available during shutdown of
-the service declared in the 
+the service declared in the
 .B Provides
-tag. In both cases the script system should avoid stopping services
+tag.  In both cases the script system should avoid stopping services
 which are declared by these two Stop tags until the script including
 these tags is stopped.
 .PP
@@ -123,8 +126,8 @@ Whereas the optional
 keyword implies that the script using this keyword
 should be stopped
 .B after
-the specified service names. Both implies that those
-services now depend on the specifying script. 
+the specified service names.  Both implies that those
+services now depend on the specifying script.
 With known dependencies and runlevel(s)
 .B insserv
 sets and reorders the corresponding symbolic links
@@ -184,7 +187,7 @@ and ending with
 are keywords.  Currently
 .B 
 is the only know keyword for marking a service
-as an interactive one, e.g. a service which requires
+as an interactive one, e.g., a service which requires
 a passphrase or password input during boot
 or runlevel change.  The special facility
 .B $null
@@ -228,7 +231,7 @@ Specify path to init.d directory.  Usefu
 Do not update symlinks.
 .TP
 .BR \-s ,\  \-\-showall, \ \-\-show\-all
-Output runlevel and sequence information. Do not update symlinks.
+Output runlevel and sequence information.  Do not update symlinks.
 .TP
 .BR \-r ,\  \-\-remove
 Remove the listed scripts from all runlevels.
@@ -238,7 +241,7 @@ Use default runlevels as defined in the
 This may restore an edited runlevel link scheme.
 .TP
 .BR \-f ,\  \-\-force
-Ignore if a required service is missed. Beside this if start and or
+Ignore if a required service is missed.  Beside this if start and or
 stop levels are specified on the command line the default levels of
 the script will be ignored.
 .TP
@@ -271,7 +274,7 @@ has to be called from the root directory
 .TP
 .RI [[ / ] path/to/init.d/ ] script\ ...
 List of scripts which have to be added to
-the runlevels. If a path is used it
+the runlevels.  If a path is used it
 should po

Bug#919608: [winbind] Memory leak in ntlm_auth

[Mathieu Parent]

Package: winbind
Version: 2:4.5.12+dfsg-1

Control: forwarded -1 https://bugzilla.samba.org/show_bug.cgi?id=12736
Control: fixed -1 2:4.7.0+dfsg-1
Control: found -1 2:4.2.14+dfsg-0+deb8u9

Hello,

I plan to fix this bug in Debian stretch.

See https://bugzilla.samba.org/show_bug.cgi?id=12736

Regards

--
Mathieu Parent

Bug#919415: isight-firmware-tools: Build-Depends on cruft package libgcrypt11-dev

[Andreas Henriksson]

Control: tags -1 + patch
Control: forwarded -1 
https://salsa.debian.org/mactel-team/isight-firmware-tools/merge_requests/1

On Tue, Jan 15, 2019 at 03:15:57PM +0100, Andreas Beckmann wrote:
> Source: isight-firmware-tools
> Version: 1.6-3
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
> 
> isight-firmware-tools build-depends on libgcrypt11-dev. This was a
> transitional package, please use libgcrypt20-dev instead.

I can confirm the fix seems to be as simple as just replacing
libgcrypt11-dev with libgcrypt20-dev in the build-dependencies.
(Atleast the package builds, I haven't done any other tests.)

For your convenience I've submitted a merge request with the fix,
and as a bonus also the translation update see above.

Regards,
Andreas Henriksson

Bug#919594: memkind: baseline violation on amd64 (and FTBFS everywhere else)

[Adam Borowski]

On Thu, Jan 17, 2019 at 08:04:09PM +0200, Adrian Bunk wrote:
> Source: memkind
> Version: 1.8.0-1
> Severity: serious
> 
> https://buildd.debian.org/status/package.php?p=memkind&suite=sid
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/memkind.html
> 
> memkind builds for no apparent reason with -msse4.2,

Accent on "no apparent reason" -- there's only a single instruction,
called as : _mm_crc32_u64() -- and it's #ifdefed out.

> which is a baseline violation even on amd64.

I've verified that the 1.8.0-1 packages work ok on an AMD Phenom2 (ie,
without SSE4.2), thus there's no actual violation.  You're right that this
causes noise for people doing QA work like you, though, and it'd be good to
patch this away.

> Build failures on other architectures seem to be often
> related to using an internal copy of jemalloc instead
> of the version in Debian.

Yeah, I've looked into using shipped jemalloc; this was not an option at the
time I uploaded this to NEW as memkind needs jemalloc >= 5.0 which wasn't
available then and the transition seemed unlikely in time for Buster.  We do
actually have 5.1 in now, though -- but, I'm talking to upstream to see if
patches they applied atop of jemalloc are actually needed.  The one for
defrag seems unused, but I'm worried about the dlopen() one -- vanilla
jemalloc can't be dlopened because of something something too much TLS data. 
No idea if you've heard of this problem; I'm mentioning this in case you
did.

I prepared _apparently_ ok patches that fix this and all portability
problems for 64-bit archs, but only during some testing I noticed that those
"obviously correct" patches break something.  Thus, I'm asking upstream how
to run the testsuite on machines without any kind of special hardware
memkind is meant for so we have at least _some_ automated checks.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands
⢿⡄⠘⠷⠚⠋⠀ for Privacy.
⠈⠳⣄

Bug#919607: libqt5gui5: krita crashes with Wacom tablet at QTabletEvent destructor

[Mateus Barbosa]

Package: libqt5gui5
Version: 5.11.3+dfsg-2
Severity: important

Dear Maintainer,

krita now crashes with the message "free(): double free detected in tcache 2"
when a Wacom tablet is used.

Steps to reproduce:
- plug Wacom tablet in
- launch krita
- open new file
- place cursor inside canvas
- approach stylus from Wacom tablet

This is possibly related to upstream bug 
.

The backtrace shows the offending code seems to be at ~QTabletEvent():

Thread 1 "krita" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) backtrace
#0  0x74bb385b in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:50
#1  0x74b9e535 in __GI_abort () at abort.c:79
#2  0x74bf5728 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x74d0028d "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#3  0x74bfbe4a in malloc_printerr (str=str@entry=0x74d01f58 
"free(): double free detected in tcache 2") at malloc.c:5341
#4  0x74bfd92d in _int_free (av=0x7fffe420, p=0x7fffe4005ce0, 
have_lock=) at malloc.c:4193
#5  0x754fecd0 in QTabletEvent::~QTabletEvent() () at 
/usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#6  0x77118497 in  () at /usr/lib/x86_64-linux-gnu/libkritaui.so.17
#7  0x77112105 in  () at /usr/lib/x86_64-linux-gnu/libkritaui.so.17
#8  0x77112464 in  () at /usr/lib/x86_64-linux-gnu/libkritaui.so.17
#9  0x77116119 in  () at /usr/lib/x86_64-linux-gnu/libkritaui.so.17
#10 0x771197f8 in KisXi2EventFilter::nativeEventFilter(QByteArray 
const&, void*, long*) () at /usr/lib/x86_64-linux-gnu/libkritaui.so.17
#11 0x75142fcf in 
QAbstractEventDispatcher::filterNativeEvent(QByteArray const&, void*, long*) () 
at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#12 0x7fffed0a7cb0 in QXcbConnection::handleXcbEvent(xcb_generic_event_t*) 
() at /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#13 0x7fffed0a8843 in QXcbConnection::processXcbEvents() () at 
/usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#14 0x7516ef82 in QObject::event(QEvent*) () at 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#15 0x75abd491 in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
() at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#16 0x75ac4ad0 in QApplication::notify(QObject*, QEvent*) () at 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#17 0x7703bcd7 in KisApplication::notify(QObject*, QEvent*) () at 
/usr/lib/x86_64-linux-gnu/libkritaui.so.17
#18 0x75145479 in QCoreApplication::notifyInternal2(QObject*, QEvent*) 
() at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#19 0x7514846b in QCoreApplicationPrivate::sendPostedEvents(QObject*, 
int, QThreadData*) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#20 0x75197b23 in  () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#21 0x721f7e0e in g_main_context_dispatch () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#22 0x721f80a8 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#23 0x721f813c in g_main_context_iteration () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#24 0x75197153 in 
QEventDispatcherGlib::processEvents(QFlags) () 
at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#25 0x7fffed139861 in  () at /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#26 0x7514414b in 
QEventLoop::exec(QFlags) () at 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#27 0x7514c2c2 in QCoreApplication::exec() () at 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#28 0x55e8d937 in main ()

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

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

Versions of packages libqt5gui5 depends on:
ii  fontconfig2.13.1-2
ii  libc6 2.28-5
ii  libdrm2   2.4.95-1
ii  libegl1   1.1.0-1
ii  libfontconfig12.13.1-2
ii  libfreetype6  2.9.1-3
ii  libgbm1   18.2.8-2
ii  libgcc1   1:8.2.0-14
ii  libgl11.1.0-1
ii  libharfbuzz0b 2.3.0-1
ii  libice6   2:1.0.9-2
ii  libinput101.12.4-1
ii  libjpeg62-turbo   1:1.5.2-2+b1
ii  libmtdev1 1.1.5-1+b1
ii  libpng16-16   1.6.36-2
ii  libqt5core5a [qtbase-abi-5-11-3]  5.11.3+dfsg-2
ii  libqt5dbus5   5.11.3+dfsg-2
ii  lib

Bug#887399: stretch-pu: package python-certbot/0.10.2-1

[Brad Warren]

I just wanted to make sure this was still on everyone’s radar. The change 
server side where tens of thousands of Debian users will begin being unable to 
renew their certificates is in less than a month.

> On Jan 8, 2019, at 4:24 PM, Harlan Lieberman-Berg  wrote:
> 
> Hello Julien, everyone,
> 
> I've uploaded the relevant packages for your examination.  The
> packages uploaded are:
> 
> - python-acme_0.28.0-1+deb9u1
> - python-certbot_0.28.0-1+deb9u1
> - python-certbot-nginx_0.28.0-1+deb9u1
> - python-certbot-apache_0.28.0-1+deb9u1
> - python-josepy_1.1.0-2+deb9u1
> - parsedatetime_2.1-3+deb9u1
> 
> On Sun, Dec 2, 2018 at 7:55 PM Harlan Lieberman-Berg
>  wrote:
>> 
>> On Sun, Dec 2, 2018 at 10:48 AM Julien Cristau  wrote:
>>> OK, let's do that then.  Sorry for not getting back to this sooner.
>> 
>> Sounds good.  I'm preparing the uploads now.
>> 
>> It looks like I will need to rebuild the version of
>> python-parsedatetime in stable to also build the python3 version.  I
>> could also backport a newer version that builds python3.  Let me know.
>> 
>> Sincerely,
>> --
>> Harlan Lieberman-Berg
>> ~hlieberman
> 
> 
> 
> -- 
> Harlan Lieberman-Berg
> ~hlieberman
> 
> -- 
> To unsubscribe, send mail to 887399-unsubscr...@bugs.debian.org.
> 

Bug#919606: installation-reports: installation report

[lama]

Package: installation-reports
Severity: wishlist

Dear Maintainer,

I am just sending you installation report as suggested in the Installation 
Howto Appendix A section 4

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

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

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


-- Package-specific info:

Boot method: win32-loader.exe
Image version: I did not download any image myself, win32-loader.exe must have 
done that
Date: 01/01/2019 22:00

Machine: Clevo M860TU
Partitions: 
System plików  Typ  1K-blużyte dostępne %uż. zamont. na
udev   devtmpfs   20105520  2010552   0% /dev
tmpfs  tmpfs   40460411320   393284   3% /run
/dev/sda3  ext4  47797996  5225584 40114660  12% /
tmpfs  tmpfs  202300411332  2011672   1% /dev/shm
tmpfs  tmpfs 51204 5116   1% /run/lock
tmpfs  tmpfs  20230040  2023004   0% /sys/fs/cgroup
/dev/loop0 squashfs 91648916480 100% /snap/core/6130
/dev/sda5  fuseblk  104848188 76399708 28448480  73% /media/win_e
/dev/sda1  fuseblk   49279352 32181584 17097768  66% /media/win_c
/dev/sda6  ext4 103145368 23125096 74737712  24% /home
tmpfs  tmpfs   4046004   404596   1% /run/user/111
tmpfs  tmpfs   404600   12   404588   1% /run/user/1000


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

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

Comments/Problems:
dual boot, installation alongside Windows XP SP3
had to give acpi=rsdt parameter




-- 

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

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

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="9 (stretch) - installer build 20170615+deb9u5"
X_INSTALLATION_MEDIUM=netboot-gtk

==
Installer hardware-summary:
==
uname -a: Linux lusterko 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) 
x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Mobile 4 Series 
Chipset Memory Controller Hub [8086:2a40] (rev 07)
lspci -knn: Subsystem: CLEVO/KAPOK Computer Device [1558:0860]
lspci -knn: 00:01.0 PCI bridge [0604]: Intel Corporation Mobile 4 Series 
Chipset PCI Express Graphics Port [8086:2a41] (rev 07)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1a.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 
Family) USB UHCI Controller #4 [8086:2937] (rev 03)
lspci -knn: Subsystem: CLEVO/KAPOK Computer Device [1558:0860]
lspci -knn: Kernel driver in use: uhci_hcd
lspci -knn: Kernel modules: uhci_hcd
lspci -knn: 00:1a.1 USB controller [0c03]: Intel Corporation 82801I (ICH9 
Family) USB UHCI Controller #5 [8086:2938] (rev 03)
lspci -knn: Subsystem: CLEVO/KAPOK Computer Device [1558:0860]
lspci -knn: Kernel driver in use: uhci_hcd
lspci -knn: Kernel modules: uhci_hcd
lspci -knn: 00:1a.2 USB controller [0c03]: Intel Corporation 82801I (ICH9 
Family) USB UHCI Controller #6 [8086:2939] (rev 03)
lspci -knn: Subsystem: CLEVO/KAPOK Computer Device [1558:0860]
lspci -knn: Kernel driver in use: uhci_hcd
lspci -knn: Kernel modules: uhci_hcd
lspci -knn: 00:1a.7 USB controller [0c03]: Intel Corporation 82801I (ICH9 
Family) USB2 EHCI Controller #2 [8086:293c] (rev 03)
lspci -knn: Subsystem: CLEVO/KAPOK Computer Device [1558:0860]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: Kernel modules: ehci_pci
lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) 
HD Audio Controller [8086:293e] (rev 03)
lspci -knn: Subsystem: CLEVO/KAPOK Computer Device [1558:0860]
lspci -knn: Kernel driver in use: snd_hda_intel
lspci -knn: Kernel modules: snd_hda_intel
lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) 
PCI Express Port 1 [8086:2940] (rev 03)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.1 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) 
PCI Express Port 2 [8086:2942] (r

Bug#918966: new(?) backlight brightness script

[Dmitry Bogatov]

[2019-01-17 21:13] Thorsten Glaser 
> On Sat, 12 Jan 2019, Dmitry Bogatov wrote:
> 
> > Sure. Your contribution would be welcome.
> 
> I pushed it to a branch “tg-brightness” in the sysvinit
> packaging on Salsa.

Next time, wip/ namespace is preferred. It makes it clear,
that force-push are to be expected.

> I decided to rework the init script, so it can even work
> on multiple backlight brightness knobs, and added the
> Intel one from my Thinkpad, keeping the ACPI one compatible.

Thank you. But I have some considerations:

 * If no knob is found, all actions are silent. I believe some
   log_success_msg "brighntess not found" would be nice.

 * You merge 'start' and 'restart' action. Restart, by
   definition, is stop->start.

 * You did not declare MSG `local'. Why?

 * `local' is not mandated by POSIX. Does all posix-like
shells in Debian support it?

 * In most cases, initscripts use '[ "${VERBOSE}" != no ]' snippet. Could you
   please convert to this style?

 * I believe, that "x$foo" is unnecessary. "$foo" expands to "" if $foo
   is empty.

Bug#462389: debhelper: 'dh_installinit --name foobar ' should fail if package.foobar.init does not exist

[Dmitry Bogatov]

control: tags -1 +patch

[2008-01-24 14:45] A Mennucc 
> the usual invocation of dh_installinit never fails,
> if it finds package.init, it installs it, otherwise it simply exists.
> 
> Instead I think that the form 'dh_installinit --name foobar' , if it does
> not find package.foobar.init, should fail (so that debian/rules dies).
> The rationale is that, if the DD has set such a command in
> debian/rules , it  means that the script should exist; and if the
> script does not exists, it is most likely a bug (for example, a typo
> such as 'dh_installinit --name fobar'), so a failure should trigger.

Got bitten by this behaviour just today, so I decided to finally address
this issue.

Dear maintainer, please consider this patch. I read documentation on
submitting patches, but using merge request is so inconvenient. At
least, I added test :)

From f377d762a4e9635bf67e4759705655899ae4de0e Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Thu, 17 Jan 2019 02:19:27 +
Subject: [PATCH] dh_installinit: --name implies, that init script is present

Previously, `dh_installinit' silently did nothing, when --name option
was passed, but initscript debian/..init was not found.

In almost all cases, explicit --name means that package maintainer meant
to install init script. If it is not present, it is bug, and must not be
hidden. Now, error is reported in this case. (Closes: #462389)
---
 dh_installinit| 4 
 t/dh_installinit/dh_installinit.t | 1 +
 2 files changed, 5 insertions(+)

diff --git a/dh_installinit b/dh_installinit
index fca0a8af..6a490370 100755
--- a/dh_installinit
+++ b/dh_installinit
@@ -311,6 +311,10 @@ foreach my $package (@{$dh{DOPACKAGES}}) {
my $init=pkgfile($package,$scriptsrc) || pkgfile($package,"init") ||
pkgfile($package,"init.d");
 
+   if (!$init && defined $dh{NAME}) {
+   error("--name=$dh{NAME} option specified, but init script not 
found");
+   }
+
if ($init ne '' && ! $dh{ONLYSCRIPTS}) {
install_dir("$tmp/etc/init.d");
install_prog($init,"$tmp/etc/init.d/$script");
diff --git a/t/dh_installinit/dh_installinit.t 
b/t/dh_installinit/dh_installinit.t
index b20caa58..b210c867 100755
--- a/t/dh_installinit/dh_installinit.t
+++ b/t/dh_installinit/dh_installinit.t
@@ -28,6 +28,7 @@ each_compat_up_to_and_incl_subtest(10, sub {
 each_compat_from_and_above_subtest(11, sub {
make_path(qw(debian/foo debian/bar debian/baz));
 
+   ok(! run_dh_tool('dh_installinit', '--name=missing'));
ok(run_dh_tool('dh_installinit'));
ok(! -e "debian/foo/lib/systemd/system/foo.service");
ok(!find_script('foo', 'postinst'));

Bug#911515: dvtm in backports

[Dmitry Bogatov]

Hello?

Dear maintainer of ncurses, could you please upload a backport of
ncurses-term?


pgpQapevBlYEs.pgp
Description: PGP signature

Bug#915517: ucspi-tcp: VCS repository is set to private

[Dmitry Bogatov]

control: close -1


[2018-12-06 19:41] Alexander Wirt 
> > [2018-12-04 12:48] Ansgar Burchardt 
> > > Version: 1:0.88-4
> > > Severity: normal
> > > 
> > > Vcs-* ist set to https://salsa.debian.org/debian/ucspi-tcp which is a
> > > private repository.  Please make the repository publically accessible.
> > 
> > Confirmed. Problem is that both web-interface and API says that I am not
> > authorized.
> > 
> > Added salsa-admin@d.o into CC. Maybe they would help.
> Create a ticket please. The user broke it by just pushing the repo. 

Issue was resolved with interaction of salsa admins. Closing.

Bug#775912: Accepting patch upstream

[Dmitry Bogatov]

control: tags -1 +upstream

[2019-01-15 19:24] Jesse Smith 
> I am applying the provided patch upstream. Looks like this should have
> been the default behaviour, at least in kernel versions after the 2.6
> series.
> 
> The patch will be included in insserv-1.19.0, likely published around
> the end of February 2019.

Wonderful. Maybe we would even fit into buster.

Bug#919030: kile: Crash when saving upon closing

[Bernhard Übelacker]

Control: tags 919030 + upstream


Dear Maintainer, hello John Scott,
I had a look and think I have found the issue.

Each open document has a object of type
KileDocument::TextInfo::TextInfo.
That contains a QMap "m_dictStructLevel".

This map is given by reference to the parser thread
in an object of type KileParser::LaTeXParserInput.

Unfortunately if timing is bad the main thread
destructs the TextInfo object and thereby the QMap too.

But in the queue in the parser thread is still
an element with a reference to that QMap.
Now it looks like the memory gets allocated again
and something written to it.

When now the parser thread tries to access the
QMap m_dictStructLevel it crashes.

Find attached a file containing some description and
the most descriptive debug session at the bottom.

I have not found an upstream bug describing this situation.


Kind regards,
Bernhard

# Buster amd64 qemu VM 20190117

apt update
apt dist-upgrade

apt install systemd-coredump xserver-xorg lightdm openbox gdb valgrind mc kile 
kile-dbgsym
apt install dpkg-dev devscripts




mkdir source/kile/orig -p
cdsource/kile/orig
apt source kile
cd




systemctl start lightdm





export DISPLAY=:0
kile

- File - New
- Book
- (not save)
- File - Quit
- Save - (filename test)





set width 0
set pagination off
directory /home/benutzer/source/kile/orig/kile-2.9.92





##



$ LANG=C kile
kf5.kservice.services: KServiceTypeTrader: serviceType "ThumbCreator" not found
org.kde.solid.udisks2: Failed enumerating UDisks2 objects: 
"org.freedesktop.DBus.Error.ServiceUnknown" 
 "The name org.freedesktop.UDisks2 was not provided by any .service files"
org.kde.solid.udisks2: Failed enumerating UDisks2 objects: 
"org.freedesktop.DBus.Error.ServiceUnknown" 
 "The name org.freedesktop.UDisks2 was not provided by any .service files"
org.kde.solid.udisks2: Failed enumerating UDisks2 objects: 
"org.freedesktop.DBus.Error.ServiceUnknown" 
 "The name org.freedesktop.UDisks2 was not provided by any .service files"
org.kde.solid.udisks2: Failed enumerating UDisks2 objects: 
"org.freedesktop.DBus.Error.ServiceUnknown" 
 "The name org.freedesktop.UDisks2 was not provided by any .service files"
org.kde.solid.udisks2: Failed enumerating UDisks2 objects: 
"org.freedesktop.DBus.Error.ServiceUnknown" 
 "The name org.freedesktop.UDisks2 was not provided by any .service files"
org.kde.solid.udisks2: Failed enumerating UDisks2 objects: 
"org.freedesktop.DBus.Error.ServiceUnknown" 
 "The name org.freedesktop.UDisks2 was not provided by any .service files"
org.kde.solid.udisks2: Failed enumerating UDisks2 objects: 
"org.freedesktop.DBus.Error.ServiceUnknown" 
 "The name org.freedesktop.UDisks2 was not provided by any .service files"
org.kde.solid.udisks2: Failed enumerating UDisks2 objects: 
"org.freedesktop.DBus.Error.ServiceUnknown" 
 "The name org.freedesktop.UDisks2 was not provided by any .service files"
kdeinit5: preparing to launch '/usr/lib/x86_64-linux-gnu/libexec/kf5/klauncher'
kdeinit5: Launched KLauncher, pid = 16054, result = 0
No DBUS session-bus found. Check if you have started the DBUS server.
kdeinit5: Communication error with launcher. Exiting!
QFSFileEngine::open: No file name specified
kf5.kservice.services: KServiceTypeTrader: serviceType "ThumbCreator" not found
Speicherzugriffsfehler (Speicherabzug geschrieben)


[  851.008751] traps: KileParser::Doc[16038] general protection ip:7fcc44c21ae7 
sp:7fcc337fda00 error:0 in libkdeinit5_kile.so[7fcc449e8000+3ba000]


# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Thu 2019-01-17 18:25:56 CET   16034  1000  1000  11 present   /usr/bin/kile


# coredumpctl gdb 16034
   PID: 16034 (kile)
   UID: 1000 (benutzer)
   GID: 1000 (benutzer)
Signal: 11 (SEGV)
 Timestamp: Thu 2019-01-17 18:25:56 CET (1min 1s ago)
  Command Line: kile
Executable: /usr/bin/kile
 Control Group: /user.slice/user-1000.slice/session-3.scope
  Unit: session-3.scope
 Slice: user-1000.slice
   Session: 3
 Owner UID: 1000 (benutzer)
   Boot ID: fc256e8509ee45d8b7b3143e6d2a0a2b
Machine ID: 32f43b50ac8c4b21941bc0b02f8e7811
  Hostname: debian
   Storage: 
/var/lib/systemd/coredump/core.kile.1000.fc256e8509ee45d8b7b3143e6d2a0a2b.16034.154774595600.lz4
   Message: Process 16034 (kile) of user 1000 dumped core.

Stack trace of thread 16038:
#0  0x7fcc44c21ae7 n/a (libkdeinit5_kile.so)
#1  0x7fcc44c1e4dc n/a (libkdeinit5_kile.so)
#2  0x7fcc44c246cd n/a (libkdeinit5_kile.so)
#3  0x7fcc41d36cd7 n/a (libQt5Core.so.5)
#4  0x7fcc41abdfa3 start_thread (libpthread.so.0)
   

Bug#919577: g++-8: Can't build GN tool due to bug in raw-string parsing

[Allan Sandfeld Jensen]

On Donnerstag, 17. Januar 2019 14:09:21 CET Matthias Klose wrote:
> Control: tags -1 + moreinfo
> Control: severity -1 normal
> 
> works for me.
> 
Try with -E -fdirectives-only. 

I suspect it the same as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88475

Which means the reason I couldn't reproduce with gcc trunk was only because I 
didn't launch that through icecc, which makes it an upstream and not debian 
bug.

'Allan

Bug#734592: [debhelper-devel] Bug#734592: makefile.pm: make output parsing a bit less strict

[Dmitry Bogatov]

[2014-01-13 16:05] Joey Hess 
>
> part 1 text/plain 702
> Andrew Shadura wrote:
> > I propose a patch to relax requirements to the make output. Currently,
> > when the target doesn't exist, makefile.pm expects string like:
> > 
> > make: *** No rule to make target 'clean'.  Stop.
> > 
> > However, if the Makefile includes autogenerated parts (as it is the case
> > with Jonathan Schleifer's buildsys.mk), make responds differently:
> > 
> > Makefile:4: buildsys.mk: No such file or directory
> > make: *** No rule to make target 'buildsys.mk'.  Stop.
> 
> Please see bug #718121.
> 
> The best way to fix this would be to fix make to have a way to enumerate
> available targets.

Probably, I am late and everybody already knows it, but

make -f debian/rules -rp|grep -E ':$'|grep -v '^#'

does exactly that.

Bug#132542: sysvinit: please make /etc/init.d/rcS a conffile

[Dmitry Bogatov]

[2019-01-15 17:35] Thorsten Glaser 
> On Tue, 15 Jan 2019, Dmitry Bogatov wrote:
>
> > As far as I can tell, /sbin/init invocation is late enough.  Usrmerge is
> > coming. /usr is mounted by initramfs since initramfs-tools=0.117 (25 Sep 
> > 2014):
>
> The latter is okay for systems booted with initramfs. But I
> recall that it was decided some not too long time ago that
> people not using it should ensure their /usr is available
> by themselves.
>
> I do not agree with usrmerge, and I fully expect to be able
> to use Debian without that systemd-originating concept.
>
> But I agree it’s “probably” late enough, although nice to be
> considerate to people whose systems aren’t.

> [Pierre Ynard]
> Also, what is the policy about /usr/libexec/ regarding
> architecture-dependent and -independent executables?

FHS uses term "binaries". I believe scripts qualify too, since /lib is
explicitly for "shared libraries and kernel modules".  Installation of
{rc, rcS} into either /lib or /etc is violation of FHS.

> [Pierre Ynard]
> My personal feelings here would be similar to Thorsten's, but what I
> would put forward is that considering how critical a component of the
> system init is, perhaps it's best to strive for robustness for now.

Wow. So strong reaction. Fine. Collegues, I understand your attitude.
You have some setup, with separate / and /usr, without initramfs, and
you do not want change anything.

  Okay. I moved {rc, rcS} to /lib (see commit 51170798), change will be
  in 2.93-4 (due in few days). Sysvinit will *not* assume, that /usr is
  mounted at /sbin/init invocation in Buster. I promise.

But what next? Assumption of mounted /usr simplify things.  You can take
a look at #551555, but I do not think this is singular case. Two-part
mount process complicates initscripts for, well, what?

I do understand dislike of initramfs, but I do not understand why
separate / and /usr. So,

 * what are benefits of setup without initramfs *and* with separate /usr
   partition on *fresh installation*?
 * what are your arguments aganist usrmerge?

PS. No offense intended to anybody. Sorry, if my previous emails felt
rude.

Bug#916692: RFA: cuyo -- Tetris-like game

[eamanu15]

Arias Emmanuel
eamanu.com

El jue., 17 de ene. de 2019 13:43, Adrian Bunk  escribió:

> Adding Bernhard to Cc (the BTS does not Cc the submitter by default).
>

Thanks Adrian

>
> On Mon, Dec 17, 2018 at 09:59:35PM -0300, eamanu15 wrote:
> > Control: retitle -1 ITA: cuyo -- Tetris-like game
> > Control: owner -1 emmanuelaria...@gmail.com
> >
> > HiBernhard!
> >
> > I would like adopt this package.
> >
> > This is on salsa?
> >
> > Cheers!
> >
> >
> > --
> > Arias Emmanuel
> > http://eamanu.com
> > Github/Gitlab; @eamanu
> > Debian: @eamanu-guest
>

Bug#919605: grub-fstest: segmentation fault with a very long value for '-n' option

[s3v]

Package: grub-common
Severity: normal

Dear maintainer,
passing a very long value to grub-fstest command with '-n" option causes a
segmentation fault.

  $ foo="0"; for i in {1..6000}; foo="$foo$i"; done
  $ grub-fstest -n $foo
  Segmentation fault

Similarly:

  $ echo "$foo" > foofile
  $ grub-fstest -n $(cat foofile)
  Segmentation fault

A more verbose output from tty1:

  $ grub-fstest -n $foo
  [ 2897.594543] grub-fstest[29069]: segfault at 0 ip 5598771051db
  sp 7ffe657517a0 error 4 in grub-fstest[559877104000+7b000]
  [ 2897.596081] Code: 05 71 c3 0d 00 01 31 c0 e9 72 fe ff ff 66 90 31 d2 48 8d
  74 24 08 48 89 df e8 41 e2 05 00 48 8b 54 24 08 48 89 05 85 dc 0c 00 <80> 3a
  73 0f 85 42 fe ff ff 48 c1 e0 09 48 89 05 71 dc 0c 00 31 c0
  Segmentation fault


Kind regards.



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

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

Bug#919604: lintian: warnings on new-style init scripts

[Dmitry Bogatov]

Package: lintian
Version: 2.5.121
Severity: wishlist

Dear Maintainer,

Lintian seems to be very confused by new style init scripts:

#!/usr/bin/env /lib/init/init-d-script
### BEGIN INIT INFO
# Provides:  bcron-sched
# Should-Start:  $syslog
# Required-Start:$time
# Required-Stop: $time
# Default-Start: 2 3 4 5
# Default-Stop:  0 1 6
# Short-Description: bcron system scheduler
### END INIT INFO
NAME='bcron-start'
DESC='bcron system scheduler'
DAEMON=/usr/sbin/bcron-start

daemon_ () { /usr/bin/daemon --noconfig --name "${NAME}" "$@"; }
if ! test -x '/usr/bin/daemon' ; then
log_failure_msg "install \`daemon' package to use ${NAME} 
script"
exit 1
fi

do_start_cmd_override () {
daemon_ "${DAEMON}"
}

do_stop_cmd_override () {
if daemon_ --running ; then
daemon_ --stop
fi
}

and outputs a lot of warnings and errors:

W: bcron: init.d-script-uses-usr-interpreter etc/init.d/bcron-update 
/usr/bin/env
W: bcron: init.d-script-does-not-source-init-functions 
etc/init.d/bcron-sched
E: bcron: init.d-script-does-not-implement-required-option 
etc/init.d/bcron-spool restart
E: bcron: init.d-script-does-not-implement-required-option 
etc/init.d/bcron-spool force-reload

Rationale:

  * /lib/init/init-d-script is shell script; kFreeBSD does not
support shell scripts as shebang interpreters, hence /usr/bin/env
  * /lib/init/init-d-script does source init functions
  * /lib/init/init-d-script does implement both restart and force-reload
in generic way (stop -> start).

Actually,

#!/usr/bin/env /lib/init/init-d-script
### BEGIN INIT INFO
# Provides:  foo
# Should-Start:  $syslog
# Required-Start:$time
# Required-Stop: $time
# Default-Start: 2 3 4 5
# Default-Stop:  0 1 6
# Short-Description: foo daemon
### END INIT INFO
NAME='foo daemon'
DESC='foo deamon that frobnicates bars'
DAEMON=/usr/sbin/foobar

is perfectly fine new style init script. As you can see, there is no
explicit references to stop/start/restart actions, but they are present.

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

Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=eo.utf8, LC_CTYPE=eo.utf8 (charmap=UTF-8), LANGUAGE=eo.utf8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)

Versions of packages lintian depends on:
ii  binutils   2.31.1-11
ii  bzip2  1.0.6-9
ii  diffstat   1.62-1
ii  dpkg   1.19.2
ii  dpkg-dev   1.19.2
ii  file   1:5.35-2
ii  gettext0.19.8.1-9
ii  gpg2.2.12-1
ii  intltool-debian0.35.0+20060710.4
ii  libapt-pkg-perl0.1.34+b1
ii  libarchive-zip-perl1.64-1
ii  libcgi-pm-perl 4.40-1
ii  libclass-accessor-perl 0.51-1
ii  libclone-perl  0.41-1+b1
pn  libdigest-sha-perl 
ii  libdpkg-perl   1.19.2
ii  libemail-valid-perl1.202-1
pn  libfile-basedir-perl   
ii  libipc-run-perl20180523.0-1
ii  liblist-moreutils-perl 0.416-1+b4
ii  libparse-debianchangelog-perl  1.2.0-13
pn  libtext-levenshtein-perl   
pn  libtimedate-perl   
ii  liburi-perl1.76-1
ii  libxml-simple-perl 2.25-1
ii  libyaml-libyaml-perl   0.76+repack-1
ii  man-db 2.8.5-1
ii  patchutils 0.3.4-2
ii  perl   5.28.1-3
ii  t1utils1.41-3
ii  xz-utils   5.2.2-1.3

Versions of packages lintian recommends:
pn  libperlio-gzip-perl  

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libhtml-parser-perl3.72-3+b3
pn  libtext-template-perl  

-- no debconf information


pgpXqsTmwnPmd.pgp
Description: PGP signature

Bug#916966: merge request on salsa

[Andreas Henriksson]

Control: forwarded -1 
https://salsa.debian.org/multimedia-team/linuxptp/merge_requests/1
Control: tags -1 + patch

Sent a merge-request on salsa with a patch that fixes the problem
by making sure  (which defines clockid_t) is included
before 

Regards,
Andreas Henriksson

Bug#132542: sysvinit: please make /etc/init.d/rcS a conffile

[Thorsten Glaser]

On Thu, 17 Jan 2019, Pierre Ynard wrote:

> Also, what is the policy about /usr/libexec/ regarding
> architecture-dependent and -independent executables?

We can use multiarch subdirectories, the same as in /usr/lib/,
for example /usr/libexec/x86_64-linux-gnux32/ for x32. That
was announced when Policy changed.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#882065: More info

[Geoff]

tags 882065 +moreinfo
thanks

Hi Heikki,

Could you check if this issue is still there with ncmpc/0.33 soon to land in 
testing?

Cheers