Bug#946412: janus-gateway: upstream does not support stable releases

[Jonas Smedegaard]

Quoting Salvatore Bonaccorso (2020-06-11 22:54:43)
> On Sun, Dec 08, 2019 at 02:09:10PM +0100, Jonas Smedegaard wrote:
> > Upstream releases are to be considered draft snapshots,
> > and this package is therefore unsuitable for inclusion
> > in long-term distributions like Debian stable.
> > 
> > This bug should be bumped to release-critical state
> > close to or after entering freeze -
> > but not before so as to ease use for users tracking testing
> > including derivatives based on Debian testing.
> 
> Reading the above, so janus should not have been in buster, right?

While in good faith, I am not sure what you are implying with the above: 
In an ideal World (where crystal balls or time machines exist), yes.

Both filing this bugreport and the upstream statement triggering it 
occured _after_ the release of Buster, indicating lack of knowledge on 
the matter at the time of release of Buster (or, in bad faith, that it 
was known but kept secret - sure you cannot mean that).


> As such it might be a good option to ask for removal of src:janus in 
> buster. If you agree on that, can you fill a bug for the 
> release-team/SRM to ask for removal of the package in the next buster 
> point release?

Yes, removal from Buster should be done.

Sorry, I am not familiar with the procedures to do that, and appreciate 
your suggestion: Do I simply file a bugreport against ftp.debian.org as 
with removals from unstable/experimental, or which different runes 
should I throw?

Kind regards,

 - Jonas

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

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

signature.asc
Description: signature

Bug#962533: mlpack FTBFS on mips64el: relocation truncated to fit

[Adrian Bunk]

On Fri, Jun 12, 2020 at 05:56:39AM +0800, YunQiang Su wrote:
> Adrian Bunk  于 2020年6月9日周二 下午11:18写道：
>...
> just add -mxgot to cxxflags.
> there are 2 type of GOT in mips: one use fewer insn while has a length
> limitaion; another uses more insns while has a big address space support.
>...

That's what I tried:

> > I tried "export DEB_CXXFLAGS_MAINT_APPEND += -mxgot" which gave me:
> >
> > ...
> > /usr/bin/c++  -g -O2 -fdebug-prefix-map=/home/bunk/build/mlpack-3.3.1=.
> > -fstack-protector-strong -Wformat -Werror=format-security -mxgot
> > -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra -ftemplate-depth=1000
> > -Wno-unused-function -O3 -fopenmp  -Wl,-z,relro -Wl,-z,now -rdynamic
> > CMakeFiles/mlpack_cf.dir/cf_main.cpp.o  -o ../../../../bin/mlpack_cf
> > -Wl,-rpath,/home/bunk/build/mlpack-3.3.1/obj-mips64el-linux-gnuabi64/lib:
> > ../../../../lib/libmlpack.so.3.3 /usr/lib/libarmadillo.so
> > /usr/lib/mips64el-linux-gnuabi64/libboost_program_options.so
> > /usr/lib/mips64el-linux-gnuabi64/libboost_unit_test_framework.so
> > /usr/lib/mips64el-linux-gnuabi64/libboost_serialization.so -lpthread
> > CMakeFiles/mlpack_cf.dir/cf_main.cpp.o: in function
> > `std::mersenne_twister_engine > 13043109905998158313ul, 29ul, 6148914691236517205ul, 17ul,
> > 8202884508482404352ul, 37ul, 1873444759240704ul, 43ul,
> > 6364136223846793005ul>::seed(unsigned long)':
> > /usr/include/c++/9/bits/random.tcc:329:(.text._ZN6mlpack4math10RandomSeedEm[_ZN6mlpack4math10RandomSeedEm]+0xb8):
> > relocation truncated to fit: R_MIPS_TLS_GOTTPREL against
> > `arma::arma_rng_cxx11_instance'
> > CMakeFiles/mlpack_cf.dir/cf_main.cpp.o: in function
> > `std::mersenne_twister_engine > 13043109905998158313ul, 29ul, 6148914691236517205ul, 17ul,
> > 8202884508482404352ul, 37ul, 1873444759240704ul, 43ul,
> > 6364136223846793005ul>::operator()()':
> > /usr/include/c++/9/bits/random.tcc:458:(.text._ZN4arma8arma_rng5randuIdE4fillEPdy[_ZN4arma8arma_rng5randuIdE4fillEPdy]+0x70):
> > relocation truncated to fit: R_MIPS_TLS_GOTTPREL against
> > `arma::arma_rng_cxx11_instance'
> > /usr/include/c++/9/bits/random.tcc:457:(.text._ZN4arma8arma_rng5randuIdE4fillEPdy[_ZN4arma8arma_rng5randuIdE4fillEPdy]+0x354):
> > relocation truncated to fit: R_MIPS_TLS_GOTTPREL against
> > `arma::arma_rng_cxx11_instance'
> > collect2: error: ld returned 1 exit status
> >
> >
> > debian-mips is Cc'ed, can a mips porter please have a look?

What are these R_MIPS_TLS_GOTTPREL relocations?

cu
Adrian

Bug#953554: Please permit Debian revisions with 1.0 native packages

[Guillem Jover]

On Thu, 2020-06-11 at 18:32:04 -0700, Felix Lechner wrote:
> On Wed, Mar 11, 2020 at 5:37 AM Ian Jackson wrote:
> >
> > I hope that whatever occurs more widely, this particular message can
> > be downgraded appropriately so that by default it is an warning rather
> > than an error.  That's all I'm asking for in this bug.
> >
> > Can we perhaps go back to
> >hyphen-in-native-debian-changelog-version
> 
> It never felt so wrong to merge two bugs, but they are now the same. I
> supported your request in the cloned policy bug #953629 and got you
> another +1. For now, I will reduce the tag's severity to a warning
> like you asked.
> 
> Lintian is not a good vehicle for policy changes, and you were unaware
> when filing that policy stood in the way. Please contact us again when
> the policy changes (or if you require additional support in the
> matter). I cannot wait to implement your request.

Oh! Given the timing of this reaction, I think it would not be
unreasonable to consider it originating out of spite? :)

Regards,
Guillem

Bug#962681: battery drain during system shutdown

[Gopal Sharma]

I am still facing the issue.

Bug#962158: lintian: New very problematic --fail-on default value

[Guillem Jover]

Control: tags -1 patch

*Sigh*

On Wed, 2020-06-10 at 08:38:05 -0700, Felix Lechner wrote:
> On Tue, Jun 9, 2020 at 11:15 PM Chris Lamb  wrote:
> >
> > Felix, can you help out? I am not in a position to contribute to this
> > discussion itself.
> 
> Well, I wish I could. Guillem makes many alarmist statements,

This is a funny way to put it I guess. :)

> but fails to explain why the change is an undue burden.

I've done that multiple times now.

> I also do not know
> how to engage productively with visceral and absolute responses such
> as:

Obviously biased, but I don't see anything visceral in any of the
"selected" (out of context) quotes below. They reflect IMO either
astonishment or a reasoned view on the matter. If you disagree you
could have as well rebutted them, which you still have not done…

(Should really not be going over these, because this is yet again
another diversion from the matter at hand but…)

> > Err…

This was in reply to:

  ,---
  As I explained on IRC this statement is probably untrue (and you did
  not have the courtesy to mention that objection here).
  `---

So pretty much astonishment at this, first because I'm not in the
habit of leaking conversations from IRC w/o permission, and second
because of the unsubstantiated truthiness claim veiled in as a
"possibility".

> > it does not make any sense whatsoever
> > does not match reality
> > it does not even make sense within a Debian-centric view

Supported in the context conveniently trimmed out.

> > I'll have to very much disagree
> > you have still not explained what this default change really accomplishes
> > besides inducing tons of work and breakage
> > No, they did not.

These are either substantiated opinion (also conveniently trimmed
out), or facts. If the facts are wrong, you can always challenge them.

> It's amazing how much time and energy Guillem expended on this issue
> here, on IRC, and in #962157 while dpkg has more open bugs than
> Lintian.

Wow, just wow, I'm not sure where to begin here TBH. First, I'm not
even sure how this is in the least relevant to this report, how it
is relevant to you how anyone else spends their time in a volunteer
project, and how that compares to anything else.

But this just feels like a pattern to me, when there are no more
technical arguments to make, you start either the unrelated diversion
and distraction, the personal comments, etc.

And, really, the bug reports have actually been 4 shortish emails. The
"bulk" of the time was on IRC, but that has not been the only and first
instance of endless and repetitive discussions going in circles, with
unrelated tangents all over the place…

> As you know from my past behavior with 'md5sums -z' or the odd
> contributor on Salsa, I am not opposed to compromise when it brings
> peace. In the present case, such a compromise could be a value 'none'
> to disable the default Guillem likes (and which I would like to
> remove).

Again with the personification, this is not something _I_ personally
like. I could personally adapt. This is something I do consider to
be a global bad default for the program and Debian, derivatives, etc
at large.

It's clear you want this behavior change, it's not clear why though.
The reasons I've seen from you are:

  - it has been advertised.
  - ftp-masters have requested it (and they are the only ones that
matter, at which moment I guess I wonder that's the point of any
non-fatal tags in lintian that ftp-masters do not use)
  - a very vague and unsubstantiated "the current solution is simple,
elegant, straightforward and explicit".
  - unrelated claims about the exit status being unreliable.
  - other unrelated stuff from IRC.

The attached (untested, just «perl -cw» checked) patch, applied after
reverting commit 30ae7cab479e64bf58618e17854794112f8cc791 does not
really look complex to me TBH, in addition of fixing a small bug.

> At the same time, the change was widely released two weeks ago. Simon
> Quigley from Ubuntu announced it on debian-devel on May 25 [1], while
> I advertised the change repeatedly on IRC and added a note to DevNews.
> Some users may have already adapted their systems.
> 
> [1] https://lists.debian.org/debian-devel/2020/05/msg00239.html

Yet again, advertising a change does not imply there's a justification
for it, that's not a technical nor even a good social reason. (Not to
mention that not everyone has apt-listchanges installed, so not even a
NEWS might be seen, and as mentioned the problem with that is that it
would go unnoticed given that it is a silent breaking change.)

> It would also give me more time to understand the possibly
> unreasonable burden on Lintian users across Debian and the derivative
> ecosystem. Simon may receive feedback from Ubuntu, a significant
> derivative. If there are real problems, I am happy to discuss a
> solution that reverts the default to Lintian's old setting.

This again shows that all the reasons exposed on IRC and on the reports
are not

Bug#925782: mp3check: diff for NMU version 0.8.7-3.1

[David da Silva Polverari]

Control: tags 925782 + pending

Dear maintainer,

I've prepared an NMU for mp3check (versioned as 0.8.7-3.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer or cancel the NMU.

Regards,

David Polverari.
diff -Nru mp3check-0.8.7/debian/changelog mp3check-0.8.7/debian/changelog
--- mp3check-0.8.7/debian/changelog	2018-12-22 18:33:01.0 -0500
+++ mp3check-0.8.7/debian/changelog	2020-06-11 00:33:53.0 -0500
@@ -1,3 +1,12 @@
+mp3check (0.8.7-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches/60_bts925782_ftbfs_with_gcc_9.patch: added to fix FTBFS
+with GCC-9. Thanks to Joachim Reichel . (Closes:
+#925782)
+
+ -- David da Silva Polverari   Thu, 11 Jun 2020 00:33:53 -0500
+
 mp3check (0.8.7-3) unstable; urgency=medium
 
   [ Helmut Grohne ]
diff -Nru mp3check-0.8.7/debian/patches/60_bts925782_ftbfs_with_gcc_9.patch mp3check-0.8.7/debian/patches/60_bts925782_ftbfs_with_gcc_9.patch
--- mp3check-0.8.7/debian/patches/60_bts925782_ftbfs_with_gcc_9.patch	1969-12-31 19:00:00.0 -0500
+++ mp3check-0.8.7/debian/patches/60_bts925782_ftbfs_with_gcc_9.patch	2020-06-11 00:33:53.0 -0500
@@ -0,0 +1,50 @@
+Description: fix FTBFS with GCC-9
+Author: Joachim Reichel 
+Bug-Debian: https://bugs.debian.org/925782
+Last-Update: 2019-09-01
+
+--- a/texception.h
 b/texception.h
+@@ -38,10 +38,10 @@
+ 
+ #define TExceptionN(n) public: virtual const char *name()  const { return #n; }
+ #define TExceptionM(m) public: virtual const char *message() const { return m; }
+-#define TExceptionM1(m,a) public: virtual const char *message() const { char *buf; asprintf(&buf, m, a); return buf; }
+-#define TExceptionM2(m,a,b) public: virtual const char *message() const { char *buf; asprintf(&buf, m, a,b); return buf; }
+-#define TExceptionM3(m,a,b,c) public: virtual const char *message() const { char *buf; asprintf(&buf, m, a,b,c); return buf; }
+-#define TExceptionM4(m,a,b,c,d) public: virtual const char *message() const { char *buf; asprintf(&buf, m, a,b,c,d); return buf; }
++#define TExceptionM1(m,a) public: virtual const char *message() const { char *buf; int result = asprintf(&buf, m, a); return result != -1 ? buf : "asprintf failure"; }
++#define TExceptionM2(m,a,b) public: virtual const char *message() const { char *buf; int result = asprintf(&buf, m, a,b); return result != -1 ? buf : "asprintf failure"; }
++#define TExceptionM3(m,a,b,c) public: virtual const char *message() const { char *buf; int result = asprintf(&buf, m, a,b,c); return result != -1 ? buf : "asprintf failure"; }
++#define TExceptionM4(m,a,b,c,d) public: virtual const char *message() const { char *buf; int result = asprintf(&buf, m, a,b,c,d); return result != -1 ? buf : "asprintf failure"; }
+ 
+ // base class of all exceptions 
+ class TException {
+--- a/tstring.cc
 b/tstring.cc
+@@ -111,7 +111,7 @@
+ tstring::Rep *tstring::Rep::create(size_t tmem) {
+size_t m = sizeof(Rep) << 1;
+while((m - 1 - sizeof(Rep)) < tmem) m <<= 1;
+-   Rep *p = new (m - 1 - sizeof(Rep)) Rep;
++   Rep *p = new (/*tag*/ true, m - 1 - sizeof(Rep)) Rep;
+p->mem = m - 1 - sizeof(Rep); p->ref = 1; p->vulnerable = false;
+return p;
+ }
+--- a/tstring.h
 b/tstring.h
+@@ -71,9 +71,12 @@
+   
+   // static methods
+   // operator new for this class
+-  static void * operator new (size_t size, size_t tmem) {
++  // add a tag parameter to ensure that the signature of the delete operator does not collide with the (void*,size_t) overload
++  static void * operator new (size_t size, bool /*tag*/, size_t tmem) {
+ 	 return ::operator new (size + tmem + 1);}
+-  static void operator delete (void *p, size_t) {
++  static void operator delete (void *p, bool /*tag*/, size_t) {
++	 ::operator delete (p); }
++  static void operator delete (void *p) {
+ 	 ::operator delete (p); }
+   
+   // create a new representation
diff -Nru mp3check-0.8.7/debian/patches/series mp3check-0.8.7/debian/patches/series
--- mp3check-0.8.7/debian/patches/series	2018-12-22 18:33:01.0 -0500
+++ mp3check-0.8.7/debian/patches/series	2020-06-11 00:12:11.0 -0500
@@ -4,3 +4,4 @@
 30_hardening.patch
 40_bts726068_remove_truncated_last_frame.patch
 nostrip.patch
+60_bts925782_ftbfs_with_gcc_9.patch

Bug#962532: Same bug in 20.1.1-1. Also calibre, vlc, stellarium segfault.

[Timo Aaltonen]

On 11.6.2020 19.43, zieg...@uni-freiburg.de wrote:
> I see the same bug in version 20.1.1-1.
> 
> I found that vlc and stellarium, and calibre all segfault immediately in
> iris_dri.so, but do not kill X. calibre does it when loading an
> epub-file with the process "LoadBook".
> 
> 
> (Martin Ziegler)
> 

don't use the intel X driver

-- 
t

Bug#951722: linking with libunwind does not reliably help

[Noah Meyerhans]

Linking against libunwind helps on (at least) armel, but it seems to
break on (at least) arm64.

The test suite reports the following when linked against libunwind on
arm64:

test-backtrace.c:14: Assert failed: strstr(str_c(bt), "test_backtrace") != NULL
backtrace_append . : FAILED
test-backtrace.c:38: Assert failed: strstr(bt, "test_backtrace") != NULL
backtrace_get  : FAILED

These are the failing lines:
https://salsa.debian.org/debian/dovecot/-/blob/master/src/lib/test-backtrace.c#L14
https://salsa.debian.org/debian/dovecot/-/blob/master/src/lib/test-backtrace.c#L38

In both cases, the issue is that the given symbol name (test_backtrace)
is not found in the string representing the stack trace.  On armel,
where the test passes, the stack trace appears complete and reasonably
useful:

#0 test_backtrace[0x0059efb8] -> #1 test_run_named_funcs[0x005d04b8] -> #2 
test_run_named_with_fatals[0x005d12cc] -> #3 __libc_start_main[0xf78e4c44] -> 
#4 _start[0x0059d3bc]

On arm64, it is:

./test-lib(+0x3f097) [0xe0c5b097] -> ./test-lib(+0x3f1e7) [0xe0c5b1e7] 
-> ./test-lib(+0x11f63) [0xe0c2df63] -> ./test-lib(+0x3bacb) 
[0xe0c57acb] -> ./test-lib(+0x3c77f) [0xe0c5877f] -> 
/lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0xe3) [0x8ac962eb] -> 
./test-lib(+0x106ab) [0xe0c2c6ab]

Note the lack of symbols.  I have not investigated whether the problem
is with dovecot's usage of libunwind or with libunwind itself.

Also notable is the fact that the second conditional preprocessor block
looks for the string "main" in the stack trace instead of
test_backtrace, so it would pass here, even though the trace itself is
of dubious value:
https://salsa.debian.org/debian/dovecot/-/blob/master/src/lib/test-backtrace.c#L21

Bug#851611: SawFish, gnome-int, debian-menu

[git]

After fixing the link the next error complains about debian-menu
missing.
This indeed vanishes if the package menu gets installed.

So if sawfish treats that missing dependency as error, it should be
required instead of suggested.

Bug#960495: transition: gdal

[Sebastiaan Couwenberg]

On 6/11/20 10:07 PM, Sebastian Ramacher wrote:
> On 2020-06-11 20:37:58 +0200, Sebastiaan Couwenberg wrote:
>> On 6/11/20 6:46 AM, Sebastiaan Couwenberg wrote:
>>> On 6/10/20 9:46 PM, Sebastian Ramacher wrote:
 Please go ahead with the upload to unstable.
>>>
>>> Thanks, gdal (3.1.0+dfsg-1) was just uploaded to unstable.
>>
>> The rebuild are looking good so far
>>
>> Please also binNMU postgis in experimental.
> 
> Scheduled.

Thanks.

Some packages were (re)built with the old gdal:

 * octave-mapping on mips64el
 * libgdal-grass  on armel, mips64el & mipsel

These need another binNMU.

Kind Regards,

Bas

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



signature.asc
Description: OpenPGP digital signature

Bug#962691: RFP: python3-griddataformats -- handle data on a regular grid for molecular simulations

[Drew Parsons]

Package: wnpp
Severity: wishlist
Control: block 962440 by -1

* Package name: python3-griddataformats
  Version : 0.5.0
  Upstream Author : Oliver Beckstein 
* URL : https://www.mdanalysis.org/GridDataFormats/
* License : LGPL3+
  Programming Lang: Python
  Description : handle data on a regular grid for molecular simulations

GridDataFormats is a pure Python library to handle data on a regular
grid using commonly used file formats in molecular simulations.

The gridData module contains a simple class Grid that makes it easier
to work with data on a regular grid. A limited number of commonly used
formats can be read and written.


Required by mdanalysis (ITP#962440).

Suitable for maintainence by the Debichem Team (alongside mdanalysis)
but could be taken up by other Teams.

Bug#962687: linux-image-4.19.0-9-amd64: computer restarts immediately when going into sleep mode

[Dawn Dorsett]

Package: src:linux
Version: 4.19.118-2
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?Computer was failing to stay in sleep mode
   * What exactly did you do (or not do) that was effective (or
 ineffective)?n/a
   * What was the outcome of this action?n/a
   * What outcome did you expect instead?n/a

*** End of the template - remove these template lines ***
Jun 12 10:00:33 Thorin systemd-sleep[2886]: Suspending system...
Jun 12 10:00:33 Thorin kernel: [ 845.654593] PM: suspend entry (deep)
Jun 12 10:00:33 Thorin kernel: [ 845.654594] PM: Syncing filesystems ... done.
Jun 12 10:00:39 Thorin kernel: [ 846.105314] Freezing user space processes ... 
(elapsed 0.002 seconds) done.
Jun 12 10:00:39 Thorin kernel: [ 846.108057] OOM killer disabled.
Jun 12 10:00:39 Thorin kernel: [ 846.108058] Freezing remaining freezable tasks 
... (elapsed 0.001 seconds) done.
Jun 12 10:00:39 Thorin kernel: [ 846.109214] Suspending console(s) (use 
no_console_suspend to debug)
Jun 12 10:00:39 Thorin kernel: [ 846.111382] serial 00:01: disabled
Jun 12 10:00:39 Thorin kernel: [ 846.124999] sd 3:0:0:0: [sdc] Synchronizing 
SCSI cache
Jun 12 10:00:39 Thorin kernel: [ 846.125048] sd 0:0:0:0: [sda] Synchronizing 
SCSI cache
Jun 12 10:00:39 Thorin kernel: [ 846.125168] sd 3:0:0:0: [sdc] Stopping disk
Jun 12 10:00:39 Thorin kernel: [ 846.125281] sd 0:0:0:0: [sda] Stopping disk
Jun 12 10:00:39 Thorin kernel: [ 846.129006] sd 2:0:0:0: [sdb] Synchronizing 
SCSI cache
Jun 12 10:00:39 Thorin kernel: [ 846.409679] sd 2:0:0:0: [sdb] Stopping disk
Jun 12 10:00:39 Thorin kernel: [ 847.053891] ACPI: Preparing to enter system 
sleep state S3
Jun 12 10:00:39 Thorin kernel: [ 848.501467] PM: Saving platform NVS memory
Jun 12 10:00:39 Thorin kernel: [ 848.501477] Disabling non-boot CPUs ...
Jun 12 10:00:39 Thorin kernel: [ 848.518692] smpboot: CPU 1 is now offline
Jun 12 10:00:39 Thorin kernel: [ 848.542519] smpboot: CPU 2 is now offline
Jun 12 10:00:39 Thorin kernel: [ 848.574488] smpboot: CPU 3 is now offline
Jun 12 10:00:39 Thorin kernel: [ 848.598462] smpboot: CPU 4 is now offline
Jun 12 10:00:39 Thorin kernel: [ 848.622433] smpboot: CPU 5 is now offline
Jun 12 10:00:39 Thorin kernel: [ 848.628681] ACPI: Low-level resume complete
Jun 12 10:00:39 Thorin kernel: [ 848.628753] PM: Restoring platform NVS memory
Jun 12 10:00:39 Thorin kernel: [ 848.629540] Enabling non-boot CPUs ...
Jun 12 10:00:39 Thorin kernel: [ 848.629565] x86: Booting SMP configuration:
Jun 12 10:00:39 Thorin kernel: [ 848.629565] smpboot: Booting Node 0 Processor 
1 APIC 0x2
Jun 12 10:00:39 Thorin kernel: [ 848.629941] cache: parent cpu1 should not be 
sleeping
Jun 12 10:00:39 Thorin kernel: [ 848.629975] intel_pstate: Disabling energy 
efficiency optimization
Jun 12 10:00:39 Thorin kernel: [ 848.630074] CPU1 is up
Jun 12 10:00:39 Thorin kernel: [ 848.630087] smpboot: Booting Node 0 Processor 
2 APIC 0x4
Jun 12 10:00:39 Thorin kernel: [ 848.630426] cache: parent cpu2 should not be 
sleeping
Jun 12 10:00:39 Thorin kernel: [ 848.630544] CPU2 is up
Jun 12 10:00:39 Thorin kernel: [ 848.630556] smpboot: Booting Node 0 Processor 
3 APIC 0x6
Jun 12 10:00:39 Thorin kernel: [ 848.630890] cache: parent cpu3 should not be 
sleeping
Jun 12 10:00:39 Thorin kernel: [ 848.631017] CPU3 is up
Jun 12 10:00:39 Thorin kernel: [ 848.631029] smpboot: Booting Node 0 Processor 
4 APIC 0x8
Jun 12 10:00:39 Thorin kernel: [ 848.631366] cache: parent cpu4 should not be 
sleeping
Jun 12 10:00:39 Thorin kernel: [ 848.631504] CPU4 is up
Jun 12 10:00:39 Thorin kernel: [ 848.631515] smpboot: Booting Node 0 Processor 
5 APIC 0xa
Jun 12 10:00:39 Thorin kernel: [ 848.631860] cache: parent cpu5 should not be 
sleeping
Jun 12 10:00:39 Thorin kernel: [ 848.631998] CPU5 is up
Jun 12 10:00:39 Thorin kernel: [ 848.635127] ACPI: Waking up from system sleep 
state S3
Jun 12 10:00:39 Thorin kernel: [ 848.706902] serial 00:01: activated
Jun 12 10:00:39 Thorin kernel: [ 848.714257] sd 0:0:0:0: [sda] Starting disk
Jun 12 10:00:39 Thorin kernel: [ 848.714459] sd 2:0:0:0: [sdb] Starting disk
Jun 12 10:00:39 Thorin kernel: [ 848.714607] sd 3:0:0:0: [sdc] Starting disk



-- Package-specific info:
** Version:
Linux version 4.19.0-9-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.118-2 (2020-04-29)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-9-amd64 
root=UUID=e0699c3f-2151-43aa-8a75-8458e88c31bf ro quiet

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: ASUS
product_name: All Series
product_version: System Version
chassis_vendor: Chassis Manufacture
chassis_version: Chassis Version
bios_vendor: American Megatrends Inc.
bios_version: 2105
board_vendor: ASUSTeK COMPUTER INC.
board_name: H81M-E
board_version: Rev X.0x

** Loaded modules:
fuse
intel_rapl
x86_pkg_temp_thermal
intel_powerclamp
snd

Bug#962685: wordpress 5.4.2 security release

[Salvatore Bonaccorso]

Hi Craig,

On Fri, Jun 12, 2020 at 09:40:34AM +1000, Craig Small wrote:
> Source: wordpress
> Version: 5.4.1+dfsg1-1
> Severity: grave
> Tags: security upstream
> Justification: user security hole
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> WordPress 5.4.2 is out and fixes the following vulnerabilities:
[...]

Thanks for filling the bugreport about those, added tracking in the
security-tracker correspondigly.

Are you requesting CVEs for those?

Regards,
Salvatore

Bug#962690: RFP: python3-mmtf -- binary encoding of biological structures

[Drew Parsons]

Package: wnpp
Severity: wishlist
Control: block 962440 by -1

* Package name: python3-mmtf
  Version : 1.1.2
  Upstream Author : Anthony Bradley 
* URL : https://github.com/rcsb/mmtf-python
* License : Apache2
  Programming Lang: Python
  Description : binary encoding of biological structures (Python 3)

The python implementation of the MMTF API, decoder and encoder.
http://mmtf.rcsb.org/

The macromolecular transmission format (MMTF) is a binary encoding of
biological structures.

Required by mdanalysis (ITP#962440).

Suitable for team maintenance under Debichem Team (alongside
libmmtf-java) but other teams might also take it on.

Bug#962689: msmtp: Please integrate secret service support in the main package

[Guillem Jover]

Source: msmtp
Source-Version: 1.8.8-1
Severity: wishlist

Hi!

I was trying to use the keepassxc Secret Service integration support
with msmtp, when I realized this is only provided with the msmtp-gnome
package which diverts the program with a rebuild of the binary with
libsecret support.

This was a bit surprising as the documentation talks about this being
supported and the preferred option, and I understand the Secret Service
is a cross-desktop specification intended to be implemented by various
tools (such as GNOME Keyring, KDE Wallet or even KeePassXC). In this
case I do not use GNOME, so installing msmtp-gnome pulls in stuff that
I do not need, and the name is a bit confusing. :)

The libsecret dependency seems lightweight, and not really GNOME
specific (well it pulls in glib but that's pretty common nowadays), so
could this be provided in the main package, avoiding the double build
and diversion?

The "gnome" dependency looks more like a Recommends to me anyway than a
hard depends. That could then be done instead in the main msmtp binary
package as:

  Recommends: keepassxc | seahorse | kwalletmanager

or similar? If the user already has GNOME installed then seahorse will
satisfy it, otherwise if KDE is installed kwalletmanager, and lastly
keepassxc would be pulled in.

Thanks,
Guillem

Bug#953554: Please permit Debian revisions with 1.0 native packages

[Felix Lechner]

Control: retitle -1 lintian: Restore format-specific changelog tags as warnings
Control: forcemerge -1 944155

Hi Ian,

On Wed, Mar 11, 2020 at 5:37 AM Ian Jackson
 wrote:
>
> I hope that whatever occurs more widely, this particular message can
> be downgraded appropriately so that by default it is an warning rather
> than an error.  That's all I'm asking for in this bug.
>
> Can we perhaps go back to
>hyphen-in-native-debian-changelog-version

It never felt so wrong to merge two bugs, but they are now the same. I
supported your request in the cloned policy bug #953629 and got you
another +1. For now, I will reduce the tag's severity to a warning
like you asked.

Lintian is not a good vehicle for policy changes, and you were unaware
when filing that policy stood in the way. Please contact us again when
the policy changes (or if you require additional support in the
matter). I cannot wait to implement your request.

Kind regards
Felix Lechner

Bug#766441: RFA: scala-mode-el -- Emacs major mode for editing scala source code

[Sławomir Wójcik]

On 29.05.2020 05:22, Nicholas D Steeves wrote:

Hi Sławomir,

Sławomir Wójcik  writes:


On 22.05.2020 05:14, Nicholas D Steeves wrote:

I've merged my changes into new repo initialized by gbp import-dsc from
the old package, it's here:
https://salsa.debian.org/Valdaer/scala-mode-el. Documented all of it in
the new changelog entry.

The newly built package is here:
https://mentors.debian.net/package/scala-mode-el


Thank you for your work on this package; this one needs a fair bit of
work before it will meet current standards.  Sorry, it's not ready to
sponsor yet.

I'm short on time for the next week, and am exhausted right now, but
here's a very quick review.  Please read it as if I had written "please"
before every point, and sorry it seems terse or vague.  I just wanted to
send you the list of things to work on before I'll have time to review
again--probably in about a week:

Hint to save time: checkout the commit where you merged the upstream
tag, then 'git checkout -b merged-new-upstream-source'.  If ever you
need to rebase you can then rebase against that branch; if you need to
rebase, this will help avoid the sticky mess of non-fastforwarding master
branch that might not be a child of upstream.

Leave the changelog in UNRELEASED state for now.


Ok


Push upstream version tags.


Done


Copyright file issues:
   * 2 files stanzas are missing


which two? I've browsed all files and I'm not sure. Could you paste some 
links to locations in the repo?



   * 2 people are missing


I've added Merlin Göttlinger as the author of 
scala-mode-prettify-symbols.el file and Ana Beatriz Guerrero Lopez in 
debian files dopyright section.


I could add Sam Halliday(original author of https://ensime.github.io/ , 
more info below) who contributed some substantial part of scala-mode, 
however he abandoned the project.


What's the policy here? Should we include him in copyright? For example 
in elpy package only the original author(Jorgen Schaefer 
) is listed in the copyright entry and the 
person which took over the project(galaunay 
) is only listed as upstream contact and not 
in the copyright section.



   * at least 1 license is missing


I've added Scala EPFL license which I missed that is still used in 
Makefile(which I believe is invoked by debhelper, although I'm not sure 
it's needed for dh_elpa) but one question here:


What would be the policy for files that Debian package doesn't use not 
only in the debian binary package but even in the build process like for 
example Cask file which would have separate license? In that case this 
license should also be incorporated in the copyright file?



   * always dedicate one line to each year[s] copyright_holder_name 
   * "updated license and author" is too vague, and isn't entirely
   accurate (see above).  Also, why did the licenses and authors change?
   Documenting these facts is part of writing a good changelog entry ;-)
   * date ranges can be tricky.  I believe you see the value in combining
   them, but it's also important to guard against false matches.  For a
   small package like this comprehensive detail is expected.
   Silversearcher-ag (or similar) may make it faster to check for (C), ©,
   and Copyright.
Control file issues:
   * revert that section change; editors is correct, lintian's claim
   notwithstanding.  Thank you for reading lintian output, btw.
   * use debhelper-compat 13 (p.s. apt install -t buster-backports
   lintian.  Lintian should have caught this)
   * Standards-Version needs to be updated.  See Debian Policy and its
   upgrading checklist.  Start at the version from the last upload and
   work your way through from there. <- Please defer this until the
   beginning of our next review cycle unless you run out of things to
   do.
   * drop emacs25


Done


   * expand the long description by a line or two (did this version lose
   the ability to send sexps to a scala process?  If so, document it in
   NEWS)  Is it just a boring mode that does very little or does it have
   any outstanding and/or cool features?
 - NOTE: if this this new upstream source has less functionality than
 the previous one it might be worth documenting the changes.  If it
 has a significantly different keymap or workflow, or breaks existing
 users' configs then do you think users would appreciate
 notification?  If so, read up on the NEWS file (found in
 debian/NEWS) and how to use it.


Yeah it's probably because the new scala-mode(once called scala-mode2 as 
in https://github.com/hvesalai/emacs-scala-mode/tree/v0.22 which I think 
was a fork of original scala-mode however I'm not sure I haven't been 
programming in Scala back then, and even if it was in IntelliJ) was 
meant to work in synergy with ensime(https://ensime.github.io/) which is 
now abandoned and has been replaced by scala 
Metals(https://scalameta.org/metals/) which is used by emacs lsp-mode/eglot.


Added information about this in NEWS file and expanded long de

Bug#962688: ITP: emacsql -- high level SQL database frontend for Emacs

[Sean Whitton]

Package: wnpp
Severity: wishlist
Owner: Sean Whitton 

* Package name: emacsql
  Version : 3.0.0
  Upstream Author : Christopher Wellons 
* URL : https://github.com/skeeto/emacsql
* License : Unlicense
  Programming Lang: Emacs Lisp & C
  Description : high level SQL database frontend for Emacs

I'm packaging this as a dependency for another Emacs addon I'm currently
trialling.  I won't upload this until I'm sure I want to use that other
addon or someone asks me to.

Copying mfv who started salsa:emacsen-team/emacsql-el some months ago.

Unfortunately I'd got further than mfv in my own Debianisation before I
discovered that repo (and mfv did not file an ITP), so I'm not going to
reuse any of mfv's work and will not continue his git history, unless
there are objections.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#958450: 83 available upstream

[積丹尼 Dan Jacobson]

Upstream is asking me to use version 83 when reporting bugs.

Bug#961314: ITP: python3-s2sphere -- Python implementation of a part of the C++ S2 geometry library

[Christoph Anton Mitterer]

Hey Emmanuel.

FYI, I've just filed:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962686

This is the C++ version, which seems however to contain also some
Python SWIG bindings (but I have no idea whether these work or are
complete - OTOH s2phere isn't complete either).


My Python knowledge isn't really good enough to tell which version one
should package respectively which is better.


Cheers,
Chris.

Bug#962686: RFP: s2geometry -- Computational geometry and spatial indexing on the sphere http://s2geometry.io/

[Christoph Anton Mitterer]

Package: wnpp
Severity: wishlist

* Package name: s2geometry
  Version : 0.9.0
  Upstream Author : ?
* URL : https://github.com/google/s2geometry
* License : Apache License 2.0
  Programming Lang: C++, Python
  Description : Computational geometry and spatial indexing on the sphere 
http://s2geometry.io/

This is a package for manipulating geometric shapes. Unlike many geometry 
libraries, S2 is
primarily designed to work with spherical geometry, i.e., shapes drawn on a 
sphere rather
than on a planar 2D map. This makes it especially suitable for working with 
geographic data.

Bug#961681: Bug #961681: octave 5.2.0 and java child processes

[Benjamin Moody]

Control: found 961681 5.2.0-2

On bullseye, with octave 5.2.0-2 and openjdk-11-jre-headless
11.0.7+9-1, "b.start()" fails:

$ octave -W -q -f
octave:1> b = javaObject("java.lang.ProcessBuilder", {"/bin/true"});
OpenJDK 64-Bit Server VM warning: Archived non-system classes are
disabled because the java.system.class.loader property is specified
(value = "org.octave.OctClassLoader"). To use archived non-system
classes, this property must be not be set
octave:2> p = b.start();
[14.392s][warning][os,thread] Failed to start thread - pthread_create
failed (EINVAL) for attributes: stacksize: 136k, guardsize: 0k,
detached.
error: [java] java.lang.OutOfMemoryError: unable to create native
thread: possibly out of memory or process/resource limits reached

(This appears to be the same issue as
.)

If I install the openjdk-8-jdk package from stretch, and force
octave 5.2.0-2 to use that instead, by running:

  # rm /usr/lib/jvm/default-java
  # ln -s java-8-openjdk-amd64/ /usr/lib/jvm/default-java
  # ln -s ../jre/lib/amd64/server/ /usr/lib/jvm/java-8-openjdk-amd64/lib/server

then there is no "Archived non-system classes" warning, and
"b.start()" suceeds, but "p.waitFor()" hangs as before.

Bug#962685: wordpress 5.4.2 security release

[Craig Small]

Source: wordpress
Version: 5.4.1+dfsg1-1
Severity: grave
Tags: security upstream
Justification: user security hole

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

WordPress 5.4.2 is out and fixes the following vulnerabilities:

Props to Sam Thomas (jazzy2fives) for finding an XSS issue where authenticated 
users with low privileges are able to add JavaScript to posts in the block 
editor.
https://core.trac.wordpress.org/changeset/47948
All releases

Props to Luigi – (gubello.me) for discovering an XSS issue where authenticated 
users with upload permissions are able to add JavaScript to media files.
https://core.trac.wordpress.org/changeset/47947 (I think)
All releases

Props to Ben Bidner of the WordPress Security Team for finding an open redirect 
issue in wp_validate_redirect().
https://core.trac.wordpress.org/changeset/47949
All releases

Props to Nrimo Ing Pandum for finding an authenticated XSS issue via theme 
uploads.
https://core.trac.wordpress.org/changeset/47950
All releases

Props to Simon Scannell of RIPS Technologies for finding an issue where 
set-screen-option can be misused by plugins leading to privilege escalation.
https://core.trac.wordpress.org/changeset/47951
All releases

Props to Carolina Nymark for discovering an issue where comments from 
password-protected posts and pages could be displayed under certain conditions.
https://core.trac.wordpress.org/changeset/47984
All releases

There is also a fix for unmoderated comments visible to indexers which
will be backported. WordPress say its not a security issue, but seems
like you are getting the site to do something that it shouldn't.
https://make.wordpress.org/core/2020/06/09/wordpress-5-4-2-prevent-unmoderated-comments-from-search-engine-indexation/
https://core.trac.wordpress.org/ticket/49956
https://core.trac.wordpress.org/changeset/47887
https://core.trac.wordpress.org/changeset/47889
Present: 5.4 only (5.1 onwards, see the ticket)


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

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

-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEEXT3w9TizJ8CqeneiAiFmwP88hOMFAl7iwOsSHGNzbWFsbEBk
ZWJpYW4ub3JnAAoJEAIhZsD/PITjYIAP/R+4+bSwUXz0IPSijvsH4PkIICe3k1wj
dBSgFWWjFcVyYZwbpQ5SqgyspGG5aFhQPNWiSAvv0BILWY///jbPmsSoqz0s58xC
QcjBkUiif1GDZq60IaA8igy2eotD90FQxr8Y16iDFSbkC0U3x4sV1UW3WlDEyxnW
ILRusFo8m0L9J+rTQUxu0SGHK4WM2nvCGNp1U3l5/JreKZxlLIeoy+y44GsCPktn
8wDIqZ91bUpfhUcyL7BZu7g94cUnC8RhZxX//TiVYlH54pXneascPuedZAGV/qi6
0TMTuSvdPd9/pKtKhCo2jUb70CRWiP4r3QDgRM7oqcx8jLaLvBcvWmaAQjpc6eZB
jgRX6HAEkm2CVFor4VtwRH/726RLLm34IokYnXU74Wp+LVjtXIYMLoP/fkbEvJW4
ClrMMEUe/+bkWLmWu6iGdbNM325eFsTvkDOngCNV/g/lsEp5gzHZwCwzL+0J21ds
/KglCuE+BRn4XSCCxOEU+HS7EM8A+NWrO95elryeVE2SRQb/11F8s6TkIMMMqFPD
B4m8+J5Ooj7LzS3dErVuXlOOVX0YXFVOL6AThfitW9SHOn37NmRsvOuSJCySKdI6
60A7WJvuH460JcpASDSR4XoJpBy+NnAkA4uTJ9ihlLKbZBkhy+vS/E/6M73yL9Aw
QCZSPwT6j/lX
=E8qn
-END PGP SIGNATURE-

Bug#962640: RFS: zmat/0.9.8 [RFS] -- a portable C-library and Octave toolbox for data compression

[Qianqian Fang]

On 6/11/20 6:13 PM, Wookey wrote:

Yes. dch -r is the conventional way to do that (and change the
timestamp at the same time), but you can just edit it. The idea is
that you leave it as 'UNRELEASED' until you really have stopped
fiddling and are ready to upload. Some tools take note of this field
to stop you accidentally uploading before you are ready. (I don't
personally find this useful, but that's why it's there).


No. Someone will have to do the work of making any adjustments needed
to build in stable and doing an upload to -backports. That can't be
done until after it has been accepted into the archive (which can take
a while (days to months) after initial upload).

https://wiki.debian.org/BuildingFormalBackports
https://wiki.debian.org/Backports



thanks for the clarifications. I realized in my package uploaded 
earlier, a bunch of settings were not done correctly, so I just 
re-uploaded a new version after making a bunch of fixes


https://salsa.debian.org/fangq/libzmat/-/commits/zmat

if you have checked out the earlier upload, please retrieve it again.

I tested the generated deb files, both the lib and dev packages seemed 
to work fine, the octave package is still having some issue to be 
recognized in octave, I am seeking help on the octave list right now.




Wookey

Bug#935614: libinfinity: FTBFS on all architectures

[Sunil Mohan Adapa]

tag 935614 + patch
thanks

Hello,

Thank you for looking into this issue.

The problem is due to reliance on particular ordering when iterating
hash table in tests. The bug is triggered by a minor tweak to hash table
algorithm in glib.

I proposed two patches on the upstream issue to fix the problem. They
are also attached here. They are alternate approaches and any one of
them will fix the problem. If the upstream takes time to fix, please
consider applying one of the patches to Debian as infinoted is currently
not available in Debian/FreedomBox testing.

Thanks,

-- 
Sunil
From ebe92d9d97dc21b82225c6a7977adf87dd00f799 Mon Sep 17 00:00:00 2001
From: Sunil Mohan Adapa 
Date: Thu, 11 Jun 2020 15:00:34 -0700
Subject: [PATCH] Iterate user table in a sorted way, fix tests with latest
 glib

This is primarily to help test cases which assume that the adopted algorithm
prioritizes the users in the exact reverse order they appear in the test
cases (and get inserted into the session in reverse order). With older glib
version, the five users being inserted happened to return the order expected by
the tests. With latest glib, due to a minor tweak in hashing strategy, the
insertion leads to unsorted list leading to failed tests.

In addition, GHashTable makes no guarantees about the stability of items when
iterating multiple times. Since the algorithm is sensitive to order of users, it
is best to return users in an order that is consistent over multiple calls and
stable over insert/remove operations.

This patch maintains a sorted list of user ids and uses it for iteration.

Closes: #22.

Signed-off-by: Sunil Mohan Adapa 
---
 libinfinity/common/inf-user-table.c | 51 -
 1 file changed, 28 insertions(+), 23 deletions(-)

diff --git a/libinfinity/common/inf-user-table.c b/libinfinity/common/inf-user-table.c
index 11b06b4..cb44ef5 100644
--- a/libinfinity/common/inf-user-table.c
+++ b/libinfinity/common/inf-user-table.c
@@ -36,15 +36,11 @@
  * users within the session.
  */
 
-typedef struct _InfUserTableForeachUserData InfUserTableForeachUserData;
-struct _InfUserTableForeachUserData {
-  InfUserTableForeachUserFunc func;
-  gpointer user_data;
-};
-
 typedef struct _InfUserTablePrivate InfUserTablePrivate;
 struct _InfUserTablePrivate {
   GHashTable* table;
+  /* To be able to iterate users in sorted order */
+  GSList* user_ids;
   /* TODO: It would be smarter to map the hash table to a helper struct
* which stores the user availability, locality and the InfUser object */
   GSList* availables;
@@ -179,15 +175,11 @@ inf_user_table_lookup_user_by_name_func(gpointer key,
   return FALSE;
 }
 
-static void
-inf_user_table_foreach_user_func(gpointer key,
- gpointer value,
- gpointer user_data)
+static gint
+inf_user_ids_list_sort_compare_func(gconstpointer a,
+gconstpointer b)
 {
-  InfUserTableForeachUserData* data;
-  data = (InfUserTableForeachUserData*)user_data;
-
-  data->func(INF_USER(value), data->user_data);
+  return GPOINTER_TO_UINT(a) - GPOINTER_TO_UINT(b);
 }
 
 static void
@@ -197,6 +189,7 @@ inf_user_table_init(InfUserTable* user_table)
   priv = INF_USER_TABLE_PRIVATE(user_table);
 
   priv->table = g_hash_table_new_full(NULL, NULL, NULL, NULL);
+  priv->user_ids = NULL;
   priv->availables = NULL;
   priv->locals = NULL;
 }
@@ -216,6 +209,9 @@ inf_user_table_dispose(GObject* object)
   g_slist_free(priv->availables);
   priv->availables = NULL;
 
+  g_slist_free(priv->user_ids);
+  priv->user_ids = NULL;
+
   g_hash_table_foreach(
 priv->table,
 inf_user_table_dispose_foreach_func,
@@ -256,6 +252,12 @@ inf_user_table_add_user_handler(InfUserTable* user_table,
   g_hash_table_insert(priv->table, GUINT_TO_POINTER(id), user);
   g_object_ref(user);
 
+  priv->user_ids = g_slist_insert_sorted(
+priv->user_ids,
+GUINT_TO_POINTER(id),
+inf_user_ids_list_sort_compare_func
+  );
+
   g_signal_connect(
 G_OBJECT(user),
 "notify::status",
@@ -314,6 +316,8 @@ inf_user_table_remove_user_handler(InfUserTable* user_table,
 );
   }
 
+  priv->user_ids = g_slist_remove(priv->user_ids, GUINT_TO_POINTER(id));
+
   inf_user_table_unref_user(user_table, user);
   g_assert(g_hash_table_lookup(priv->table, GUINT_TO_POINTER(id)) == user);
   g_hash_table_remove(priv->table, GUINT_TO_POINTER(id));
@@ -646,21 +650,22 @@ inf_user_table_foreach_user(InfUserTable* user_table,
 gpointer user_data)
 {
   InfUserTablePrivate* priv;
-  InfUserTableForeachUserData data;
+  InfUser* user;
+  GSList* item;
+
+  guint user_id;
 
   g_return_if_fail(INF_IS_USER_TABLE(user_table));
   g_return_if_fail(func != NULL);
 
   priv = INF_USER_TABLE_PRIVATE(user_table);
 
-  data.func = func;
-  data.user_data = user_data;
-
-  g_hash_table_foreach(
-priv->table,
-inf_user_table_foreach_user_func,
-&data
-  );
+  for(item = priv->user_ids; item != 

Bug#762086: spamassassin: email reports have sometimes list of others email addresses included

[Robert L Mathews]

I experienced this bug, but found it is fixed in SpamAssassin 3.4.3 and
later by:

 https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7577

 https://svn.apache.org/viewvc?view=revision&revision=1844813

Using the "bullseye" or "buster-backports" version of SpamAssassin
solves the problem, so I'm guessing this bug report can be closed.

If it helps, attached is a Perl script that shows the original problem
for those having trouble duplicating it.

-- 
Robert L Mathews
#!/usr/bin/perl

=pod

Demonstrate Debian bug 762086. On my machine, this prints this
for the first message:

*  0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
*  provider (address[at]yahoo.com)

And this for the second message:

*  0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
*  provider (address[at]yahoo.com) (address[at]gmail.com)

=cut

use Mail::SpamAssassin;

my $spamassassin = Mail::SpamAssassin->new({
	debug => 0,
	});

my $message_lines = <\r
To: "To 1" \r
Subject: Test 1\r
\r
Test 1
EOF

my $sa_message = $spamassassin->parse($message_lines);
my $sa_status = $spamassassin->check($sa_message);
print $sa_status->get_tag('REPORT');
$sa_status->finish;
$sa_message->finish;


$message_lines = <\r
To: "To 2" \r
Subject: Test 2\r
\r
Test 2
EOF

$sa_message = $spamassassin->parse($message_lines);
$sa_status = $spamassassin->check($sa_message);
print $sa_status->get_tag('REPORT');

Bug#962100: python-memprof: Fix for autopkg tests

[Brian Murray]

Package: python-memprof
Version: 0.3.6-2
Followup-For: Bug #962100
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu groovy ubuntu-patch

Dear Maintainer,

I've discovered a fix which allows the autopkg tests to pass.

In Ubuntu, the attached patch was applied to achieve the following:

  * Properly import getsize so autopkg tests pass. (Closes: #962100)


Thanks for considering the patch.
diff -Nru python-memprof-0.3.6/debian/patches/import-pyx.patch 
python-memprof-0.3.6/debian/patches/import-pyx.patch
--- python-memprof-0.3.6/debian/patches/import-pyx.patch1969-12-31 
16:00:00.0 -0800
+++ python-memprof-0.3.6/debian/patches/import-pyx.patch2020-06-11 
13:08:25.0 -0700
@@ -0,0 +1,20 @@
+Description: Properly import getsize for autopkgtests
+Author: Brian Murray 
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962100
+Last-Update: 2020-06-11
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: python-memprof-0.3.6/memprof/memprof.py
+===
+--- python-memprof-0.3.6.orig/memprof/memprof.py
 python-memprof-0.3.6/memprof/memprof.py
+@@ -21,6 +21,9 @@ import time
+ import argparse
+ import types
+ 
++import pyximport
++pyximport.install()
++
+ from .mp_utils import *  # noqa
+ from .getsize import getSize, isInteresting
+ 
diff -Nru python-memprof-0.3.6/debian/patches/series 
python-memprof-0.3.6/debian/patches/series
--- python-memprof-0.3.6/debian/patches/series  2020-01-18 15:17:53.0 
-0800
+++ python-memprof-0.3.6/debian/patches/series  2020-06-11 13:06:46.0 
-0700
@@ -1 +1,2 @@
 deb_specific__dont_require_argparse.patch
+import-pyx.patch

Bug#962254: NFS(v4) broken at 4.19.118-2

[Elliott Mitchell]

Bit more experimentation on this issue.

I tried a very small C program meant to create files with fewer
permissions bits set.  This succeeded which strengthens the theory of
the umask getting ignored.

I haven't seen anything hinting whether this is more a client or server
issue.

I can speculate perhaps somewhere between 4.9 and 4.15 the NFS client
code stepped closer to proper the "proper" 4.2 protocol.  If a
corresponding NFS server was slow at getting merged, what we're seeing
could happen.

Alternatively someone was trying to get a Linux NFS v4.2 client to work
better with a different NFS v4.2 server, so they fixed Linux's NFS v4.2
client.  Yet they failed to test with Linux's v4.2 server.


This though is speculation.  All I can say is sometime between kernels
4.9 and 4.15, NFS v4.2 got broken.  There are hints this is related to
handling of umask.


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

Bug#961676: 5.6 kernel crashes host when using VFIO on KVM guests

[Simon John]

The new linux-image-5.6.0-2-amd64 (5.6.14-2) from today is no better, 
only change is its signed I guess?


Also I noticed the 5.3/5.4/5.5 kernels have all been removed from my 
system and the servers so I have no way to boot back into a kernel that 
doesn't break VFIO.


Has this issue been looked at or is 5.7 due soon?

Regards.

--
Simon John

Bug#962640: RFS: zmat/0.9.8 [RFS] -- a portable C-library and Octave toolbox for data compression

[Wookey]

On 2020-06-11 17:58 -0400, Qianqian Fang wrote:
> I hope these are acceptable solutions. the only error left is the "UNRELEASED"
> in the changelog. should I set it to "unstable"?

Yes. dch -r is the conventional way to do that (and change the
timestamp at the same time), but you can just edit it. The idea is
that you leave it as 'UNRELEASED' until you really have stopped
fiddling and are ready to upload. Some tools take note of this field
to stop you accidentally uploading before you are ready. (I don't
personally find this useful, but that's why it's there).

> will the package be backported
> automatically in the future to stable?

No. Someone will have to do the work of making any adjustments needed
to build in stable and doing an upload to -backports. That can't be
done until after it has been accepted into the archive (which can take
a while (days to months) after initial upload).

https://wiki.debian.org/BuildingFormalBackports
https://wiki.debian.org/Backports

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


signature.asc
Description: PGP signature

Bug#962640: RFS: zmat/0.9.8 [RFS] -- a portable C-library and Octave toolbox for data compression

[Qianqian Fang]

thank you all for sharing your feedback.

I updated my packaging files and fixed most of the issues (also received 
some help from the debian-octave list). The updated package can be found at


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

A quick summary:

1. I renamed the library back to libzmat1 as many of you suggested it is 
the right naming format


2. I modified the orig package via a setup script 
 to


    - 1) remove the bundled lz4 files, and link the binary with 
system's liblz4 library, and


    - 2) add the missing octave DESCRIPTION/INDEX files,

3. bumped my debhelper compat level to 12

I hope these are acceptable solutions. the only error left is the 
"UNRELEASED" in the changelog. should I set it to "unstable"? will the 
package be backported automatically in the future to stable?


thanks

Qianqian

Bug#962533: mlpack FTBFS on mips64el: relocation truncated to fit

[YunQiang Su]

Adrian Bunk  于 2020年6月9日周二 下午11:18写道：

> Source: mlpack
> Version: 3.3.1-1
> Severity: serious
> Tags: ftbfs
>
> It seems Boost 1.67 -> 1.71 increased something:
>
>
> https://buildd.debian.org/status/fetch.php?pkg=mlpack&arch=mips64el&ver=3.3.1-1%2Bb1&stamp=1591444281&raw=0
>
> ...
> /usr/bin/c++  -g -O2 -fdebug-prefix-map=/<>=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
> -D_FORTIFY_SOURCE=2 -Wall -Wextra -ftemplate-depth=1000
> -Wno-unused-function -O3 -fopenmp  -Wl,-z,relro -Wl,-z,now -rdynamic
> CMakeFiles/mlpack_cf.dir/cf_main.cpp.o  -o ../../../../bin/mlpack_cf
> -Wl,-rpath,/<>/obj-mips64el-linux-gnuabi64/lib:
> ../../../../lib/libmlpack.so.3.3 /usr/lib/libarmadillo.so
> /usr/lib/mips64el-linux-gnuabi64/libboost_program_options.so
> /usr/lib/mips64el-linux-gnuabi64/libboost_unit_test_framework.so
> /usr/lib/mips64el-linux-gnuabi64/libboost_serialization.so -lpthread
> CMakeFiles/mlpack_cf.dir/cf_main.cpp.o: in function
> `std::basic_ostream >& std::operator<<  std::char_traits, std::allocator >(std::basic_ostream std::char_traits >&, std::__cxx11::basic_string std::char_traits, std::allocator > const&)':
> /usr/include/c++/9/bits/basic_string.h:6421:(.text+0x300): relocation
> truncated to fit: R_MIPS_CALL16 against `std::basic_ostream std::char_traits >& std::__ostream_insert std::char_traits >(std::basic_ostream
> >&, char const*, long)@@GLIBCXX_3.4.9'
> CMakeFiles/mlpack_cf.dir/cf_main.cpp.o: in function `void
> std::__cxx11::basic_string,
> std::allocator >::_M_construct(char*, char*,
> std::forward_iterator_tag)':
> /usr/include/c++/9/bits/basic_string.tcc:219:(.text+0x760): relocation
> truncated to fit: R_MIPS_CALL16 against `std::__cxx11::basic_string std::char_traits, std::allocator >::_M_create(unsigned long&,
> unsigned long)@@GLIBCXX_3.4.21'
> /usr/include/c++/9/bits/basic_string.tcc:233:(.text+0x7c0): relocation
> truncated to fit: R_MIPS_CALL16 against `__stack_chk_fail@@GLIBC_2.4'
> /usr/include/c++/9/bits/basic_string.tcc:212:(.text+0x7d0): relocation
> truncated to fit: R_MIPS_CALL16 against `std::__throw_logic_error(char
> const*)@@GLIBCXX_3.4'
> CMakeFiles/mlpack_cf.dir/cf_main.cpp.o: in function
> `__gnu_cxx::new_allocator std::char_traits, std::allocator > >::allocate(unsigned long,
> void const*)':
> /usr/include/c++/9/ext/new_allocator.h:114:(.text+0xb34): relocation
> truncated to fit: R_MIPS_CALL16 against `operator new(unsigned
> long)@@GLIBCXX_3.4'
> CMakeFiles/mlpack_cf.dir/cf_main.cpp.o: in function
> `std::vector,
> std::allocator >, std::allocator std::char_traits, std::allocator > >
> >::_S_check_init_len(unsigned long,
> std::allocator,
> std::allocator > > const&)':
> /usr/include/c++/9/bits/stl_vector.h:1767:(.text+0xbc4): relocation
> truncated to fit: R_MIPS_CALL16 against `std::__throw_length_error(char
> const*)@@GLIBCXX_3.4'
> CMakeFiles/mlpack_cf.dir/cf_main.cpp.o: in function
> `std::__cxx11::basic_string,
> std::allocator >*
> std::__uninitialized_copy::__uninit_copy std::char_traits, std::allocator > const*,
> std::__cxx11::basic_string,
> std::allocator >*>(std::__cxx11::basic_string std::char_traits, std::allocator > const*,
> std::__cxx11::basic_string,
> std::allocator > const*, std::__cxx11::basic_string std::char_traits, std::allocator >*)':
> /usr/include/c++/9/bits/stl_uninitialized.h:86:(.text+0xbd0): relocation
> truncated to fit: R_MIPS_CALL16 against `__cxa_begin_catch@@CXXABI_1.3'
> CMakeFiles/mlpack_cf.dir/cf_main.cpp.o: in function `void
> std::_Destroy_aux::__destroy std::char_traits, std::allocator
> >*>(std::__cxx11::basic_string,
> std::allocator >*, std::__cxx11::basic_string std::char_traits, std::allocator >*)':
> /usr/include/c++/9/bits/stl_construct.h:107:(.text+0xbe0): relocation
> truncated to fit: R_MIPS_CALL16 against `__cxa_rethrow@@CXXABI_1.3'
> CMakeFiles/mlpack_cf.dir/cf_main.cpp.o: in function
> `std::_Vector_base,
> std::allocator >, std::allocator std::char_traits, std::allocator > >
> >::_M_deallocate(std::__cxx11::basic_string,
> std::allocator >*, unsigned long)':
> /usr/include/c++/9/bits/stl_vector.h:350:(.text+0xbf8): relocation
> truncated to fit: R_MIPS_CALL16 against `operator
> delete(void*)@@GLIBCXX_3.4'
> CMakeFiles/mlpack_cf.dir/cf_main.cpp.o: in function
> `__gnu_cxx::new_allocator std::char_traits, std::allocator > >::~new_allocator()':
> /usr/include/c++/9/ext/new_allocator.h:89:(.text+0xc04): relocation
> truncated to fit: R_MIPS_CALL16 against `_Unwind_Resume@@GCC_3.0'
> CMakeFiles/mlpack_cf.dir/cf_main.cpp.o: in function
> `std::__cxx11::basic_string,
> std::allocator >::_M_dispose()':
> /usr/include/c++/9/bits/basic_string.h:231:(.text+0xc1c): additional
> relocation overflows omitted from the output
>

just add -mxgot to cxxflags.
there are 2 type of GOT in mips: one use fewer insn while has a length
limitaion; another uses more insns while has a big address space support.

collect2: error: ld returned 1 exit status
> make[4]: ***
> [src/mlpack/methods/cf/CMakeFiles/mlpack

Bug#962684: RFS: fclib/3.1.0+dfsg-2 -- read and write problems from the Friction Contact Library (library)

[Stephen Sinclair]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: fclib
   Version : 3.1.0+dfsg-2
   Upstream Author : fclib-proj...@lists.gforge.inria.fr
 * URL : https://frictionalcontactlibrary.github.io/
 * License : Apache-2.0
 * Vcs : https://salsa.debian.org/science-team/fclib
   Section : science

It builds those binary packages:

  libfclib0 - read and write problems from the Friction Contact
Library (library)
  libfclib-dev - read and write problems from the Friction Contact
Library (headers)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/f/fclib/fclib_3.1.0+dfsg-2.dsc

Changes since the last upload:

   * Patch wrong argument to cs_transpose which leads to segfault.
 (Closes: #927761)

The previous upload, 3.1.0+dfsg-1, failed on buildd and this patch
fixes the problem.  This package is required for siconos 4.3.0+dfsg-1,
uploaded in parallel, with RFS #962441:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962441

Regards,

--
  Stephen Sinclair

Bug#961536: openmw FTBFS with openscenegraph 3.6.5

[bret curtis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello Sebastian,

On 2020-06-11 at 20:28, sramac...@debian.org wrote:
> Hi Bret
>
> The build on mipsel failed:
>
https://buildd.debian.org/status/fetch.php?pkg=openmw&arch=mipsel&ver=0.46.0-1&stamp=1591883193&raw=0

>
> It's missing -latomic. But I'm wondiering if it really makes sense to
> build the package on mips*. Is anyone able to play games on mips?
>
> Cheers
> --
> Sebastian Ramacher

That's not that big of a loss, 32-bit mips can only address 2GiB of memory
per process anyway. I would assume the moment you load Morrowind and its
expansions that it would quickly run out of memory anyway.

I added mipsel to the same list as armel and armhf.

Cheers,
Bret
-BEGIN PGP SIGNATURE-
Version: FlowCrypt 7.7.9 Gmail Encryption
Comment: Seamlessly send and receive encrypted email

wsFcBAEBCAAGBQJe4qd+AAoJEMI3e31YTLkwmW4P/1BPe4E4RK0Vw0pdSQf5
Fyq1iQt2Xb73Y9swL3pCKdx5/3QuV+JmTgL7o563Je2KG78SvoiQr0nXeAp6
zE7ZuNUEtuWd5GSzxSvbidGv8FXyNOseiy2JqZEUkUX278Ezir5XFwBaX2na
xfobOjoIR+y61A7C/z/0saoYL53u71RRxuCrkKKGya+FLkOYyuM98Xb2EnNI
I0yEVqoxCjgWD4fgKeveSHfpMBV+loeXqcWVmuNoKRrc0Ln1LkwtzMvNKOKw
XA4wYwlX1aY1miVzcCBqm6QVBNDvxprtfQCi/gcC3CYSHgV/P0a/U2nYDOcw
EQsr6W+AF0NpZIBBTZHVK6wDvUIrHqtDaA8vrB67qeAmb56Rea1z9OsSvfmj
gZWREmHAkp0P1YdpLu6kPwTk/xnVOaPg+G+VwTQUzx1Gizir+gmp87T3wHGx
I7cfiF4QHw8HJb0E/lSo9EKvYUv01hsRw0zfAgdfC2i0x1oSa+VoaASkfldE
wJdq+9SDykFGQKWEXnU2lR0K6FHpnJqdu/WFYVLLSObdB97NUn57yG0DL8vj
AcaeWrL2d8GoLZ990OFYACzJvXjgOgCg+0RA8GmkRMtFH6sCQ/fK4TPqaB0/
2EECPawnAiSs6Pey/SB4hjvXntJqd3FmtYW9yDBcAU8FELIlJTFxvkgz5tl2
4CuP
=seRY
-END PGP SIGNATURE-

Bug#962669: Bug#962672: buster-pu: package ca-certificates/20200611~deb10u1

[Adrian Bunk]

Control: tags 962669 moreinfo

On Thu, Jun 11, 2020 at 08:18:38PM +0100, Adam D. Barratt wrote:
> On Thu, 2020-06-11 at 13:48 -0500, Michael Shuler wrote:
> > On 6/11/20 1:33 PM, Adam D. Barratt wrote:
> > > Just to confirm - will the certificates be automatically re-added
> > > (assuming that users have either the automatically trust or prompt
> > > options enabled)?
> > 
> > (stretch-pu report cc'ed, since same applies)
> > 
> > Excellent question. I believe we're going to hit #743339 "Previously 
> > removed certificates not added again". I had not found a reasonable
> > fix for that case in general, to preserve a user's selections. Maybe
> > a "good enough" fix will have to do for the specific ones added back.
> 
> OK.
> 
> In that case, how does this seem as an SUA text?
> 
> 
> The ca-certificates update described in SUA 182-1 removed some
> certificates issued by Symantec (under various brand names).
> Unfortunately, this removal led to a number of reported regressions.
> The affected certificates have therefore been reintroduced.
> 
> If you have already installed the package from SUA 182-1, and need to
> use the affected certificates, you may need to manually enable them by
> running "dpkg-reconfigure ca-certificates" as root.
> 

This does not work in various embedded scenarios.

Would it work to force-enable them in /etc/ca-certificates.conf
from the preinst when upgrading from old-version matching 20200601* ?

Unrelated to that, please keep the Python 2 -> 3 build dependency
change out of this emergency update.

> Regards,
> 
> Adam

cu
Adrian

Bug#962683: RFP: python3-msmb-theme -- applies slight modifications to sphinx_rtd_theme

[Drew Parsons]

Package: wnpp
Severity: wishlist
Control: block 962442 by -1

* Package name: python3-msmb-theme
  Version : 1.2.0
  Upstream Author : Dave Snider
* URL : https://github.com/msmbuilder/msmb_theme
* License : MIT
  Programming Lang: Python
  Description : applies slight modifications to sphinx_rtd_theme

This applies slight modifications to sphinx_rtd_theme. It needs the
aforementioned theme to be installed.

Modifications:
  Styling tweaks in msmb.css
  Styling for Jupyter notebooks

Required by mdtraj (ITP#962442) (for generating docs with sphinx).

To be maintained by the Python Modules Team on behalf of the Debichem
Team.

Bug#953629: debian-policy: Please permit Debian revisions with 1.0 native packages

[Jonathan Nieder]

Hi,

Sam Hartman wrote:

> I think there are at least two cases where this issue comes up and is
> important, and where using a debian revision without separate upstream
> tarballs is the right approach:
>
> 1) small packages currently maintained by the upstream maintainer where
> debian revision is incremented for packaging only changes and upstream
> revision is incremented for upstream versions
>
> and
>
> 2) Cases typically outside the Debian archive where a git tree is being
> built as a Debian package especially as part of a CI system and where
> the effort of tracking upstream tarballs is undesired.
>
> 2) is more of an issue for lintian than it is for debian-policy.

I don't have any strong opinions about this, but I got the impression
that Ian's motivation is a different case 3):

| Most packages are maintained in git nowadays.  It is usual to have a
| separate git branch for Debian and upstream work.  In such a situation
| it makes perfect sense to have an upstream version number which
| corresponds to an upstream tag.  For packages with a very small (or
| zero) Debian delta to the upstream files, it makes sense to maintain
| these git branches using `git merge' rather than as a stack of
| patches.
|
| However, there are serious inherent problems with all of the
| non-native source formats.  There are many that can occur in git
| repositories which are not representable in non-native packages.  For
| example, changes to symlinks.  Worse, one must either choose
| `3.0 (quilt)' which involves patch files within the git tree
| and a great deal of complexity to manage those; or 1.0-with-diff which
| has an even more restricted set of things it can represent.

Regardless of what happens to the 1.0 format, shouldn't the non-native
package formats be improved to handle this?  The "git diff" format,
which GNU patch has reasonable support for, is able to represent all
of these kinds of changes, including changes to symlinks.  Tooling for
handling 3.0 (quilt) packages is reasonably good at generating an
appropriate single-diff quilt at build time.  To the extent that this
doesn't work, it seems worth fixing.

Thanks,
Jonathan

Bug#962682: nheko FTCBFS: multiple issues

[Helmut Grohne]

Source: nheko
Version: 0.7.1-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability ftcbfs

nheko fails to cross build from source. The immediate cause is its
Build-Depends on g++. This dependency is unsatisfiable and needs cross
translation. Unfortunately, cross translation isn't supported in the
archive yet. However, the dependency is implicitly satisfied even in
buster, so it can be safely dropped. Then it runs cmake for the build
architecture. An easy way to pass cross flags to cmake is calling it via
dh_auto_configure The resulting patch makes nheko cross buildable.
Please consider applying it.

Helmut
diff --minimal -Nru nheko-0.7.1/debian/changelog nheko-0.7.1/debian/changelog
--- nheko-0.7.1/debian/changelog2020-04-24 20:02:57.0 +0200
+++ nheko-0.7.1/debian/changelog2020-05-24 17:24:16.0 +0200
@@ -1,3 +1,12 @@
+nheko (0.7.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Drop g++ build dependency satisfied in buster.
++ Let dh_auto_configure pass cross flags to cmake.
+
+ -- Helmut Grohne   Sun, 24 May 2020 17:24:16 +0200
+
 nheko (0.7.1-1) unstable; urgency=medium
 
   * New upstream release.
diff --minimal -Nru nheko-0.7.1/debian/control nheko-0.7.1/debian/control
--- nheko-0.7.1/debian/control  2020-04-24 17:57:33.0 +0200
+++ nheko-0.7.1/debian/control  2020-05-24 17:24:14.0 +0200
@@ -6,7 +6,6 @@
 Build-Depends: cmake (>= 3.15)
  , debhelper-compat (=12)
  , dh-exec
- , g++ (>= 4:7)
  , libboost1.71-dev
  , libboost-atomic1.71-dev
  , libboost-chrono1.71-dev
diff --minimal -Nru nheko-0.7.1/debian/rules nheko-0.7.1/debian/rules
--- nheko-0.7.1/debian/rules2020-03-09 23:52:04.0 +0100
+++ nheko-0.7.1/debian/rules2020-05-24 17:24:16.0 +0200
@@ -15,10 +15,10 @@
 override_dh_auto_build: FAKEHOME = HOME=$(CURDIR)/fakehome
 override_dh_auto_build:
[ -d fakehome ] || mkdir fakehome
-   $(FAKEHOME) cmake -Hmtxclient -B.deps -DCMAKE_VERBOSE_MAKEFILE=ON 
-DBUILD_LIB_TESTS=OFF -DBUILD_SHARED_LIBS=OFF
-   $(FAKEHOME) cmake --build .deps
-   $(FAKEHOME) cmake -H. -Bbuild -DCMAKE_BUILD_TYPE=RelWithDebInfo 
-DCMAKE_INSTALL_PREFIX=.deps/usr -DCMAKE_VERBOSE_MAKEFILE=ON
-   $(FAKEHOME) cmake --build build
+   $(FAKEHOME) dh_auto_configure --sourcedirectory=mtxclient 
--builddirectory=.deps -- -DCMAKE_VERBOSE_MAKEFILE=ON -DBUILD_LIB_TESTS=OFF 
-DBUILD_SHARED_LIBS=OFF
+   $(FAKEHOME) dh_auto_build --sourcedirectory=mtxclient 
--builddirectory=.deps
+   $(FAKEHOME) dh_auto_configure --builddirectory=build -- 
-DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_PREFIX_PATH=.deps 
-DCMAKE_INSTALL_PREFIX=.deps/usr -DCMAKE_VERBOSE_MAKEFILE=ON
+   $(FAKEHOME) dh_auto_build --builddirectory=build
rm -rf fakehome
 
 override_dh_auto_test:

Bug#962681: battery drain during system shutdown

[Gopal Sharma]

Package: linux
Version: 4.19.0-4 +
Severity: grave
A regression was introduced in 4.13-rc1(Mainline) and newer kernels. This
regression caused battery drain during system suspend, hibernation or
shutdown for some PCI devices that are not allowed by user space to wake
up the system from sleep (or power off).

It has been fixed in the upstream kernel, but still present in buster
and bullseye.

Kindly patch the debian kernel.

https://patchwork.kernel.org/patch/10387667/

Thanks,

Gopal.

Bug#946412: janus-gateway: upstream does not support stable releases

[Salvatore Bonaccorso]

Hi Jonas,

On Sun, Dec 08, 2019 at 02:09:10PM +0100, Jonas Smedegaard wrote:
> Package: janus-gateway
> Version: 0
> Severity: important
> Tags: upstream
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Upstream releases are to be considered draft snapshots,
> and this package is therefore unsuitable for inclusion
> in long-term distributions like Debian stable.
> 
> This bug should be bumped to release-critical state
> close to or after entering freeze -
> but not before so as to ease use for users tracking testing
> including derivatives based on Debian testing.

Reading the above, so janus should not have been in buster, right?

As such it might be a good option to ask for removal of src:janus in
buster. If you agree on that, can you fill a bug for the
release-team/SRM to ask for removal of the package in the next buster
point release?

Regards,
Salvatore

Bug#962622: qmapshack: Segmentation fault: no file found for translations

[ael]

On Thu, Jun 11, 2020 at 09:24:01PM +0200, Sebastiaan Couwenberg wrote:
> 
> The issue was already fixed upstream, those changes have been included
> as patch which will be included in the next upload. As the gdal
> transition just started, the the upload will have to wait until that's
> completed.

Thanks. I saw the upstream duplicate bug. Menawhile I must look into code page 
generation.

ael

Bug#962680: janus: CVE-2020-13898 CVE-2020-13899 CVE-2020-13900 CVE-2020-13901

[Salvatore Bonaccorso]

Source: janus
Version: 0.10.0-1
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://github.com/meetecho/janus-gateway/pull/2214

Hi,

The following vulnerabilities were published for janus.

CVE-2020-13898[0]:
| An issue was discovered in janus-gateway (aka Janus WebRTC Server)
| through 0.10.0. janus_sdp_process in sdp.c has a NULL pointer
| dereference.


CVE-2020-13899[1]:
| An issue was discovered in janus-gateway (aka Janus WebRTC Server)
| through 0.10.0. janus_process_incoming_request in janus.c discloses
| information from uninitialized stack memory.


CVE-2020-13900[2]:
| An issue was discovered in janus-gateway (aka Janus WebRTC Server)
| through 0.10.0. janus_sdp_preparse in sdp.c has a NULL pointer
| dereference.


CVE-2020-13901[3]:
| An issue was discovered in janus-gateway (aka Janus WebRTC Server)
| through 0.10.0. janus_sdp_merge in sdp.c has a stack-based buffer
| overflow.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-13898
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13898
[1] https://security-tracker.debian.org/tracker/CVE-2020-13899
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13899
[2] https://security-tracker.debian.org/tracker/CVE-2020-13900
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13900
[3] https://security-tracker.debian.org/tracker/CVE-2020-13901
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13901
[4] https://github.com/meetecho/janus-gateway/pull/2214

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#962679: RFS: idle3-tools/0.9.1-6 [QA] -- idle3-tools - change the idle3 timer of recent Western Digital Hard Disk Drives

[Fabio Augusto De Muzio Tobich]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "idle3-tools"

 * Package name: idle3-tools
   Version : 0.9.1-6
   Upstream Author : [fill in name and email of upstream]
 * URL : http://idle3-tools.sourceforge.net/
 * License : GPL-3+
 * Vcs : https://salsa.debian.org/debian/idle3-tools
   Section : admin

It builds those binary packages:

  idle3-tools - change the idle3 timer of recent Western Digital Hard Disk 
Drives

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

  https://mentors.debian.net/package/idle3-tools

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

  dget -x 
https://mentors.debian.net/debian/pool/main/i/idle3-tools/idle3-tools_0.9.1-6.dsc

Changes since the last upload:

   * QA upload.
   * debian/control:
   - Added 'Rules-Requires-Root: no' to source stanza.
   - Added Vcs-* fields to source stanza.
   - Removed trailing whitespace.
   * debian/copyright:
   - Added 'hdparm' License block.
   - Added Leandro Ramos and myself to packaging block.
   - Updated block for 'sqio.c'.
   - Updated packaging years.
   - Updated short license fields.
   - Using a secure URI in Format field.
   - Using a secure URI in Source field.
   * debian/patches/01-695876-idle3ctl.8.patch: updated header.
   * debian/patches/02_fix-spelling-errors.patch: created to fix spelling errors
 in the manpage.
   * debian/patches/03_fix-makefile-for-hardening.patch: created to fix Makefile
 to use flags for gcc hardening.
   * debian/patches/04_fix-typo-in-idle3ctl.c.patch: added.
   * debian/rules:
   - Added flags for gcc hardening.
   - Removed DH_VERBOSE export.
   - Removed trailing whitespace.
   - Removed unnecessary override for dh_auto_install.
   * debian/salsa-ci.yml: added to provide CI tests for Salsa.
   * debian/upstream/metadata: created.
   * debian/watch: created.

Regards,

--
  Fabio Augusto De Muzio Tobich


pgp2jnYLHlYl2.pgp
Description: PGP signature

Bug#962678: RFS: m2vrequantiser/1.1-5 [QA] -- MPEG-2 streams requantization

[Fabio Augusto De Muzio Tobich]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: m2vrequantiser
   Version : 1.1-5
   Upstream Author : Martin Wimpress 
 * URL : https://launchpad.net/m2vrequantiser
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/debian/m2vrequantiser
   Section : video

It builds those binary packages:

  m2vrequantiser - MPEG-2 streams requantization

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/m/m2vrequantiser/m2vrequantiser_1.1-5.dsc

Changes since the last upload:

   * QA upload.
   * debian/control: added 'Rules-Requires-Root: no' to source stanza.
   * debian/copyright: updated packaging years.
   * debian/patches/: updated patches headers.
   * debian/rules:
   - Added DEB_BUILD_MAINT_OPTIONS variable to improve GCC hardening.
   - Removed unnecessary dh argument.
   * debian/tests/control: created to perform trivial CI test.
   * debian/upstream/metadata: created.
   * debian/watch:
   - Bumped version to 4.
   - Improved search regex.

Regards,

--
  Fabio Augusto De Muzio Tobich


pgpYDU3zlNDL3.pgp
Description: PGP signature

Bug#962675: can cdbfasta be marked Multi-Arch: foreign?

[Andreas Tille]

On Thu, Jun 11, 2020 at 06:26:47PM +0200, Helmut Grohne wrote:
> 
> microbiomeutil fails to cross build from source, because it fails
> running cdbfasta with an "Exec format error". Usually, this indicates
> that the relevant package should be marked Multi-Arch: foreign. It is
> not entirely clear to me whether doing so is correct. Can you help me
> figure out? Please point out what is wrong below.
> 
> Reading the cdbfasta manual page, it seems to be a tool for transforming
> file formats. Looking into microbiomeutil, it seems that the input
> format is textual. Textual file formats usually are
> architecture-independent. Then microbiomeutil installs the output files
> into an architecture-independent package. If those output files were
> architecture-dependent, then microbiomeutil would be wrong in doing so.
> This suggests that the marking should be correct. The question really
> is: Does the command line interface or input/output format of cdbfasta
> or cdbyank depend on the processor architecture it is being run on? If
> the answer is "no", please mark it Multi-Arch: foreign. If the answer is
> "yes", please close this bug. If the answer is not clear, please get in
> touch we me an we can figure out together.

Getting in touch with you and the Debian Med mailing list since the
answer is not clear to me.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#962677: mark g++-multilib-mipsel-linux-gnu and other multilibs Multi-Arch: foreign

[Helmut Grohne]

Package: g++-multilib-mipsel-linux-gnu
Version: 1.185.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

In the absence of cross-translatable toolchain dependencies (#666743), a
workaround can be expanding Build-Depends. This is already used by e.g.
gcc-N and linux. If you apply this workaround to g++-multilib, it
becomes:

g++-multilib [mipsel] , g++-multilib-mipsel-linux-gnu [mipsel] 


Unfortuntely, g++-multilib-mipsel-linux-gnu is not Multi-Arch tagged, so
a mipsel package is found, but there is none. The dependency is
unsatisfiable. Since the package name contains an architecture, it
really should be marked Multi-Arch: foreign.

mipsel is only an example here. It really works the same way for any
other architecture.

Please consider applying the attached patch.

Helmut
diff --minimal -Nru gcc-defaults-1.185.1/debian/changelog 
gcc-defaults-1.185.1+nmu1/debian/changelog
--- gcc-defaults-1.185.1/debian/changelog   2019-09-09 14:30:14.0 
+0200
+++ gcc-defaults-1.185.1+nmu1/debian/changelog  2020-06-11 18:07:43.0 
+0200
@@ -1,3 +1,10 @@
+gcc-defaults (1.185.1+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark all cross tools Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 11 Jun 2020 18:07:43 +0200
+
 gcc-defaults (1.185.1) unstable; urgency=medium
 
   * Build the mipsel and mips64el cross packages from the
diff --minimal -Nru gcc-defaults-1.185.1/debian/control 
gcc-defaults-1.185.1+nmu1/debian/control
--- gcc-defaults-1.185.1/debian/control 2019-09-09 14:30:14.0 +0200
+++ gcc-defaults-1.185.1+nmu1/debian/control2020-06-11 18:07:36.0 
+0200
@@ -541,6 +541,7 @@
 Package: gcc-multilib-x86-64-linux-gnu
 Priority: optional
 Architecture: arm64 i386 ppc64el x32
+Multi-Arch: foreign
 Depends: cpp-x86-64-linux-gnu (= ${version:cpp}),
   gcc-x86-64-linux-gnu (= ${version:gcc}),
   gcc-${pv:gcc}-multilib-x86-64-linux-gnu ${reqv:gcc},
@@ -556,6 +557,7 @@
 Package: g++-multilib-x86-64-linux-gnu
 Priority: optional
 Architecture: arm64 i386 ppc64el x32
+Multi-Arch: foreign
 Depends: cpp-x86-64-linux-gnu (= ${version:cpp}),
   g++-x86-64-linux-gnu (= ${version:gpp}),
   gcc-multilib-x86-64-linux-gnu (= ${version:gcc}),
@@ -570,6 +572,7 @@
 Package: gobjc-multilib-x86-64-linux-gnu
 Priority: optional
 Architecture: arm64 i386 ppc64el x32
+Multi-Arch: foreign
 Depends: cpp-x86-64-linux-gnu (>= ${version:cpp}),
   gobjc-x86-64-linux-gnu (>= ${version:gobjc}),
   gcc-multilib-x86-64-linux-gnu (>= ${version:cpp}),
@@ -586,6 +589,7 @@
 Package: gobjc++-multilib-x86-64-linux-gnu
 Priority: optional
 Architecture: arm64 i386 ppc64el x32
+Multi-Arch: foreign
 Depends: cpp-x86-64-linux-gnu (>= ${version:cpp}),
   gcc-multilib-x86-64-linux-gnu (>= ${version:cpp}),
   gobjc++-x86-64-linux-gnu (>= ${version:gobjcxx}),
@@ -604,6 +608,7 @@
 Package: gfortran-multilib-x86-64-linux-gnu
 Priority: optional
 Architecture: arm64 i386 ppc64el x32
+Multi-Arch: foreign
 Depends: cpp-x86-64-linux-gnu (= ${version:cpp}),
   gcc-multilib-x86-64-linux-gnu (= ${version:gcc}),
   gfortran-x86-64-linux-gnu (= ${version:gfort}),
@@ -621,6 +626,7 @@
 Package: gccgo-multilib-x86-64-linux-gnu
 Priority: optional
 Architecture: arm64 i386 ppc64el x32
+Multi-Arch: foreign
 Depends: cpp-x86-64-linux-gnu (>= ${version:cpp}),
   g++-multilib-x86-64-linux-gnu (>= ${version:gcc}),
   gccgo-x86-64-linux-gnu (>= ${version:ggo}),
@@ -637,6 +643,7 @@
 Package: gdc-multilib-x86-64-linux-gnu
 Priority: optional
 Architecture: arm64 i386 ppc64el x32
+Multi-Arch: foreign
 Depends: cpp-x86-64-linux-gnu (>= ${version:cpp}),
   gdc-${pv:gdc}-multilib-x86-64-linux-gnu ${reqv:gdc},
   gdc-x86-64-linux-gnu (>= ${version:gdc}),
@@ -792,6 +799,7 @@
 Package: gcc-multilib-s390x-linux-gnu
 Priority: optional
 Architecture: amd64 i386 x32 arm64 ppc64el
+Multi-Arch: foreign
 Depends: cpp-s390x-linux-gnu (= ${version:cpp}),
   gcc-s390x-linux-gnu (= ${version:gcc}),
   gcc-${pv:gcc}-multilib-s390x-linux-gnu ${reqv:gcc},
@@ -807,6 +815,7 @@
 Package: g++-multilib-s390x-linux-gnu
 Priority: optional
 Architecture: amd64 i386 x32 arm64 ppc64el
+Multi-Arch: foreign
 Depends: cpp-s390x-linux-gnu (= ${version:cpp}),
   g++-s390x-linux-gnu (= ${version:gpp}),
   gcc-multilib-s390x-linux-gnu (= ${version:gcc}),
@@ -821,6 +830,7 @@
 Package: gobjc-multilib-s390x-linux-gnu
 Priority: optional
 Architecture: amd64 i386 x32 arm64 ppc64el
+Multi-Arch: foreign
 Depends: cpp-s390x-linux-gnu (>= ${version:cpp}),
   gobjc-s390x-linux-gnu (>= ${version:gobjc}),
   gcc-multilib-s390x-linux-gnu (>= ${version:cpp}),
@@ -837,6 +847,7 @@
 Package: gobjc++-multilib-s390x-linux-gnu
 Priority: optional
 Architecture: amd64 i386 x32 arm64 ppc64el
+Multi-Arch: foreign
 Depends: cpp-s390x-linux-gnu (>= ${version:cpp}),
   gcc-multilib-s390x-linux-gnu (>= ${version:cpp}),
   gobjc++-s390x-linux-gnu (>= ${version:gobjcxx}),
@@ -855,6 +866,7 @@
 Package: gfortran-multilib-s390x-linux-gnu
 Priority:

Bug#962675: can cdbfasta be marked Multi-Arch: foreign?

[Helmut Grohne]

Package: cdbfasta
Version: 0.99-20100722-6
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:microbiomeutil

microbiomeutil fails to cross build from source, because it fails
running cdbfasta with an "Exec format error". Usually, this indicates
that the relevant package should be marked Multi-Arch: foreign. It is
not entirely clear to me whether doing so is correct. Can you help me
figure out? Please point out what is wrong below.

Reading the cdbfasta manual page, it seems to be a tool for transforming
file formats. Looking into microbiomeutil, it seems that the input
format is textual. Textual file formats usually are
architecture-independent. Then microbiomeutil installs the output files
into an architecture-independent package. If those output files were
architecture-dependent, then microbiomeutil would be wrong in doing so.
This suggests that the marking should be correct. The question really
is: Does the command line interface or input/output format of cdbfasta
or cdbyank depend on the processor architecture it is being run on? If
the answer is "no", please mark it Multi-Arch: foreign. If the answer is
"yes", please close this bug. If the answer is not clear, please get in
touch we me an we can figure out together.

Helmut

Bug#962676: libzstd FTBFS for alpha: libc doesn't #define st_mtime

[Helmut Grohne]

Source: libzstd
Version: 1.4.5+dfsg-1
Tags: ftbfs patch
User: helm...@debian.org
Usertags: rebootstrap

libzstd fails to build from source on alpha. programs/util.c has code
that checks whether st_mtime is defined as a macro. If yes, it uses a
struct timespec. Otherwise a struct utimebuf. alpha is the only Debian
architecture that does not define st_mtime (while still providing the
field). The code in libzstd selects the struct utimebuf path and fails,
because that isn't declared.

I don't think that st_mtime is guaranteed to be a macro anywhere.
Therefore libzstd should cope with it not being one. The attached patch
achieves that by special casing alpha. Do you have any better ideas?

Helmut
--- libzstd-1.4.5+dfsg.orig/programs/util.c
+++ libzstd-1.4.5+dfsg/programs/util.c
@@ -148,8 +148,10 @@
 /* We check that st_mtime is a macro here in order to give us confidence
  * that struct stat has a struct timespec st_mtim member. We need this
  * check because there are some platforms that claim to be POSIX 2008
- * compliant but which do not have st_mtim... */
-#if (PLATFORM_POSIX_VERSION >= 200809L) && defined(st_mtime)
+ * compliant but which do not have st_mtim...
+ * And then there is alpha, which doesn't define st_mtime, but still has it.
+ */
+#if (PLATFORM_POSIX_VERSION >= 200809L) && (defined(st_mtime) || defined(__alpha__))
 {
 /* (atime, mtime) */
 struct timespec timebuf[2] = { {0, UTIME_NOW} };

Bug#961536: openmw FTBFS with openscenegraph 3.6.5

[Sebastian Ramacher]

Hi Bret

On 2020-06-11 02:36:15 -0700, bret curtis wrote:
> Hello Sebastian,
> On 2020-06-11 at 09:11, sramac...@debian.org wrote:
> > Hi bret
> >
> > On 2020-06-09 18:28:02 +0200, bret curtis wrote:
> > > OpenMW 0.46 has been released and I've uploaded it here, it just
> > > someone kind and just to review and upload. :)
> > >
> > > https://salsa.debian.org/games-team/openmw
> > >
> > > Once uploaded and built, this bug should be closed.
> >
> > Thanks, uploaded with the alternative build dependencies on
> > openscenegraph reversed (patch attached). The buildds only consider the
> > first alternative and openscenegraph-3.4 is no longer in the archive.
> >
> > In d/rules, the dh_missing call should be placed in an override for
> > dh_missing.
> >
> > Cheers
> > --
> > Sebastian Ramacher
> 
> That's great news, and that's fine. Thanks!  OSG 3.4 is only there for
> launchpad PPA reasons as one of our last releases against 3.4.  Moving
> forward to 0.47 we'll target 3.6 exclusively and drop support for OSG 3.4
> so I'll drop that eventually from control.

The build on mipsel failed:
https://buildd.debian.org/status/fetch.php?pkg=openmw&arch=mipsel&ver=0.46.0-1&stamp=1591883193&raw=0

It's missing -latomic. But I'm wondiering if it really makes sense to
build the package on mips*. Is anyone able to play games on mips?

> I have a question about getting OpenMW out of 'contrib' and into 'main'.
> What exactly is holding us up?
> 
> We have an example-suite (our own game for lack of a better name) that can
> be run with OpenMW, would it be better to package this along with OpenMW or
> package it up as something new and put a depend on OpenMW for it?

I'm not involved in games packaging at all. I'd try to get some feedback
on the Debian games list (debian-devel-ga...@lists.debian.org).

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#953629: debian-policy: Please permit Debian revisions with 1.0 native packages

[Sam Hartman]

I strongly agree with Ian in this matter.

I think there are at least two cases where this issue comes up and is
importand, and where using a debian revision without separate upstream
tarballs is the right approach:

1) small packages currently maintained by the upstream maintainer where
debian revision is incremented for packaging only changes and upstream
revision is incremented for upstream versions

and

2) Cases typically outside the Debian archive where a git tree is being
built as a Debian package especially as part of a CI system and where
the effort of tracking upstream tarballs is undesired.

2) is more of an issue for lintian than it is for debian-policy.

While I feel strongly about this, and believe that  I adequately
explained my position years ago on debian-devel when dpkg first started
rejecting packages with debian revisions and 3.0(native) format,
I don't have the emotional energy for a discussion of this.
The way I was treated by the dpkg maintainer back then caused me to stop
working on Debian for months and seriously consider moving on to other
things.
I just don't have the emotional bandwidth to deal with a discussion
where well-considered arguments will be ignored and/or dismissed with
little consideration.

So, +1 on this, but don't expect me to be able to participate much in
the discussion.


signature.asc
Description: PGP signature

Bug#960495: transition: gdal

[Sebastian Ramacher]

On 2020-06-11 20:37:58 +0200, Sebastiaan Couwenberg wrote:
> On 6/11/20 6:46 AM, Sebastiaan Couwenberg wrote:
> > On 6/10/20 9:46 PM, Sebastian Ramacher wrote:
> >> Please go ahead with the upload to unstable.
> > 
> > Thanks, gdal (3.1.0+dfsg-1) was just uploaded to unstable.
> 
> The rebuild are looking good so far
> 
> Please also binNMU postgis in experimental.

Scheduled.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#962592: autocomplete with tar command doesn't work (Debian 10.4)

[Gabriel F. T. Gomes]

On 10 Jun 2020, Sławomir Stańczak wrote:
>
>$ tar -cf 000/ not working

If I understand correctly, you would like for 'tar -cf ' to
complete with tar files already present in the file system. Although I
believe that this would be a reasonable thing to do, upstream
bash-completion seems to believe that there's no point in doing so, as
can be seem in the current code [1]:

  # Generate completions for -f/--file.
  __tar_file_option()
  {
local ext="$1"

case "$tar_mode" in
  c)
# no need to advise user to re-write existing tarball
_filedir -d
;;
  *)
_filedir "$ext"
;;
esac
  }

On the other hand, Ville Skyttä, the current upstream maintainer,
suggested, in the past [2], that the behavior you expect could be a
good thing.

I'll try to come up with an upstream patch.


Cheers,
Gabriel

PS: This bug is similar to https://bugs.debian.org/619548, which I
closed on the assumption that upstream wouldn't want this change. Now I
believe I shouldn't have closed it at all, so I'll use this new bug to
track this. Thanks for the report.

[1] 
https://github.com/scop/bash-completion/blob/master/completions/tar#L215-L229
[2] https://bugs.debian.org/618734#68

Bug#858156: patch

[tv7iR8OPvrPi]

Package: marco
Version: 1.20.3-1

The icon is mangled when the application is using XWMHints() method,
xterm is affected but also application using SDL1.2 framework among others.
The problem occur in Debian 9 and 10 with marco window manager.

See attached patch, the patch can be applied to marco source (Debian version 9 
or 10).diff -pur a/src/core/iconcache.c b/src/core/iconcache.c
--- a/src/core/iconcache.c	2018-12-19 14:47:57.0 -0500
+++ b/src/core/iconcache.c	2020-06-11 09:15:26.943970191 -0400
@@ -335,11 +335,20 @@ apply_mask (GdkPixbuf *pixbuf,
   int src_stride;
   int dest_stride;
 
-  w = MIN (gdk_pixbuf_get_width (mask), gdk_pixbuf_get_width (pixbuf));
-  h = MIN (gdk_pixbuf_get_height (mask), gdk_pixbuf_get_height (pixbuf));
-
   with_alpha = gdk_pixbuf_add_alpha (pixbuf, FALSE, 0, 0, 0);
 
+  /* make sure we have the proper pixel format before proceeding */
+  if (gdk_pixbuf_get_n_channels (with_alpha) != 4 ||
+  gdk_pixbuf_get_bits_per_sample (with_alpha) != 8 ||
+  gdk_pixbuf_get_has_alpha (with_alpha) != 1 ||
+  gdk_pixbuf_get_n_channels (mask) != 4 ||
+  gdk_pixbuf_get_bits_per_sample (mask) != 8 ||
+  gdk_pixbuf_get_has_alpha (mask) != 1)
+return with_alpha; /* wrong pixel format: no alpha */
+
+  w = MIN (gdk_pixbuf_get_width (mask), gdk_pixbuf_get_width (with_alpha));
+  h = MIN (gdk_pixbuf_get_height (mask), gdk_pixbuf_get_height (with_alpha));
+
   dest = gdk_pixbuf_get_pixels (with_alpha);
   src = gdk_pixbuf_get_pixels (mask);
 
@@ -352,13 +361,13 @@ apply_mask (GdkPixbuf *pixbuf,
   j = 0;
   while (j < w)
 {
-  guchar *s = src + i * src_stride + j * 3;
+  guchar *s = src + i * src_stride + j * 4;
   guchar *d = dest + i * dest_stride + j * 4;
 
   /* s[0] == s[1] == s[2], they are 255 if the bit was set, 0
* otherwise
*/
-  if (s[0] == 0)
+  if (s[3] == 0)
 d[3] = 0;   /* transparent */
   else
 d[3] = 255; /* opaque */

Bug#962622: qmapshack: Segmentation fault: no file found for translations

[Sebastiaan Couwenberg]

Control: tags -1 pending

On 6/11/20 7:24 PM, Sebastiaan Couwenberg wrote:
> On 6/11/20 7:21 PM, ael wrote:
>> On Thu, Jun 11, 2020 at 06:28:58PM +0200, Sebastiaan Couwenberg wrote:
>>> On 6/11/20 4:55 PM, ael wrote:
 Small test.img (20M) attached.
>>>
>>> This indeed causes a segfault, but gmapsup.img files from
>>> garmin.openstreetmap.nl work correctly.
>>
>> It is likely to be something to do with the typ file. If I omit a typ
>> file, then there is no problem. But still, any segfault is always a bug,
>> of course.
> 
> Indeed, the exception should at least be caught. Please subscribe to the
> issue in the upstream issue tracker if you haven't done so already to
> follow up there.

The issue was already fixed upstream, those changes have been included
as patch which will be included in the next upload. As the gdal
transition just started, the the upload will have to wait until that's
completed.

Kind Regards,

Bas

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

Bug#962674: stretch-pu: package ca-certificates/20200611~deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2020-06-11 at 13:33 -0500, Michael Shuler wrote:
> #911289 resulted in a regression, and the explicitly blacklisted
> roots  have been reverted. One in particular, "GeoTrust Global CA",
> has caused  serious issues noted in #962596. The other reverted roots
> also remain in  the Mozilla CA bundle[0], so #911289 will require
> additional research  and be re-opened when uploaded.

As with the buster update, please go ahead; thanks.

Regards,

Adam

Bug#962672: buster-pu: package ca-certificates/20200611~deb10u1

[Adam D. Barratt]

On Thu, 2020-06-11 at 13:48 -0500, Michael Shuler wrote:
> On 6/11/20 1:33 PM, Adam D. Barratt wrote:
> > Just to confirm - will the certificates be automatically re-added
> > (assuming that users have either the automatically trust or prompt
> > options enabled)?
> 
> (stretch-pu report cc'ed, since same applies)
> 
> Excellent question. I believe we're going to hit #743339 "Previously 
> removed certificates not added again". I had not found a reasonable
> fix for that case in general, to preserve a user's selections. Maybe
> a "good enough" fix will have to do for the specific ones added back.

OK.

In that case, how does this seem as an SUA text?


The ca-certificates update described in SUA 182-1 removed some
certificates issued by Symantec (under various brand names).
Unfortunately, this removal led to a number of reported regressions.
The affected certificates have therefore been reintroduced.

If you have already installed the package from SUA 182-1, and need to
use the affected certificates, you may need to manually enable them by
running "dpkg-reconfigure ca-certificates" as root.


Regards,

Adam

Bug#762930: radicale: The multifilesystem storage backend takes too much CPU

[Jonas Smedegaard]

Version: 2.0.0~rc1-1

Hi Tina,

Quoting Martína Ferrari (2014-09-26 14:19:41)
> While trying to migrate to the new multifilesystem storage backend, I 
> naively copied all the contacts using icedove. I noticed it was taking 
> too long, so I checked the server and found that it consumed 100% CPU 
> for more than an hour to write about 600 records. A quick strace 
> revealed that for every new record, it was re-creating dozens of 
> unrelated files (probably all of them?).
> 
> I have not debugged this issue, but it is clearly a problem. Also, I 
> don't know if this is also present in the other backends, as I haven't 
> tried doing such a bulk import.

First of all, sorry for the horribly late response!

Things have improved since release 0.9, to the point that I consider it 
is tolerable nowadays.

Upcoming release 3 will have further improvements specifically for bulk 
transfers (but I don't know if Icedove makes use of that).

I dare close this as solved upstream.  Please reopen if you disagree.


Kind regards,

 - Jonas

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

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

signature.asc
Description: signature

Bug#953629: debian-policy: Please permit Debian revisions with 1.0 native packages

[Felix Lechner]

Hi,

As a Lintian maintainer, I would like to express support for Ian's
effort to remove restrictions on Debian version strings.

Unlike Ian, however, I also believe all packages should be converted
to format 3.0. A package's 'nativeness' is then declared explicitly,
and does not have to be inferred from the version string.

Lintian still does the latter for installation packages (aka 'binary'
packages) because the expected changelog locations differ (and tags
are issued accordingly). In my view, nativeness should only matter for
source packages. The provenance of an installation package should not
matter.

I wrote this message because the Lintian bug that is blocked by this
one will be triaged in another way. Lintian supports Ian's effort to
the extent that it simplifies the parsing of version strings.

Kind regards
Felix Lechner

Bug#249470: whizzytex: wrong pagebreaks in duplex view

[remy]

Even in full document view, there may be some small differences in the page
layout, since whizzytex still instrument the document to track information
such as line numbers, counters, etc. which include \special commands
at many places, which may sometimes modify the layout.

This is unfortunate, but I do not consider this as a bug.

Didier Rémy


> Package: whizzytex
> Version: 1.1.3.0-1
> Severity: normal

> Hi,

> I have been using whizzytex for quite some time now. I mostly use
> whizzytex's duplex view to proof read my tex files.

> There is a problem with the attached example (main document is
> logik.tex). The last page of the document (page 18) has two more lines
> in whizzytex's version (viewed with advi). A manual latex run produces
> a different page break, with those two lines still on page 17.

> I have already stripped down the files as much as possible. If I
> remove some pages from the front of the document, all page breaks are
> correct.

Bug#962672: buster-pu: package ca-certificates/20200611~deb10u1

[Michael Shuler]

On 6/11/20 1:33 PM, Adam D. Barratt wrote:

Just to confirm - will the certificates be automatically re-added
(assuming that users have either the automatically trust or prompt
options enabled)?


(stretch-pu report cc'ed, since same applies)

Excellent question. I believe we're going to hit #743339 "Previously 
removed certificates not added again". I had not found a reasonable fix 
for that case in general, to preserve a user's selections. Maybe a "good 
enough" fix will have to do for the specific ones added back.


Thanks for the question, patch ideas welcomed.

Michael

Bug#960495: transition: gdal

[Sebastiaan Couwenberg]

On 6/11/20 6:46 AM, Sebastiaan Couwenberg wrote:
> On 6/10/20 9:46 PM, Sebastian Ramacher wrote:
>> Please go ahead with the upload to unstable.
> 
> Thanks, gdal (3.1.0+dfsg-1) was just uploaded to unstable.

The rebuild are looking good so far

Please also binNMU postgis in experimental.

Kind Regards,

Bas

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



signature.asc
Description: OpenPGP digital signature

Bug#962672: buster-pu: package ca-certificates/20200611~deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2020-06-11 at 13:25 -0500, Michael Shuler wrote:
> #911289 resulted in a regression, and the explicitly blacklisted
> roots  have been reverted. One in particular, "GeoTrust Global CA",
> has caused  serious issues noted in #962596. The other reverted roots
> also remain in  the Mozilla CA bundle[0], so #911289 will require
> additional research  and be re-opened when uploaded.

Please feel free to get the new version uploaded. (It will need to be
in unstable before we push it to -updates, but they could be uploaded
at the same time.)

Just to confirm - will the certificates be automatically re-added
(assuming that users have either the automatically trust or prompt
options enabled)?

Regards,

Adam

Bug#962674: stretch-pu: package ca-certificates/20200611~deb9u1

[Michael Shuler]

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

Hi release team,

#911289 resulted in a regression, and the explicitly blacklisted roots 
have been reverted. One in particular, "GeoTrust Global CA", has caused 
serious issues noted in #962596. The other reverted roots also remain in 
the Mozilla CA bundle[0], so #911289 will require additional research 
and be re-opened when uploaded.


stretch-proposed-updates and stretch-updates both got the previous upload.

I would like to upload ca-certificates_20200611~deb9u1 with the 
following changes:



ca-certificates (20200611~deb9u1) stretch; urgency=medium

   * Rebuild for stretch.
   * This oldstable release Closes: #962596, #942915

  -- Michael Shuler   Thu, 11 Jun 2020 09:11:56 
-0500


ca-certificates (20200611) unstable; urgency=medium

   * mozilla/blacklist:
 Revert Symantec CA blacklist (#911289). Closes: #962596
 The following root certificates were added back (+):
 + "GeoTrust Global CA"
 + "GeoTrust Primary Certification Authority"
 + "GeoTrust Primary Certification Authority - G2"
 + "GeoTrust Primary Certification Authority - G3"
 + "GeoTrust Universal CA"
 + "thawte Primary Root CA"
 + "thawte Primary Root CA - G2"
 + "thawte Primary Root CA - G3"
 + "VeriSign Class 3 Public Primary Certification Authority - G4"
 + "VeriSign Class 3 Public Primary Certification Authority - G5"
 + "VeriSign Universal Root Certification Authority"

   [ Gianfranco Costamagna ]
   * debian/{rules,control}:
 Merge Ubuntu patch from Matthias Klose to use Python3 during build.
 Closes: #942915

  -- Michael Shuler   Thu, 11 Jun 2020 08:38:00 
-0500



Source debdiff attached.

ca-certificates_20200611~deb9u1 uploaded to mentors[1], RFS will be 
submitted pending pu approval. Source can be fetched from mentors or the 
`debian-stretch` git branch, commit 
c151326dda72f703f7001f655e331b548eb1e411.


Binary debdiff files list matches unstable upload for 20200611 currently 
on mentors - RFS: #962669.


[0] 
https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport

[1] https://mentors.debian.net/package/ca-certificates

Kind regards,
Michael

diffstat for ca-certificates-20200601~deb9u1 ca-certificates-20200611~deb9u1

 debian/changelog|   37 +++--
 debian/control  |8 
 mozilla/Makefile|2 +-
 mozilla/blacklist.txt   |   23 ---
 mozilla/certdata2pem.py |2 +-
 5 files changed, 33 insertions(+), 39 deletions(-)

diff -Nru ca-certificates-20200601~deb9u1/debian/changelog 
ca-certificates-20200611~deb9u1/debian/changelog
--- ca-certificates-20200601~deb9u1/debian/changelog2020-06-05 
11:52:50.0 -0500
+++ ca-certificates-20200611~deb9u1/debian/changelog2020-06-11 
09:11:56.0 -0500
@@ -1,16 +1,33 @@
-ca-certificates (20200601~deb9u1) stretch; urgency=medium
+ca-certificates (20200611~deb9u1) stretch; urgency=medium
 
   * Rebuild for stretch.
-  * Merge changes from 20200601
-- d/control
-  * This release updates the Mozilla CA bundle to 2.40, blacklists
-distrusted Symantec roots, and blacklists expired "AddTrust External
-Root". Closes: #956411, #955038, #911289, #961907
-  * Fix permissions on /usr/local/share/ca-certificates when using symlinks.
-Closes: #916833
-  * Remove email-only roots from mozilla trust store. Closes: #721976
+  * This oldstable release Closes: #962596, #942915
 
- -- Michael Shuler   Fri, 05 Jun 2020 11:52:50 -0500
+ -- Michael Shuler   Thu, 11 Jun 2020 09:11:56 -0500
+
+ca-certificates (20200611) unstable; urgency=medium
+
+  * mozilla/blacklist:
+Revert Symantec CA blacklist (#911289). Closes: #962596
+The following root certificates were added back (+):
++ "GeoTrust Global CA"
++ "GeoTrust Primary Certification Authority"
++ "GeoTrust Primary Certification Authority - G2"
++ "GeoTrust Primary Certification Authority - G3"
++ "GeoTrust Universal CA"
++ "thawte Primary Root CA"
++ "thawte Primary Root CA - G2"
++ "thawte Primary Root CA - G3"
++ "VeriSign Class 3 Public Primary Certification Authority - G4"
++ "VeriSign Class 3 Public Primary Certification Authority - G5"
++ "VeriSign Universal Root Certification Authority"
+
+  [ Gianfranco Costamagna ]
+  * debian/{rules,control}:
+Merge Ubuntu patch from Matthias Klose to use Python3 during build.
+Closes: #942915
+
+ -- Michael Shuler   Thu, 11 Jun 2020 08:38:00 -0500
 
 ca-certificates (20200601) unstable; urgency=medium
 
diff -Nru ca-certificates-20200601~deb9u1/debian/control 
ca-certificates-20200611~deb9u

Bug#962673: cunit: autopkgtest failure: stdio.h: No such file or directory

[Joao Eriberto Mota Filho]

Source: cunit
Version: 2.1-3-dfsg-2.2
Severity: serious

Autopkgtest fails since last NMU with the following messages:

autopkgtest [17:33:49]: test test.sh: [---
debian/tests/test.c:1:10: fatal error: stdio.h: No such file or directory
1 | #include 
  |  ^
compilation terminated.
/tmp/autopkgtest-lxc.m92mckta/downtmp/build.vSN/src/debian/tests/test.sh: 8: 
/tmp/autopkgtest-lxc.m92mckta/downtmp/autopkgtest_tmp/test: not found
debian/tests/test.c:1:10: fatal error: stdio.h: No such file or directory
1 | #include 
  |  ^
compilation terminated.
/tmp/autopkgtest-lxc.m92mckta/downtmp/build.vSN/src/debian/tests/test.sh: 8: 
/tmp/autopkgtest-lxc.m92mckta/downtmp/autopkgtest_tmp/test: not found
autopkgtest [17:33:49]: test test.sh: ---]
autopkgtest [17:33:49]: test test.sh:  - - - - - - - - - - results - - - - - - 
- - - -
test.sh  FAIL non-zero exit status 127
autopkgtest [17:33:50]: test test.sh:  - - - - - - - - - - stderr - - - - - - - 
- - -
debian/tests/test.c:1:10: fatal error: stdio.h: No such file or directory
1 | #include 
  |  ^
compilation terminated.
/tmp/autopkgtest-lxc.m92mckta/downtmp/build.vSN/src/debian/tests/test.sh: 8: 
/tmp/autopkgtest-lxc.m92mckta/downtmp/autopkgtest_tmp/test: not found
debian/tests/test.c:1:10: fatal error: stdio.h: No such file or directory
1 | #include 
  |  ^
compilation terminated.
/tmp/autopkgtest-lxc.m92mckta/downtmp/build.vSN/src/debian/tests/test.sh: 8: 
/tmp/autopkgtest-lxc.m92mckta/downtmp/autopkgtest_tmp/test: not found
autopkgtest [17:33:50]:  summary
test.sh  FAIL non-zero exit status 127


The release team has announced [1] that failing autopkgtest are now considered
RC in testing. The full log from autopkgtest is availble here[2].

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html
[2] https://ci.debian.net/data/autopkgtest/unstable/amd64/c/cunit/5861880/log.gz

Regards,

Eriberto

Bug#959768: [PATCH] initramfs-tools/hook-functions: Fix libgcc_s.so.1 dependency

[John Paul Adrian Glaubitz]

Hi Ben!

On 6/11/20 2:45 PM, Ben Hutchings wrote:
>>> Fix it by searching the relevant libgcc_so files.
>>> The fix is modelled after the btrfs hook functions in
>>> /usr/share/initramfs-tools/hooks/btrfs.
>> Could you open a merge request on Salsa so that Ben just needs to merge this
>> change?
> 
> I actually implemented a fix for this already but didn't push it.
> 
> Can you check whether the benh/libgcc_s branch works for you?

Yes, I can confirm that this fixes the issue for me.

Adrian

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

Bug#962672: buster-pu: package ca-certificates/20200611~deb10u1

[Michael Shuler]

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

Hi release team,

#911289 resulted in a regression, and the explicitly blacklisted roots 
have been reverted. One in particular, "GeoTrust Global CA", has caused 
serious issues noted in #962596. The other reverted roots also remain in 
the Mozilla CA bundle[0], so #911289 will require additional research 
and be re-opened when uploaded.


buster-proposed-updates and buster-updates both got the previous upload.

I would like to upload ca-certificates_20200611~deb10u1 with the 
following changes:



ca-certificates (20200611~deb10u1) buster; urgency=medium

  * Rebuild for buster.
  * This stable release Closes: #962596, #942915

 -- Michael Shuler   Thu, 11 Jun 2020 09:07:27 
-0500


ca-certificates (20200611) unstable; urgency=medium

  * mozilla/blacklist:
Revert Symantec CA blacklist (#911289). Closes: #962596
The following root certificates were added back (+):
+ "GeoTrust Global CA"
+ "GeoTrust Primary Certification Authority"
+ "GeoTrust Primary Certification Authority - G2"
+ "GeoTrust Primary Certification Authority - G3"
+ "GeoTrust Universal CA"
+ "thawte Primary Root CA"
+ "thawte Primary Root CA - G2"
+ "thawte Primary Root CA - G3"
+ "VeriSign Class 3 Public Primary Certification Authority - G4"
+ "VeriSign Class 3 Public Primary Certification Authority - G5"
+ "VeriSign Universal Root Certification Authority"

  [ Gianfranco Costamagna ]
  * debian/{rules,control}:
Merge Ubuntu patch from Matthias Klose to use Python3 during build.
Closes: #942915

 -- Michael Shuler   Thu, 11 Jun 2020 08:38:00 
-0500



Source debdiff attached.

ca-certificates_20200611~deb10u1 uploaded to mentors[1], RFS will be 
submitted pending pu approval. Source can be fetched from mentors or the 
`debian-buster` git branch, commit 442fd47f4831483b72329e0df1f6260e4a91ab36.


Binary debdiff files list matches unstable upload for 20200611 currently 
on mentors - RFS: #962669.


[0] 
https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport

[1] https://mentors.debian.net/package/ca-certificates

Kind regards,
Michael
diffstat for ca-certificates-20200601~deb10u1 ca-certificates-20200611~deb10u1

 debian/changelog|   34 +++---
 debian/control  |2 +-
 mozilla/Makefile|2 +-
 mozilla/blacklist.txt   |   23 ---
 mozilla/certdata2pem.py |2 +-
 5 files changed, 30 insertions(+), 33 deletions(-)

diff -Nru ca-certificates-20200601~deb10u1/debian/changelog 
ca-certificates-20200611~deb10u1/debian/changelog
--- ca-certificates-20200601~deb10u1/debian/changelog   2020-06-03 
13:09:34.0 -0500
+++ ca-certificates-20200611~deb10u1/debian/changelog   2020-06-11 
09:07:27.0 -0500
@@ -1,13 +1,33 @@
-ca-certificates (20200601~deb10u1) buster; urgency=medium
+ca-certificates (20200611~deb10u1) buster; urgency=medium
 
   * Rebuild for buster.
-  * Merge changes from 20200601
-- d/control; set d/gbp.conf branch to debian-buster
-  * This release updates the Mozilla CA bundle to 2.40, blacklists
-distrusted Symantec roots, and blacklists expired "AddTrust External
-Root". Closes: #956411, #955038, #911289, #961907
+  * This stable release Closes: #962596, #942915
 
- -- Michael Shuler   Wed, 03 Jun 2020 13:09:34 -0500
+ -- Michael Shuler   Thu, 11 Jun 2020 09:07:27 -0500
+
+ca-certificates (20200611) unstable; urgency=medium
+
+  * mozilla/blacklist:
+Revert Symantec CA blacklist (#911289). Closes: #962596
+The following root certificates were added back (+):
++ "GeoTrust Global CA"
++ "GeoTrust Primary Certification Authority"
++ "GeoTrust Primary Certification Authority - G2"
++ "GeoTrust Primary Certification Authority - G3"
++ "GeoTrust Universal CA"
++ "thawte Primary Root CA"
++ "thawte Primary Root CA - G2"
++ "thawte Primary Root CA - G3"
++ "VeriSign Class 3 Public Primary Certification Authority - G4"
++ "VeriSign Class 3 Public Primary Certification Authority - G5"
++ "VeriSign Universal Root Certification Authority"
+
+  [ Gianfranco Costamagna ]
+  * debian/{rules,control}:
+Merge Ubuntu patch from Matthias Klose to use Python3 during build.
+Closes: #942915
+
+ -- Michael Shuler   Thu, 11 Jun 2020 08:38:00 -0500
 
 ca-certificates (20200601) unstable; urgency=medium
 
diff -Nru ca-certificates-20200601~deb10u1/debian/control 
ca-certificates-20200611~deb10u1/debian/control
--- ca-certificates-20200601~deb10u1/debian/control 2020-06-03 
13:09:34.0 -0500
+++ ca-certificates-20200611~deb10u1/debian/control 2

Bug#962443: Issue not in Thunar 1.8.14-0ubuntu1; potential fix in commit

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, 2020-06-09 at 21:41 +0200, Karl Voit wrote:
> I could not reproduce the issue with an up-to-date Xubuntu 20.04 LTS
> 
> which is featuring Thunar 1.8.14-0ubuntu1.
> 
> 
> 
> So I took a quick look at the commit history of the project. I found a
> 
> potentiel commit candidate that provides a fix for the issue reported:
> 
> https://gitlab.xfce.org/xfce/thunar/-/commit/adca28cea8eeb8efd457cd794271eee72867c23d

So could you try with Thunar 1.8.14-1 from testing or sid so we can confirm
it's fixed there as well?

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl7idPwACgkQ3rYcyPpX
RFt57Af+JyD6TTtkwCFxoTtoKqYBzpnmBRTDpKOZzD+X8+aOProVlr0YREW3XNsC
WU0Y3iEA6KxV50PyncClA0M8jJVaoQaz56XnCpAT0vBr2PwiuHXPb01JvPRFlCz8
YUBznP2B5j5kJUvPe907rUrgbGLVMeDOMs/KgPy+8e/GMARRtO2SO668F2hQkGJz
tEEZiw+0OX8Zjdx/GOP8s67Xmc+Ev6UgpjowffMisoz0ipnlJHiWyKnmsbJ5z6q3
BPB5TgBGw5ZwTJzAryCWLDOiGs9RmCLOm+JzsM9sm5sJJBxyzkrKQ/NKFaQ0KJb2
vR6XGwyP0pAiR0FByyEkwO/TvYz+jg==
=wuSK
-END PGP SIGNATURE-

Bug#962643: cunit: broken NMU does FTBFS

[Eriberto]

All right with build now! \o/

However, I can see the CI tests failing again and we will need a new
NMU. We will work over it now (using Salsa to approve the local
changes in tests). I will open a bug.

Em qui., 11 de jun. de 2020 às 13:22, Adrian Bunk  escreveu:
>
> Something unrelated missing on your list:
> debdiff between previous and current binary packages.
> Both file differences and dependency differences are worth checking.

Added, thanks!
>
> > We are in a local sprint. We are monitoring all builds to prevent
> > issues. We are 17 people working around several issues.
> >...
>
> Ah, I already wondered about all the Brazilian names in
> https://ftp-master.debian.org/deferred.html


Yes. We are 14 collaborators and 3 sponsors.


> I hope I did not come across as unfriendly, more than 100k unwanted LOC
> in the debdiff was just a shock while still drinking my wake-up black tea.

I understand you first impressions and I know your nice work around
Debian. You're welcome.

Cheers,

Eriberto

Bug#962671: lintian: Identify test cases without declared diagnostic value

[Felix Lechner]

Package: lintian
Severity: wishlist

Hi,

Test cases that do not expect any tags or declare any Test-Against:
tags have no declared diagnostic value and should be adjusted or
removed. An internal harness test should identify such cases.

Kind regards
Felix Lechner

Bug#962645: qbittorrent-nox: Qbittorrent-nox is barely usable after the upgrade to 4.2.4-1+b1

[jim_p]

Package: qbittorrent-nox
Version: 4.2.4-1+b1
Followup-For: Bug #962645

The same thing happens on the gui version of qbittorrent, at least on amd64!
The torrent is added as usual, it downloads as it should and once it is done,
qbittorrent crashes with the following output

https://paste.debian.net/1151639/



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

Kernel: Linux 5.6.0-2-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages qbittorrent-nox depends on:
ii  libc6   2.30-8
ii  libgcc-s1   10.1.0-3
ii  libqt5core5a5.12.5+dfsg-10+b1
ii  libqt5network5  5.12.5+dfsg-10+b1
ii  libqt5xml5  5.12.5+dfsg-10+b1
ii  libssl1.1   1.1.1g-1
ii  libstdc++6  10.1.0-3
ii  libtorrent-rasterbar10  1.2.5-1+b1
ii  zlib1g  1:1.2.11.dfsg-2

qbittorrent-nox recommends no packages.

Versions of packages qbittorrent-nox suggests:
pn  qbittorrent-dbg  

-- no debconf information

Bug#962670: Please change meson.build to renable the -o option which is used to collect logs for debugging.

[Jeremiah C. Foster]

Package: flashrom
Version: 1.2-5
Severity: important
Tags: upstream

Dear Maintainer,

Recently upstream made changes to the meson.build file to add the flag
-DSTANDALONE. That flag removes the ability to output logs to a file
with the -o flag. Upstream has issued a patch to return the build file
to enable logs to be piped to a file again;
https://review.coreboot.org/c/flashrom/+/42230/1/meson.build It would
be great if the flashrom maintainer could pick up this change too for
Debian.

Many thanks!

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

Kernel: Linux 5.6.16-958.native (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_CRAP
Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set 
LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE=en_US.UTF-8 (charmap=locale: Cannot set LC_MESSAGES to default 
locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages flashrom depends on:
ii  libc6 2.30-8
ii  libftdi1-21.4-2+b2
ii  libpci3   1:3.6.4-1
ii  libusb-1.0-0  2:1.0.23-2

flashrom recommends no packages.

flashrom suggests no packages.

-- debconf information excluded

Bug#962669: RFS: ca-certificates/20200611 [RC] -- Common CA certificates

[Michael Shuler]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "ca-certificates"

 * Package name: ca-certificates
   Version : 20200611
 * License : Mozilla Public License Version 2.0
 * Vcs : https://salsa.debian.org/debian/ca-certificates
   Section : misc

It builds those binary packages:

  ca-certificates - Common CA certificates
  ca-certificates-udeb - Common CA certificates - udeb

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


  https://mentors.debian.net/package/ca-certificates

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/ca-certificates/ca-certificates_20200611.dsc


Changes since the last upload:

   * mozilla/blacklist:
 Revert Symantec CA blacklist (#911289). Closes: #962596
 The following root certificates were added back (+):
 + "GeoTrust Global CA"
 + "GeoTrust Primary Certification Authority"
 + "GeoTrust Primary Certification Authority - G2"
 + "GeoTrust Primary Certification Authority - G3"
 + "GeoTrust Universal CA"
 + "thawte Primary Root CA"
 + "thawte Primary Root CA - G2"
 + "thawte Primary Root CA - G3"
 + "VeriSign Class 3 Public Primary Certification Authority - G4"
 + "VeriSign Class 3 Public Primary Certification Authority - G5"
 + "VeriSign Universal Root Certification Authority"
 .
   [ Gianfranco Costamagna ]
   * debian/{rules,control}:
 Merge Ubuntu patch from Matthias Klose to use Python3 during build.
 Closes: #942915

Regards,

--
  Michael Shuler

Bug#962622: qmapshack: Segmentation fault: no file found for translations

[Sebastiaan Couwenberg]

On 6/11/20 7:21 PM, ael wrote:
> On Thu, Jun 11, 2020 at 06:28:58PM +0200, Sebastiaan Couwenberg wrote:
>> On 6/11/20 4:55 PM, ael wrote:
>>> Small test.img (20M) attached.
>>
>> This indeed causes a segfault, but gmapsup.img files from
>> garmin.openstreetmap.nl work correctly.
> 
> It is likely to be something to do with the typ file. If I omit a typ
> file, then there is no problem. But still, any segfault is always a bug,
> of course.

Indeed, the exception should at least be caught. Please subscribe to the
issue in the upstream issue tracker if you haven't done so already to
follow up there.

Kind Regards,

Bas

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

Bug#962622: qmapshack: Segmentation fault: no file found for translations

[ael]

On Thu, Jun 11, 2020 at 06:28:58PM +0200, Sebastiaan Couwenberg wrote:
> Control: tags -1 - moreinfo
> Control: tags -1 upstream
> Control: forwarded -1 https://github.com/Maproom/qmapshack/issues/209
> 
> On 6/11/20 4:55 PM, ael wrote:
> > Small test.img (20M) attached.
> 
> This indeed causes a segfault, but gmapsup.img files from
> garmin.openstreetmap.nl work correctly.

It is likely to be something to do with the typ file. If I omit a typ
file, then there is no problem. But still, any segfault is always a bug,
of course.

ael

Bug#962596: ca-certificates: Removal of GeoTrust Global CA requires investigation

[Carlos Alberto Lopez Perez]

On 11/06/2020 18:34, Michael Borg wrote:
> Yep I know but I cannot tell all my customers to run this workaround, some
> of our users are not experienced at all The only thing I see here is
> that I need to provide a hotfix ourselves. We cannot wait for days... You
> are saying we cannot make an exception and push this fix ASAP?

Pushing packages to Debian takes time. If you need something for today you need 
to fix it yourself.

You can downgrade to the old version of the package ca-certificates or install 
the missed certificate manually

This recipe allows to do that:

wget --no-check-certificate -c 
https://www.geotrust.com/resources/root_certificates/certificates/GeoTrust_Global_CA.pem
   \
&& mkdir /usr/local/share/ca-certificates/extra 
  \
&& mv GeoTrust_Global_CA.pem 
/usr/local/share/ca-certificates/extra/GeoTrust_Global_CA.crt   
 \
&& update-ca-certificates

And when you upgrade to the fixed version of ca-certificates you can remove the 
directory /usr/local/share/ca-certificates/extra 
and run the command update-ca-certificates again.



signature.asc
Description: OpenPGP digital signature

Bug#962532: Same bug in 20.1.1-1. Also calibre, vlc, stellarium segfault.

[ziegler]

I see the same bug in version 20.1.1-1.

I found that vlc and stellarium, and calibre all segfault 
immediately in iris_dri.so, but do not kill X. calibre does 
it when loading an epub-file with the process "LoadBook".



(Martin Ziegler)

Bug#962668: Also gives ValueError with another PDF

[Nelson A. de Oliveira]

Hi again!

With another PDF it fails with ValueError:

=
Traceback (most recent call last):
  File "/usr/bin/ebook-convert", line 20, in 
sys.exit(main())
  File "/usr/lib/calibre/calibre/ebooks/conversion/cli.py", line 401, in main
plumber.run()
  File "/usr/lib/calibre/calibre/ebooks/conversion/plumber.py", line 1108, in 
run
self.oeb = self.input_plugin(stream, self.opts,
  File "/usr/lib/calibre/calibre/customize/conversion.py", line 245, in __call__
ret = self.convert(stream, options, file_ext,
  File "/usr/lib/calibre/calibre/ebooks/conversion/plugins/pdf_input.py", line 
73, in convert
opf.render(opffile)
  File "/usr/lib/calibre/calibre/ebooks/metadata/opf2.py", line 1521, in render
item = E.item(id=unicode_type(ref.id), href=href)
  File "src/lxml/builder.py", line 210, in lxml.builder.ElementMaker.__call__
  File "src/lxml/builder.py", line 195, in 
lxml.builder.ElementMaker.__init__.add_dict
  File "src/lxml/etree.pyx", line 2429, in lxml.etree._Attrib.__setitem__
  File "src/lxml/apihelpers.pxi", line 593, in lxml.etree._setAttributeValue
  File "src/lxml/apihelpers.pxi", line 1540, in lxml.etree._utf8
ValueError: All strings must be XML compatible: Unicode or ASCII, no NULL bytes 
or control characters
=

I am unsure if I can attach this PDF here, but I can send it privately if 
needed.

Thank you!

Best regards,
Nelson

Bug#962622: qmapshack: Segmentation fault: no file found for translations

[Sebastiaan Couwenberg]

Control: tags -1 - moreinfo
Control: tags -1 upstream
Control: forwarded -1 https://github.com/Maproom/qmapshack/issues/209

On 6/11/20 4:55 PM, ael wrote:
> Small test.img (20M) attached.

This indeed causes a segfault, but gmapsup.img files from
garmin.openstreetmap.nl work correctly.

I've forwarded the issue upstream as it doesn't seem to be packaging
related issue.

Kind Regards,

Bas

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

Bug#962643: cunit: broken NMU does FTBFS

[Adrian Bunk]

On Thu, Jun 11, 2020 at 11:45:45AM -0300, Eriberto wrote:
>...
> So, I did a double
> check using my sponsor checklist[1], I ran debuild and cowbuilder.
> After this I did a debuild -S and the trash inside debian/ was sent.
> Sorry for this.
> 
> [1] http://bit.ly/pkgcheck
>...

When I sponsor packages I am usually doing the -S at the start and
won't touch the built source package afterwards - this is either
being uploaded or rejected later.

Something unrelated missing on your list:
debdiff between previous and current binary packages.
Both file differences and dependency differences are worth checking.

> We are in a local sprint. We are monitoring all builds to prevent
> issues. We are 17 people working around several issues.
>...

Ah, I already wondered about all the Brazilian names in
https://ftp-master.debian.org/deferred.html

> Thanks a lot for your help.

I hope I did not come across as unfriendly, more than 100k unwanted LOC 
in the debdiff was just a shock while still drinking my wake-up black tea.

> Cheers,
> 
> Eriberto

cu
Adrian

Bug#924172: www.debian.org: differences under english/ between builds in stretch and buster

[Shlomi Fish]

Hi Axel!

You can find my attempt to fix the debian build here:

https://www.shlomifish.org/Files/files/code/wml.debian-shlomify-1.diff

The sed addition to debian/rules seems to improve matters, but the restoration
of p9_slice (to fix loading SliceTermParser.pm ) gives dpkg-source a fit. I
really find the debian gbp stuff puzzling.

here is the script i used:

https://www.shlomifish.org/Files/files/text/docker-wml-debian-perl-v0.1.0.txt

On Thu, 11 Jun 2020 17:00:42 +0200
Axel Beckert  wrote:

> Hi Shlomi,
> 
> [taking Cyril and Laura out of the loop]
> 
> Shlomi Fish wrote:
> > > IIRC I had test suite failures. Need to check 2.28 again. (And yes, I
> > > know, I haven't filed an upstream bug report yet — still haven't
> > > figured out what exactly is the cause for the failures.)  
> > 
> > Ah - thanks for the update. I guess I can try building the package
> > myself in a VM/container. For the record, the build and tests pass
> > fine in travis-ci/ubuntu bionic , locally on fedora and mageia, on
> > the mageia build system, and on appveyor/mswin10/cygwin .  
> 
> Yeah, another reason for not having it reported upstream is that I'm
> not yet sure if one of the Debian patches is the culprit.

It seems like this is the case.

> 
> Regarding Travis CI: IMHO its value is quite limited by the fact that
> Travis is nearly always two or more years behind the latest Ubuntu LTS
> release. (Actually I'm kinda surprised that they in the meanwhile
> managed to support 18.04. The last time I looked (IIRC a few months
> ago around the 20.04 release) they were still on 16.04.
> 

Yes, you can run docker containers in travis.

> > > Will do — as soon I get it building again.  
> > 
> > I'll try to help.  
> 
> Appreciated, but I would kinda feel bad in case one of the Debian
> patches will be identified as the culprit and someone else had to do
> my work. :-)

No worries.

> 
> > > > Converting some of my sites away from wml has shortened their
> > > > build times considerably.  
> > > 
> > > But are they as flexible as before while still being statically
> > > compiled? I doubt.  
> > 
> > They are still "statically compiled" (or generated:
> > https://github.com/shlomif/shlomif-tech-diary/blob/master/static-site-generators--despair.md
> > ), and I verified that they generated the same output before and
> > after using "diff -u -r", html-minifier and other tools. Template
> > Toolkit is fairly flexible [...]  
> 
> Ah, TT. Oh well, from my point of view, TT always felt too generic to
> me. I had the feeling that I'd have to write a lot of the
> infrastructure for static compiling that WML already offers (mainly
> wmk, but also some of the passes like splice), myself. So I never
> considered it to be a WML replacement but rather something that is on
> the same level as e.g. Embperl.)
>

Perhaps.
 
>   Regards, Axel



-- 

Shlomi Fish   https://www.shlomifish.org/
UNIX Fortune Cookies - https://www.shlomifish.org/humour/fortunes/

Fortran - there isn’t a way to do it... oh wait! Now there is.
— https://www.shlomifish.org/humour/ways_to_do_it.html

Please reply to list if it's a mailing list post - https://shlom.in/reply .

Bug#962466: dbus: system-bus autopackage test fails when not run under systemd

[Simon McVittie]

On Mon, 08 Jun 2020 at 14:20:47 +0100, Mark Hindley wrote:
> A patch with the required changes is attached for your consideration.

Thanks, I'll apply this.

> The test attempts to detect whether systemd is available by testing for
> /run/systemd. However, this path can exist on non-systemd systems.

This seems somewhat least-astonishment-violating... is this because
elogind is pretending to be systemd-logind, and needs to create other
directories there to emulate systemd-logind's "filesystem API"?

smcv

Bug#962622: qmapshack: Segmentation fault: no file found for translations

[ael]

On Thu, Jun 11, 2020 at 05:52:04AM +0200, Sebastiaan Couwenberg wrote:
> Control: tags -1 moreinfo
> 
> On 6/10/20 10:08 PM, ael wrote:
> > Trying to read a gmapsupp.img generated by mkgmap using mapnik.typ
> > results in an immediate crash.
> 
> Can you share this file somewhere to help reproduce the issue?

I will see if I can generate a much smaller test.img that also causes
the crash. I did see it before with much smaller file so I should
be able to do that.

ael

Bug#962596: ca-certificates: Removal of GeoTrust Global CA requires investigation

[Michael Shuler]

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

Bump severity. Pending branch commits:

master: commit 679daf6e9bf6fcdcb574b8029297d24836fafde0
  Revert "Set release 20200601; add Symantec CAs to blacklist"
  This reverts commit 1efe81a680eedb94111716c8825290a0cde509af.

debian-buster: commit 442fd47f4831483b72329e0df1f6260e4a91ab36
  Merge branch 'master' into debian-buster

debian-stretch: commit c151326dda72f703f7001f655e331b548eb1e411
  Merge branch 'debian-buster' into debian-stretch

Kind regards,
Michael

Bug#962393: game-data-packager: warning about missing modules

[Jonathan Dowland]

On Sun, Jun 07, 2020 at 02:02:40PM +0200, Reiner Herrmann wrote:

I think this warning should only be shown when it's actually packaging
doom-related packages, because when I want to package data for a different
game, I'm not really interested in missing modules for doom.


I agree.

--
Jonathan Dowland

Bug#943322: llvmlite lags behind upstream verison; blocks Numba update

[Drew Parsons]

Package: python3-llvmlite
Version: 0.32.0-1
Followup-For: Bug #943322
Control: severity -1 serious
Control: block 962176 by -1 

numba has RC bug #962176 that it is failing tests with numpy 1.18. The
latest version numba 0.50.0 fixes this, but requires the latest
version of llvmlite, 0.33.0.

Raising the severity of this bug to Serious, to match the severity of
Bug#962176.


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

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

Versions of packages python3-llvmlite depends on:
ii  libc6   2.30-8
ii  libllvm81:8.0.1-9
ii  libstdc++6  10.1.0-3
ii  llvm-8  1:8.0.1-9
ii  python3 3.8.2-3

python3-llvmlite recommends no packages.

Versions of packages python3-llvmlite suggests:
pn  llvmlite-doc  

-- no debconf information

Bug#962658: libwayland-cursor0: Cursor image left on screen after cursor moved on. Can only be removed by logging out.

[Michel Dänzer]

On 2020-06-11 2:27 p.m., Alan Chandler wrote:
> Package: libwayland-cursor0
> Version: 1.18.0-1
> Severity: normal
> 
> Dear Maintainer,
> 
> 
> I was editing some code in vscode, when, randomly, I though the cursor had
> frozen.  However I soon realised that it was elsewhere on the screen and what 
> I
> was seeing was a frozen image of it.
> 
> Despite closing vscode and switching to different workspaces on my (gnome)
> desktop, the cursor remained in the same place on the screen. It seemed to
> always be in the foreground - ie opening a new window over the top of where it
> was would still show the cursor image, it was not displaced by the new pixels
> from the overlaying window.
> 
> In the end the only way I was able to get it to disappear was to log out and
> then log back in.  The frozen image was removed from the screen on logout.
> 
> My computer is running a AMD graphics card (I think its a RX580) and I need to
> load Linux Non Free Firmware to have a working system at all. I presume that
> could be part of the issue.

This has nothing to do with libwayland-cursor, it's between libmutter
and the amdgpu kernel driver.

Basically, due to unfortunate interaction between mutter and the amdgpu
kernel driver, the former can stop using the HW cursor and start drawing
the cursor in software instead. But in your case, the HW cursor remains
visible, in front of everything else.

I submitted https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1240
to prevent something like this from happening in mutter when
transitioning from monitors disabled via DPMS to enabled. However, from
your description I'm not sure this will help for you as well.

The fact that the HW cursor stays on is most likely an amdgpu kernel
driver issue and should be reported at
https://gitlab.freedesktop.org/drm/amd/-/issues .


-- 
Earthling Michel Dänzer   |   https://redhat.com
Libre software enthusiast | Mesa and X developer

Bug#924172: www.debian.org: differences under english/ between builds in stretch and buster

[Axel Beckert]

Hi Shlomi,

[taking Cyril and Laura out of the loop]

Shlomi Fish wrote:
> > IIRC I had test suite failures. Need to check 2.28 again. (And yes, I
> > know, I haven't filed an upstream bug report yet — still haven't
> > figured out what exactly is the cause for the failures.)
> 
> Ah - thanks for the update. I guess I can try building the package
> myself in a VM/container. For the record, the build and tests pass
> fine in travis-ci/ubuntu bionic , locally on fedora and mageia, on
> the mageia build system, and on appveyor/mswin10/cygwin .

Yeah, another reason for not having it reported upstream is that I'm
not yet sure if one of the Debian patches is the culprit.

Regarding Travis CI: IMHO its value is quite limited by the fact that
Travis is nearly always two or more years behind the latest Ubuntu LTS
release. (Actually I'm kinda surprised that they in the meanwhile
managed to support 18.04. The last time I looked (IIRC a few months
ago around the 20.04 release) they were still on 16.04.

> > Will do — as soon I get it building again.
> 
> I'll try to help.

Appreciated, but I would kinda feel bad in case one of the Debian
patches will be identified as the culprit and someone else had to do
my work. :-)

> > > Converting some of my sites away from wml has shortened their
> > > build times considerably.
> > 
> > But are they as flexible as before while still being statically
> > compiled? I doubt.
> 
> They are still "statically compiled" (or generated:
> https://github.com/shlomif/shlomif-tech-diary/blob/master/static-site-generators--despair.md
> ), and I verified that they generated the same output before and
> after using "diff -u -r", html-minifier and other tools. Template
> Toolkit is fairly flexible [...]

Ah, TT. Oh well, from my point of view, TT always felt too generic to
me. I had the feeling that I'd have to write a lot of the
infrastructure for static compiling that WML already offers (mainly
wmk, but also some of the passes like splice), myself. So I never
considered it to be a WML replacement but rather something that is on
the same level as e.g. Embperl.)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#961979: transition: libwebsockets

[GCS]

On Thu, Jun 11, 2020 at 4:10 PM Paul Gevers  wrote:
> On 11-06-2020 13:46, László Böszörményi (GCS) wrote:
> > Basically the transition is over.
>
> Only when everything is in testing.
 Indeed, that's what I meant it's (only) basically over. The migration
of packages (when this transition can be closed) only depends on time
now.

Sorry for the confusion,
Laszlo/GCS

Bug#962643: cunit: broken NMU does FTBFS

[Eriberto]

Hi Adrian, how are you?

Em qui., 11 de jun. de 2020 às 03:15, Adrian Bunk  escreveu:
>
> On Thu, Jun 11, 2020 at 08:46:23AM +0300, Adrian Bunk wrote:
> >...
> > The diffstat of this NMU is
> >  510 files changed, 139791 insertions(+), 3 deletions(-)
> >
> > It is the responsibility of the sponsor (Cc'ed) to verify that
> > sponsored uploads are not broken:
> > https://wiki.debian.org/DebianMentorsFaq#What_is_the_process_for_sponsoring_a_package.3F
>
> I have to take that back, it is actually likely that this went wrong on
> the sponsor side due to verifying the package:
>
> The debdiff in #960715 looks OK.
>
> Building a source package for upload after having done a testbuild
> can cause this kind of problems, when the source tree is not clean
> many unwanted changes might end up in the new source package.

Thanks a lot for your comments.

The problem is caused by several files in directories created by
package inside debian/ (build, build-ncurses e tmp-ncurses) and not
cleaned by dh_clean. Initially, Regis did a fix for this but I asked
him to remove it because an NMU should not modify some things in
third-party packages (cleanup wasn't a RC target). So, I did a double
check using my sponsor checklist[1], I ran debuild and cowbuilder.
After this I did a debuild -S and the trash inside debian/ was sent.
Sorry for this.

[1] http://bit.ly/pkgcheck

We are in a local sprint. We are monitoring all builds to prevent
issues. We are 17 people working around several issues. Don't worry
because this issue will be fixed today with a NMU without delay and
with an override_dh_autoclean.

Thanks a lot for your help.

Cheers,

Eriberto

Bug#962667: FTBFS on ppc64el

[Frédéric Bonnard]

Package: src:ardour
Version: 1:6.0.0~ds0-1
Control: tags -1 ftbfs

--

Dear maintainer,
ardour fails to build on ppc64el since 1:6.0.0~ds0-1 as shown here :
https://buildd.debian.org/status/logs.php?pkg=ardour

Regards,


F.


signature.asc
Description: PGP signature

Bug#962666: ModuleNotFoundError: No module named 'MySQLdb'

[Olaf Zaplinski]

Package: mailman3-web
Version: 0+20180916-8
Severity: normal

Dear Maintainer,

on a fresh installed Debian host I have installed mariadb-server first and then 
mailman3-full.

Auto configuration of mailman3-web fails:



Creating config file /etc/mailman3/mailman-hyperkitty.cfg with new version
Setting up g++ (4:8.3.0-1) ...
update-alternatives: using /usr/bin/g++ to provide /usr/bin/c++ (c++) in auto 
mode
Setting up python3-django-postorius (1.2.4-1) ...
Setting up python3-django-hyperkitty (1.2.2-1) ...
Setting up mailman3-web (0+20180916-8) ...
Determining localhost credentials from /etc/mysql/debian.cnf: succeeded.
dbconfig-common: writing config to /etc/dbconfig-common/mailman3-web.conf

Creating config file /etc/dbconfig-common/mailman3-web.conf with new version
checking privileges on database mailman3web for mailman3web@localhost: user 
creation needed.
granting access to database mailman3web for mailman3web@localhost: success.
verifying access for mailman3web@localhost: success.
creating database mailman3web: already exists.
dbconfig-common: flushing administrative password

Creating config file /etc/mailman3/mailman-web.py with new version
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/django/db/backends/mysql/base.py", line 
26, in 
import MySQLdb as Database
ModuleNotFoundError: No module named 'MySQLdb'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/django-admin", line 21, in 
management.execute_from_command_line()
  File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", 
line 364, in execute_from_command_line
utility.execute()
  File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", 
line 338, in execute
django.setup()
  File "/usr/lib/python3/dist-packages/django/__init__.py", line 27, in setup
apps.populate(settings.INSTALLED_APPS)
  File "/usr/lib/python3/dist-packages/django/apps/registry.py", line 108, in 
populate
app_config.import_models()
  File "/usr/lib/python3/dist-packages/django/apps/config.py", line 202, in 
import_models
self.models_module = import_module(models_module_name)
  File "/usr/lib/python3.7/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 1006, in _gcd_import
  File "", line 983, in _find_and_load
  File "", line 967, in _find_and_load_unlocked
  File "", line 677, in _load_unlocked
  File "", line 728, in exec_module
  File "", line 219, in _call_with_frames_removed
  File "/usr/lib/python3/dist-packages/hyperkitty/models/__init__.py", line 25, 
in 
from .category import ThreadCategory
  File "/usr/lib/python3/dist-packages/hyperkitty/models/category.py", line 61, 
in 
class ThreadCategory(models.Model):
  File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 124, in 
__new__
new_class.add_to_class('_meta', Options(meta, app_label))
  File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 325, in 
add_to_class
value.contribute_to_class(cls, name)
  File "/usr/lib/python3/dist-packages/django/db/models/options.py", line 214, 
in contribute_to_class
self.db_table = truncate_name(self.db_table, 
connection.ops.max_name_length())
  File "/usr/lib/python3/dist-packages/django/db/__init__.py", line 33, in 
__getattr__
return getattr(connections[DEFAULT_DB_ALIAS], item)
  File "/usr/lib/python3/dist-packages/django/db/utils.py", line 211, in 
__getitem__
backend = load_backend(db['ENGINE'])
  File "/usr/lib/python3/dist-packages/django/db/utils.py", line 115, in 
load_backend
return import_module('%s.base' % backend_name)
  File "/usr/lib/python3.7/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "/usr/lib/python3/dist-packages/django/db/backends/mysql/base.py", line 
30, in 
'Did you install mysqlclient or MySQL-python?' % e
django.core.exceptions.ImproperlyConfigured: Error loading MySQLdb module: No 
module named 'MySQLdb'.
Did you install mysqlclient or MySQL-python?
dpkg: error processing package mailman3-web (--configure):
 installed mailman3-web package post-installation script subprocess returned 
error exit status 1
dpkg: dependency problems prevent configuration of mailman3-full:
 mailman3-full depends on mailman3-web (>= 0+20180916-1); however:
  Package mailman3-web is not configured yet.




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

Kernel: Linux 4.19.0-9-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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mailman3-web depends on:
ii  dbconfig-mysql

Bug#962652: plm: Exercise not working : useless error message

[Martin Quinson]

Hello,

The problem is that this exercise have two worlds. You can switch between 
worlds by clicking on the combobox showing "Swiss cheese" in your interface.
As you can see, there is no (easy) way to hardcode a path for the buggles that 
will lead to the solution. 

It is very often the case in PLM that several worlds are used to have more than 
one test case for the code provided by the user. They act as separate unit 
tests for the proposed solution.
The same code is run by every buggles in every worlds (some exercises have 
multiple buggles on the same world, too).

In this case, you could still determine which is buggle is running by looking 
at the local configuration (where the walls are), and then hardcode a solution 
for each of them. So the exercise is not as robust as one could hope, but I'm 
not sure that it is worth fixing it. The maze lesson is just for fun anyway, 
the pedagogical value is not very high.

A better fix would be to:
- Change the error message to hint about the possibility that it occured in 
another world than the one currently displayed
- Make the combobox blink in red for the same effect

I think I prefer the first solution, because I'd like to change the PLM 
interface to move toward JavaFX so I prefer to not invest too much time to fix 
that swing interface. 

Do you confirm my analysis and validate my proposed fix?

Thanks for your interest,
Mt. 

- Le 11 Juin 20, à 12:06, Georges Khaznadar georg...@debian.org a écrit :

> Package: plm
> Version: 2.8.1-1
> Severity: normal
> 
> Dear Maintainer,
> 
>   * I started plm, with locale=fr.FR-UTF8, and selected Python
> language, then chose exercise #1: "RandomMouseMaze"
>   * I wrote a program to drive the buggle to its destination;
> you can check the program in the attached screenshot and
> attached source file.
>   * The target of the exercise was reached, but a spurious
> warning is emitted when the buggle reaches a fork in the
> maze, just after the interpretation of the substring
> "DAGAGADAADAA". When the target is reached, I can read a
> report about the program's behaviour which I cannot
> understand.
> 
> 
> *** End of the template - remove these template lines ***
> 
> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>  APT prefers stable
>  APT policy: (900, 'stable'), (499, 'testing'), (400, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
> LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages plm depends on:
> ii  default-jdk  2:1.11-72
> ii  java-wrappers0.3
> ii  jruby9.1.17.0-3
> ii  jython   2.7.2+repack1-1
> ii  libgettext-commons-java  0.9.6-6
> ii  libhttpclient-java   4.5.11-1
> ii  libhttpcore-java 4.4.13-1
> ii  libhttpmime-java 4.5.11-1
> ii  libjgit-java 3.7.1-6
> ii  libjson-simple-java  2.3.0-1
> ii  libmiglayout-java5.1-2
> ii  librsyntaxtextarea-java  2.5.8-1
> ii  scala2.11.12-4
> ii  scala-library2.11.12-4
> 
> plm recommends no packages.
> 
> plm suggests no packages.
> 
> -- no debconf information
> 
> *** /tmp/random_mouse_maze.py
> chemin="DAGAGADAADAADAAGADA"
> for c in chemin:
>if c=="D":
>  droite()
>elif c=="G":
>  gauche()
>elif c=="A":
>   avance()

Bug#962664: MultiArch: cannot install amd64 version of package that depends on "all" architecture package

[Mike]

Package: dpkg
Version: 1.19.7
Severity: important

Dear Maintainer,

I am trying to cross-grade at least some of my system from i386 to amd64.  In 
particular I'm trying to swtich dpkg so that the
default arch for anything new is amd64.

I followed the instructions here:
https://wiki.debian.org/CrossGrading
but after installing tar, dpkg and apt amd64 versions there are a lot of broken 
packages, and apt isn't able to resolve it, so
I switched them back and did some more investigation.

There are several packages that cannot be installed, but they all seem to be 
the same root cause.  The simplest example is yelp:am64

 apt install yelp:amd64
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 yelp:amd64 : Depends: python3-distro:amd64 but it is not installable
E: Unable to correct problems, you have held broken packages.

 dpkg -l python3-distro
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  python3-distro 1.3.0-1  all  Linux OS platform information API


There is no way to install yelp:amd64.

Installing via dpkg -i gives the same dependency error.

It depends on python3-distro:amd64, but python3-distro is architecture 
independent, and already installed.

-- Package-specific info:

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

Kernel: Linux 4.19.0-9-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.6-9.2~deb10u1
ii  libc62.28-10
ii  liblzma5 5.2.4-1
ii  libselinux1  2.8-1+b1
ii  tar  1.30+dfsg-6
ii  zlib1g   1:1.2.11.dfsg-1

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt1.8.2.1
pn  debsig-verify  

-- no debconf information

Bug#950645: src:gmp, add lib64 for i386 x32 mipsel etc

[Thorsten Glaser]

On Thu, 11 Jun 2020, YunQiang Su wrote:

> > So we see that the package libgcc-9-dev-i386-cross:amd64 does not exist
> 
> in fact it may be problem of apt, since we do have libgcc-9-dev-i386-cross:all

Ah, but :all packages that are not Multi-Arch:foreign (which this
probably doesn’t qualify for) are implicitly architecture-qualified,
so maybe the Depends must be changed to libgcc-9-dev-i386-cross:all
explicitly?

> It is a :amd64 package, it shouldn't  depends on :i386 package.

With Multi-Arch, this is possible and allowed; wine does it,
for example.

Please get the people behind Multi-Arch on board as well,
they can share valuable insight and perhaps help fixing this.

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#962665: python3: System site-packages directory not in sys.path breaking mechanism for pip3 install from source

[Matthias]

Package: python3
Version: 3.6.7-1~18.04
Severity: important

Dear Maintainer,

after installing a python package (radiotray) from source with pip3 (sudo pip3
install .) The package is not listed by pip3 (pip3 list), nor can it be
imported.

When checking manually the files a located under: /usr/lib/python3.6/site-
packages/radiotray
But this path is missing in the sys.path of python3:

python3 -m site
sys.path = [
'/home/mat',
'/usr/lib/python36.zip',
'/usr/lib/python3.6',
'/usr/lib/python3.6/lib-dynload',
'/home/mat/.local/lib/python3.6/site-packages',
'/usr/local/lib/python3.6/dist-packages',
'/usr/lib/python3/dist-packages',
]
USER_BASE: '/home/mat/.local' (exists)
USER_SITE: '/home/mat/.local/lib/python3.6/site-packages' (exists)
ENABLE_USER_SITE: True

I am aware of the circumstance that debian place the python module installed as
deb package under dist-packages, but this should not prohibit the usage of pip3
for system wide python modules.

A similar bug issue is: https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=765022
Sadly this issue was archived without solving the problem.

So please add the site-packages directory under /usr to the sys.path of
python3.
Propably the following patch need to be adapted to fix this issue:
https://salsa.debian.org/cpython-
team/python3/-/blob/master/debian/patches/sysconfig-debian-schemes.diff

After adding the site-packages directory to the sys.path it should be possible
to use pip3 for install modules system wide.

Cheers Matthias



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

Kernel: Linux 4.15.0-101-generic (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 python3 depends on:
ii  libpython3-stdlib  3.6.7-1~18.04
ii  python3-minimal3.6.7-1~18.04
ii  python3.6  3.6.9-1~18.04ubuntu1

python3 recommends no packages.

Versions of packages python3 suggests:
pn  python3-doc   
pn  python3-tk
pn  python3-venv  

-- no debconf information

Bug#962663: RM: cligh -- ROM; Abandoned from upstream

[Emmanuel Arias]

Package: ftp.debian.org
Severity: normal

Hi,

Cligh is abandoned from upstream [0] and has low popcorn.

[0] https://github.com/CMB/cligh/issues/16


Cheers,
Arias Emmanuel
@eamanu
yaerobi.com

Bug#962646: cligh: Abandoned from upstream

[Emmanuel Arias]

Hi Salvo,

Yes, cligh isn't active now, and the upstream mentions that hub
could be a best tool.

Thanks for the report I will mark for removal.

Cheers,
Arias Emmanuel
@eamanu
http://eamanu.com

El jue., 11 de jun. de 2020 a la(s) 04:33, Salvo Tomaselli
(tipos...@tiscali.it) escribió:
>
> Package: cligh
> Version: 0.3-3
> Severity: important
>
> Dear Maintainer,
>
> cligh is an abandoned project by upstream.
>
> https://github.com/CMB/cligh/issues/16
>
> Also, it is non functional in the case when one (like me) is using
> two factor authentication.
>
> https://github.com/CMB/cligh/issues/17
>
> I would consider its removal from the archive.
>
> It has a low popcon so it should not be much of an issue.
>
> Best
>
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.6.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) (ignored: 
> LC_ALL set to it_IT.UTF-8), LANGUAGE=it (charmap=UTF-8) (ignored: LC_ALL set 
> to it_IT.UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages cligh depends on:
> ii  python3 3.8.2-3
> ii  python3-github  1.43.7-1
> ii  python3-xdg 0.26-3
>
> cligh recommends no packages.
>
> cligh suggests no packages.
>
> -- no debconf information

Bug#961979: transition: libwebsockets

[Paul Gevers]

Hi László,

On 11-06-2020 13:46, László Böszörményi (GCS) wrote:
> Basically the transition is over.

Only when everything is in testing.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#924172: www.debian.org: differences under english/ between builds in stretch and buster

[Shlomi Fish]

Hi Axel,

On Thu, 11 Jun 2020 13:51:28 +0200
Axel Beckert  wrote:

> Hi Shlomi,
> 
> Shlomi Fish wrote:
> > 2. The newest release of wml is 2.28.0 (see
> > https://github.com/thewml/website-meta-language/releases )  
> 
> I know.
> 
> > while Debian sid is stuck at 2.12.x (see
> > https://packages.debian.org/sid/wml ).  
> 
> Yes, as I didn't get any newer releases (up to 2.24) to build properly
> anymore. You can see my tries here:
> https://salsa.debian.org/debian/wml/-/tree/2.20.4-pkg-incomplete
> (ignore the version in the branch name, I didn't expect this to last
> several upstream releases).
> 
> IIRC I had test suite failures. Need to check 2.28 again. (And yes, I
> know, I haven't filed an upstream bug report yet — still haven't
> figured out what exactly is the cause for the failures.)
> 

Ah - thanks for the update. I guess I can try building the package myself in a
VM/container. For the record, the build and tests pass fine in travis-ci/ubuntu
bionic , locally on fedora and mageia, on the mageia build system, and on
appveyor/mswin10/cygwin .

> > I'd rather not support such an old release,  
> 
> It's not about Debian Unstable, it's about the WML version in current
> Debian Unstable (which only happens to be the same upstream version as
> in Debian Unstable for the reasons mentioned above) and Debian (well,
> I) will support this until the EoL of Debian 10 Buster.
>

ok.
 
> > so if the new version still exhibits some
> > regressions, please send a failing testcase to
> > https://github.com/thewml/website-meta-language/tree/master/src/wml_test and
> > I'll try to fix it.  
> 
> Will do — as soon I get it building again.
> 

I'll try to help.

> > Converting some of my sites away from wml has shortened their build times
> > considerably.  
> 
> But are they as flexible as before while still being statically
> compiled? I doubt.
> 

They are still "statically compiled" (or generated:
https://github.com/shlomif/shlomif-tech-diary/blob/master/static-site-generators--despair.md
), and I verified that they generated the same output before and after using
"diff -u -r", html-minifier and other tools. Template Toolkit is fairly
flexible and has fewer "WTF?" surprises than wml, as I discovered some
misrendered output during the conversions. There may be some features that only
wml has and TT doesn't, but I think the benefits outweigh the drawbacks.

>   Regards, Axel



-- 

Shlomi Fish   https://www.shlomifish.org/

Objective Visual Turbo Global jIronOpenPerl++.NET™ Enterprise Edition♭
Professional Home Premium Ultimate 64-bit Single-user.
— based on a Freenode #perl conversation ( https://is.gd/cCUBY2 )

Please reply to list if it's a mailing list post - https://shlom.in/reply .

Bug#901321: Bug#876197: Removed package(s) from unstable

[Helio Loureiro]

Hi,

Today is the bug anniversary day.  Is there any update on it?

Best Regards,
Helio Loureiro
http://helio.loureiro.eng.br
http://br.linkedin.com/in/helioloureiro
http://twitter.com/helioloureiro


On Thu, 11 Jul 2019 at 18:52, Helio Loureiro 
wrote:

> Hi,
>
> Just to confirm that after Buster release, this bug stills open and the
> error persists.
>
> Best Regards,
> Helio Loureiro
> http://helio.loureiro.eng.br
> http://br.linkedin.com/in/helioloureiro
> http://twitter.com/helioloureiro
>
>
>
> On Tue, 3 Jul 2018 at 13:20, Helio Loureiro  wrote:
>
>> Hi,
>>
>> I started on Debian at Ham release.  At that time mpage was part of
>> Debian.  So I've a profound relationship with mpage as great tool along all
>> these years.
>>
>> But if my statement is correct, that package after 20 years at Debian was
>> wrongly removed due a license which doesn't apply to delivered binaries, do
>> you really believe the best approach is to ask a volunteer out of Debian
>> developers/maintainers to join on Debian mentors to fix it?   Wouldn't be
>> easier for you and Eriberto to just revert the removal?  I guess that any
>> DSC from theses 20 years of Debian would work just fine.
>>
>> Vänliga hälsningar/Best Regards,
>> Helio Loureiro
>> http://helio.loureiro.eng.br
>> https://se.linkedin.com/in/helioloureiro
>> http://twitter.com/helioloureiro
>>
>> Note: if you failed to reach me, try my alternative mail "
>> helio.loure...@gmail.com".
>> I'm implementing DKIM on my mail server, so some disturbance is expected.
>>
>> On Mon, 2 Jul 2018 11:46:36 +0200 Paul Gevers  wrote:
>> > Sending again to the new bug.
>> >
>> >  Forwarded Message 
>> > Subject: Re: Bug#876197: Removed package(s) from unstable
>> > Date: Mon, 11 Jun 2018 15:01:35 +0200
>> > From: Paul Gevers 
>> > To: Helio Loureiro 
>> > CC: Eriberto Mota 
>> >
>> > Dear Helio,
>> >
>> > On 11-06-18 14:45, Helio Loureiro wrote:
>> > > Is possible to keep this bug as open and revert the decision?
>> >
>> > As the package isn't in Debian anymore, the bug is closed. However, any
>> > Debian maintainer (and via sponsoring anybody) can reintroduce the
>> > package if it is considered useful. So the answers are: no and yes.
>> >
>> > > So is it possible to revert the package removal or at the least move
>> it
>> > > to contrib instead?
>> >
>> > If you want to reintroduce the package to Debian, I suggest you contact
>> > Debian mentors¹². I don't have any personal interest in mpage.
>> >
>> > Paul
>> >
>> > ¹ http://mentors.debian.net/
>> > ² IRC #debian-mentors on oftc
>> >
>> >
>> >
>>
>>