Bug#1042521: polymake: FTBFS with Perl 5.38: ‘Perl_ck_fun’ was not declared in this scope

[Benjamin Lorenz]

Dear David,

On 08/11/2023 23.09, David Bremner wrote:

David Bremner  writes:
I didn't have a chance to investigate so far, but I am seeing a test
failure with Polymake 4.11 building with Perl 5.36. I will try to build
with 5.38 and report a proper build log.

*** Failed tests ***

/<>/apps/polytope/rules/slack_ideal.rules:29: testcase 1
expected: regular return
  got: EXCEPTION: no more rules available to compute 'GENERATORS


That looks like the same as #1052830.
I was able to reproduce this and it comes from a changed return type of 
the Singular saturation command. The attached patch should fix this and 
work with both old and new Singular versions.


Best,
Benjamin
commit 4ce0549f510d246c8f69c85c509fc2d13d882442
Author: Benjamin Lorenz 
Date:   Thu Nov 9 11:15:06 2023 +0100

singular: support new return types for saturation command

This was changed from (ideal, exponent) to just the ideal in singular 4-3-2p5.
To allow older versions we keep using sat but support both return types
instead of switching to the new sat_with_exp.

diff --git a/bundled/singular/apps/ideal/src/singularIdeal.cc b/bundled/singular/apps/ideal/src/singularIdeal.cc
index 4cbc00a6f4..bdade5c29d 100644
--- a/bundled/singular/apps/ideal/src/singularIdeal.cc
+++ b/bundled/singular/apps/ideal/src/singularIdeal.cc
@@ -236,22 +236,24 @@ public:
   arg.next->data=(void *)idCopy(J);
   // call primdecSY
   BOOLEAN res=iiMake_proc(sathdl, nullptr ,);
-  if(!res && (iiRETURNEXPR.Typ() == LIST_CMD)){
- lists L = (lists)iiRETURNEXPR.Data();
- SingularIdeal_wrap* result;
- if(L->m[0].Typ() == IDEAL_CMD){
-result = new SingularIdeal_impl((::ideal) (L->m[0].Data()),singRing);
- } else {
-throw std::runtime_error("Something went wrong for the primary decomposition");
+  if(!res) {
+ ::ideal iddata = nullptr;
+ if (iiRETURNEXPR.Typ() == LIST_CMD) {
+lists L = (lists)iiRETURNEXPR.Data();
+if(L->m[0].Typ() == IDEAL_CMD)
+   iddata = (::ideal) L->m[0].Data();
+ } else if (iiRETURNEXPR.Typ() == IDEAL_CMD) {
+iddata = (::ideal) iiRETURNEXPR.Data();
+ }
+ if (iddata != nullptr) {
+SingularIdeal_wrap* result = new SingularIdeal_impl(iddata, singRing);
+iiRETURNEXPR.CleanUp();
+iiRETURNEXPR.Init();
+return result;
  }
- iiRETURNEXPR.CleanUp();
- iiRETURNEXPR.Init();
- return result;
-  } else {
- iiRETURNEXPR.Init();
- throw std::runtime_error("Something went wrong for the saturation");
   }
-
+  iiRETURNEXPR.Init();
+  throw std::runtime_error("saturation: unable to parse ideal from return value");
}
 
Array primary_decomposition() const

Bug#1042521: polymake: FTBFS with Perl 5.38: ‘Perl_ck_fun’ was not declared in this scope

[Benjamin Lorenz]

Dear David,

we have now managed to work around the perl changes and released 
polymake version 4.11 which restores compatibility with perl 5.38.


Among various other adjustments the workaround relies on an 
auto-generated perl source file that was is now copied into the polymake 
source.
This means it will almost surely need more changes for future perl 
releases and we cannot really say if this approach will keep working.
Right now polymake does work with the latest perl blead and we will be 
on the lookout for new issues.


Best
Benjamin

Bug#1053316: polymake: Causes FTBFS for gap-polymaking by failing tests

[Benjamin Lorenz]

On 02/10/2023 08.46, Joachim Zobel wrote:

Am Sonntag, dem 01.10.2023 um 15:30 -0300 schrieb David Bremner:

I'm currently waiting to see what happens with

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

before putting much effort into debugging polymake issues.


The discussion done in the inncluded link boils down to "won't fix,
wait for Julia". Is there any timeline for this?


Unfortunately there is really no timeline for this and I would be 
surprised if we can get this to work without perl within a year.


Regarding the current issue:
This seems like a rebuild of polymake against the new singular version 
might help.
The libsingular package seems to have a very strict soname which is not 
reflected in the package name, i.e.

libsingular4m3n0 version 4.3.1 contains libsingular-Singular-4.3.1.so
libsingular4m3n0 version 4.3.2 contains libsingular-Singular-4.3.2.so
But for each of these packages the soname contains the full version 
(full filename).


I am not really sure how to handle this, do we need to pin singular to a 
specific patch version to make this work?


Benjamin

Bug#1021844: barrier: uscan fails to determine upstream version

[Lorenz Kästle]

Package: barrier
Version: 2.4.0+dfsg-2+b1
Severity: normal
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

- -BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,
The debian package tracking system can not determine the upstream
version of this software. This is like related to some changes
on github.com which breaks the uscan workflow.
My best guess so far is, that they are using Javascript now to
display the release files and this does not work outside of a browser.

Using the uscan git mode though works, at least for some of my work
recently.
I am attaching a patch for the watch file.


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

Kernel: Linux 5.19.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages barrier depends on:
ii  libavahi-compat-libdnssd1  0.8-6
ii  libc6  2.35-3
ii  libgcc-s1  12.2.0-3
ii  libqt5core5a   5.15.4+dfsg-5
ii  libqt5gui5 5.15.4+dfsg-5
ii  libqt5network5 5.15.4+dfsg-5
ii  libqt5widgets5 5.15.4+dfsg-5
ii  libssl33.0.5-2
ii  libstdc++6 12.2.0-3
ii  libx11-6   2:1.8.1-2
ii  libxext6   2:1.3.4-1+b1
ii  libxi6 2:1.8-1+b1
ii  libxinerama1   2:1.1.4-3
ii  libxrandr2 2:1.5.2-2+b1
ii  libxtst6   2:1.2.3-1.1
ii  openssl3.0.5-2

barrier recommends no packages.

barrier suggests no packages.

- - -- debconf-show failed

- -BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEKAfQE9RqCCOLiHBM/scKxdDQy9UFAmNLD50ACgkQ/scKxdDQ
y9XRZA//aLBrYPDbHWvRjQ/VvaTeG98Q7/zGzaJPk13ic/1G1+6wSH/yiWKjytOU
Zfgwg9WXTgEL+FwPSJsO8l9UwILX9YSg3eNS+8OeVy+sBH39NgARcW+++MUbP0WT
CDFsMb1ggMjmnAzgp4i8rr8jtxu9ltEWW26LbTvlR7xO3YseMulhh08J6/O7Ijyp
8SAFAZdqFRAiMEDzSljU8Wt4mu0M2Sue3ZNVkSrEmMI3JoEcw5RrzMdsDranVNLc
na7Vk6se3BeFvljWnU6C9ol+l5t1X4DzQroxhReVtwKAtSjeBN5qBhW1OiW8oZFI
eF3UUNJo3CfsEZcdkYv0o0sHCZXHm/rGZufX8jrHJxZOLLXHMSyrldLiVNt3a/kx
HpDr8B1QBPpx/dXSf4FHvKqFdxolYno/67Vsaziw2rO7p5SHb9MFEtDgDFhIBP3T
I5SdVJpR9NqzY/Xmtlvow68jsBlLGccP5M+0uZL3IRWVLKzZwSOi1QdGI7/rTU6v
ztMLXkpMQfgRTQYeG2vk0rTmXcMMgrCmyQZGjbWnHN4NRyQ8RT0Pj7+W7cLzG31g
gfvn4CRHHFNkdYfTtd/xnKdjQoeMXC8khmU5BYrVLghIfIr8LMh+pJmS85g0hjNP
g+7OWzNC4+LUrA7xjfYNTw1Vs/G48hMfBjSvbspjZB3HWqWv6Pg=
=nSNv
- -END PGP SIGNATURE-

*** git/barrier/watchfile.barrier
diff --git a/debian/watch b/debian/watch
index 358e47e..faed7ad 100644
- --- a/debian/watch
+++ b/debian/watch
@@ -1,3 +1,3 @@
 version=4
- -opts="dversionmangle=s/\+dfsg$//,repacksuffix=+dfsg" \
- -https://github.com/debauchee/barrier/releases 
.*/v?([\d\.]+)\.tar\.(?:bz2|gz|xz)
+opts="mode=git,gitmode=full,dversionmangle=s/\+dfsg$//,repacksuffix=+dfsg" \
+https://github.com/debauchee/barrier refs/tags/v@ANY_VERSION@

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEKAfQE9RqCCOLiHBM/scKxdDQy9UFAmNLEPYACgkQ/scKxdDQ
y9XY6g/+IankO9oqt/h9KtKLnupqUu+jtonwjXMG3X3YOqSRTjxNElzJkIMr2VBa
ynxkgOKEU2qriLJLmdxNHW3ixbssqyQaltqjjAfeHMrX75Lzw66N2YaaltcVPb1/
TNvWPj8Gwt5Dd3LK04IqHtjupA/6mbqj7yMO3nPCv2LE/Hgt1NWsSA33y7LJ546o
bumyM5nP98XsDCXpcR1W+mb3h4D5RWBOhM98ZGnltn4CPQ7NxC4ILpwJj5bEgIvS
geD+d1PlOowgI4GiIaBZDMYo2q+SiJWfZee3ZijnfsXX+qC2u0smp8f4zEUt8Hf3
sqrhMJ2jBmAp7f053Qv0mZ6jtjA9LbuhiGDEGkOQYMSB4YSh2hcRxN5Uk0RlZfcv
r5huHrfdDzD8Q45w2n0gDwT97k2+9qVhsxE1zu7zc28MkesqNUVTrlkUT13P2++o
kw44QLy1S+78ij8qb5g4ANNvoS30jUtTZ5I/QuZ09RiRzEAnYfahohCnO6NZflFD
lAVuEwxCWF3BlDQG09LoBY6vu42QP/vGnwDeOxqGdFLDd8E6Tg94Y1hQ9mO8ePr9
GjWIO87Yg0mLPO8roniFo12COkE6yLCTY92+JDTZHxQ//ST67OZ2XdWkL1BsKFU9
lizlduoOyXr/molY3dxm50W7gyhNwKSTBoNQBC51mqht7goijm8=
=vOCl
-END PGP SIGNATURE-

Bug#1014296: polymake: FTBFS with Perl 5.36: HVhek_UNSHARED’ was not declared in this scope

[Benjamin Lorenz]

Hi,

the attached patch should fix the build with perl 5.36:
- adapt to renamed HVhek_UNSHARED
- adjust for changes in the complement operation

Best,
Benjamin Lorenz

On 03/07/2022 16.33, Niko Tyni wrote:

Source: polymake
Version: 4.6-3
Tags: ftbfs
User: debian-p...@lists.debian.org
Usertags: perl-5.36-transition

This package fails to build from source with Perl 5.36 (currently in
experimental.)

Build log at

   
http://perl.debian.net/rebuild-logs/perl-5.36-throwaway/polymake_4.6-3/polymake_4.6-3_amd64-2022-06-09T09:42:58Z.build

Excerpt:

   FAILED: 
/<>/build/Opt/lib/perlx/5.36.0/x86_64-linux-gnu-thread-multi/RefHash.o
 g++ -c -o /<>/build/Opt/lib/perlx/5.36.0/x86_64-linux-gnu-thread-multi/RefHash.o -MMD -MT 
/<>/build/Opt/lib/perlx/5.36.0/x86_64-linux-gnu-thread-multi/RefHash.o -MF 
/<>/build/Opt/lib/perlx/5.36.0/x86_64-linux-gnu-thread-multi/RefHash.o.d -fPIC -pipe -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++14 -ftemplate-depth-200 -fno-strict-aliasing -fopenmp -Wshadow 
-Wlogical-op -Wconversion -Wzero-as-null-pointer-constant -Wno-parentheses -Wno-error=unused-function -Wno-stringop-overflow -Wno-array-bounds -Wno-maybe-uninitialized 
-Wno-free-nonheap-object -DPOLYMAKE_WITH_FLINT  -DPOLYMAKE_DEBUG=0 -DNDEBUG -O2 -I/usr/lib/x86_64-linux-gnu/perl/5.36/CORE -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv 
-fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64  -DPerlVersion=5360 -Wno-nonnull  
-I/<>/include/core-wrappers -I/<>/include/core 
/<>/build/perlx/5.36.0/x86_64-linux-gnu-thread-multi/RefHash.cc && : 'COMPILER_USED=11.3.0'
   /<>/lib/core/src/perl/RefHash.xxs: In member function ‘SV* 
pm::perl::glue::{anonymous}::tmp_keysv::set(SV*)’:
   /<>/lib/core/src/perl/RefHash.xxs:74:22: error: 
‘HVhek_UNSHARED’ was not declared in this scope; did you mean ‘HVhek_NOTSHARED’?
  74 |HEK_FLAGS(hekp) = HVhek_UNSHARED;
 |  ^~
 |  HVhek_NOTSHARED
   [954/965]   g++ -c -o /<>/build/Opt/lib/perlx/5.36.0/x86_64-linux-gnu-thread-multi/Poly.o -MMD -MT 
/<>/build/Opt/lib/perlx/5.36.0/x86_64-linux-gnu-thread-multi/Poly.o -MF 
/<>/build/Opt/lib/perlx/5.36.0/x86_64-linux-gnu-thread-multi/Poly.o.d -fPIC -pipe -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++14 -ftemplate-depth-200 -fno-strict-aliasing -fopenmp -Wshadow 
-Wlogical-op -Wconversion -Wzero-as-null-pointer-constant -Wno-parentheses -Wno-error=unused-function -Wno-stringop-overflow -Wno-array-bounds -Wno-maybe-uninitialized 
-Wno-free-nonheap-object -DPOLYMAKE_WITH_FLINT  -DPOLYMAKE_DEBUG=0 -DNDEBUG -O2 -I/usr/lib/x86_64-linux-gnu/perl/5.36/CORE -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv 
-fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64  -DPerlVersion=5360 -Wno-nonnull  
-I/<>/include/core-wrappers -I/<>/include/core 
/<>/build/perlx/5.36.0/x86_64-linux-gnu-thread-multi/Poly.cc && : 'COMPILER_USED=11.3.0'
   [955/965]   g++ -c -o /<>/build/Opt/lib/perlx/5.36.0/x86_64-linux-gnu-thread-multi/RuleGraph.o -MMD -MT 
/<>/build/Opt/lib/perlx/5.36.0/x86_64-linux-gnu-thread-multi/RuleGraph.o -MF 
/<>/build/Opt/lib/perlx/5.36.0/x86_64-linux-gnu-thread-multi/RuleGraph.o.d -fPIC -pipe -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++14 -ftemplate-depth-200 -fno-strict-aliasing -fopenmp -Wshadow 
-Wlogical-op -Wconversion -Wzero-as-null-pointer-constant -Wno-parentheses -Wno-error=unused-function -Wno-stringop-overflow -Wno-array-bounds -Wno-maybe-uninitialized 
-Wno-free-nonheap-object -DPOLYMAKE_WITH_FLINT  -DPOLYMAKE_DEBUG=0 -DNDEBUG -O2 -I/usr/lib/x86_64-linux-gnu/perl/5.36/CORE -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv 
-fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64  -DPerlVersion=5360 -Wno-nonnull  
-I/<>/include/core-wrappers -I/<>/include/core 
/<>/build/perlx/5.36.0/x86_64-linux-gnu-thread-multi/RuleGraph.cc && : 'COMPILER_USED=11.3.0'
   ninja: build stopped: subcommand failed.
   make[1]: *** [debian/rules:56: override_dh_auto_build] Error 1
   make[1]: Leaving directory '/<>'
   make: *** [debian/rules:35: build] Error 2
  
diff --git a/lib/core/src/perl/RefHash.xxs b/lib/core/src/perl/RefHash.xxs
index f6087a10aa..fbf7309a50 100644
--- a/lib/core/src/perl/RefHash.xxs
+++ b/lib/core/src/perl/RefHash.xxs
@@ -71,7 +71,11 @@ SV* tmp_keysv::set(SV* keysv)
Copy(obj.keyp, HEK_KEY(hekp), sizeof(SV*), char);
HEK_LEN(hekp) = sizeof(SV*);
HEK_HASH(hekp) = U32(obj.keyl >> 4);  // hash value
+#if defined(HVhek_NOTSHARED)

Bug#1002281: polymake: FTBFS: /<>/apps/polytope/rules/slack_ideal.rules:37: testcase 1 expected: regular return got: EXCEPTION: no more rules available to compute 'GENERATORS'

[Benjamin Lorenz]

On 21/12/2021 17.49, Lucas Nussbaum wrote:

  [ /polytope/objects/Polytope/properties/Geometry/SLACK_IDEAL ] 1   ? cannot 
open `standard.lib`
// ** Could not get 'Singular'.
// ** Either set environment variable 'SINGULAR_EXECUTABLE' to 'Singular',
// ** or make sure that 'Singular' is at "/usr/Singular"
// ** Could not get 'BinDir'.
// ** Either set environment variable 'SINGULAR_BIN_DIR' to 'BinDir',
// ** or make sure that 'BinDir' is at ""
// ** Could not get 'RootDir'.
// ** Either set environment variable 'SINGULAR_ROOT_DIR' to 'RootDir',
// ** or make sure that 'RootDir' is at "%b/.."
// ** Could not find dynamic library: p_Procs_FieldIndep.so (path )
// ** Singular will work properly, but much slower.
// ** See the INSTALL section in the Singular manual for details.
polymake:  WARNING: rule GENERATORS, N_VARIABLES : NON_SATURATED.GENERATORS, 
NON_SATURATED.N_VARIABLES failed: cannot open elim.lib at 
/<>/bundled/singular/apps/ideal/rules/singular.rules line 210.

verifying: 1 FAILED


Thanks for the report, this seems to be caused by an incomplete singular 
installation during testing, for building we only require 
libsingular4-dev and at runtime libpolymake-dev-common does depend on 
the full singular package.


For the tests to work at least singular-data (with dependency 
singular-modules) should be installed in addition to libsingular4-dev.


Best
Benjamin

PS: In the previous builds the autoconfiguration of polymake did not 
accept the singular installation for some reason.
But some other change (maybe in singular or some dependency) seems to 
have fixed that and now we are seeing this error during the tests.

Bug#993330: polymake: FTBFS with Perl 5.34: error: ‘Perl_pp_keys’ was not declared in this scope

[Benjamin Lorenz]

On 31/08/2021 17.29, David Bremner wrote:

This package fails to build from source with Perl 5.34 (currently
in experimental). I don't presently understand why; I'm not aware of
changes to Perl_pp_keys or Perl_pp_rv2hv. So the root issue might also
be on the Perl side. At least it seems to reliably fail the same way.


There is a new upstream release, which I should try packaging before we
get too far in debugging this.


That issue should be fixed in polymake 4.4. For polymake 4.3 you can try 
the attached patch.
There were no real changes to these macros, but they were moved into 
some ifdef restricting their use to the perl core.


Best
Benjamin
diff --git a/lib/core/src/perl/RefHash.xxs b/lib/core/src/perl/RefHash.xxs
index 60a4d75481..ceb3735087 100644
--- a/lib/core/src/perl/RefHash.xxs
+++ b/lib/core/src/perl/RefHash.xxs
@@ -437,7 +437,7 @@ OP* intercept_pp_keys(pTHX)
I32 gimme = GIMME_V;
if (gimme == G_ARRAY && (stash==my_pkg || (stash && ref_key_allowed(stash {
   SSize_t sp_dist = SP - PL_stack_base;
-  OP* ret = Perl_pp_keys(aTHX);
+  OP* ret = def_pp_KEYS(aTHX);
   SV** last = PL_stack_sp;
   for (sp = PL_stack_base + sp_dist; sp <= last; ++sp)
  key2ref(aTHX_ *sp);
@@ -445,7 +445,7 @@ OP* intercept_pp_keys(pTHX)
}
if (gimme == G_SCALAR && (mg = hash_is_cpp_class(hv, stash)))
   return cpp_keycnt(aTHX_ hv, mg);
-   return Perl_pp_keys(aTHX);
+   return def_pp_KEYS(aTHX);
 }
 
 // aassign isn't intercepted directly, since it is used very often and not only with hashes.
@@ -576,7 +576,7 @@ OP* pp_rv2hv_ref_retrieve(pTHX)
 {
dSP;
SSize_t sp_dist = SP - PL_stack_base;
-   OP* ret = Perl_pp_rv2hv(aTHX);
+   OP* ret = def_pp_RV2HV(aTHX);
SV** last = PL_stack_sp;
for (SP = PL_stack_base + sp_dist; SP < last; SP += 2)
   key2ref(aTHX_ *SP);
@@ -601,7 +601,7 @@ OP* intercept_pp_rv2hv(pTHX)
HV* stash;
if (PL_op->op_flags & OPf_REF) {
   if (PL_op->op_next->op_type == OP_AASSIGN) {
- PL_op = Perl_pp_rv2hv(aTHX);
+ PL_op = def_pp_RV2HV(aTHX);
  return ref_assign(aTHX);
   }
   if (SvROK(hv)) {
@@ -621,18 +621,18 @@ OP* intercept_pp_rv2hv(pTHX)
  if (stash == my_pkg || (stash && ref_key_allowed(stash)))
 return pp_rv2hv_ref_retrieve(aTHX);
  else
-return Perl_pp_rv2hv(aTHX);
+return def_pp_RV2HV(aTHX);
   }
   SAVEI8(PL_op->op_flags);  // just for the case the op dies
   PL_op->op_flags ^= OPf_REF;
-  Perl_pp_rv2hv(aTHX);   // get the hash
+  def_pp_RV2HV(aTHX);   // get the hash
   PL_op->op_flags ^= OPf_REF;
   hv = TOPs;
   stash = SvSTASH(hv);
   if (stash == my_pkg || (stash && ref_key_allowed(stash)))
  return pp_rv2hv_ref_retrieve(aTHX);
}
-   return Perl_pp_rv2hv(aTHX);
+   return def_pp_RV2HV(aTHX);
 }
 
 OP* intercept_pp_padhv(pTHX)


OpenPGP_signature
Description: OpenPGP digital signature

Bug#991767: samba: Attempt to change password over IPv6 using kpasswd fails on AD DC server

[Lorenz Schori]

Package: samba
Version: 2:4.13.5+dfsg-2
Severity: normal

Dear Maintainer,

After upstream commit 43c808f2ff907497dfff0988ff90a48fdcfc16ef any
attempt to change a password over IPv6 fails on the server side. Samba
generates the following log entries (on the domain controller):

Starting GENSEC mechanism krb5
Failed to start GENSEC server mech krb5: NT_STATUS_INTERNAL_ERROR

On the client side the request to change the password results in the
following message after a delay of a couple of seconds:

kpasswd: Cannot contact any KDC for requested realm changing
password

Upstream commit 43c808f2ff907497dfff0988ff90a48fdcfc16ef changed calls
to tsocket_address_bsd_sockaddr() in gensec_krb5.c such that IPv6
addresses will be rejected.

Affected are all upstream releases from branches 4.14 and 4.13. Older
branches / releases are not affected.

On the distro side, this bug affects soon to be released Debian
Bullseye, it does neither affect current stable Debian Buster nor Ubuntu
Focal (LTS).

Upstream bug (fixed in upstream release 4.13.10):
https://bugzilla.samba.org/show_bug.cgi?id=14750

-- Package-specific info:
* /etc/samba/smb.conf present, but not attached
* /var/lib/samba/dhcp.conf not present

-- System Information:
Debian Release: 11.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing'), (90,
'unstable'), (1, 'experimental') Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8),
LANGUAGE=C.UTF-8 Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages samba depends on:
ii  adduser  3.118
ii  dpkg 1.20.9
ii  init-system-helpers  1.60
ii  libbsd0  0.11.3-1
ii  libc62.31-13
ii  libgnutls30  3.7.1-5
ii  libldb2  2:2.2.0-3.1
ii  libpam-modules   1.4.0-9
ii  libpam-runtime   1.4.0-9
ii  libpopt0 1.18-2
ii  libpython3.9 3.9.2-1
ii  libtalloc2   2.3.1-2+b1
ii  libtasn1-6   4.16.0-2
ii  libtdb1  1.4.3-1+b1
ii  libtevent0   0.10.2-1
ii  libwbclient0 2:4.13.5+dfsg-2
ii  lsb-base 11.1.0
ii  procps   2:3.3.17-5
ii  python3  3.9.2-3
ii  python3-dnspython2.0.0-1
ii  python3-samba2:4.13.5+dfsg-2
ii  samba-common 2:4.13.5+dfsg-2
ii  samba-common-bin 2:4.13.5+dfsg-2
ii  samba-libs   2:4.13.5+dfsg-2
ii  tdb-tools1.4.3-1+b1

Versions of packages samba recommends:
ii  attr1:2.4.48-6
ii  logrotate   3.18.0-2
ii  python3-markdown3.3.4-1
ii  samba-dsdb-modules  2:4.13.5+dfsg-2
ii  samba-vfs-modules   2:4.13.5+dfsg-2

Versions of packages samba suggests:
pn  bind9  
pn  bind9utils 
pn  ctdb   
ii  ldb-tools  2:2.2.0-3.1
pn  ntp | chrony   
pn  smbldap-tools  
pn  ufw
pn  winbind

-- no debconf information

Bug#990441: sympa: Sympa does not start correctly after rebooting

[Sabine Lorenz]

Package: sympa
Version: 6.2.40~dfsg-1+deb10u1
Severity: normal

Dear Maintainer,

After installing Sympa 6.2.40 as Debian package on a Debian 10
machine,Sympa does not start correctly after reboot of the maschine.
Acoortding to the log eentries, Sympa cannot access the database
(mariaDB).
The https://sympa-community.github.io/manual/install/automate-startup.html page 
documents how to configure systemd for automatic startup, but these 
instructions are actually for non-packaged installations.
I would expect the configuration of systemd to be included in the Debian 
package.

Can you please include that in the Debian package that Sympa needs 
mysql.service and is only started when the database-service is running?
Since of course different database services can be used, it could be asked 
during the installation of the package which database service is used.

Kind regards,
Sabine

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

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

Versions of packages sympa depends on:
ii  adduser3.118
ii  ca-certificates20200601~deb10u2
ii  dbconfig-common2.0.11+deb10u1
ii  debconf [debconf-2.0]  1.5.71
ii  exim4-daemon-light [mail-transport-agent]  4.92-8+deb10u6
ii  fonts-font-awesome 5.0.10+really4.7.0~dfsg-1
ii  libarchive-zip-perl1.64-1
ii  libc6  2.28-10
ii  libcgi-fast-perl   1:2.13-1
ii  libcgi-pm-perl 4.40-1
ii  libclass-singleton-perl1.5-1
ii  libcrypt-eksblowfish-perl  0.009-2+b5
ii  libcrypt-openssl-x509-perl 1.8.12-1
ii  libcrypt-smime-perl0.25-1+b1
ii  libdatetime-format-mail-perl   0.4030-1
ii  libdbd-csv-perl0.5300-1+deb10u1
ii  libdbd-mysql-perl  4.050-2
ii  libdbd-pg-perl 3.7.4-3
ii  libdbd-sqlite3-perl1.62-3
ii  libdbi-perl1.642-1+deb10u2
ii  libfcgi-perl   0.78-2+b3
ii  libfile-copy-recursive-perl0.44-1
ii  libfile-nfslock-perl   1.29-1
ii  libhtml-format-perl2.12-1
ii  libhtml-stripscripts-parser-perl   1.03-2
ii  libhtml-tree-perl  5.07-2
ii  libintl-perl   1.26-2
ii  libio-stringy-perl 2.111-3
ii  libjs-jquery   3.3.1~dfsg-3+deb10u1
ii  libjs-jquery-migrate-1 1.4.1-1
ii  libjs-jquery-minicolors2.2.6+dfsg-3
ii  libjs-jquery-ui1.12.1+dfsg-5
ii  libmail-dkim-perl  0.54-1
ii  libmailtools-perl  2.18-1
ii  libmime-charset-perl   1.012.2-1
ii  libmime-encwords-perl  1.014.3-2
ii  libmime-lite-html-perl 1.24-3
ii  libmime-tools-perl 5.509-1
ii  libnet-cidr-perl   0.19-1
ii  libnet-dns-perl1.19-1
ii  libnet-ldap-perl   1:0.6500+dfsg-1
ii  libnet-netmask-perl1.9104-1
ii  libregexp-common-perl  2017060201-1
ii  libsoap-lite-perl  1.27-1
ii  libtemplate-perl   2.27-1+b1
ii  libterm-progressbar-perl   2.22-1
ii  libunicode-linebreak-perl  0.0.20190101-1
ii  libxml-libxml-perl 2.0134+dfsg-1
ii  lsb-base   10.2019051400
ii  mhonarc2.6.19-2
ii  perl   5.28.1-6+deb10u1
ii  rsyslog [system-log-daemon]8.1901.0-1
ii  sqlite33.27.2-3+deb10u1

Versions of packages sympa recommends:
ii  apache2-suexec-custom [apache2-suexec]  2.4.38-3+deb10u4
ii  default-mysql-server1.0.5
ii  doc-base0.10.8
ii  libapache2-mod-fcgid1:2.3.9-4
ii  libcrypt-ciphersaber-perl   1.01-2.1
ii  libio-socket-ssl-perl   2.060-3
ii  locales 2.28-10
ii  logrotate   3.14.0-4

Versions of packages sympa suggests:
ii  apache2 [httpd-cgi]  2.4.38-3+deb10u4
pn  libauthcas-perl  
pn  libdbd-odbc-perl 
pn  

Bug#986381: polymake: VISUAL with threejs fails

[Benjamin Lorenz]

Dear Joachim,

thanks for the report,


F12 displays a warning

"THREE.OrbitControls: As part of the transition to ES6 Modules, the files in
'examples/js' were deprecated in May 2020 (r117) and will be deleted in
December 2020 (r124)...


these warnings can be ignored as we ship pre-r124 versions of those 
files. Transition to ES6 modules is planned but not done yet.



> "ReferenceError: Can't find variable: THREE"

The reason for this error and the broken visualization is probably 
because the correct order in the minified js file got lost during the 
latest update.


As a quick check could you please try to fetch the polymake sources and run:

cd polymake-4.3/external/js
uglifyjs three.js OrbitControls.js Projector.js SVGRenderer.js \
   TrackballControls.js WebGL.js -c -m -o /tmp/three.polymake.js

Use that /tmp/three.polymake.js file to replace the one from the 
polymake-common package at:

/usr/share/polymake/resources/threejs/js/three.polymake.js


If that does help this can be fixed by a small change in debian/rules, 
moving three.js to the front of the JS variable:
-JS:= OrbitControls.js Projector.js SVGRenderer.js three.js 
TrackballControls.js  WebGL.js
+JS:= three.js OrbitControls.js Projector.js SVGRenderer.js 
TrackballControls.js  WebGL.js


Best,
Benjamin



OpenPGP_signature
Description: OpenPGP digital signature

Bug#985549: golang-github-containers-dnsname: Incorrect installation path for dnsname binary

[Lorenz Schori]

Fix submitted via MR in salsa:
https://salsa.debian.org/go-team/packages/golang-github-containers-dnsname/-/merge_requests/2


pgpOadshxzZGM.pgp
Description: OpenPGP digital signature

Bug#985548: (no subject)

[Lorenz Schori]

Fix submitted via MR in salsa:
https://salsa.debian.org/go-team/packages/golang-github-containers-dnsname/-/merge_requests/1


pgpbDiVKdCHTu.pgp
Description: OpenPGP digital signature

Bug#985548: (no subject)

[Lorenz Schori]

Fix submitted via MR in salsa:
https://salsa.debian.org/go-team/packages/golang-github-containers-dnsname/-/merge_requests/1


pgpydNCx3xkYF.pgp
Description: OpenPGP digital signature

Bug#985549: golang-github-containers-dnsname: Incorrect installation path for dnsname binary

[Lorenz Schori]

Package: golang-github-containers-dnsname
Version: 1.1.1+ds1-4
Severity: normal

Dear Maintainer,

The golang-github-containernetworking-plugin-dnsname package places the
dnsname binary into /usr/lib/dnsname. However, it should go into
/usr/lib/cni/dnsname, otherwise podman will display the following error
when trying to start a container on a network with dnsname plugin
enabled:

WARN[] Error validating CNI config
file /etc/cni/net.d/mynetwork.conflist: [failed to find plugin
"dnsname" in path
[/usr/libexec/cni /usr/lib/cni /usr/local/lib/cni /opt/cni/bin]]

In order to work around this it is enough to symlink the binary into the
correct location:

ln -s /usr/lib/dnsname /usr/lib/cni/dnsname

Cheers,
Lorenz

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

Kernel: Linux 4.19.0-14-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled


pgpbNecBcZqLA.pgp
Description: OpenPGP digital signature

Bug#985548: golang-github-containers-dnsname: Missing dependency dnsmasq-base

[Lorenz Schori]

Package: golang-github-containers-dnsname
Version: 1.1.1+ds1-4
Severity: normal

Dear Maintainer,

The dnsname cni plugin requires dnsmasq in order to work properly. Thus
golang-github-containers-dnsname should depend on dnsmasq-base.

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

Kernel: Linux 4.19.0-14-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled


pgpQZomwZ3kXF.pgp
Description: OpenPGP digital signature

Bug#981252: polymake: tests fail on mips{64,}el

[Benjamin Lorenz]

Hello David,

On 28/01/2021 12.59, David Bremner wrote:

The relevant output from the tests seems to be

  [ /polytope/objects/Polytope/properties/Triangulation and volume/RELATIVE_VOLUME ] 1polymake: 
 WARNING: rule RELATIVE_VOLUME : SQUARED_RELATIVE_VOLUMES failed: Undefined subroutine 
::polytope::Polytope__Rational::_Full_Spez::sum_of_square_roots_naive called at 
/<>/apps/polytope/rules/rational.rules line 73.

/<>/apps/polytope/rules/rational.rules:65: testcase 1
expected: regular return
  got: EXCEPTION: no more rules available to compute 'RELATIVE_VOLUME'

At a guess I'd imagine an architecture dependent bug in one of the
dependencies. But that's purely a guess.



please try the attached patch, the issue is that this testcase should 
not be run when flint is disabled.


I will do some tests with the new flint 2.7 soon to check whether the 
mips(64) situation has improved.


Best
Benjamin
diff --git a/apps/polytope/rules/rational.rules 
b/apps/polytope/rules/rational.rules
index ba5b3244c7..d621777100 100644
--- a/apps/polytope/rules/rational.rules
+++ b/apps/polytope/rules/rational.rules
@@ -62,7 +62,7 @@ property N_01POINTS : Int;
 # The value is encoded as a map collecting the coefficients of various roots 
encountered in the sum.
 # For example, {(3 1/2),(5 7)} represents sqrt{3}/2 + 7 sqrt{5}.
 # If the output is not satisfactory, please use a symbolic algebra package.
-# @example The following prints the 2-dimensional volume of a centered square 
with side length 2 embedded in the 3-space (the result is 4):
+# @example [require bundled:flint] The following prints the 2-dimensional 
volume of a centered square with side length 2 embedded in the 3-space (the 
result is 4):
 # > $M = new Matrix([1,-1,1,0],[1,-1,-1,0],[1,1,-1,0],[1,1,1,0]);
 # > $p = new Polytope(VERTICES=>$M);
 # > print $p->RELATIVE_VOLUME;


OpenPGP_signature
Description: OpenPGP digital signature

Bug#974112: kdecorations crash

[Tobias Lorenz]

Hello,

I can reproduce the problem as well.

My plasma/breeze window decorations are gone. Yesterday the following 
packages were upgraded to 4:5.19.5-3:


libkdecorations2private7
libkdecorations2-5v5
libkf5screen-bin
libkf5screen7

If I try to open the window decoration settings dialog, the whole system 
settings window crashes reproducable.


Application: systemsettings5 (5.17.5)

Qt Version: 5.15.1
Frameworks Version: 5.74.0
Operating System: Linux 5.9.0-1-amd64 x86_64
Distribution: Debian GNU/Linux bullseye/sid

The crash can be reproduced every time.

-- Backtrace:
Application: Systemeinstellungen (systemsettings5), signal: Segmentation 
fault

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7fbb0adb4180 (LWP 5959))]

Thread 14 (Thread 0x7fbac27ef700 (LWP 5976)):
#0  0x7fbb0d463d99 in g_mutex_lock () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#1  0x7fbb0d412f2a in g_main_context_iteration () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7fbb0fac372b in 
QEventDispatcherGlib::processEvents(QFlags) 
() from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#3  0x7fbb0fa6ab7b in 
QEventLoop::exec(QFlags) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x7fbb0f88b9be in QThread::exec() () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x7fbb0eb9f085 in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#6  0x7fbb0f88cb01 in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#7  0x7fbb0dfeaea7 in start_thread (arg=) at 
pthread_create.c:477
#8  0x7fbb0f52bd4f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95


Thread 13 (Thread 0x7fbacbfff700 (LWP 5972)):
#0  0x7fbb0d41267a in g_main_context_check () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#1  0x7fbb0d412dc5 in ?? () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7fbb0d412f3f in g_main_context_iteration () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7fbb0fac372b in 
QEventDispatcherGlib::processEvents(QFlags) 
() from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x7fbb0fa6ab7b in 
QEventLoop::exec(QFlags) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x7fbb0f88b9be in QThread::exec() () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x7fbb0eb9f085 in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#7  0x7fbb0f88cb01 in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#8  0x7fbb0dfeaea7 in start_thread (arg=) at 
pthread_create.c:477
#9  0x7fbb0f52bd4f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95


Thread 12 (Thread 0x7fbae661d700 (LWP 5971)):
#0  0x7fbb0d463db4 in g_mutex_unlock () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#1  0x7fbb0d412e13 in ?? () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7fbb0d412f3f in g_main_context_iteration () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7fbb0fac372b in 
QEventDispatcherGlib::processEvents(QFlags) 
() from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x7fbb0fa6ab7b in 
QEventLoop::exec(QFlags) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x7fbb0f88b9be in QThread::exec() () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x7fbb0eb9f085 in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#7  0x7fbb0f88cb01 in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#8  0x7fbb0dfeaea7 in start_thread (arg=) at 
pthread_create.c:477
#9  0x7fbb0f52bd4f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95


Thread 11 (Thread 0x7fbae6ffd700 (LWP 5970)):
#0  futex_abstimed_wait_cancelable (private=0, abstime=0x7fbae6ffccd0, 
clockid=-419443632, expected=0, futex_word=0x5585ad8776a0) at 
../sysdeps/nptl/futex-internal.h:320
#1  __pthread_cond_wait_common (abstime=0x7fbae6ffccd0, 
clockid=-419443632, mutex=0x5585ad877650, cond=0x5585ad877678) at 
pthread_cond_wait.c:520
#2  __pthread_cond_timedwait (cond=0x5585ad877678, mutex=0x5585ad877650, 
abstime=0x7fbae6ffccd0) at pthread_cond_wait.c:656
#3  0x7fbb0f892aa4 in QWaitCondition::wait(QMutex*, QDeadlineTimer) 
() from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x7fbb0f890ae1 in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x7fbb0f88cb01 in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x7fbb0dfeaea7 in start_thread (arg=) at 
pthread_create.c:477
#7  0x7fbb0f52bd4f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95


Thread 10 (Thread 0x7fbae77fe700 (LWP 5969)):
#0  futex_abstimed_wait_cancelable (private=0, abstime=0x7fbae77fdcd0, 
clockid=-411050928, expected=0, futex_word=0x5585ad8b83d0) at 
../sysdeps/nptl/futex-internal.h:320
#1  __pthread_cond_wait_common (abstime=0x7fbae77fdcd0, 
clockid=-411050928, mutex=0x5585ad8b8380, cond=0x5585ad8b83a8) at 
pthread_cond_wait.c:520
#2  __pthread_cond_timedwait (cond=0x5585ad8b83a8, mutex=0x5585ad8b8380, 
abstime=0x7fbae77fdcd0) at 

Bug#951151: polymake: test failure on mips64el

[Benjamin Lorenz]

On 13/02/2020 16.53, Benjamin Lorenz wrote:
> On 13/02/2020 13.18, David Bremner wrote:
>> Benjamin Lorenz  writes:
>>>> It looks like it's flint related?
>>>
>>> Yes, I think this is a bug in flint and for now I suggest disabling the
>>> flint-interface of polymake with the configure option --without-flint on
>>> mips64el. This has basically no functionality loss as polymake will use
>>> its own generic polynomial arithmetic instead (it will be somewhat slower).
>>> Currently rebuilding polymake to check the testsuite again but this will
>>> take some time and I will report back tomorrow.
>>>
>>
>> The easy thing would be to disable it everywhere. It is also possible to
>> do it on an architecture specific basis. Do you think the (small) added
>> complexity of the latter is worth it?
> 
> It seems we might need some extra stuff for mips64el anyway as I see
> some weird segfaults even without flint (at different testcases).

I finally got this running on mips64el:
1) update to polymake 4.0r1, this includes:
   - a (slightly adjusted) fix for gmp 6.2
   - a fix for the TERM issue in the reproducible builds (FTBFS)
   - disables a libnormaliz test when libnormaliz is not configured
   - and some other bugfixes
2) switch off both flint and libnormaliz on mips64el with:
   --without-flint --without-libnormaliz
   The normaliz package also runs into a similar flint crash as it also
uses flint for polynomial arithmetic.
   Switching off flint for all architectures would be ok but I really
want to keep libnormaliz active on all other architectures.
   I have reported the flint crash upstream:
   https://github.com/wbhart/flint2/issues/614
3) switch the linker on mips64el:
   add -fuse-ld=bfd to LDFLAGS
   by default polymake will use -fuse-ld=gold if it is available but
then exception handling doesn't seem to work on mips64el and I really
don't want to investigate this any further.

Benjamin

Bug#951151: polymake: test failure on mips64el

[Benjamin Lorenz]

On 13/02/2020 13.18, David Bremner wrote:
> Benjamin Lorenz  writes:
> 
>>
>>> It looks like it's flint related?
>>
>> Yes, I think this is a bug in flint and for now I suggest disabling the
>> flint-interface of polymake with the configure option --without-flint on
>> mips64el. This has basically no functionality loss as polymake will use
>> its own generic polynomial arithmetic instead (it will be somewhat slower).
>> Currently rebuilding polymake to check the testsuite again but this will
>> take some time and I will report back tomorrow.
>>
> 
> The easy thing would be to disable it everywhere. It is also possible to
> do it on an architecture specific basis. Do you think the (small) added
> complexity of the latter is worth it?

It seems we might need some extra stuff for mips64el anyway as I see
some weird segfaults even without flint (at different testcases).

But I am still investigating those, backtrace seems to point to the
exception handling code of libgcc / libstdc++:
Program received signal SIGSEGV, Segmentation fault.
parse_lsda_header (context=0x4000b9d880, p=0x260ae60 ,
info=0x4000b9cb50) at
../../../../src/libstdc++-v3/libsupc++/eh_personality.cc:58
58  ../../../../src/libstdc++-v3/libsupc++/eh_personality.cc: No
such file or directory.
(gdb) bt
#0  parse_lsda_header (context=0x4000b9d880,
p=0x260ae60 ,
info=0x4000b9cb50)
at ../../../../src/libstdc++-v3/libsupc++/eh_personality.cc:58
#1  0x00400161005c in __cxxabiv1::__gxx_personality_v0
(version=,
actions=, exception_class=,
ue_header=0x400cfa8d50,
context=0x4000b9d880) at
../../../../src/libstdc++-v3/libsupc++/eh_personality.cc:454
#2  0x0040017e33ac in _Unwind_RaiseException (exc=0x400cfa8d50) at
../../../src/libgcc/unwind.inc:118
#3  0x00400161126c in __cxxabiv1::__cxa_throw (obj=0x400cfa8d70,
tinfo=0x4005e7ccf8 , dest=)
at ../../../../src/libstdc++-v3/libsupc++/eh_throw.cc:90
#4  0x0040056fdfb8 in pm::lin_solve (A=..., b=...)
at /usr/include/c++/9/ext/new_allocator.h:89
#5  0x00400c7a8408 in
polymake::fan::remove_redundancies (f=...)
at ./include/core/polymake/internal/shared_object.h:1097
...

Bug#951137: polymake: FTBFS if terminal is unset

[Benjamin Lorenz]

On 11/02/2020 16.22, Gianfranco Costamagna wrote:
> Hello, looks like with TERM=unknown the testsuite fails:
> 
> *** Failed tests ***
> 
> /<>/apps/common/rules/functions_help.rules:248: testcase 1
> expected: regular return
>  got: EXCEPTION: Can't find a valid termcap file at 
> /<>/perllib/Polymake/Core/InteractiveCommands.pm line 32.

Thanks for the report, we will make this non-fatal in the next polymake
revision 4.0r1, probably next week.

> I think exporting a valid TERM in rules file is something sane to do.

This seems very reasonable, yes.
I am somewhat surprised that this did not appear in the debian package
builds, but it did for the reproducibility tests and also on ubuntu.

Bug#951151: polymake: test failure on mips64el

[Benjamin Lorenz]

After some time of setting this up and building I can reproduce it and
got a better backtrace which seems well inside flint (up to frame 6):

Program received signal SIGSEGV, Segmentation fault.
0x0040014cb29c in flint_mpz_set_ui (r=0x400c8e3dd0, r=0x400c8e3dd0,
u=9223372036854775837)
at ./gmpcompat.h:73
73  ./gmpcompat.h: No such file or directory.
(gdb) bt
#0  0x0040014cb29c in flint_mpz_set_ui (r=0x400c8e3dd0,
r=0x400c8e3dd0, u=9223372036854775837)
at ./gmpcompat.h:73
#1  fmpz_set_ui (val=9223372036854775837, f=0x4000b9e7a0) at ./fmpz.h:214
#2  _fmpz_poly_xgcd_modular (len2=3, poly2=0x400c8e3d50, len1=3,
poly1=0x4003fe51c0, t=0x400c8ee520,
s=0x400c8e3c90, r=0x400c8e3cb8) at xgcd_modular.c:129
#3  _fmpz_poly_xgcd_modular (r=0x400c8e3cb8, s=0x400c8e3c90,
t=0x400c8ee520, poly1=0x4003fe51c0,
len1=3, poly2=0x400c8e3d50, len2=3) at xgcd_modular.c:34
#4  0x0040014ec9f8 in _fmpz_poly_xgcd (len2=3, poly2=, len1=3,
poly1=0x4003fe51c0, t=0x400c8ee520, s=0x400c8e3c90, r=0x400c8e3cb8)
at ./fmpz_poly.h:632
#5  _fmpq_poly_xgcd (G=0x400c8e3cf0, denG=0x400c8e3cb8, S=0x400c8e3c90,
denS=0x400c8e3c58,
T=0x400c8ee520, denT=0x400c8ee4e8, A=,
denA=0x400c8e3808, lenA=3, B=0x400c8e3d50,
denB=0x400c8e3d18, lenB=3) at xgcd.c:106
#6  0x0040014ecf00 in fmpq_poly_xgcd (G=0x400c8e3cb0,
S=0x400c8e3c50, T=0x400c8ee4e0,
A=0x400c8e3800, B=0x400c8e3d10) at xgcd.c:234
#7  0x00400137027c in pm::FlintPolynomial::xgcd (p2=..., p1=...,
t=..., s=..., g=...)
at ./include/core/polymake/FlintPolynomial.h:689
#8  pm::FlintPolynomial::xgcd (p2=..., p1=..., t=..., s=..., g=...)
at ./include/core/polymake/FlintPolynomial.h:685
...


I have tried to create a flint-only testcase for this which is attached
and gives on debian amd64:
lorenz@debian-unstable-amd64:~/pm40$ gcc flint-mips.cc -lflint
lorenz@debian-unstable-amd64:~/pm40$ ./a.out
(1) * (x^2 + 3*x + 1) + (-1) * (x^2 + 3*x) = 1

But in a mips64el qemu chroot:
$ gcc flint-mips.c -lflint
$ ./a.out
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault

The backtrace for this is slightly different:

Program received signal SIGSEGV, Segmentation fault.
0x0040008b922c in fmpz_get_mpz (x=0x4000811fd8, f=)
at ./gmpcompat.h:66
66  ./gmpcompat.h: No such file or directory.
(gdb) bt
#0  0x0040008b922c in fmpz_get_mpz (x=0x4000811fd8, f=)
at ./gmpcompat.h:66
#1  0x004000908f8c in _fmpq_poly_get_str_pretty (poly=0x40015c86f0,
den=0x4000812110, len=3, var=0x401170 "x") at get_str_pretty.c:138
#2  0x004000909844 in fmpq_poly_get_str_pretty (poly=,
var=) at get_str_pretty.c:215
#3  0x00400e10 in main (argc=1, argv=0x4000812318) at
flint-mips.c:20


> It looks like it's flint related?

Yes, I think this is a bug in flint and for now I suggest disabling the
flint-interface of polymake with the configure option --without-flint on
mips64el. This has basically no functionality loss as polymake will use
its own generic polynomial arithmetic instead (it will be somewhat slower).
Currently rebuilding polymake to check the testsuite again but this will
take some time and I will report back tomorrow.

#include 
#include 

#include "flint/fmpq_poly.h"

int main(int argc, char* argv[])
{
char *strp1, *strp2, *strg, *strs, *strt;
fmpq_poly_t p1,p2;
fmpq_poly_t g, s, t;

fmpq_poly_init(p1);
fmpq_poly_init(p2);
fmpq_poly_init(g);
fmpq_poly_init(s);
fmpq_poly_init(t);
fmpq_poly_set_str(p1, "3  1 3 1");
fmpq_poly_set_str(p2, "3  0 3 1");
fmpq_poly_xgcd(g,s,t,p1,p2);
strp1 = fmpq_poly_get_str_pretty(p1, "x");
strp2 = fmpq_poly_get_str_pretty(p2, "x");
strg  = fmpq_poly_get_str_pretty(g, "x");
strs  = fmpq_poly_get_str_pretty(s, "x");
strt  = fmpq_poly_get_str_pretty(t, "x");
flint_printf("(%s) * (%s) + (%s) * (%s) = %s\n", strs, strp1, strt, strp2, strg);
flint_free(strp1);
flint_free(strp2);
flint_free(strg);
flint_free(strs);
flint_free(strt);
fmpq_poly_clear(p1);
fmpq_poly_clear(p2);
fmpq_poly_clear(g);
fmpq_poly_clear(s);
fmpq_poly_clear(t);

return EXIT_SUCCESS;
}

Bug#946379: unattended-upgrades: wrong german translation in the help information

[Lorenz Wenner]

Package: unattended-upgrades
Version: 1.15
Severity: minor
Tags: newcomer

Dear Maintainer,

when i do "unattended-upgrades --help" i get:

-8<-
Usage: unattended-upgrades [options]

Options:
  -h, --helpshow this help message and exit
  -d, --debug   Nachrichten zur Fehlersuche ausgeben
  --apt-debug   APT/LibAPT detaillierte Nachrichten zur Fehlersuche
ausgeben lassen
  -v, --verbose Infomeldungen anzeigen
  --dry-run Simulation, herunterladen, aber nicht installieren
  --download-only   Nur herunterladen, aber nicht versuchen zu
installieren.
  --minimal-upgrade-steps
Upgrade in minimal steps (and allow interrupting with
SIGTERM) (default)
  --no-minimal-upgrade-steps
Aktualisierung in kleinen Schritten (und Unterbrechung
mit SIGTERM erlauben)
->8-

i think something went wrong in the german translation of the sections
concerning --(no-minimal-upgrade-steps). the german text for --no-minimal-
upgrade-steps would be correct for --minimal-upgrade-steps but is -- as i
strongly assume -- wrong for --no-minimal-upgrade-steps.

kind regards & hope this helps
Lorenz Wenner



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

Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages unattended-upgrades depends on:
ii  debconf [debconf-2.0]  1.5.73
ii  lsb-base   11.1.0
ii  lsb-release11.1.0
ii  python33.7.5-1
ii  python3-apt1.8.4+b1
ii  python3-dbus   1.2.14-1
ii  python3-distro-info0.22
ii  ucf3.0038+nmu1
ii  xz-utils   5.2.4-1+b1

Versions of packages unattended-upgrades recommends:
ii  anacron 2.3-29
ii  cron [cron-daemon]  3.0pl1-135
ii  systemd-sysv244-3

Versions of packages unattended-upgrades suggests:
pn  bsd-mailx   
pn  default-mta | mail-transport-agent  
pn  needrestart 
ii  powermgmt-base  1.36
ii  python3-gi  3.34.0-3

-- debconf information excluded

Bug#946197: Let's switch to OpenRC?

[Lorenz]

> Thomas Goirand  writes:
> 
> So, my proposal is to get rid of sysv-rc provided by sysvinit, in the
favor of
> OpenRC, so that developers can start replacing their init scripts by
superior
> runscripts.

Please don't: runit uses sysvinit scripts as a fallback for a missing
runscript (with
runscript I mean the native runit init scripts).
Also as a side note, I suspect you are a bit underestimating the work
needed to replace like ~1000
working scripts into their respective Debian packages.

Regards,
Lorenzo

Bug#945316: polymake: FTBFS with perl 5.30

[Benjamin Lorenz]

On 26/11/2019 01.51, Andreas Beckmann wrote:
> On 26/11/2019 00.00, Benjamin Lorenz wrote:
>> tldr: please rebuild normaliz and then try polymake again.
> 
> Thanks for the analysis. binNMU of normaliz requested: #945504

Thanks.

>> This is very weird but after some digging through backtraces, headers
>> and bugzilla I am quite sure that this is caused by:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92267
> 
>> that debian already backported the fix for the gcc bug to gcc 9.2.1-16
> 
> Since you looked into this: when was this gcc bug introduced in Debian?

According to the gcc bugtracker this was introduced upstream with gcc 9
in the following commit:
https://gcc.gnu.org/viewcvs/gcc?view=revision=260380
Thus it affects all 9.1 and 9.2 versions until 9.2.1-16 (9.2.1-20
contains the upstream backport).
See also #935902 and #943401.

I don't know when the default compiler for building packages was
switched to gcc 9.

> We should probably make a note to rebuild everything that was built with
> the buggy libstdc++ before the release of bullseye...

It don't think the bug affects many packages but this would be the
safest choice...

Benjamin



signature.asc
Description: OpenPGP digital signature

Bug#945316: polymake: FTBFS with perl 5.30

[Benjamin Lorenz]

On 23/11/2019 20.30, Andreas Beckmann wrote:
> Control: affects 941933 + src:polymake
> Control: retitle -1 polymake: FTBFS with normaliz 3.8.1: segfaults during 
> tests
> 
> On 23/11/2019 10.45, Benjamin Lorenz wrote:
>> On 22/11/2019 22.06, Andreas Beckmann wrote:
>>> polymake FTBFS against perl 5.30:
> 
>> This was already reported and should be fixed with
>> https://bugs.debian.org/941933
>> but it seems that the builds need to be triggered again as the logs are
>> older than the normaliz 3.8.1+ds-1 upload.
> 
> OK, tried my first self-served give-backs ...
> 
> ... some architectures succeeed (arm64, s390x), some had tests failing
> with segmentation faults (amd64, i386, armhf, ppc64el), mips*el is
> still building.
> 
> https://buildd.debian.org/status/package.php?p=polymake=unstable
> 
> Andreas
> 

tldr: please rebuild normaliz and then try polymake again.


This is very weird but after some digging through backtraces, headers
and bugzilla I am quite sure that this is caused by:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92267

The effect is that using the same std::deque template instantiation in
different libraries built with gcc 8 and gcc 9 can cause segfaults
because of an ABI incompatibility. In this case libppl.so.14.0.0 was
built with gcc 8 and libnormaliz with gcc 9 (9.2.1-12), both of them are
using std::deque. My build for polymake was with gcc 9 (9.2.1-19).

So I rebuilt ppl which to my surprise didn't help, but then I noticed
that debian already backported the fix for the gcc bug to gcc 9.2.1-16
(see
https://tracker.debian.org/news/1075824/accepted-gcc-9-921-16-source-into-unstable/).
This means that instead of ppl only normaliz needed to be rebuilt with
gcc >= 9.2.1-16.

Some logs from my experiments (rebuilding polymake is not necessary for
testing this, just switching out the other libraries):

### current normaliz build from unstable (ppl as well):

$ file /usr/lib/x86_64-linux-gnu/libnormaliz.so.3.8.1

/usr/lib/x86_64-linux-gnu/libnormaliz.so.3.8.1: ELF 64-bit LSB shared
object, x86-64, version 1 (GNU/Linux), dynamically linked,
BuildID[sha1]=49042b16a0c8fd0e5ecec9aa50e4fcf70842b8d5, stripped



$ objdump -s -j .comment
/usr/lib/debug/.build-id/49/042b16a0c8fd0e5ecec9aa50e4fcf70842b8d5.debug




Contents of section .comment:


  4743433a 20284465 6269616e 20392e32  GCC: (Debian 9.2


 0010 2e312d31 32292039 2e322e31 20323031  .1-12) 9.2.1 201


 0020 39313032 320091022.



lorenz@debian-unstable-amd64:~/polymake-3.2r4$ perl perl/polymake
--script run_testcases --applications polytope --examples
totally_dual_integral



*** Testing in application polytope ***





testing Examples:


 [ /functions/Optimization/totally_dual_integral ] 1Segmentation fault




### Installing my new local normaliz build:

# dpkg -i libnormaliz-dev_3.8.1+ds-1_amd64.deb
libnormaliz-dev-common_3.8.1+ds-1_all.deb
libnormaliz3_3.8.1+ds-1_amd64.deb libnormaliz3-dbgsym_3.8.1+ds-1_amd64.deb


$ file /usr/lib/x86_64-linux-gnu/libnormaliz.so.3.8.1

/usr/lib/x86_64-linux-gnu/libnormaliz.so.3.8.1: ELF 64-bit LSB shared
object, x86-64, version 1 (GNU/Linux), dynamically linked,
BuildID[sha1]=836dd385fe81deb4ca8b25dc9552a677ec24cc48, stripped

$ objdump -s -j .comment
/usr/lib/debug/.build-id/83/6dd385fe81deb4ca8b25dc9552a677ec24cc48.debug

Contents of section .comment:
  4743433a 20284465 6269616e 20392e32  GCC: (Debian 9.2
 0010 2e312d31 39292039 2e322e31 20323031  .1-19) 9.2.1 201
 0020 39313130 390091109.

$ perl perl/polymake --script run_testcases --applications polytope
--examples "totally_dual_integral"

*** Testing in application polytope ***

testing Examples:
 [ /functions/Optimization/totally_dual_integral ] 1 OK

*** Summary ***

*** All tests successful ***


For reference the top of the backtrace for the segfault with some weird
values for __n and __pos for the std::deque:

 [ /functions/Optimization/totally_dual_integral ] 1

Program received signal SIGSEGV, Segmentation fault.

0x7114972c in std::deque
>::_M_fill_insert (this=0x7fffab88, __pos=, __n=140737488330560,
__x=) at /usr/include/c++/8/bits/deque.tcc:305
305 /usr/include/c++/8/bits/deque.tcc: No such file or directory.
(gdb) bt
#0  0x7114972c in std::deque
>::_M_fill_insert (this=0x7fffab88, __pos=, __n=140737488330560,
__x=) at /usr/include/c++/8/bits/deque.tcc:305
#1  0x70f110af in std::deque
>::resize (this=0x7fffab88, __new_size=,
__x=) at /usr/include/c++/9/bits/stl_deque.h:757
#2  0x70f14a77 in libnormaliz::Full_Cone::Full_Cone
(this=0x7fffa0f0, M=..., do_make_prime=) at
/usr/include/c++/9/bits/stl_vector.h:915
#3  0x70e579cf in libnormaliz::Cone<__gmp_expr<__mpz_struct [1],
__mpz_struct [1]> >::compute_full_cone
(this=this@entry=0x7fffc380, ToCompute=...)
at ../../source/libnormaliz/cone.cpp:2899

Benjamin



signature.asc
Description: OpenPGP digital signature

Bug#945316: polymake: FTBFS with perl 5.30

[Benjamin Lorenz]

On 22/11/2019 22.06, Andreas Beckmann wrote:
> polymake FTBFS against perl 5.30:
> https://buildd.debian.org/status/package.php?p=polymake=unstable
> 
> *** Summary ***
> 
> *** Failed tests ***
> 
> /<>/apps/polytope/src/gc_closure.cc:173: testcase 1
> expected: regular return
>  got: EXCEPTION: no more rules available to compute 
> 'HILBERT_BASIS_GENERATORS'
> 
> make[1]: *** [debian/rules:41: override_dh_auto_test] Error 1

This was already reported and should be fixed with
https://bugs.debian.org/941933
but it seems that the builds need to be triggered again as the logs are
older than the normaliz 3.8.1+ds-1 upload.

Benjamin



signature.asc
Description: OpenPGP digital signature

Bug#945120: libopenmpi-dev: Sid upgrade to libopenmpi-dev 4.0.2-2 has issues in setup step

[Lorenz]

Dear Maintainer,

I observed the same issue on my system. Reinstalling libopenmpi-dev caused 
update-alternatives to figure out what was wrong and fixed the issue for me:

Setting up libopenmpi-dev:amd64 (4.0.2-2) ...
update-alternatives: warning: forcing reinstallation of alternative 
/usr/lib/x86_64-linux-gnu/openmpi/include because link group 
mpi-x86_64-linux-gnu is broken

The second time around, the /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so 
symlink exists and everything works. I'm not sure when exactly that is created, 
but like Ron, I suspect that it's too late.

Cheers,
Lorenz

Bug#944461: [Pkg-utopia-maintainers] Bug#944461: upower: segfaults when trying to communicate with usbmuxd when iPhone is plugged in

[Lorenz Hübschle-Schneider]

Thanks Michael, I missed that.

#944236 (upower: stack smashing detected) and #941703 (libimobiledevice6: 
Crashes upower with stack smashing when connecting an iPhone) also appear to be 
the same issue, but I see that's been noted already. I guess they can all be 
merged into one.

As far as I can tell the source of the problem is a SONAME tracking issue in 
libusbmuxd: https://github.com/libimobiledevice/libusbmuxd/issues/81 which 
breaks something in libimobiledevice which then causes upower to crash.

Cheers,
Lorenz

On Sun, 10 Nov 2019, at 15:34, Michael Biebl wrote:
> Am 10.11.19 um 13:15 schrieb Lorenz:
> > Package: upower
> > Version: 0.99.11-1
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> > when I have my (locked) iPhone plugged into my laptop, upower reproducibly
> > segfaults after five seconds. It is then automatically restarted by systemd,
> > but crashes again five seconds later. gdb was unable to produce a traceback 
> > for
> > the crashing thread, but strace produces:
> > 
> 
> Sounds like a duplicate of #941833
> 
> 
> -- 
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
> 
> 
> Attachments:
> * signature.asc

Bug#944461: upower: segfaults when trying to communicate with usbmuxd when iPhone is plugged in

[Lorenz]

ps/unix/sysv/linux/poll.c:29
> resultvar = 18446744073709551100
> sc_cancel_oldtype = 0
> #1  0x77c4a09e in g_main_context_poll (priority=,
n_fds=2, fds=0x555ce4b0, timeout=, context=0x555cd0b0)
at ../../../glib/gmain.c:4216
> ret = 
> errsv = 
> poll_func = 0x77c599e0 
> max_priority = 2147483647
> timeout = -1
> some_ready = 
> nfds = 2
> allocated_nfds = 
> fds = 0x555ce4b0
> #2  0x77c4a09e in g_main_context_iterate (context=0x555cd0b0,
block=block@entry=1, dispatch=dispatch@entry=1, self=) at
../../../glib/gmain.c:3912
> max_priority = 2147483647
> timeout = -1
> some_ready = 
> nfds = 2
> allocated_nfds = 
> fds = 0x555ce4b0
> #3  0x77c4a403 in g_main_loop_run (loop=0x555cd1a0) at
../../../glib/gmain.c:4111
> __FUNCTION__ = "g_main_loop_run"
> #4  0x77eb78f6 in gdbus_shared_thread_func (user_data=0x555b6dd0)
at ../../../gio/gdbusprivate.c:279
> data = 0x555b6dd0
> #5  0x77c72d0d in g_thread_proxy (data=0x555ae4f0) at
../../../glib/gthread.c:805
> thread = 0x555ae4f0
> __FUNCTION__ = "g_thread_proxy"
> #6  0x77baafb7 in start_thread (arg=) at
pthread_create.c:486
> ret = 
> pd = 
> now = 
> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140737329723136,
-1214051612260060498, 140737488344750, 140737488344751, 140737329723136,
140737329721024, 1214071305163223726, 1214068683123831470}, mask_was_saved =
0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0,
canceltype = 0}}}
> not_first_call = 
> #7  0x77adc2cf in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
>
> Thread 2 (Thread 0x770b8700 (LWP 6988)):
> #0  0x77ad1d0f in __GI___poll (fds=0x555b8860, nfds=1,
timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
> resultvar = 18446744073709551100
> sc_cancel_oldtype = 0
> #1  0x77c4a09e in g_main_context_poll (priority=,
n_fds=1, fds=0x555b8860, timeout=, context=0x555b9e90)
at ../../../glib/gmain.c:4216
> ret = 
> errsv = 
> poll_func = 0x77c599e0 
> max_priority = 2147483647
> timeout = -1
> some_ready = 
> nfds = 1
> allocated_nfds = 
> fds = 0x555b8860
> #2  0x77c4a09e in g_main_context_iterate
(context=context@entry=0x555b9e90, block=block@entry=1,
dispatch=dispatch@entry=1, self=) at ../../../glib/gmain.c:3912
> max_priority = 2147483647
> timeout = -1
> some_ready = 
> nfds = 1
> allocated_nfds = 
> fds = 0x555b8860
> #3  0x77c4a1bf in g_main_context_iteration (context=0x555b9e90,
may_block=may_block@entry=1) at ../../../glib/gmain.c:3978
> retval = 
> #4  0x77c4a211 in glib_worker_main (data=) at
../../../glib/gmain.c:5858
> #5  0x77c72d0d in g_thread_proxy (data=0x555ae450) at
../../../glib/gthread.c:805
> thread = 0x555ae450
> __FUNCTION__ = "g_thread_proxy"
> #6  0x77baafb7 in start_thread (arg=) at
pthread_create.c:486
> ret = 
> pd = 
> now = 
> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140737338115840,
-1214051612260060498, 140737488344782, 140737488344783, 140737338115840,
140737338113728, 1214068006091469486, 1214068683123831470}, mask_was_saved =
0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0,
canceltype = 0}}}
> not_first_call = 
> #7  0x77adc2cf in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
>
> Thread 1 (Thread 0x773f2840 (LWP 6984)):
> #0  0x in  ()
> #1  0x7fffe800aa10 in  ()
> #2  0x in  ()

Please let me know if there's any more information that would help.

Cheers,
Lorenz



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

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

Versions of packages upower depends on:
ii  dbus   1.12.16-2
ii  libc6  2.29-3
ii  libglib2.0-0   2.62.2-3
ii  libgudev-1.0-0 233-1
ii  libimobiledevice6  1.2.1-6
ii  libplist3  2.0.1~git20190104.3f96731-1
ii  libupower-glib30.99.11-1
ii  libusb-1.0-0   2:1.0.23-1
ii  udev   242-8

Versions of packages upower recommends:
ii  policykit-1  0.105-26

upower suggests no packages.

-- no debconf information

Bug#943395: runit: Minor fixes to invoke-run

[Lorenz]

Il giorno dom 3 nov 2019 alle ore 05:55 Dmitry Bogatov 
ha scritto:

> Do you want me to upload #943395 and #942320 right now, or wait for
> dh-runit and git-daemon?

I think it's better to wait.
For git-daemon-run I already have the patch but i'm not able to test it
because git
fails to build for me. Just haven't had the time to dig a little bit more
on this.

Thanks,
Lorenzo

Bug#942323: runit-helper: Use dot-symlinks to mark a service as disable

[Lorenz]

Il giorno dom 20 ott 2019 alle ore 22:06 Dmitry Bogatov 
ha scritto:

> Sorry, don't follow. Previously no link in /etc/service was created if
> dh-runit decides that service should not be enabled, now hidden link is
> created instead. How it is more confusing?

OK, from existing users there are no visible consequences and a bug is
fixed.
I just meant that probably should be documented somewhere that runit uses
.simlink to mark a service as disabled.

 > What buggy behaviour will this change cause for git-run users?

git-daemon-run use 'update-service --remove' in its maint scripts, so
after #942320 patch is applied, it will set git daemon as disabled on
remove (as it was a user choice) and it will delete the setting on install.

Bug#941933: polymake: FTBFS: no more rules available to compute 'HILBERT_BASIS_GENERATORS'

[Benjamin Lorenz]

On 10/7/19 8:30 PM, Niko Tyni wrote:
> On Mon, Oct 07, 2019 at 08:59:47PM +0300, Niko Tyni wrote:
>> Source: polymake
>> Version: 3.2r4-4
>> Severity: serious
>> Tags: ftbfs
>> Control: block 935737 with -1
>>
>> This package failed to build in sid when rebuilding against Perl 5.30.
>>
>> Looking at the history at
>>
>>   
>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/polymake.html
>>
>> it seems to have regressed around 2019-07-29, so not Perl 5.30 specific.
> 
> Upstream 3.5 release notes 
> mention
> 
> - support for clang 8 and gcc 9
> - support for perl 5.30 
> 
> so hopefully this is fixed upstream. 

This test-failure comes because
libnormaliz-dev-common: /usr/include/libnormaliz/integer.h
requires
libeantic-dev:amd64: /usr/include/e-antic/renfxx.h
but installing libnormaliz-dev as a dependency for polymake does not
pull in libeantic-dev.
Also: normaliz 3.7.1 with newly added e-antic support was uploaded to
unstable 2019-07-19.

More details:
The configure script of polymake disables the (optional) libnormaliz
interface because of a compile test. But this testcase does not have the
flag to disable it in this case.
I will adjust the testcase in the polymake master and also have a look
whether the configure checks can be made fatal in this case.

polymake 3.2 seems to work fine with perl 5.30.


I will try to make a pull request for polymake 3.5 but this will
probably take a few weeks.



signature.asc
Description: OpenPGP digital signature

Bug#934231: anacron: please provide a runscript for runit

[Lorenz]

Il giorno dom 8 set 2019 alle ore 21:17 Dmitry Bogatov 
ha scritto:

> > +# don't restart anacron when it's done

> Why? Will it work correctly on machine that is up for 24/7?

When anacron is done with its jobs it exit and when restarted, if it
detects that
there are no job to run it exits again. For machines up 24/7 the package
ships
a cronjob, so it will work.

I think I have addressed (on salsa) other issues except the finish file: I
will open a bug with a
patch for that but i'm short on free time right now.

Lorenzo

Bug#935958: runit: Tools to help generating runscripts

[Lorenz]

Il giorno dom 1 set 2019 alle ore 15:25 Dmitry Bogatov 
ha scritto:

> > > * please do not print "Starting $NAME". It goes to log, quite
> > >   pointless and may confuse scripts/tools that want to analyze log.
> > [ ...]

> I have two ideas:
>
>  * Check for $VERBOSE variable. If you have issues with services {foo},
>   you can
>
># mkdir -p /etc/sv/foo/conf
># echo 1 > /et/sv/foo/conf/VERBOSE
>
>  * You can write to /dev/tty63 (or some other unused tty). It is hard to
>   copy-paste from there, though.
>
> Either way, 'runsv:' is improvement, imho.
>
> [...]
>
> Also, I am worried about runscripts being so repetive. We already know
> historic study case: classic init.d scripts and init-d-script(5).
>
> At minimum, I think we need something like 'invoke-finish' in bin:runit
> and dh_runit to create one-line `finish` script by default.  Variable
> 'NAME' should be exported by `invoke-run'.

Ok, I'll propose some suitable solution for this before sending other
patches
with runscripts.

Bug#939373: xorg-server: Copy/paste broken with wayland

[Martin Lorenz]

Source: xorg-server
Version: 2:1.20.4-1
Severity: normal

Dear Maintainer,

I'm not really sure if this is the right package to report this bug to,
bus as xwayland is built from it, I guess I'm right ...

Since a recent update to my system it defaults to wayland instead of
xorg. From that moment on, copy/paste behaviour went berserk!

It is not really consistent how it goes wromg, but there are some common
annoyances that I observe:

1. copy/paste via primary selection works within some applications 
2. copy/paste via primary selection almost allways fails from 
   one application to another
3. when copying text and trying to paste it, it gets replaced
   by text that got accidentially selected by some default mechanism
   (e.g. when pressing Ctrl-L in nautilus to paste a path)
4. sometimes the primary selection will replace the text selected by
   Ctrl-C and vice versa
   ... this is really annoying, as I am used to take primary selection
   and copy/paste buffer to be completely seperated and used it that way
   for more than twenty years

... there might be more, but at the moment I can't remember all
annoyances that struck me in this case.


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

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

Bug#939372: gnome: Inconsistent appearence of "recently used" in file chooser

[Martin Lorenz]

Package: gnome-common
Version: 3.18.0-4
Severity: normal
File: gnome

Dear Maintainer,

in recent versions of gnome I found, that the file-chooser dialog is
somhow inconsistent...

## Steps to reproduce

 1. use whichever gnome software you want
 2. open the file chooser either to load or to save a file
 3. notice that there sometimes is a "recently used" item and sometimes not

## Current behavior
"Recently used" file list appears in some cases and is missing in others ...

## Expected outcome
A "recently used" entry is present at each and every file chooser (as it used 
to be)
In a "save" chooser I'd expect it to be a list of recently used directories to 
save my file into,
in an "open" chooser it should be a list of recently used files of suitable 
file-type for the application




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

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

Versions of packages gnome-common depends on:
ii  autoconf  2.69-11
ii  autoconf-archive  20180313-1
ii  automake  1:1.16.1-4
ii  autopoint 0.19.8.1-9
ii  gettext   0.19.8.1-9
ii  intltool  0.51.0-5
ii  libtool   2.4.6-11
ii  pkg-config0.29-6

gnome-common recommends no packages.

gnome-common suggests no packages.

-- no debconf information

Bug#935985: python3-ldap3: Value "0" not accepted for "pwdLastSet" attribute

[Lorenz Kaestle]

Package: python3-ldap3
Version: 2.4.1-1
Severity: normal
Tags: patch

Dear Maintainer,
My usecase is the creation of new accounts within a windows active directory 
enviroment.
The new account gets a one-time password which has to be changed on first login.
To use this functionality, the "pwdLastSet" attribut of the account has to be 
set to 0,
but the validation functionality of ldap3 only permits the value -1.

The problem is in the file
"/usr/lib/python3/dist-packages/ldap3/protocol/formatters/validators.py" and I
fixed it with this patch:

69c69
< """Accept -1 only (used by pwdLastSet in AD)
---
> """Accept -1 or 0 only (used by pwdLastSet in AD)
72c72
< if input_value == -1 or input_value == '-1':
---
> if input_value == -1 or input_value == '-1' or input_value == 0 or 
> input_value == "0":
76c76,77
< if len(input_value) == 1 and input_value == -1 or input_value == '-1':
---
> if (len(input_value) == 1 and input_value == -1 or input_value == 
> '-1' or
> input_value == 0 or input_value == "0"):


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

Kernel: Linux 4.19.0-5-amd64 (SMP w/1 CPU core)
Kernel taint flags: TAINT_WARN
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/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-ldap3 depends on:
ii  python3 3.7.3-1
ii  python3-pyasn1  0.4.2-3

python3-ldap3 recommends no packages.

python3-ldap3 suggests no packages.

-- no debconf information
69c69
< """Accept -1 only (used by pwdLastSet in AD)
---
> """Accept -1 or 0 only (used by pwdLastSet in AD)
72c72
< if input_value == -1 or input_value == '-1':
---
> if input_value == -1 or input_value == '-1' or input_value == 0 or 
> input_value == "0":
76c76,77
< if len(input_value) == 1 and input_value == -1 or input_value == '-1':
---
> if (len(input_value) == 1 and input_value == -1 or input_value == 
> '-1' or
> input_value == 0 or input_value == "0"):
69c69
< """Accept -1 only (used by pwdLastSet in AD)
---
> """Accept -1 or 0 only (used by pwdLastSet in AD)
72c72
< if input_value == -1 or input_value == '-1':
---
> if input_value == -1 or input_value == '-1' or input_value == 0 or 
> input_value == "0":
76c76,77
< if len(input_value) == 1 and input_value == -1 or input_value == '-1':
---
> if (len(input_value) == 1 and input_value == -1 or input_value == 
> '-1' or
> input_value == 0 or input_value == "0"):

Bug#934500: dh-runit: permissions of supervise directory

[Lorenz]

Il giorno ven 23 ago 2019 alle ore 13:22 Dmitry Bogatov 
ha scritto:

> [...]What about making
> in postinst symlink
>
>/run/runit/supervise/foo -> /lib/runit/supervise/foo
>
> if latter exists? It should resolve problem with overwriting symlink of
> running process.

It's ok for me, thanks

Bug#934500: dh-runit: permissions of supervise directory

[Lorenz]

>>if test ! -h "$svdir"/supervise; then
>>  rm -rf "$svdir"/supervise
>> -ln -s /var/lib/runit/supervise/"$sv" "$svdir"/supervise
>> +ln -s /run/runit/supervise/"$sv" "$svdir"/supervise
>
>Will it handle both /var/lib and /run/runit location?

Mmm.. No
In my system i have a mix of
* supervise inside /etc/sv/foo that is not a symlink ( due to my own
experiment i believe)
* supervise that is a symlink to /var/lib/runit/supervise/foo (current
dh-runit)
* supervise that is a symlink to /var/lib/supervise/foo (update-service
before dh-runit)
if you prefer i can force a replace of /var/ with /run each time one types
'update-service --add  /etc/sv/foo'
new patch attached should handle all of the above cases, except
it won't replace a supervise dir of an already running service (of course)

About this, I forsee trouble during an upgrade of a package that already
ship a runscript, think of the following

1 acpid is running (with runit) and supervise links to /var/lib/
2 upgrade of acpid, with new dh (supervise links to /run/)
3 unpack will replace supervise symlink of a running service-- > what
happens?
4 then postinstall try to send signals to acpid..

I can test the opposite (switch from /run into /var) and it doesn't
end up good

# sv status acpid
run: acpid: (pid 5576) 17s; run: log: (pid 5575) 17s

# readlink /etc/sv/acpid/supervise
/run/runit/supervise/acpid

# apt-get install --reinstall acpid
Reading package lists... Done
Building dependency tree
Reading state information... Done
[...]
Preparing to unpack .../acpid_1%3a2.0.32-1_amd64.deb ...
Unpacking acpid (1:2.0.32-1) over (1:2.0.32-1) ...
Setting up acpid (1:2.0.32-1) ...
insserv: Script rsync has overlapping Default-Start and Default-Stop
runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.
insserv: Script lvm2 has overlapping Default-Start and Default-Stop
runlevels (S) and (S). This should be fixed.
Stopping ACPI services: acpid.
Starting ACPI services: acpid.
Processing triggers for man-db (2.8.6.1-1) ...

Looks all good but then

# sv status acpid
fail: acpid: runsv not running

# ps aux | grep acpid
root  1473  0.0  0.0   2312  1284 ?Ss   11:37   0:00 runsvdir
-P /etc/service log: t runsv acpid: warning: unable to open
supervise/pid.new: file does not exist runsv acpid: warning: unable to open
supervise/pid.new: file does not exist runsv acpid: warning: unable to open
supervise/pid.new: file does not exist runsv acpid: warning: unable to open
log/supervise/pid.new: file does not exist runsv acpid: warning: unable to
open log/supervise/pid.new: file does not exist .
root  5574  0.0  0.0   2160   736 ?Ss   16:25   0:00 runsv acpid
runit-l+  5575  0.0  0.0   2304   680 ?S16:25   0:00 svlogd -tt
/var/log/runit/acpid
root 13527  0.0  0.0   2452  1792 ?S16:26   0:00
/usr/sbin/acpid -f
root 28142  0.0  0.0   6524   880 pts/0S+   16:29   0:00 grep acpid

Looks an acpid process managed by runsv survives but i can't send signal to
it!

Maybe let runit-helper create the symlinks rather than
shipping in the package itself is a more flexible approach?
Anything else I'm missing ?

Lorenzo
From 1abd914b1a171ea89899699bbec3e2a901e61bac Mon Sep 17 00:00:00 2001
From: Lorenzo Puliti 
Date: Mon, 19 Aug 2019 14:58:38 +0200
Subject: [PATCH] update-service: move supervise directories in tmpfs

Create log and service's supervise directories under /run/
tmpfs (they were in /var/ previously).
Also try to replace old supervise directories pointing to /var
with new one pointing to /run, when possible.
---
 debian/contrib/update-service | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/debian/contrib/update-service b/debian/contrib/update-service
index 7e72501..bb83f2b 100644
--- a/debian/contrib/update-service
+++ b/debian/contrib/update-service
@@ -63,11 +63,24 @@ case "$opt" in
 if test "${svdir#/etc/}" != "$svdir"; then
   if test ! -h "$svdir"/supervise; then
 rm -rf "$svdir"/supervise
-ln -s /var/lib/runit/supervise/"$sv" "$svdir"/supervise
+ln -s /run/runit/supervise/"$sv" "$svdir"/supervise
+  else
+#934500 force the switch of supervise into /run, keep untill bullseye +1
+if [ $(readlink "$svdir"/supervise) != /run/runit/supervise/"$sv" ]; then
+rm -rf "$svdir"/supervise
+ln -s /run/runit/supervise/"$sv" "$svdir"/supervise
+fi
   fi
   if test -d "$svdir"/log && test ! -h "$svdir"/log/supervise; then
 rm -rf "$svdir"/log/supervise
-ln -s /var/lib/runit/log/supervise/"$sv" "$svdir"/log/supervise
+ln -s /run/runit/supervise/"$sv".log "$svdir"/log/supervise
+  fi
+  #934500 force the switch of supervise into /run, keep untill bullseye +1
+  if [ -h "$svdir"/log/supervise ]; then
+if [ $(readlink "$svdir"/log/supervise) != /run/runit/supervise/"$sv".log ]; then
+rm -rf "$svdir"/log/supervise

Bug#934500: dh-runit: permissions of supervise directory

[Lorenz]

Il giorno mer 14 ago 2019 alle ore 21:22 Dmitry Bogatov 
ha scritto:

>Yes, I go this way.

Ok.
in commit d07519ae you already create /run/runit/supervise directory,
but the directory for the appendant log of 'foo' service will be
/run/runit/log/supervise/foo
or
/run/runit/supervise/foo.log ?

Lorenzo

Bug#934500: dh-runit: permissions of supervise directory

[Lorenz]

Il giorno dom 11 ago 2019 alle ore 19:48 Dmitry Bogatov 
ha scritto:

> The simpliest fix is revert of #924903. More attractive way is to move
> supervise directories into /run.

The permission issue is not essential to me, but i prefer to move supervise
directories into /run.
I don't see a strong reason to have persistent supervise directories: the
files inside are mostly (if not all) not recyclable, bug like #919296
proves that pre-create files with the porpose of speeding up the start of a
runsv process doesn't work.
Moreover, if i recall correcly, Debian's runit already need to rely on /run
if it wants to become /etc readonly proof.
Let me know in advance if you are going this way, I will prepare a patch
for update-service too.

Lorenzo

Bug#933078: runit: forced-rescan feature

[Lorenz]

Hi Dmitry, thanx for this, i'm testing right now.

Il giorno ven 26 lug 2019 alle ore 15:30 Dmitry Bogatov 
ha scritto:
> Here I request review. Is this feature really needed. Is timestamp file
> needed? Maybe there are simplier ways to implement it?

Gerrit Pape said he is collecting patches to do a maintenance release of
runit [1] : maybe
you can submit the patch to the supervision mailing list to get a review?

Lorenzo

[1] https://www.mail-archive.com/supervision@list.skarnet.org/msg02073.html

Bug#932290: insserv: Script has overlapping Default-Start and Default-Stop runlevels

[Lorenz]

Control: severity -1 normal

Ok, here is what I've found out; to reproduce the issue you need to
disable with update-rc.d a script that has an empty ' Default-Stop: ' field
in the LSB header.

# update-rc.d ssh disable
insserv: warning: current start runlevel(s) (empty) of script `ssh'
overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (2 3 4 5) of script `ssh'
overrides LSB defaults (empty).
insserv: Script ssh has overlapping Default-Start and Default-Stop
runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.
insserv: Script rsync has overlapping Default-Start and Default-Stop
runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.
insserv: Script lvm2 has overlapping Default-Start and Default-Stop
runlevels (S) and (S). This should be fixed.

there are other scripts that can trigger this, for example on my system I
also
have Cron and Anacron.

This is a minor issue, but still i have few suggestions:

1. the message looks like an error, but insserv exits 0, so i guess it' a
warning,
maybe it should be ' insserv: warning: Script ssh has ...'
2. disabling a service is a legit action and insserv already prints a
warning about
overriding LSB defaults, so what is this warning about (what is to be
fixed)?
Is an empty ' Default-Stop: ' field a bug, or it's something else?

Thanks,
Lorenzo

Bug#931658: runit-init: Boot hangs with QEMU if openssh-server is installed

[Lorenz]

Il giorno mar 9 lug 2019 alle ore 01:52 Colin Watson 
ha scritto:
>Is this just another instance of problems with your virtual machine not
>having enough entropy (#912616 etc.)?

It looks you are right, thanks for the tip!

Dmitry, I can pass the test that include openssh-server with a command like
(see #912087 message 118)

$ autopkgtest ./runit-init_2.1.2-32_all.deb ./runit_2.1.2-32_amd64.deb
 ./runit  \
-- qemu --qemu-options='-object rng-random,filename=/dev/urandom,id=rng0
-device virtio-rng-pci,rng=rng0' \
./debian-unstable.img

This rely on the host having enough entropy and i'm not sure how to pass
those options to salsa CI

Bug#930758: runit: Add a test for switching init (systemd-->runit)

[Lorenz]

Dmitry Bogatov:
>Can't we just conflict with libnss-systemd?
Yes, that would solve the issue for runit

>Can you please file separate bug about hang boot?
Done. I'm still digging on this, but no luck so far..

Thanks,
Lorenzo



Il giorno gio 4 lug 2019 alle ore 19:41 Dmitry Bogatov 
ha scritto:

>
> [2019-07-03 02:36] Lorenz 
> > Dmitry,
> > sorry it took so long to send the patches,
>
> No need to be sorry :) You are doing awesome job at tasks I do not dare
> to tackle.
>
> > but while updating the test i run into several issues i'm not able to
> > solve by myself:
> > * I try to include openssh into the test but it makes the test fail
> because
> > ssh get stuck
> >at boot (same issue as reported by Martin Pitt in #838480 message #49)
>
> I confirm addition of `openssh-server' into test dependency indeed makes
> it hang (my log is at bottom). I will take a look and try to reproduce
> bug interactively (over VNC).
>
> > * then i try a Vbox VM and i failed to reproduce the ssh issue, but i run
> > into several other issues, see #931356
>
> Can't we just conflict with libnss-systemd?
>
> > Althought the test as it is now in the patches pass, we should deal
> > with the above issues as they are likely hitting users that attempt
> > the switch
>
> Not sure about libnss, but I agree -- ssh server is extremely important.
> Can you please file separate bug about hang boot?
>
>
>
>

Bug#930758: runit: Add a test for switching init (systemd-->runit)

[Lorenz]

Dmitry,
sorry it took so long to send the patches, but while updating the test i
run into
several issues i'm not able to solve by myself:
* I try to include openssh into the test but it makes the test fail because
ssh get stuck
   at boot (same issue as reported by Martin Pitt in #838480 message #49)
* then i try a Vbox VM and i failed to reproduce the ssh issue, but i run
into
   several other issues, see #931356
Althought the test as it is now in the patches pass, we should deal with
the above issues
as they are likely hitting users that attempt the switch


Il giorno mer 3 lug 2019 alle ore 01:33 Lorenzo Puliti <
lorenzo.r...@gmail.com> ha scritto:

> Package: runit
> Version: 2.1.2-31
> Followup-For: Bug #930758
>
> Hi,
> it looks like init-system-helpers 1.57 breaks the test (it removes
> runit-init from
> the list of supported init).
> Anyway the following patches should work
>
> Lorenzo
>
>
> -- System Information:
> Debian Release: 10.0
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.20.3-van (SMP w/4 CPU cores; PREEMPT)
> Kernel taint flags: TAINT_OOT_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: runit (via /run/runit.stopit)
>
> Versions of packages runit depends on:
> ii  libc6   2.28-10
> ii  runit-helper2.8.10
> ii  sysuser-helper  1.3.3
>
> Versions of packages runit recommends:
> ii  runit-init  2.1.2-30
>
> runit suggests no packages.
>
> -- Configuration Files:
> /etc/runit/3 changed [not included]
>
> -- no debconf information
>

Bug#930758: runit: Add a test for switching init (systemd-->runit)

[Lorenz]

Hi,

> Why are these 'service' calls? Do 'service' support runit already?

No, not yet. I'm using 'service' script to test if those services, started
as sysv scripts,
are up.  According to my testing, rsyslog, cron, udev and dbus are
installed and running in
the systemd testbed, so it make sense to me to test if they are running
after the switch.
Anyway, i'm not sure what to test to decide if the init switch is
successful, ideas are welcome.

As for other observations you made, i will have a look and send new patches
soon

Lorenzo

Il giorno ven 21 giu 2019 alle ore 15:01 Dmitry Bogatov 
ha scritto:

>
> [2019-06-20 02:07] Lorenzo Puliti 
> > Hi,
>
> Hi!
>
> > while experimenting with autopkgtest i manage to write a small test
> > that, starting from a systemd qemu machine, installs runit-init and
> reboot into
> > it, checking if there is a working getty to login with and if essential
> > services (syslog, udev ..) are up.
> > While the test is very simple it could be useful to have something like
> > this around to make sure that the compat layer in /run/initctl will not
> > get broken (by systemd) and that some future development in stage1/2
> will not
> > break the runit-init boot.
> > I have tested it on my pc, the last attach is the output of the test
>
> Sounds good, let's see.
>
> > Subject: [PATCH 1/3] Provide a service for a getty on serial tty
> >
> > diff --git a/debian/getty-ttyS0/run b/debian/getty-ttyS0/run
> > new file mode 100755
> > index 000..31dccf6
> > --- /dev/null
> > +++ b/debian/getty-ttyS0/run
> > @@ -0,0 +1,8 @@
> > +#!/bin/sh
> > +NAME=getty-ttyS0
> > +if pgrep -x agetty -t ttyS0; then
> > +sv d getty-ttyS0
> > +echo "already another getty on ttyS0"
> > +fi
> > +exec 2>&1
> > +exec chpst -P fgetty /dev/ttyS0
>
> As I understand it, you assume that fgetty is present. Currently, runit
> does not have hard dependency of 'fgetty'. Can this runscript be made to
> fallback on "getty" from util-linux?
>
> > >From 374b79ae1c811b668668f22f57e77a6d352670a4 Mon Sep 17 00:00:00 2001
> > From: Lorenzo Puliti 
> > Date: Mon, 17 Jun 2019 14:43:55 +0200
> > Subject: [PATCH 2/3] Prepare source for autopkgtest
> >
> > Add a stanza in debian/control and a debian/tests directory
> > needed for autopkgtest
> > ---
> >  debian/control   | 1 +
> >  debian/tests/control | 1 +
> >  2 files changed, 2 insertions(+)
> >  create mode 100644 debian/tests/control
> >
> > diff --git a/debian/control b/debian/control
> > index 23300e5..0764231 100644
> > --- a/debian/control
> > +++ b/debian/control
> > @@ -13,6 +13,7 @@ Build-Depends: bash-completion,
> > doc-base,
> >  Vcs-Browser: https://salsa.debian.org/debian/runit
> >  Vcs-Git: https://salsa.debian.org/debian/runit.git
> > +Testsuite: autopkgtest
> >
> >  Package: runit
> >  Architecture: any
> > diff --git a/debian/tests/control b/debian/tests/control
> > new file mode 100644
> > index 000..8d1c8b6
> > --- /dev/null
> > +++ b/debian/tests/control
> > @@ -0,0 +1 @@
>
> Are you sure this is needed? I believe autopkgtest tests are run without
> "Testsuite" field in debian/control. In my "gdbm" package, they do.
>
> > Subject: [PATCH 3/3] add a test for switching to runit-init
> >
> > Add a smoke test for the switch systemd --> runit-init
> > ---
>
> > --- a/debian/tests/control
> > +++ b/debian/tests/control
> > @@ -1 +1,7 @@
> > -
> > +Tests: init-switch
> > +Depends: runit,
> > +  runit-init,
> > +  getty-run,
> > +  fgetty,
> > +  psmisc,
> > +Restrictions: needs-root, isolation-machine, breaks-testbed
>
> I am positive that runit-init implies getty-run. Maybe this list could
> be shinked even futher?
>
> > diff --git a/debian/tests/init-switch b/debian/tests/init-switch
> > new file mode 100755
> > index 000..1e09238
> > --- /dev/null
> > +++ b/debian/tests/init-switch
> > @@ -0,0 +1,60 @@
> > + #!/bin/sh
> > + set -e
> > +
> > +
> > + if [ -z "$AUTOPKGTEST_REBOOT_MARK" ]; then
> > +if [ -d /run/systemd/system ]; then
> > +init=systemd
> > +elif [ -e /run/initctl ]; then
> > +init=sysv
> > +else
> > +init=unknown-init
> > +fi
> > +echo "testbed is running with $init"
> > +
> > +if [ -e /tmp/autopkgtest-reboot ]; then
> > +echo "enabling the serial getty"
> > +ln -s /etc/sv/getty-ttyS0 /etc/service/
> > +echo "Done"
> > +/tmp/autopkgtest-reboot-prepare runit
> > +echo "reboot"
> > +reboot
> > +else
> > +echo "testbed does not support reboot"
> > +echo "can't perform this test"
> > +exit 1
> > +fi
> > + else
> > +echo "detecting runit-init"
> > +if [ -e /run/runit.stopit ]; then
> > +echo "OK"
> > +else
> > +echo "init is not runit" && exit 1
> > +fi
> > +# searching for runsvdir is pointless, since autopkgtest use serial
> getty
> > +#to connect with the qemu-system, and getty-S0 starts only after
> runsvdir..
>
> > +#echo "detecting runsvdir"

Bug#930160: transgui: Cannot connect via SSL/TLS

[Lorenz]

Package: transgui
Version: 5.0.1-5.1
Severity: important

Dear Maintainer,

I'm not sure quite when this started, but some update in the last couple of
months broke transgui. I can no longer connect via SSL/TLS. Upon attempting to
connect, I get the error message

> error:140A90C4:SSL routines:func(169):reason(196)

I believe that this means that transgui is built against an older version of
OpenSSL, and that rebuilding the package would fix it?

Cheers,
Lorenz



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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
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/dash
Init: systemd (via /run/systemd/system)

Versions of packages transgui depends on:
ii  libatk1.0-0 2.30.0-2
ii  libc6   2.28-10
ii  libcairo2   1.16.0-4
ii  libgdk-pixbuf2.0-0  2.38.1+dfsg-1
ii  libglib2.0-02.58.3-2
ii  libgtk2.0-0 2.24.32-3
ii  libpango-1.0-0  1.42.4-6
ii  libssl1.1   1.1.1c-1
ii  libx11-62:1.6.7-1

transgui recommends no packages.

transgui suggests no packages.

Bug#924132: runit: Add support for runit in init-system-helpers

[Lorenz]

Sure, here is the link

https://salsa.debian.org/debian/init-system-helpers/merge_requests/10

Thanks

Il giorno ven 24 mag 2019 alle ore 19:59 Felipe Sateler 
ha scritto:

> Hi Lorenz
>
> On Tue, May 21, 2019, 11:42 Lorenzo Puliti  wrote:
>
>> Control: reassign 924132 init-system-helpers
>>
>> Dear init-system-helpers Maintainers,
>>
>>  here are a series of 5 commits that add support for runit-init into
>>  'update-rc.d', 'invoke-rc.d' and 'service' scripts.
>>
>>
>> https://salsa.debian.org/Lorenzo.ru.g-guest/init-system-helpers/commits/runit
>>
>>  This has been already reviewed by Dmitry Bogatov.
>>  If you don't have further question or requirements, can you upload to
>> experimental
>>  and then, after Buster release, to unstable?
>>
>
> Could you post the patches as a salsa MR? It would make for easier review.
>
>
> Saludos
>

Bug#928935: Invoke-run: add a way to not stop sysv scripts

[Lorenz]

Hi,

> True. Here are patches. What do you think?

I haven't had time to test but the patch looks good to me, just an
observation:
to my experience

/etc/init.d/${service} status

is not always reliable in term of both results and exit codes, we will have
the
chance to fix a certain number of sysv init scripts because of this

thanks



Il giorno gio 16 mag 2019 alle ore 10:54 Dmitry Bogatov 
ha scritto:

>
> control: tags -1 +pending +patch
>
> [2019-05-13 14:35] Lorenzo Puliti 
> > Hi,
> >
> > In order to avoid conflicts, recent version of invoke-run interpreter
> stops the sysv
> > init scripts before starting the run service.
> > Please note that this logic, when applied to daemons like dbus, slim,
> sddm, lightdm
> > (and possibly others) will break the graphic session, so there is need
> for a way
> > to prevent the sysv script being replaced by the run script while the
> graphic session
> > is active.
> > This also will need support in dh-runit.
>
> True. Here are patches. What do you think?
>
> From 66e9071165250793d8900f17cd5b35ca7b45526b Mon Sep 17 00:00:00 2001
> From: Dmitry Bogatov 
> Date: Tue, 14 May 2019 10:45:06 +
> Subject: [PATCH] invoke-run: add option to not stop sysv scripts
>
> Closes: #928935
> ---
>  debian/contrib/lib/invoke-run | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/debian/contrib/lib/invoke-run b/debian/contrib/lib/invoke-run
> index a424b73..9fa5c59 100755
> --- a/debian/contrib/lib/invoke-run
> +++ b/debian/contrib/lib/invoke-run
> @@ -40,7 +40,17 @@ if [ -r "/etc/default/${service}" ] ; then
>  fi
>
>  readonly initscript="/etc/init.d/${service}"
> +readonly noreplace="/var/lib/runit/noreplace/${service}"
> +
>  if [ -x "${initscript}" ] ; then
> +   # Stopping some services (e.g display manager) is disruptive
> +   # and must be done only manually by user.
> +   if [ -f "${noreplace}" ] ; then
> +   if "${initscript}" status >/dev/null 2>&1 ; then
> +   sv down "${service}"
> +   exit 0
> +   fi
> +   fi
> "${initscript}" stop
>  fi
>
> And here is patch for dh_runit. It may be more convenient to see it at
> salsa.debian.org/runit-team/dh-runit.
>
> From cb411affcbc2eb183ee5f35e50c3863c0b94f98a Mon Sep 17 00:00:00 2001
> From: Dmitry Bogatov 
> Date: Tue, 14 May 2019 15:41:52 +
> Subject: [PATCH] Add option to mark service as non-restartable
>
> ---
>  dh_runit   | 18 ++
>  t/924903.t |  5 -
>  t/928935.t | 10 ++
>  3 files changed, 32 insertions(+), 1 deletion(-)
>  create mode 100644 t/928935.t
>
> diff --git a/dh_runit b/dh_runit
> index 5ed55b5..4c9820e 100755
> --- a/dh_runit
> +++ b/dh_runit
> @@ -5,6 +5,7 @@ use v5.10.1;
>  use strict;
>  use Debian::Debhelper::Dh_Lib;
>  use File::Find;
> +use File::Path qw(make_path);
>  use File::stat;
>  use feature 'signatures';
>  no warnings 'experimental';
> @@ -17,6 +18,7 @@ sub parse_options($opts) {
>  when (/^name=(.*)$/)   { $conf->{name} = $1; };
>  when (/^since=(.*)$/)  { $conf->{since} = $1; };
>  when (/^logscript$/)   { $conf->{logscript} = 1};
> +when (/^noreplace$/)   { $conf->{noreplace} = 1};
>  when (/^defaults$/){ "do nothing"; };
>  default{ error("unknown option `$opt'"); }
>  }
> @@ -59,6 +61,13 @@ PKG: foreach my $pkg (@{$dh{DOPACKAGES}}) {
>  my $conf = parse_options($opts);
>  my $name = $conf->{name} || basename($path);
>
> +if ($conf->{noreplace}) {
> +make_path("${tmp}/var/lib/runit/noreplace/");
> +open(my $fh, ">", "${tmp}/var/lib/runit/noreplace/${name}")
> +|| die $!;
> +close($fh);
> +}
> +
>  if ( -f $path) {
>  install_dir("$sv_dir/$name");
>  install_prog($path, "$sv_dir/$name/run");
> @@ -182,6 +191,15 @@ version of package. See #923233.
>  If this option is not specified, it means that runscript was provided
>  all history of package.
>
> +=item I
> +
> +Mark service as non-restartible. Interpreter B, provided by
> +I package does not stop sysvinit-managed instance of service to
> +replace it with runit-managed instance when service is marked as
> +non-restartible.
> +
> +Display managers (xdm, kdm, ...) are examples of non-restartible services.
> +
>  =item I
>
>  If you don't need other options, specify this one.
> diff --git a/t/924903.t b/t/924903.t
> index 710ea39..b969314 100644
> --- a/t/924903.t
> +++ b/t/924903.t
> @@ -1,7 +1,7 @@
>  #!/usr/bin/perl
>  use strict;
>  use warnings;
> -use Test::More tests => 3;
> +use Test::More tests => 4;
>  use File::stat;
>  use T;
>
> @@ -11,3 +11,6 @@ ok(-d $path, 'supervise directory correctly created');
>  my $info = stat($path);
>  my $mode = sprintf("%o", $info->mode & 0777);
>  is($mode, '700', 'supervise directory have conservative permissions');
> +
> +my $noreplace = 

Bug#918764: udev: "udevadm control --reload-rules" kills all processes except init

[Lorenz]

Hi Felipe,

Felipe Sateler wrote:
> > > Upstream asks if cgroup is in v2-mode in the affected systems.

> With `findmnt -R /sys/fs/cgroup`. It should list controllers in the cgroup
> or cgroup2 filesystems.

root@lorenz:~# findmnt -R /sys/fs/cgroup
TARGET   SOURCE  FSTYPE  OPTIONS
/sys/fs/cgroup   tmpfs   tmpfs   rw,nosuid,nodev,noexec,mode=755
├─/sys/fs/cgroup/unified cgroup2 cgroup2
rw,nosuid,nodev,noexec,relatime,nsdelegate
└─/sys/fs/cgroup/elogind cgroup  cgroup
rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/elogind/elogind-cgroups-agent,name=elogind


Il giorno lun 4 feb 2019 alle ore 16:11 Gedalya  ha
scritto:

>
> > This currently looks like this now (after I have uninstalled
> > cgroupfs-mount):
> >
> > → findmnt -R /sys/fs/cgroup
> > TARGET   SOURCE  FSTYPE  OPTIONS
> > /sys/fs/cgroup   tmpfs   tmpfs   rw,nosuid,nodev,noexec,mode=755
> > ├─/sys/fs/cgroup/unified cgroup2 cgroup2
> rw,nosuid,nodev,noexec,relatime,nsdelegate
> > └─/sys/fs/cgroup/elogind cgroup  cgroup
> rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/elogind
> >
> > But I have to assume that these mount points where at least present
> > before I uninstalled cgroupfs-mount, too.
> >
> >   Regards, Axel
>
> I can say I've always had this issue with only cgroup2 mounted and no
> cgroup (what you might call "v1")
>
>
>

Bug#918764: udev: "udevadm control --reload-rules" kills all processes except init

[Lorenz]

Hi Felipe,
thanks for looking into this.
I've made a very quick test of the patch you provided this morning,
patching systemd 240-5 source
and rebuilding the whole thing.
It works for me.

Lorenz

Bug#918764: udev: "udevadm control --reload-rules" kills all processes except init

[Lorenz]

Hi,

Il giorno mer 30 gen 2019 alle ore 11:26 Axel Beckert  ha
scritto:

> >His "Actually I'm wrong on this" mail
> >(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918764#127) was
> >(and actually still is) confusing me.
>

I'm wrong on the claim that, for example, i can crash a VT session by
executing a 'udevadm' command from the graphic session, or vice versa.
To be more clear, when you read message #122 just ignore those lines:

> ..Final Bonus Weirdness:
> if you start udevd in background in the VT session, then go to the
graphic
> session and prompt a udevadm command from there, it's the VT session that
get crashed.

The rest of the message. i.e. how to trigger the bug and the commit that
introduces this bug in Debian's systemd still holds true to me.


> >But some of the details from his first mail which were not cited in
> >his "Actually I'm wrong on this" mail (mainly "This was introduced in
> >commit e803efca") tell me that this _is_ actually a bug in the udev
> >package.
>

That commit triggered the bug in Debian, but the bug itself was already in
the code
since at least systemd v232-15.
According to my experiments, the culprit is the following:

>when udevd is run in background and it's not detached with it's own
'--daemon' option,
>then a udevadm command is enough to kill everything.

It does not make any sense to me, but that's it.

Regards,
Lorenz

Bug#918764: udev: "udevadm control --reload-rules" kills all processes except init

[Lorenz]

> >when udevd is run in background and it's not detached  with it's own
> '--daemonize' option,
>
Sorry, udev option is '--daemon' , not --daemonize.

> ..Final Bonus Weirdness:
> if you start udevd in background in the VT session, then go to the
graphic
> session and prompt a udevadm command from there, it's the VT session that
get crashed.
Actually I'm wrong on this, it looks like switching from VT to Graphic
session (and vice versa)
with systemd trigger the restart of udev and this is enough to crash the
session, no need to
to prompt any 'udeadm' command in this case.

Regards,
Lorenz

Bug#918764: udev: "udevadm control --reload-rules" kills all processes except init

[Lorenz]

Hi,

I manage to reproduce this with systemd, in a Virtualbox VM.
here are the steps, after booting with systemd as init
* stop udev
   # systemctl stop systemd-udevd
   make sure there is no 'systemd-udevd' process list in pstree
* start udev in background like this
   # setsid --fork /lib/systemd/systemd-udevd
   OR like this
   # start-stop-daemon --start --name systemd-udevd --exec
/lib/systemd/systemd-udevd --background
   in any case make sure udedv is running
* try one of the following (wait few seconds after prompt)
   # udevadm trigger --type=subsystems action=add
   # udevadm trigger --type=devices action=add
   # udevadm settle

As a result all process belonging to you session are crashed and restarted;
if you are doing this in a VT you get kicked out and the screen is cleared;
if you are doing this in a graphical session you get the login screen of
your
display manager (I use slim + lxqt ).
This is a bit different from what happens when init is not systemd, in that
i belive systemd-logind is constraining the killing within the session ( or
the slice),
but ... Final Bonus Weirdness:
if you start udevd in background in the VT session, then go to the graphic
session and prompt a udevadm command from there, it's the VT session that
get crashed.

This was introduced in commit e803efca
https://salsa.debian.org/systemd-team/systemd/commit/e803efca59978aa5bb1d8806247f986d0c0f7e67

when udevd is run in background and it's not detached  with it's own
'--daemonize' option,
then a udevadm command is enough to kill everything.
The commits uses 'start-stop-daemon' with '--background' option, so it
triggered a bug that
was already in the code since who-knows-when.. i can reproduce this also
with another VM
(stretch) that has systemd 232-25.

Non-Systemd users can workaround this by using the init script from systemd
239-7

https://salsa.debian.org/systemd-team/systemd/blob/debian/239-7/debian/udev.init

or by editing the current init script replacing the --background option
with ' -- --daemonize".
(some other adjustments are nedded to the script)
Be aware that in both case this will reintroduce bug #791944

Dear Systemd Maintainers,
still you can't reproduce this? Can you please say something?

Lorenz






Il giorno gio 24 gen 2019 alle ore 08:36 Gedalya  ha
scritto:

> Hi,
>
> With the help of snapshot.d.o, I've found that the problem first appeared
> in 239-8.
>
> I've also been able to trigger it by restarting udev and running 'udevadm
> control --log-priority=debug'.
>
> Still no insight on what is the factor causing this to happen on some
> machines and not on others.
>
> Regards,
>
> Gedalya
>
>
>

Bug#918764: udev: "udevadm control --reload-rules" kills all processes except init

[Lorenz]

Hi Michael, Axel

I had a system crash yesterday, during an upgrade. Udev, Grub and mdadm
were
all involved in the upgrade. The system went down during the postinst
stage, leaving
some packages uncofigured.
Even if i can't reproduce running

udevadm control --reload-rules

I think it's the same problem.
Also, i had 2 similar crashes during an upgrade in October and December
2018. Looking at
apt logs i found that both udev and grub were involved in those upgrades.
I can reproduce the crash with the following

# dpkg -i -i udev_240-4_amd64.deb mdadm_4.1-1_amd64.deb
also this works as well (in crashing my system)
#dpkg -i udev_240-4_amd64.deb grub-pc_2.02+dfsg1-10_amd64.deb
while the both the following don't lead to a crash
# dpkg -i mdadm_4.1-1_amd64.deb grub-pc_2.02+dfsg1-10_amd64.deb
# dpkg -i udev_240-4_amd64.deb && dpkg -i grub-pc_2.02+dfsg1-10_amd64.deb


>Is this specific to version 240-2?
>Could you try downgrading udev to either 239-15 or 240-1 and report back
>with the results.

Downgraded udev down to udev-239-7, wich looks safe to me while udev 239-8
is affected; i'm currently with  239-8.

>Anyway, I'm taking Dmitry into Cc since sysvinit-core's init is the
>only process which survives this issue and hence might be involved.

i don't have sysvinit-core installed, init is runit.

>So I wonder what part of my setup causes this:
>
>* 2x LVM on LUKS on MD RAID1 (2 spinning HDDs and 2 SSDs)
>* an (internal) USB 3.0 SD card reader which lets LVM throw warnings
>  about "no medium found" for all devices from /dev/sde to /dev/sdk or so.
>* Three screens (1x HDMI, 1x DP, 1x DVI-D)
>* Logitech USB dongle with Solaar

I have
* runit as PID 1
* /home is on  RAID mirror
* mdadm is installed
* systemd is not installed
* kernel is 4.18.0-1-amd64

>I can't reproduce this problem.
>Neither with a 4.18 (4.18.20-2), 4.19 (4.19.12-1) or 4.20 (4.20-1~exp1)
>kernel. Tested both with systemd as PID 1 and inside a VM with sysvinit
>as PID 1.

That's not my enough, i suspect you need also one (or more than one) of
the following:
* no systemd installed
* mdadm installed
* a RAID setup (althought i'm not sure this one is feasible in virtualbox)

Anything else i can do to help solving this?
Thanks,
Lorenz






Il giorno mer 16 gen 2019 alle ore 15:49 Dmitry Bogatov 
ha scritto:

>
> [ More eyes is better, so please use sysvi...@packages.debian.org
>   instead personally me for sysvinit-related issues. I read list
>   carefully. ]
>
> [2019-01-15 16:17] Axel Beckert 
> > Anyway, I'm taking Dmitry into Cc since sysvinit-core's init is the
> > only process which survives this issue and hence might be involved.
> > (Dmitry: Please tell me if I should rather send this to the
> > mailing-list.)
> >
> > I will probably also check if an earlier sysvinit version, like e.g.
> > 2.88dsf-59.11 (as 2.88dsf-60 IIRC had some issues of its own), makes
> > the issue go away, just to be sure (like with udev 239-15).
>
> Yes, please compare with sysvinit-core=2.88dsf-59.9 (version from
> stable), but I doubt it have something to do with sysvinit, since the
> only way sysvinit interacts with udev is 'Should-Start: udev'
> dependency of some bin:initscripts.
>
>

Bug#912937: runit: Can't shutdown or reboot when using single user mode

[Lorenz]

On Thu, 20 Dec 2018 18:04:25 + Dmitry Bogatov 
wrote:
> ... What do you think about state of
> salsa:runit-team/runit, commit a8d698d? I am considering uploading it to
> unstable.

Wait, when I proposed you to move the start of sysv scripts to stage 2 I
completely
forgot about runit-sysv and runit-systemd! They also use stage 2,
so we need to make sure that `sulogin' and
`/lib/runit/async-timeout /lib/runit/run_sysv_scripts '/etc/rc2.d' '
are executed only when runit is init ( /run/runit.stopit exists )

Bug#912937: runit: Can't shutdown or reboot when using single user mode

[Lorenz]

On Thu, 20 Dec 2018 18:04:25 + Dmitry Bogatov 
wrote:



> ... What do you think about state of
> salsa:runit-team/runit, commit a8d698d? I am considering uploading it to
> unstable.
It should solve this bug, and also having a 90 sec timeout looks like a
final
solution to any misbehaving daemon :)
Unfortunately I haven't had the time to test it yet.

> > About changing runlevel, we can open a whishlist bug that
> > reference to this one, and keep it as a reminder.
>
> Would you be so kind to file this bug?

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

Thanks

Bug#912937: runit: Can't shutdown or reboot when using single user mode

[Lorenz]

Hi !
We are approaching the freeze, and I think that the state of runit about
'sulogin' is
acceptable but not optimal: there are two minor issues unresolved

[2018-11-09 01:09] alecfeld...@disroot.org

> Glancing over the changes, changing the runsvdir is a bad idea, since
> now stage 3 won't stop t he correct services.

* sulogin will not be stopped correctly on stage 3

* sulogin print a message that says
  ' press Control+-D to continue or give root password for maintenance'
   Now if I press Control+D i would expect the boot process to continue, but
   what i get is only a restart of sulogin

[2018-11-13 16:28] alecfeld...@disroot.org

> It is quite strange how debian uses /etc/service to store currently
> active services. Other distributions use /run/runit or /var/service,
> though /run makes more sense. Perhaps /etc/service could be moved
> somewhere else? This would solve the issue with etc being read-only.

Probably. But such changes with large disruptive potential I'd prefer
to make after release.

Since a changing runlevel mechanism is not coming before the freeze,
why start sulogin as a supervised process with runsvdir?
I'm thinking of a stage 2 that does:
* a plain 'sulogin' (followed by)
* code to start sysv services in rc2 (without checking for 'single')

or, if managing sulogin is really needed, start a runsv process
' runsv /etc/runit/runsvdir/single/sulogin'
that self destroy in finish file ( 'sv e
/etc/runit/runsvdir/single/sulogin').

This way an admin can choose to reboot in sulogin shell or type Control-D
or just exit the shell to continue with the boot.
About changing runlevel, we can open a whishlist bug that
reference to this one, and keep it as a reminder.

Bug#915261: SysV init regression thanks to broken "container detection" logic

[Lorenz]

I confirm the bug. This prevent me to start/restart udev, and i'm not in a
container.

On Sun, 2 Dec 2018 09:00:07 + Jamie Heilman 
wrote:
> The logic change in the init script to check for a writable /sys is
> backwards; udev *should* start if /sys if writable.

I don't have experience with container, so can't tell if the logic is
backwards,
it looks to me that /sys directory is read/execute only in my Debian, but
'test -w' performed by root exit 0..

# cat /home/ombra/udevtest.txt
Script started on 2018-12-02 14:36:45+01:00
root@lorenz:~# ls -l / | grep sys
dr-xr-xr-x  12 root root 0 Dec  2 14:20 sys
root@lorenz:~# test -w /sys
root@lorenz:~# echo $?
0
root@lorenz:~# exit
exit

Script done on 2018-12-02 14:37:37+01:00

I suspect this is breaking the boot sequence in non-systemd installs,
can you please revert to using "ps" for this test untill you sort it out?

Thanks,
Lorenzo

Bug#913832: lists.debian.org: New mailing list: debian-runit

[Lorenz]

On Thu, 15 Nov 2018 20:31:21 +0100
> On Thu, 15 Nov 2018, Dmitry Bogatov wrote:
>>...
> > Please create new mailing list.
>> 
> >  Currently I do maintain runit init system and related tools {dh-runit
> >  and *-run packages} myself, but as contributors appear, there is need
> >  in coordinating efforts and team maintainance.

Alexander Wirt  wrote:
> In my eyes this list is far too special for lists.debian.org.

Hi Alexander,
as a runit user and contributor I support Dmitry request for a dedicated
mailing list.
Currently available way to contribute to runit are
   * Open a bug/whishlist, possibly providing a patch
   * Contact the maintainer privately with mail (1 to 1 comunication)
   * pull request on salsa
Contributions are scattered across these three, sometimes a mix happens,
and it's difficult to have a clear idea of what's going on.
See bug #912937, an example of mixed public/private comunication,
with the chat going offtopic towards runit's overall state in Debian.

A dedicated mailing list can help avoid duplication and maybe gather
some new contributors. There is not a huge list of topics to discuss,
but all are relevant/low level stuff like
 * How (when/if) to integrate runit with 'init-system-helpers'
 * maybe discuss a template for runscripts
 * if and how introduce runlevel support
 * how to handle emergency shell
Those things can easily break a system and one wants to avoid
"try --> error --> retry" routine, some discussion before may help.

Finally, for packages like *-run scripts, there will be (hopefully) more
than one contributor,
could be handy to have a runit mailing list to set as maintainer with
contributors as uploaders..
Hope you can change your mind

Best Regards,
Lorenzo

Bug#911949: [polymake] FTBFS with boost1.67

[Benjamin Lorenz]

Hi,

thanks for the report! We already have a patch included in polymake
3.2r3 and 3.2r4 that fixes the build error and keeps compatibility with
older boost versions. (And also added another change there to avoid a
depreciation warning for math::lcm)

I have tried updating the package here:
https://salsa.debian.org/bremner/polymake/merge_requests/2

Best,
Benjamin



signature.asc
Description: OpenPGP digital signature

Bug#912174: polymake FTBFS: test failure

[Benjamin Lorenz]

Hi,

this comes from a different output order produced by cdd version 0.94j
(probably caused by https://github.com/cddlib/cddlib/pull/10 ).

We have disabled this test in polymake 3.2r4. I have tried updating the
package and created a pull request here:
https://salsa.debian.org/bremner/polymake/merge_requests/2

Best,
Benjamin



signature.asc
Description: OpenPGP digital signature

Bug#909192: mate-desktop-environment: Installing sysvinit-core removes mate-desktop-environment

[Lorenz]

On Thu, 20 Sep 2018 18:44:16 + Mike Gabriel <
mike.gabr...@das-netzwerkteam.de> wrote:
> Hi Ian,
>
> On  Do 20 Sep 2018 16:45:41 CEST, Ian Jackson wrote:
>
> > Mike Gabriel writes ("Re: Bug#909192: mate-desktop-environment:
> > Installing sysvinit-core removes mate-desktop-environment"):
> >> many thanks for all this background info. I might have a potential
> >> contract to get this solved in the loop, so, I may probably return to
> >> it soon (or not so soon). Let's see...
> >
> > Can you let us know when you will know whether this is going to
> > transpire ?
>
> This is not going to be a paid project, unfortunately, as I hoped.
>
> > Also, we had an IRC conversation on #debian-devel about pam_systemd
> > and the dbus user service.  I think it contains a lot of useful
> > information particularly from smcv.  See below.
> >
> > This is a transcript of #debian-devel manually edited to remove other
> > conversations, and also to remove unconstructive comments (of which
> > unfortunately there were some).
>
> Thanks for the transcript.
>
> I'll have this on my radar as an RC-like bug on the MATE side and take
> a look later in October / November (when back from VAC). If noone else
> has addressed it by then.
>
> Mike
> --
>
> DAS-NETZWERKTEAM
> mike gabriel, herweg 7, 24357 fleckeby
> mobile: +49 (1520) 1976 148
> landline: +49 (4354) 8390 139
>
> GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
> mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de
>

Hi,
i think this

> mate-desktop-environment -> mate-desktop-environment-core ->
> dconf-settings-backend -> dconf-service -> default-dbus-session-bus
> -> dbus-user-session -> systemd

is not what is pulling in systemd as init; in fact the chain could be also

mate-desktop-environment -> mate-desktop-environment-core ->
dconf-settings-backend -> dconf-service -> default-dbus-session-bus ->
dbus-x11 and dbus-x11

and dbus-x11 does not require systemd nor pam-systemd
see here  https://packages.debian.org/sid/dconf-service

Please look at the list of packages from the bug reporter that apt wants to
remove:

>The following packages will be REMOVED:
>  caja colord dbus-user-session gvfs gvfs-backends gvfs-daemons kcalc kgamma5 
> kio libkf5auth5 libkf5configwidgets5 libkf5iconthemes-bin libkf5iconthemes5 
> libkf5kiocore5 libkf5kiowidgets5
>  libkf5notifyconfig5 libkf5textwidgets5 libkf5wallet-bin libkf5xmlgui5 
> libpam-systemd libpolkit-qt5-1-1 lightdm mate-applet-brisk-menu mate-applets 
> mate-control-center
>  mate-desktop-environment mate-desktop-environment-core mate-panel 
> mate-polkit mate-power-manager mate-settings-daemon network-manager 
> network-manager-fortisslvpn
>  network-manager-fortisslvpn-gnome network-manager-gnome network-manager-l2tp 
> network-manager-l2tp-gnome policykit-1 quassel-client rtkit synaptic 
> systemd-sysv task-mate-desktop udisks2

the chain wich is pulling in systemd as init is the fact that the shim is
rc-buggy combined with
consolekit being removed from archives, and that leave no other options to
polkit that depend on systemd as init.
This makes this bug not Mate-specific, as every DE that has a polkit
authentication agent will soon have the same problem.

The only thing that could be asked to the Mate Team, once (if?) elogind
gets packaged for Debian, is to turn the
mate-power-manager dependency from
' systemd | consolkit'
into
'systemd| libpam-elogind | consolkit '

Best Regards,
Lorenzo

Bug#881506: xul-ext-gnome-keyring doesn't work with firefox >=57

[Lorenz]

On Fri, 28 Sep 2018 21:18:54 +0200 Moritz Mühlenhoff wrote:

On Wed, Sep 26, 2018 at 02:27:00AM +, Ximin Luo wrote:
> Pretty sure it doesn't work with TB60, I just upgraded myself and am no 
longer using this extension.
Shall we remove it from the archive?


I can confirm that upstream version 0.13 does work with Thunderbird 60, 
see also https://github.com/swick/mozilla-gnome-keyring/pull/56.


Please consider updating the package instead of removing it.

Cheers,
Lorenz

Bug#872468: bug persists with version 1.184

[Lorenz Hübschle-Schneider]

Hello,

this bug still exists in console-setup version 1.184.

It also makes 'update-initramfs' very noisy, as 'setupcon --save-keyboard 
$destination' prints the same 976 lines for each installed kernel version.

Cheers,
Lorenz

Bug#898335: linux-image-4.16.0-1-amd64: Boot hangs for quite some time. Black screen. Cursor only.

[Tobias Lorenz]

Dear Maintainer,

the issue is gone since some days.

In the last days there were several updates in testing that might have 
delivered the 
fix, e.g. mount, util-linux, mdadm, plymouth. I haven't further analysed it.

works for me ;-)

Originally I intended to post this issue as addition for #898098. I guess this 
issue can 
be closed as well.

Bye
Tobias

Bug#898335: linux-image-4.16.0-1-amd64: Boot hangs for quite some time. Black screen. Cursor only.

[Tobias Lorenz]

Package: src:linux
Version: 4.16.5-1
Severity: important

Dear Maintainer,

I have the same issue on my ThinkPad X220.

After grub, the linux-image-4.16.0-1-amd64 is loading and remains in a state
with black screen and blinking cursor only. After about 2 minutes the boot
continues with the plymouth screen coming up and the prompt asking for the
harddisk password.

When I select linux-image-4.15.0-3-amd64 the boot runs normal.

Bye
Tobias



-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: LENOVO
product_name: 4286CTO
product_version: ThinkPad X220
chassis_vendor: LENOVO
chassis_version: Not Available
bios_vendor: LENOVO
bios_version: 8DET66WW (1.36 )
board_vendor: LENOVO
board_name: 4286CTO
board_version: Not Available

** Network interface configuration:

auto lo
iface lo inet loopback

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core Processor 
Family DRAM Controller [8086:0104] (rev 09)
Subsystem: Lenovo 2nd Generation Core Processor Family DRAM Controller 
[17aa:21da]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 

00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core 
Processor Family Integrated Graphics Controller [8086:0126] (rev 09) (prog-if 
00 [VGA controller])
Subsystem: Lenovo 2nd Generation Core Processor Family Integrated 
Graphics Controller [17aa:21da]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- 
SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0
ExtTag- RBE+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- 
Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ 
TransPend-
LnkCap: Port #1, Speed 5GT/s, Width x1, ASPM L0s L1, Exit 
Latency L0s <1us, L1 <16us
ClockPM- Surprise- LLActRep+ BwNot- ASPMOptComp-
LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ 
DLActive- BWMgmt- ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- 
Surprise-
Slot #0, PowerLimit 10.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- 
LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- 
Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- 
Interlock-
Changed: MRL- PresDet- LinkState-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- 
CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID , PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range BC, TimeoutDis+, LTR-, OBFF 
Not Supported ARIFwd-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, 
OBFF Disabled ARIFwd-
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
 Transmit Margin: Normal Operating Range, 
EnterModifiedCompliance- ComplianceSOS-
 Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB, 
EqualizationComplete-, EqualizationPhase1-
 EqualizationPhase2-, EqualizationPhase3-, 
LinkEqualizationRequest-
Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
Address:   Data: 
Capabilities: [90] Subsystem: Lenovo 6 Series/C200 Series Chipset 
Family PCI Express Root Port 1 [17aa:21da]
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: pcieport
Kernel modules: shpchp

00:1c.1 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset 
Family PCI Express Root Port 2 [8086:1c12] (rev b4) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
   

Bug#887155: swi-prolog FTBFS on armel/armhf/mipsel: Not enough resources: no_memory

[Benjamin Lorenz]

Dear Lev,

It seems a fix for this bug was merged into the upstream stable
repository some time ago:
https://github.com/SWI-Prolog/swipl/commit/3923765d56e5

I have an unstable i386 VM where I could reproduce these memory errors
and adding this to the patches resolves it.

Since there is still no new upstream release and to avoid the
autoremoval of this (+ a few downstream packages [1]), could you try to
create a new debian release for 7.6.4 with this patch and the one for
#893421.

With these two patches the package was successfully built with java 9 on
the VM where I previously had these memory errors.

Best,
Benjamin

[1] I'm a developer for polymake which would also be affected by the
removal since it depends on ppl which in depends on swipl.

Bug#895224: pdfpc movie playback with gstreamer 1.14.0

[Lorenz Hübschle-Schneider]

Thanks! I'm not very familiar with Debian policy, so I can't really comment on 
what kind of a dependency it should be. But it does seem inconsistent to have a 
"Depends: libgstreamer1.0-0 "but "Recommends: gstreamer1.0-gtk3", given that 
both are required to play video.

Bug#895224: pdfpc movie playback with gstreamer 1.14.0

[Lorenz Hübschle-Schneider]

Do you have the package gstreamer1.0-gtk3 installed? This fixes movie playback 
for me. It seems like pdfpc should at least have a 'Recommends' dependency on 
it.

You can increase the verbosity of gstreamer in pdfpc by setting the GST_DEBUG 
environment variable to, e.g., 4.

Cheers,
Lorenz

Bug#893421: swi-prolog FTBFS with openjdk-9

[Benjamin Lorenz]

The configure script of the swi-prolog jpl package only checks whether
lib/$arch/server or jre/lib/$arch/server exists but the $arch
subdirectory was removed in openjdk9. Because of the failed check the
LDFLAGS are missing the correct directories for libjava.so and related
libraries.
I have created a pull request to for this:
https://github.com/SWI-Prolog/packages-jpl/pull/8

I have tried this on i386 and the package now compiles but make check
then fails with the same errors as in #887155.

Regards,
Benjamin Lorenz

Bug#892982: bugs.debian.org: system freeze after lock screen/switched off moniturs/spontaneously

[Hermann Lorenz]

Package: bugs.debian.org
Severity: important
Tags: upstream

Dear Maintainers,

because the kernel logs show clock errors for amdgpu and segfaults in the gnome
shell, I'm not sure which package I have to refer to.  Please feel free to ask
for other log files or hardware configurations that might be of interest to
you.


First Scenario
==

I observed several freezes of my system in October/November.  They occured,
when
 * the screen was locked or
 * when the monitors were switched off.
The screen froze not every time, but in the majority of the times I did this.
Over the last months I "solved" this issue by not locking the screen or turning
off the monitors while the system was running.  During this time I did not
observe any freezes like this.  Yesterday I switched off the monitors and when
I returned, I observed a freezing of the system again.

The follwing actions did not seem to have any effect:

 * on mouse movement, the cursor does not move
 * Ctrl+Shift+F3 doesn't switch to a terminal
 * Ctrl+Shift+Del holding for 10+ seconds does not reboot.

I missed to do press Alt+Print+K, next time I will test this too.

The only solution to recover is to press the power button on the tower for
several seconds and to reboot the system.


Here a short excerpt from /var/log/kern.log from yesterday:

Mar 14 10:19:24 mundus kernel: [ 5483.172863]
[drm:amdgpu_atombios_dp_link_train [amdgpu]] *ERROR* clock recovery tried 5
times
Mar 14 10:19:24 mundus kernel: [ 5483.172879]
[drm:amdgpu_atombios_dp_link_train [amdgpu]] *ERROR* clock recovery failed
Mar 14 12:44:50 mundus kernel: [14209.555905] gnome-shell[1254]: segfault
at 38 ip 7ff9ec3f8f70 sp 7ffe1cf6aaf8 error 4 in
libmutter-1.so.0.0.0[7ff9ec398000+15]
Mar 14 12:44:51 mundus kernel: [14209.583537] rfkill: input handler enabled
Mar 14 12:44:51 mundus kernel: [14209.755875]
[drm:amdgpu_atombios_dp_link_train [amdgpu]] *ERROR* displayport link status
failed
Mar 14 12:44:51 mundus kernel: [14209.755896]
[drm:amdgpu_atombios_dp_link_train [amdgpu]] *ERROR* clock recovery failed
Mar 14 12:44:51 mundus kernel: [14209.932953]
[drm:amdgpu_atombios_dp_link_train [amdgpu]] *ERROR* displayport link status
failed
Mar 14 12:44:51 mundus kernel: [14209.932973]
[drm:amdgpu_atombios_dp_link_train [amdgpu]] *ERROR* clock recovery failed
Mar 14 12:44:51 mundus kernel: [14210.120708]
[drm:amdgpu_atombios_dp_link_train [amdgpu]] *ERROR* displayport link status
failed
Mar 14 12:44:51 mundus kernel: [14210.120728]
[drm:amdgpu_atombios_dp_link_train [amdgpu]] *ERROR* clock recovery failed
Mar 14 12:44:51 mundus kernel: [14210.297755]
[drm:amdgpu_atombios_dp_link_train [amdgpu]] *ERROR* displayport link status
failed
Mar 14 12:44:51 mundus kernel: [14210.297774]
[drm:amdgpu_atombios_dp_link_train [amdgpu]] *ERROR* clock recovery failed
Mar 14 12:53:19 mundus kernel: [14718.348671] rfkill: input handler
disabled
Mar 14 13:43:18 mundus kernel: [17716.735394] gnome-shell[14938]: segfault
at 55ba0af83c18 ip 7fb6aebe2676 sp 7ffda3cf9020 error 4 in
libst-1.0.so[7fb6aebc2000+4d000]
Mar 14 13:43:18 mundus kernel: [17716.783243] rfkill: input handler enabled
Mar 14 13:43:25 mundus kernel: [17723.744111] rfkill: input handler
disabled




Second Scenario
===

Because in this second scenario the behaviour is different, I was not sure if
it is relevant to you.  But since it also results in a reset of the user
session, I wanted to mention it.

The screen freezes during normal usage at random.  This happens every two or
three days.  After let's say 30 seconds the log in screen is shown and a new
session is started.  This also occured during the phase when I did not lock the
screen.

Again a short excerpt from /var/log/kern.log regarding the second scenario:

Mar 15 05:35:32 mundus kernel: [ 2026.148912] show_signal_msg: 17 callbacks
suppressed
Mar 15 05:35:32 mundus kernel: [ 2026.148914] gnome-shell[1257]: segfault
at 562055805a68 ip 7fbae1b7b676 sp 7fff83108b90 error 4 in
libst-1.0.so[7fbae1b5b000+4d000]
Mar 15 05:35:32 mundus kernel: [ 2026.195608] rfkill: input handler enabled
Mar 15 05:35:39 mundus kernel: [ 2033.100377] rfkill: input handler
disabled

In this specific case I was moving a window via Super+Shift+Left from one
monitor to another when the GUI crashed.  After logging in I was able to use
the system as normal.



Kind Regards
  Hermann



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

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

Bug#886494: polymake: Can't locate loadable object for module Polymake::Ext in @INC

[Benjamin Lorenz]

On 01/06/2018 08:08 PM, Niko Tyni wrote:
> Running polymake currently fails with
>
>   $ polymake
>   Can't locate loadable object for module Polymake::Ext in @INC
>
> Apparently this is because it was built with Perl 5.26.0, but
> we've since moved to 5.26.1.
>
> I see two better alternatives:
>
> 1) [preferrable] fix polymake not to install its extensions in a
>   versioned directory (currently /usr/lib/polymake/perlx/5.26.0).

This would work for minor updates (5.26.0 -> 5.26.1 seems to work) but
the extension does depend heavily on the major version, so I dont think
this is a good idea.

> I note that the confusing @INC list above (it has
> /usr/lib/polymake/perlx/5.26.0 so it looks like it should work) is
> because "use lib" will add versioned subdirectories to @INC if it
> finds any, but will apparently *not* add arch-specific subdirectories
> (like /usr/lib/polymake/perlx/5.26.0/x86_64-linux-gnu-thread-multi)
> under those, and that's what would be needed here. I'm not quite sure
> if this is a glitch in lib.pm's handling of binary-compatible versions
> ($Config{inc_version_list}).

This is a good point, it looks like the Config.pm contains:
inc_version_list => '5.26.0',

but the perl INSTALL file states:

> If you do want to use modules from some previous perl versions, the
> variable must contain a space separated list of directories under the
> site_perl directory, and has to include architecture-dependent
> directories separately, eg.
>
>   sh Configure -Dinc_version_list="5.16.0/x86_64-linux 5.16.0" ...

It seems the perl Configure script tries to generate this list
automatically (probably from $sitelib=/usr/local/share/perl/5.26.1) but
failed to pick up the arch-specific directory because it might not exist?

I dont have such an installation at hand but this could be tested by
adding the arch-specific path for inc_version_list in
'/usr/lib/x86_64-linux-gnu/perl/5.26.1/Config.pm' manually first. If
this helps, the Configure command for perl should probably get an extra
-Dinc_version_list=.

Best,
Benjamin



signature.asc
Description: OpenPGP digital signature

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

[Lorenz Minder]

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

Dear Maintainer,

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

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

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

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

I don't know a workaround for this problem.

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

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

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

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

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

-- no debconf information

Bug#881667: [pkg-lxqt-devel] Bug#881667: lxqt-qtplugin: Directory Menu plugin fail to open any directory

[Lorenz]

>And why should this be a bug in lxqt-qtplugin?
Feel free to reassign if you know which package is responsible for this; I
have a problem with a plugin in lxqt-panel, but that package hasn't been
upgraded, so i searched the apt logs and found out that the only lxqt
package that has been upgraded is lxqt-qtplugins, that's why i choose this
one.

About mixing Sid and experimental:
> 2) take all things from sid - should work just fine
it's not working in Sid and when i start reportbug for filing a bug it
says: "there is a new version of this package in experimental" so i decided
to try that version before filing the bug..






2017-11-14 0:12 GMT+01:00 Alf Gaida :

> And why should this be a bug in lxqt-qtplugin?
>
> On 13.11.2017 23:42, Lorenzo Puliti wrote:
> > Package: lxqt-qtplugin
> > Version: 0.12.0-2
> > Severity: normal
> >
> > Dear Maintainer,
> >
> >* What led up to the situation?
> > Since the last upgrade of my system, the "Directory Menu" Plugin is not
> >  working anymore: clikking on any directory or subdirectory showed by
> > the plugin simply does nothing.
> > Before the upgrade cliccking on a directory in the plugin result in
> konqueror
> > opening that directory (konqueror is my default file manager).
> > The upgrade involve lxqt-qtplugin (0.11.1-2+b1 --> 0.11.1-2+b2 ) and
> other
> >  qt libs.
> >* What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> > I try to run a lxqt-panel from a terminal and got this error while using
> the
> > Directory Menu Plugin:
> >
> > /usr/bin/xdg-open: 912: /usr/bin/xdg-open: pcmanfm: not found
> >
> > and find out that now the plugin need pcmanfm (none of pcmanfm-qt,
> konqueror
> > or dolphin works) installed to work.
> > I also try to upgrade to the experimental new version but still need
> pcmanfm
> > installed.
> > For now as a workaround i'm keeping pcmanfm but its not good
> > to have to install a FM only to get a plugin to work..
> > Can we go back to when the plugin was working with different file
> managers?
> >
> > Thank You
> > Lorenzo
> >
> >
> > -- System Information:
> > Debian Release: buster/sid
> >   APT prefers unstable
> >   APT policy: (500, 'unstable'), (1, 'experimental')
> > Architecture: amd64 (x86_64)
> >
> > Kernel: Linux 4.8.12-van (SMP w/4 CPU cores; PREEMPT)
> > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US:en (charmap=UTF-8)
> > Shell: /bin/sh linked to /bin/dash
> > Init: unable to detect
> >
> > Versions of packages lxqt-qtplugin depends on:
> > ii  libc62.24-17
> > ii  libdbusmenu-qt5-20.9.3+16.04.20160218-1
> > ii  libfm-qt30.12.0-11
> > ii  libglib2.0-0 2.54.2-1
> > ii  libqt5core5a [qtbase-abi-5-9-2]  5.9.2+dfsg-4
> > ii  libqt5dbus5  5.9.2+dfsg-4
> > ii  libqt5gui5   5.9.2+dfsg-4
> > ii  libqt5widgets5   5.9.2+dfsg-4
> > ii  libqt5xdgiconloader3 3.1.0-2
> > ii  libstdc++6   7.2.0-11
> >
> > Versions of packages lxqt-qtplugin recommends:
> > ii  lxqt-config   0.11.1-4
> > ii  lxqt-session  0.11.1-6
> >
> > Versions of packages lxqt-qtplugin suggests:
> > pn  lxqt | lxqt-core  
> >
> > -- no debconf information
> >
> > ___
> > pkg-lxqt-devel mailing list
> > pkg-lxqt-de...@lists.alioth.debian.org
> > https://lists.alioth.debian.org/mailman/listinfo/pkg-lxqt-devel
>
>

Bug#874759: (no subject)

[Lorenz Schori]

First patch rewrites the URLs and updates debian/watch, second one
replaces the libxml dependency with expat.
https://libvips.blogspot.ch/2016/09/whats-new-in-84.htmlFrom f48c214aa77cf64adffc71ee81ecee07a3d4475c Mon Sep 17 00:00:00 2001
From: Lorenz Schori <l...@znerol.ch>
Date: Sat, 9 Sep 2017 16:09:13 +0200
Subject: [PATCH 1/2] Rewrite URLs to github project

---
 README.Debian | 4 ++--
 control   | 2 +-
 copyright | 2 +-
 watch | 3 ++-
 4 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/README.Debian b/README.Debian
index ebfda4a..d6a6388 100644
--- a/README.Debian
+++ b/README.Debian
@@ -2,10 +2,10 @@
 Examples
 
 
-A number of vips examples are available.  Please see the "Supported"
+A number of vips examples are available.  Please see the "Documentation"
 section of the vips website:
 
-http://www.vips.ecs.soton.ac.uk/
+https://jcupitt.github.io/libvips/
 
 General Notes
 =
diff --git a/control b/control
index f02c47b..8b8d05f 100644
--- a/control
+++ b/control
@@ -16,7 +16,7 @@ Build-Depends: cdbs (>= 0.4.93~), debhelper (>> 9~), dh-autoreconf,
 XS-Python-Version: all
 Maintainer: Laszlo Boszormenyi (GCS) <g...@debian.org>
 Standards-Version: 3.9.8
-Homepage: http://www.vips.ecs.soton.ac.uk
+Homepage: https://jcupitt.github.io/libvips/
 
 Package: libvips42
 Section: libs
diff --git a/copyright b/copyright
index 99e1322..d6b8270 100644
--- a/copyright
+++ b/copyright
@@ -3,7 +3,7 @@ October 2, 2004.
 It was taken over by Laszlo Boszormenyi (GCS) <g...@debian.org> on March 19,
 2015.
 
-It was downloaded from http://www.vips.ecs.soton.ac.uk
+It was downloaded from https://jcupitt.github.io/libvips/
 
 Upstream Maintainers:
   John Cupitt <jcup...@gmail.com>
diff --git a/watch b/watch
index c8a0e23..c7826d3 100644
--- a/watch
+++ b/watch
@@ -1,2 +1,3 @@
 version=3
-http://www.vips.ecs.soton.ac.uk/supported/current/vips-([\d\.]+).tar.gz
+opts=filenamemangle=s/.+\/v?(\d\S+)\.tar\.gz/-$1\.tar\.gz/ \
+  https://github.com/jcupitt/libvips/tags .*/v?(\d\S+)\.tar\.gz
-- 
2.11.0

From 27cf785f0b612664989e759cc70b2dfeba533493 Mon Sep 17 00:00:00 2001
From: Lorenz Schori <l...@znerol.ch>
Date: Sat, 9 Sep 2017 16:27:47 +0200
Subject: [PATCH 2/2] 8.5: Switch from libxml2 to libexpat1

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

diff --git a/control b/control
index 8b8d05f..1dbcfda 100644
--- a/control
+++ b/control
@@ -10,7 +10,7 @@ Build-Depends: cdbs (>= 0.4.93~), debhelper (>> 9~), dh-autoreconf,
  libglib2.0-dev, libice-dev, gettext, pkg-config, libxml-parser-perl,
  libexif-gtk-dev,
  python-all-dev, python-dev (>= 2.6.6-3~), python-gi-dev (>= 3.12),
- liborc-0.4-dev, libopenexr-dev (>= 1.6.1-8.1), libmatio-dev, libxml2-dev,
+ liborc-0.4-dev, libopenexr-dev (>= 1.6.1-8.1), libmatio-dev, libexpat1-dev,
  libcfitsio-dev, libopenslide-dev, libwebp-dev, libgsf-1-dev,
  libgirepository1.0-dev, gtk-doc-tools (>= 1.14)
 XS-Python-Version: all
@@ -44,7 +44,7 @@ Description: image processing system good for very large ones
 Package: libvips-dev
 Section: libdevel
 Architecture: any
-Depends: ${misc:Depends}, libvips42 (= ${binary:Version}), libjpeg-dev, libtiff-dev, zlib1g-dev, fftw3-dev | libfftw3-dev, liblcms2-dev, libpng-dev, libmagickcore-dev, libmagickwand-dev, libfreetype6-dev, libpango1.0-dev, libfontconfig1-dev, libglib2.0-dev, libice-dev, gettext, pkg-config, libexif-gtk-dev, python-all-dev, python-dev (>= 2.6.6-3~), liborc-0.4-dev, libopenexr-dev, libmatio-dev, libxml2-dev, libcfitsio-dev, libopenslide-dev, libwebp-dev, libgsf-1-dev, libgif-dev (>= 5.1), libpoppler-glib-dev, librsvg2-dev
+Depends: ${misc:Depends}, libvips42 (= ${binary:Version}), libjpeg-dev, libtiff-dev, zlib1g-dev, fftw3-dev | libfftw3-dev, liblcms2-dev, libpng-dev, libmagickcore-dev, libmagickwand-dev, libfreetype6-dev, libpango1.0-dev, libfontconfig1-dev, libglib2.0-dev, libice-dev, gettext, pkg-config, libexif-gtk-dev, python-all-dev, python-dev (>= 2.6.6-3~), liborc-0.4-dev, libopenexr-dev, libmatio-dev, libexpat1-dev, libcfitsio-dev, libopenslide-dev, libwebp-dev, libgsf-1-dev, libgif-dev (>= 5.1), libpoppler-glib-dev, librsvg2-dev
 Recommends: libvips-doc, libvips-tools
 Suggests: nip2
 Description: image processing system good for very large ones (dev)
-- 
2.11.0

Bug#874759: vips: New release 8.5 available, project relocated to github

[Lorenz Schori]

Source: vips
Severity: normal

Dear Maintainer,

A new major version (8.5) is available on the relocated project page:
https://jcupitt.github.io/libvips/

Regrettably the old wiki/website neither mentions the new release nor
redirects users to the new site. That also applies to the old release
directory where debian/watch is pointing to.

Note that there are new Python bindings as well using cffi:
https://github.com/jcupitt/pyvips

-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable')

Bug#872536: suckless-tools: dmenu fails to capture the keyboard from wayland windows

[Lorenz Hübschle-Schneider]

Thank you Ilias. It does seem like using an alternative implementation
on (X)Wayland is best for now. It's unfortunate that supporting Wayland
seems to be quite a lot of work. Due to a bunch of other
incompatibilities I disabled Wayland on my systems for now. Should I
leave this issue open for others or would you rather close it?

Cheers,
Lorenz

Bug#872536: suckless-tools: dmenu fails to capture the keyboard from wayland windows

[Lorenz Hübschle-Schneider]

Package: suckless-tools
Version: 43-1
Severity: important

Dear Maintainer,

since gnome-session 3.24.1-2 was uploaded to testing, Gnome uses wayland by
default. However, dmenu fails to capture the keyboard when a wayland window
(e.g. gnome-terminal) is in the foreground. It works fine when an X11
(Xwayland) window (e.g. chromium) is active. Are there any plans to support
wayland?

Cheers,
Lorenz



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

Kernel: Linux 4.12.0-1-amd64 (SMP w/8 CPU cores)
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/dash
Init: systemd (via /run/systemd/system)

Versions of packages suckless-tools depends on:
ii  libc6   2.24-14
ii  libcap2-bin 1:2.25-1
ii  libfontconfig1  2.12.3-0.2
ii  libpam0g1.1.8-3.6
ii  libx11-62:1.6.4-3
ii  libxft2 2.3.2-1+b2
ii  libxinerama12:1.1.3-1+b3
ii  libxrandr2  2:1.5.1-1
ii  libxss1 1:1.2.2-1+b2

suckless-tools recommends no packages.

Versions of packages suckless-tools suggests:
pn  dwm 
pn  stterm  
pn  surf

-- no debconf information

Bug#861307: sympa: when using cookie spam_protection, user is not redirected to their originally requested page

[Sabine Lorenz]

Package: sympa
Version: 6.1.23~dfsg-2+deb8u1
Severity: normal

Dear Maintainer,

when directly loading the URL of an email in the archive the user is requested 
to click the button "I am not a spammer" and after doing that the user is 
redirected to the main archiv page of the list instead of the originally 
requested page.

-- System Information:
Debian Release: 8.7
Architecture: amd64 (x86_64)

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

Versions of packages sympa depends on:
ii  adduser3.113+nmu3
ii  ca-certificates20141019+deb8u2
ii  dbconfig-common1.8.47+nmu3+deb8u1
ii  debconf [debconf-2.0]  1.5.56
ii  exim4-daemon-light [mail-transport-agent]  4.84.2-2+deb8u3
ii  libarchive-zip-perl1.39-1
ii  libc6  2.19-18+deb8u7
ii  libcgi-fast-perl   1:2.04-1
ii  libcgi-pm-perl 4.09-1
ii  libdbd-mysql-perl  4.028-2+deb8u2
ii  libdbd-pg-perl 3.4.2-1
ii  libdbd-sqlite3-perl1.44-1
ii  libdbd-sybase-perl 1.14-1+b2
ii  libdbi-perl1.631-3+b1
ii  libfcgi-perl   0.77-1+deb8u1
ii  libfile-copy-recursive-perl0.38-1
ii  libhtml-format-perl2.11-1
ii  libhtml-stripscripts-parser-perl   1.03-1
ii  libhtml-tree-perl  5.03-1
ii  libintl-perl   1.23-1+deb8u1
ii  libio-stringy-perl 2.110-5
ii  libmailtools-perl  2.13-1
ii  libmime-charset-perl   1.011.1-1+deb8u2
ii  libmime-encwords-perl  1.014.3-1+deb8u1
ii  libmime-lite-html-perl 1.24-1
ii  libmime-tools-perl 5.505-1
ii  libmsgcat-perl 1.03-6+b1
ii  libnet-ldap-perl   1:0.6400+dfsg-2
ii  libnet-netmask-perl1.9021-1
ii  libregexp-common-perl  2013031301-1
ii  libsoap-lite-perl  1.11-1
ii  libtemplate-perl   2.24-1.2+b1
ii  libterm-progressbar-perl   2.16-1
ii  libunicode-linebreak-perl  0.0.20140601-2+deb8u2
ii  libxml-libxml-perl 2.0116+dfsg-1+deb8u1
ii  lsb-base   4.1+Debian13+nmu1
ii  mhonarc2.6.19-1
ii  perl   5.20.2-3+deb8u6
ii  perl-modules   5.20.2-3+deb8u6
ii  rsyslog [system-log-daemon]8.4.2-1+deb8u2
ii  sqlite33.8.7.1-1+deb8u2

Versions of packages sympa recommends:
ii  apache2-suexec2.4.10-10+deb8u8
ii  apache2-suexec-pristine [apache2-suexec]  2.4.10-10+deb8u8
ii  doc-base  0.10.6
ii  libapache2-mod-fcgid  1:2.3.9-1+b1
ii  libcrypt-ciphersaber-perl 0.61-4
ii  libfile-nfslock-perl  1.24-1
ii  libio-socket-ssl-perl 2.002-2+deb8u2
ii  libmail-dkim-perl 0.40-1
ii  locales   2.19-18+deb8u7
ii  logrotate 3.8.7-1+b1
ii  mysql-server  5.5.55-0+deb8u1

Versions of packages sympa suggests:
ii  apache2 [httpd-cgi]  2.4.10-10+deb8u8
pn  libauthcas-perl  
pn  libdbd-oracle-perl   
pn  libtext-wrap-perl
ii  openssl  1.0.1t-1+deb8u6

-- Configuration Files:
/etc/sympa/auth.conf changed [not included]
/etc/sympa/topics.conf changed [not included]

-- debconf information:
  sympa/db/dbname: sympa
  sympa/passwords-do-not-match:
  sympa/internal/reconfiguring: false
  sympa/dbconfig-install: true
  sympa/pgsql/method: unix socket
  sympa/upgrade-backup: true
  sympa/pgsql/authmethod-admin: ident
  sympa/database-type: mysql
  sympa/pgsql/changeconf: false
  sympa/remote/host:
  sympa/dbconfig-reinstall: false
  sympa/purge: false
  sympa/listmaster: listmas...@lists1.scc.kit.edu
  wwsympa/fastcgi: false
  sympa/use_soap: false
  sympa/remote/newhost:
  sympa/pgsql/no-empty-passwords:
  sympa/upgrade-error: abort
  wwsympa/webserver_type: Apache 2
  sympa/dbconfig-upgrade: true
  sympa/remote/port:
  sympa/pgsql/admin-user: postgres
  sympa/pgsql/manualconf:
  sympa/remove-error: abort
  sympa/install-error: abort
  wwsympa/wwsympa_url: http://lists1.scc.kit.edu/wws
  sympa/remove_spool: false
  sympa/language: de
  sympa/pgsql/authmethod-user: password
  sympa/mysql/admin-user: root
  sympa/db/app-user: 

Bug#860807: sympa: Messages in Apache Error Log

[Sabine Lorenz]

Package: sympa
Version: 6.1.23~dfsg-2+deb8u1
Severity: minor

Dear Maintainer,

there seems to be an error in the web-template search_user.tt2 because when 
searching for a user via the Sympa web-interface 
I see a lot of errors of the following kind in the Apache Error-Logs:

[Thu Apr 20 12:29:57.911585 2017] [fcgid:warn] [pid 1995:tid 140261619365632] 
[client 141.52.0.0:53613] mod_fcgid: stderr: Use of
uninitialized value in concatenation (.) or string at 
/usr/share/sympa/default/web_tt2/search_user.tt2 line 43., referer: https://
www.lists.kit.edu/sympa/serveradmin/users

Apparently this error message doesn't occur after searching for every 
email-address. (The error messag seems to occur when searching for an 
email-address that is member or owner of serveral mailinglist and it seems to 
be ok when searching for an email-address that is only member or owner of a few 
mailinglists.)

Could you please fix this error if you can reproduce the error?

Best regards,
Sabine Lorenz

-- System Information:
Debian Release: 8.7
Architecture: amd64 (x86_64)

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

Versions of packages sympa depends on:
ii  adduser3.113+nmu3
ii  ca-certificates20141019+deb8u2
ii  dbconfig-common1.8.47+nmu3+deb8u1
ii  debconf [debconf-2.0]  1.5.56
ii  exim4-daemon-light [mail-transport-agent]  4.84.2-2+deb8u3
ii  libarchive-zip-perl1.39-1
ii  libc6  2.19-18+deb8u7
ii  libcgi-fast-perl   1:2.04-1
ii  libcgi-pm-perl 4.09-1
ii  libdbd-mysql-perl  4.028-2+deb8u2
ii  libdbd-pg-perl 3.4.2-1
ii  libdbd-sqlite3-perl1.44-1
ii  libdbd-sybase-perl 1.14-1+b2
ii  libdbi-perl1.631-3+b1
ii  libfcgi-perl   0.77-1+deb8u1
ii  libfile-copy-recursive-perl0.38-1
ii  libhtml-format-perl2.11-1
ii  libhtml-stripscripts-parser-perl   1.03-1
ii  libhtml-tree-perl  5.03-1
ii  libintl-perl   1.23-1+deb8u1
ii  libio-stringy-perl 2.110-5
ii  libmailtools-perl  2.13-1
ii  libmime-charset-perl   1.011.1-1+deb8u2
ii  libmime-encwords-perl  1.014.3-1+deb8u1
ii  libmime-lite-html-perl 1.24-1
ii  libmime-tools-perl 5.505-1
ii  libmsgcat-perl 1.03-6+b1
ii  libnet-ldap-perl   1:0.6400+dfsg-2
ii  libnet-netmask-perl1.9021-1
ii  libregexp-common-perl  2013031301-1
ii  libsoap-lite-perl  1.11-1
ii  libtemplate-perl   2.24-1.2+b1
ii  libterm-progressbar-perl   2.16-1
ii  libunicode-linebreak-perl  0.0.20140601-2+deb8u2
ii  libxml-libxml-perl 2.0116+dfsg-1+deb8u1
ii  lsb-base   4.1+Debian13+nmu1
ii  mhonarc2.6.19-1
ii  perl   5.20.2-3+deb8u6
ii  perl-modules   5.20.2-3+deb8u6
ii  rsyslog [system-log-daemon]8.4.2-1+deb8u2
ii  sqlite33.8.7.1-1+deb8u2

Versions of packages sympa recommends:
ii  apache2-suexec2.4.10-10+deb8u8
ii  apache2-suexec-pristine [apache2-suexec]  2.4.10-10+deb8u8
ii  doc-base  0.10.6
ii  libapache2-mod-fcgid  1:2.3.9-1+b1
ii  libcrypt-ciphersaber-perl 0.61-4
ii  libfile-nfslock-perl  1.24-1
ii  libio-socket-ssl-perl 2.002-2+deb8u2
ii  libmail-dkim-perl 0.40-1
ii  locales   2.19-18+deb8u7
ii  logrotate 3.8.7-1+b1
ii  mysql-server  5.5.54-0+deb8u1

Versions of packages sympa suggests:
ii  apache2 [httpd-cgi]  2.4.10-10+deb8u8
pn  libauthcas-perl  
pn  libdbd-oracle-perl   
pn  libtext-wrap-perl
ii  openssl  1.0.1t-1+deb8u6

-- Configuration Files:
/etc/sympa/auth.conf changed [not included]
/etc/sympa/topics.conf changed [not included]

-- debconf information:
  wwsympa/remove_spool: false
  sympa/upgrade-backup: true
  sympa/internal/reconfiguring: false
  wwsympa/wwsympa_url: http://lists1.scc.kit.edu/wws
  sympa/language: de
  sympa/mysql/method: unix socket
  sympa/use_soap: false
  sympa/pgsql/changeconf: false
  sympa/hostname

Bug#858261: gcc-6: "internal compiler error: Segmentation fault" when building webkit2gtk

[Lorenz Hübschle-Schneider]

Package: g++-6
Version: 6.3.0-9
Followup-For: Bug #858261

Dear Maintainer,

I get a similar failure when compiling RaftLib [1]. I'm not entirely sure it's
the same bug but it appeared with the last update (6.3.0-9) so it might well be.

Steps to reproduce:
git clone https://github.com/RaftLib/RaftLib
cd RaftLib
mkdir build
cd build
cmake ..
make

This fails with:

In file included from /tmp/RaftLib/raftinc/ringbufferheap.tcc:25:0,
 from /tmp/RaftLib/raftinc/ringbufferbase.tcc:66,
 from /tmp/RaftLib/raftinc/ringbuffer.tcc:34,
 from /tmp/RaftLib/raftinc/port.hpp:37,
 from /tmp/RaftLib/raftinc/kernel.hpp:29,
 from /tmp/RaftLib/raftinc/allocate.hpp:29,
 from /tmp/RaftLib/src/allocate.cpp:25:
/tmp/RaftLib/raftinc/ringbufferheap_abstract.tcc: In lambda function:
/tmp/RaftLib/raftinc/ringbufferheap_abstract.tcc:371:64: internal compiler 
error: Segmentation fault
 local_insert_helper( *begin, *end, sig );
^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
src/CMakeFiles/raft.dir/build.make:86: recipe for target 
'src/CMakeFiles/raft.dir/allocate.cpp.o' failed

Didn't get a coredump despite them being enabled, but don't have time to figure
out what's going on with that right now, sorry.

Cheers,
Lorenz

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

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

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

Versions of packages g++-6 depends on:
ii  gcc-66.3.0-9
ii  gcc-6-base   6.3.0-9
ii  libc62.24-9
ii  libgmp10 2:6.1.2+dfsg-1
ii  libisl15 0.18-1
ii  libmpc3  1.0.3-1+b2
ii  libmpfr4 3.1.5-1
ii  libstdc++-6-dev  6.3.0-9
ii  zlib1g   1:1.2.8.dfsg-5

g++-6 recommends no packages.

Versions of packages g++-6 suggests:
ii  g++-6-multilib6.3.0-9
pn  gcc-6-doc 
ii  libstdc++6-6-dbg  6.3.0-9

-- no debconf information

Bug#835432: polymake: FTBFS with '.' removed from perl's @INC

[Benjamin Lorenz]

On 25/08/16 19:59, David Bremner wrote:
> Dominic Hargreaves  writes:
> 
>>
>> This bug will become RC when the perl package change removing '.' from
>> @INC by default is uploaded to unstable, expected in a week or two.
>>
>> By the way, when preparing this patch I found that the git repository
>> at git://anonscm.debian.org/collab-maint/polymake.git was behind the
>> Debian archive.
> 
> 
> Hi Dom!
> 
> Thanks for the patch. I'll wait a few days to see if upstream has an
> comments / suggestions.
> 
> d

Hi,

thanks for the patch, seems fine to me. I have applied it to our
development branch and will also add it to the next bugfix-release. For
the time being, it would be best if you could add it to the debian patches.

Best,
Benjamin

Bug#819333: [llvm-3.8-dev] LLVMgold.so is missing, so "clang -flto" is unusable

[Lorenz Hübschle-Schneider]

Awesome - thank you very much! I must confess that I'm not very
proficient in Debian packaging and the package build process. I'll have
to change that some day ;)

Best,
Lorenz

On Mon, 8 Aug 2016, at 18:40, Sylvestre Ledru wrote:
> I think I found the fix. So, don't bother :)
> 
> Le 08/08/2016 à 17:10, Sylvestre Ledru a écrit :
> > I will have a look but don't hesitate to provide a patch to make
> > things moving faster
> >
> > Le 08/08/2016 à 16:41, Lorenz Hübschle-Schneider a écrit :
> >> Dear maintainer,
> >>
> >> this issue is still present in version 1:3.8.1-8. According to
> >> http://llvm.org/docs/GoldPlugin.html the fix should be quite simple. I'd
> >> really appreciate it if you could bring back LLVMgold.so in 3.8.
> >>
> >> Best,
> >> Lorenz
> >>
> >> On Sat, 26 Mar 2016 23:10:18 +0100 Steffen Weinhart
> >> <stw...@blue-cable.de> wrote:
> >>> Package: llvm-3.8-dev
> >>> Version: 1:3.8-2
> >>> Severity: important
> >>>
> >>> In versions prior to 3.8 (final), there was LLVMgold.so, which was used
> >>> e.g. when clang was invoked with "-flto". When using clang-3.8 with
> >>> "-flto" now, the linker cannot find the library and aborts. Why has it
> >>> been removed? Or at least what package should I install then? "apt-file
> >>> search LLVMgold.so" only finds entries in older llvm-3.*-dev packages.
> >>>
> >>> --- System information. ---
> >>> Architecture: amd64
> >>> Kernel: Linux 4.4.6
> >>>
> >>> Debian Release: stretch/sid
> >>> 900 testing security.debian.org
> >>> 900 testing ftp.deb-multimedia.org
> >>> 900 testing ftp.de.debian.org
> >>> 500 testing-updates ftp.de.debian.org
> >>> 500 testing-proposed-updates ftp.de.debian.org
> >>> 500 stable-updates ftp.de.debian.org
> >>> 500 stable security.debian.org
> >>> 500 stable ftp.de.debian.org
> >>> 500 proposed-updates ftp.de.debian.org
> >>> 50 unstable ftp.deb-multimedia.org
> >>> 50 unstable ftp.de.debian.org
> >>> 100 jessie-backports ftp.de.debian.org
> >>> 1 experimental ftp.de.debian.org
> >>>
> >>> --- Package information. ---
> >>> Package's Depends field is empty.
> >>>
> >>> Package's Recommends field is empty.
> >>>
> >>> Package's Suggests field is empty.
> >>>
> >>>
> >>
> >> ___
> >> Pkg-llvm-team mailing list
> >> pkg-llvm-t...@lists.alioth.debian.org
> >> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-llvm-team
> >>
> >
> > ___
> > Pkg-llvm-team mailing list
> > pkg-llvm-t...@lists.alioth.debian.org
> > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-llvm-team
> 
> 

Bug#819333: [llvm-3.8-dev] LLVMgold.so is missing, so "clang -flto" is unusable

[Lorenz Hübschle-Schneider]

Dear maintainer,

this issue is still present in version 1:3.8.1-8. According to
http://llvm.org/docs/GoldPlugin.html the fix should be quite simple. I'd
really appreciate it if you could bring back LLVMgold.so in 3.8.

Best,
Lorenz

On Sat, 26 Mar 2016 23:10:18 +0100 Steffen Weinhart
<stw...@blue-cable.de> wrote:
> Package: llvm-3.8-dev
> Version: 1:3.8-2
> Severity: important
> 
> In versions prior to 3.8 (final), there was LLVMgold.so, which was used 
> e.g. when clang was invoked with "-flto". When using clang-3.8 with 
> "-flto" now, the linker cannot find the library and aborts. Why has it 
> been removed? Or at least what package should I install then? "apt-file 
> search LLVMgold.so" only finds entries in older llvm-3.*-dev packages.
> 
> --- System information. ---
> Architecture: amd64
> Kernel: Linux 4.4.6
> 
> Debian Release: stretch/sid
> 900 testing security.debian.org
> 900 testing ftp.deb-multimedia.org
> 900 testing ftp.de.debian.org
> 500 testing-updates ftp.de.debian.org
> 500 testing-proposed-updates ftp.de.debian.org
> 500 stable-updates ftp.de.debian.org
> 500 stable security.debian.org
> 500 stable ftp.de.debian.org
> 500 proposed-updates ftp.de.debian.org
> 50 unstable ftp.deb-multimedia.org
> 50 unstable ftp.de.debian.org
> 100 jessie-backports ftp.de.debian.org
> 1 experimental ftp.de.debian.org
> 
> --- Package information. ---
> Package's Depends field is empty.
> 
> Package's Recommends field is empty.
> 
> Package's Suggests field is empty.
> 
> 

Bug#792519: systemd-logind fails to start on system using LDAP

[Lorenz Hübschle-Schneider]

Dear all,

I get similar symptoms (but no boot failures, just unnecessarily slow
boot times) with current unstable (systemd 231-1, dbus 1.10.8-1,
libnss-ldap 265-3+b1) using systemd-networkd instead of NetworkManager.

Loads of
> dbus-daemon[2395]: nss_ldap: could not connect to any LDAP server as (null) - 
> Can't contact LDAP server
in the logs until at some point networkd connects.

I suspect that the network may only be brought up at that point because
of an NFS automount that is triggered:
> systemd[1]: home.automount: Got automount request for /home, triggered by 
> 2458 (mount)
> systemd[1]: Starting Wait for Network to be Configured...

 After that request there are some more failures (this time from nscd
 instead of dbus) until the network is actually connected.

I have nss_initgroups_ignoreusers set up for all system users and
'bind_policy soft' in /etc/ldap.conf

Anything I can do to help fix this?

Best,
Lorenz

On Sun, 19 Jul 2015 15:03:53 -0300 Felipe Sateler <fsate...@debian.org>
wrote:
> On 17 July 2015 at 18:44, Daniel Schepler <dschep...@gmail.com> wrote:
> > On Wed, Jul 15, 2015 at 12:30 PM, Felipe Sateler <fsate...@debian.org>
> > wrote:
> >>
> >> On 15 July 2015 at 16:09, Daniel Schepler <dschep...@gmail.com> wrote:
> >> > On Wed, Jul 15, 2015 at 11:48 AM, Felipe Sateler <fsate...@debian.org>
> >> > wrote:
> >> >>
> >> >> Hmm. Could you please attach the upgrade logs since some time before
> >> >> the problems occurred?  Might network manager have been updated in the
> >> >> meantime?
> >> >
> >> >
> >> > Attaching /var/log/dpkg.log.  I think the first failed boot was
> >> > 2015-07-08
> >> > or 2015-07-09.  From the previous history, the last upgrade of dbus was:
> >> >
> >> > 2015-05-20 09:46:36 upgrade dbus:amd64 1.8.16-1 1.8.18-1
> >> >
> >> >>
> >> >> Also, how do you manage your connections?
> >> >>
> >> >> I also found this old redhat bug[1]. Could you try adding a conf
> >> >> snippet to order the ldap components before dbus? Use systemctl edit
> >> >>  and add Before=dbus.service.
> >> >>
> >> >>
> >> >> [1] https://bugzilla.redhat.com/show_bug.cgi?id=502072
> >> >
> >> >
> >> > OK, it will be a while before I can test it because I'm doing work using
> >> > the
> >> > machine right now.
> >> >
> >> > It would appear to me from the logs that NetworkManager can't
> >> > successfully
> >> > start before dbus is available - and I would probably want to make nslcd
> >> > dependent on networking being up.  Would that mean that I'd have to set
> >> > things up so it manually connects eth0 over DHCP, then starts nslcd,
> >> > then
> >> > starts dbus?  And then NetworkManager would be left only managing wlan0?
> >> > And if so, where would I look for documentation on setting up the unit
> >> > to
> >> > connect eth0?  (Sorry for the last very basic question.)
> >>
> >> I think (but I'm not sure) that nm will still connect without dbus
> >> available yet, but it will of course not answer any dbus requests. So
> >> it should only be necessary to order ldap before dbus.
> >>
> >> However, this solution may prove brittle. Reading the linked redhat
> >> bug there are two promsing suggestions:
> >>
> >> 1. Add 'bind_policy soft' to /etc/ldap.conf.
> >> 2. Set nss_initgroups_ignoreusers to at least
> >> 'root,dirsrv,gdm,rtkit,pulse,haldaemon,polkituser,avahi,dbus'
> >>
> >> It seems the problem is that nss_ldap is trying to query ldap for
> >> system users. That seems wrong to me, as the system should be able to
> >> work without network.
> >

Bug#827310: [xul-ext-pwdhash] similar problem here

[Lorenz Wenner]

Package: xul-ext-pwdhash
Version: 1.7-13

--- Please enter the report below this line. ---

i also upgraded from iceweasel 38 to 45.2.0esr-1~deb8u1 and found the 
pwdhash-addon to be deactivated although depending on the new version of 
firefox/iceweasel


as suggested in the previous mail i investigated the file
/usr/share/xul-ext/pwdhash/install.rdf but there i found

*

so i was not really sure what to do.

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.16.0-4-amd64

Debian Release: 8.5
  500 stable-updates  ftp.de.debian.org   500 stable 
security.debian.org   500 stable  packages.x2go.org   500 stable 
 ftp.de.debian.org   500 stable  dl.google.com   100 
jessie-backports ftp.de.debian.org

--- Package information. ---
Depends(Version) | Installed
-+-===
iceweasel| 45.2.0esr-1~deb8u1


Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#827310: [xul-ext-pwdhash] similar problem here

[Lorenz Wenner]

Package: xul-ext-pwdhash
Version: 1.7-13

--- Please enter the report below this line. ---

i also upgrade from iceweasel 38 to 45.2.0esr-1~deb8u1 and found the 
pwdhash-addon to be deactivated although depending on the new version of 
firefox/iceweasel


as suggested in the previous mail i investigated the file
/usr/share/xul-ext/pwdhash/install.rdf but there i found

*

so i was not really sure what to do.

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.16.0-4-amd64

Debian Release: 8.5
  500 stable-updates  ftp.de.debian.org   500 stable 
security.debian.org   500 stable  packages.x2go.org   500 stable 
 ftp.de.debian.org   500 stable  dl.google.com   100 
jessie-backports ftp.de.debian.org

--- Package information. ---
Depends(Version) | Installed
-+-===
iceweasel| 45.2.0esr-1~deb8u1


Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#110919: [dpkg] can be closed?

[Lorenz Wenner]

Package: dpkg
Version: 1.17.27

--- Please enter the report below this line. ---

i think this bug can be closed because dpkg doesn't have the 
--reconfigure option any more. i don't know since which version.



--- System information. ---
Architecture: amd64
Kernel:   Linux 3.16.0-4-amd64

Debian Release: 8.5
  500 stable-updates  ftp.de.debian.org   500 stable 
security.debian.org   500 stable  packages.x2go.org   500 stable 
 ftp.de.debian.org   500 stable  dl.google.com   100 
jessie-backports ftp.de.debian.org

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Suggests  (Version) | Installed
===-+-===
apt | 1.0.9.8.3

Bug#60528: [dpkg] can be closed

[Lorenz Wenner]

Package: dpkg
Version: 1.17.27

--- Please enter the report below this line. ---

dpkg -l

lists only installed packages. i did not find out that you would have to 
do to get a list of all available packages.


--- System information. ---
Architecture: amd64
Kernel:   Linux 3.16.0-4-amd64

Debian Release: 8.5
  500 stable-updates  ftp.de.debian.org   500 stable 
security.debian.org   500 stable  packages.x2go.org   500 stable 
 ftp.de.debian.org   500 stable  dl.google.com   100 
jessie-backports ftp.de.debian.org

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Suggests  (Version) | Installed
===-+-===
apt | 1.0.9.8.3

Bug#33263: [dpkg] same as #30126

[Lorenz Wenner]

Package: dpkg
Version: 1.17.27

--- Please enter the report below this line. ---

i think this is the same as #30126 which i found to be fixed, since 
dpkg-divert puts out the info that directories are not supported.


--- System information. ---
Architecture: amd64
Kernel:   Linux 3.16.0-4-amd64

Debian Release: 8.5
  500 stable-updates  ftp.de.debian.org   500 stable 
security.debian.org   500 stable  packages.x2go.org   500 stable 
 ftp.de.debian.org   500 stable  dl.google.com   100 
jessie-backports ftp.de.debian.org

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Suggests  (Version) | Installed
===-+-===
apt | 1.0.9.8.3

Bug#30126: [dpkg] can be closed?

[Lorenz Wenner]

Package: dpkg
Version: 1.17.27

--- Please enter the report below this line. ---

when i type

dpkg-divert --rename /usr/include/linux

i get

dpkg-divert: error: cannot divert directories

Use --help for help about diverting files.

so i think this is fixed. i also think this the is same as bug #33263

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.16.0-4-amd64

Debian Release: 8.5
  500 stable-updates  ftp.de.debian.org   500 stable 
security.debian.org   500 stable  packages.x2go.org   500 stable 
 ftp.de.debian.org   500 stable  dl.google.com   100 
jessie-backports ftp.de.debian.org

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Suggests  (Version) | Installed
===-+-===
apt | 1.0.9.8.3

Bug#815666: Xwayland crash

[Lorenz Hübschle-Schneider]

Yes, it's fixed. Thanks a lot.

Lorenz

Bug#815666: Duplicate of #814982

[Lorenz Hübschle-Schneider]

Yes, that certainly seems possible as I mentioned in my initial
report. However, I can exclude the possibility of it being a duplicate
of #813687 after the upgrade to mutter 3.18.3.

Bug#815666: xwayland: crashes when turning on screens after waking up from lockscreen

[Lorenz Hübschle-Schneider]

e='ca.desrt.dconf'
> Mar 01 11:53:03 i10pc82 gdm-launch-environment][815]: 
> pam_unix(gdm-launch-environment:session): session closed for user Debian-gdm
> Mar 01 11:53:03 i10pc82 /usr/lib/gdm3/gdm-x-session[977]: (II) 
> systemd-logind: got pause for 13:68
> Mar 01 11:53:03 i10pc82 /usr/lib/gdm3/gdm-x-session[977]: (II) 
> systemd-logind: got pause for 13:77
> Mar 01 11:53:03 i10pc82 /usr/lib/gdm3/gdm-x-session[977]: (II) 
> systemd-logind: got pause for 13:70
> Mar 01 11:53:03 i10pc82 /usr/lib/gdm3/gdm-x-session[977]: (II) 
> systemd-logind: got pause for 13:64
> Mar 01 11:53:03 i10pc82 /usr/lib/gdm3/gdm-x-session[977]: (II) 
> systemd-logind: got pause for 13:69
> Mar 01 11:53:03 i10pc82 /usr/lib/gdm3/gdm-x-session[977]: (II) 
> systemd-logind: got pause for 226:0
> Mar 01 11:53:03 i10pc82 /usr/lib/gdm3/gdm-x-session[977]: (II) 
> systemd-logind: got pause for 13:66
> Mar 01 11:53:03 i10pc82 /usr/lib/gdm3/gdm-x-session[977]: (II) 
> systemd-logind: got pause for 13:67
> Mar 01 11:53:03 i10pc82 /usr/lib/gdm3/gdm-x-session[977]: (II) 
> systemd-logind: got pause for 13:65
> Mar 01 11:53:03 i10pc82 /usr/lib/gdm3/gdm-x-session[977]: (EE) intel(0): page 
> flipping failed, on CRTC:21 (pipe=0), disabling synchronous page flips
> Mar 01 11:53:03 i10pc82 gnome-session[989]: (gnome-settings-daemon:1069): 
> color-plugin-WARNING **: failed to delete device: failed to obtain 
> org.freedesktop.color-manager.delete-device auth
> Mar 01 11:53:03 i10pc82 gdm3[810]: Child process -827 was already dead.
> Mar 01 11:53:03 i10pc82 /usr/lib/gdm3/gdm-x-session[977]: (II) intel(0): 
> resizing framebuffer to 3000x1920
> Mar 01 11:53:03 i10pc82 /usr/lib/gdm3/gdm-x-session[977]: (EE) intel(0): 
> failed to set mode: Permission denied [13]
> Mar 01 11:53:03 i10pc82 /usr/lib/gdm3/gdm-x-session[977]: (II) intel(0): 
> switch to mode 1920x1080@60.0 on HDMI2 using pipe 1, position (1920, 0), 
> rotation left, reflection none
> Mar 01 11:53:03 i10pc82 /usr/lib/gdm3/gdm-x-session[977]: (EE) intel(0): 
> failed to set mode: Permission denied [13]
> Mar 01 11:53:03 i10pc82 gnome-session[989]: Window manager warning: 
> Configuring CRTC 64 with mode 72 (1920 x 1080 @ 60.00) at position 1920, 
> 0 and transform 1 failed
> Mar 01 11:53:03 i10pc82 gnome-session[989]: (gnome-settings-daemon:1069): 
> color-plugin-WARNING **: failed to create device: failed to obtain 
> org.freedesktop.color-manager.create-device auth

is this in any way helpful? Should it be reassigned to gnome-shell?
Could it be related to #813687? I have a dual-monitor setup if that
makes a difference.

Cheers,
Lorenz

Bug#816080: [wajig] Segfault on wajig show command for some packages.

[Lorenz Hübschle-Schneider]

Sounds like a duplicate of #815581 (fixed / pending) to me

Cheers
Lorenz

Bug#815666: xwayland: crashes when turning on screens after waking up from lockscreen

[Lorenz Hübschle-Schneider]

Attached is the output of gdb "thread apply all bt full" for
gnome-shell, both the grandchild process of gdm-x-session and
gdm-wayland-session. The parent in both cases is gnome-session-binary,
and gnome-session is invoked without flags/parameters (X) or
"--mode=gdm --wayland --display-server" (wayland). Maybe these can be
of help?

Cheers
Lorenz

On Tue, Feb 23, 2016 at 2:35 PM, Lorenz Hübschle-Schneider
<lorenz-...@lgh-alumni.de> wrote:
> Package: xwayland
> Version: 2:1.18.1-1
> Severity: grave
> Justification: renders package unusable
>
> Dear Maintainer,
>
> since today my machine is no longer lockable, as Xwayland segfaults upon 
> waking
> up whenever I lock the screen for more than a few seconds.  The precise
> criterion for the crash happening or not is the monitors powering down. The
> segfault occurs when the monitors power up again.  This renders my system
> unlockable as gnome-session now uses Xwayland by default.
>
> >From the journal:
>
> Feb 23 13:47:45 i10pc82 gnome-session[836]: (EE)
> Feb 23 13:47:45 i10pc82 gnome-session[836]: (EE) Backtrace:
> Feb 23 13:47:45 i10pc82 gnome-session[836]: (EE) 0: /usr/bin/Xwayland 
> (xorg_backtrace+0x4e) [0x55e3df37cb0e]
> Feb 23 13:47:45 i10pc82 gnome-session[836]: (EE) 1: /usr/bin/Xwayland 
> (0x55e3df1e2000+0x19ee99) [0x55e3df380e99]
> Feb 23 13:47:45 i10pc82 gnome-session[836]: (EE) 2: 
> /lib/x86_64-linux-gnu/libc.so.6 (0x7ff802838000+0x33590) [0x7ff80286b590]
> Feb 23 13:47:45 i10pc82 gnome-session[836]: (EE) 3: /usr/bin/Xwayland 
> (MakeAtom+0x30) [0x55e3df3352f0]
> Feb 23 13:47:45 i10pc82 gnome-session[836]: (EE) 4: /usr/bin/Xwayland 
> (0x55e3df1e2000+0xe7cd8) [0x55e3df2c9cd8]
> Feb 23 13:47:45 i10pc82 gnome-session[836]: (EE) 5: /usr/bin/Xwayland 
> (0x55e3df1e2000+0xe8739) [0x55e3df2ca739]
> Feb 23 13:47:45 i10pc82 gnome-session[836]: (EE) 6: /usr/bin/Xwayland 
> (0x55e3df1e2000+0xe8d5b) [0x55e3df2cad5b]
> Feb 23 13:47:45 i10pc82 gnome-session[836]: (EE) 7: /usr/bin/Xwayland 
> (0x55e3df1e2000+0x164dcf) [0x55e3df346dcf]
> Feb 23 13:47:45 i10pc82 gnome-session[836]: (EE) 8: /usr/bin/Xwayland 
> (0x55e3df1e2000+0x168de3) [0x55e3df34ade3]
> Feb 23 13:47:45 i10pc82 gnome-session[836]: (EE) 9: 
> /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf0) [0x7ff802858870]
> Feb 23 13:47:45 i10pc82 gnome-session[836]: (EE) 10: /usr/bin/Xwayland 
> (_start+0x29) [0x55e3df21b019]
> Feb 23 13:47:45 i10pc82 gnome-session[836]: (EE)
> Feb 23 13:47:45 i10pc82 gnome-session[836]: (EE) Segmentation fault at 
> address 0x0
> Feb 23 13:47:45 i10pc82 gnome-session[836]: (EE)
> Feb 23 13:47:45 i10pc82 gnome-session[836]: Fatal server error:
> Feb 23 13:47:45 i10pc82 gnome-session[836]: (EE) Caught signal 11 
> (Segmentation fault). Server aborting
> Feb 23 13:47:45 i10pc82 gnome-session[836]: (EE)
> Feb 23 13:47:45 i10pc82 gnome-session[836]: (gnome-settings-daemon:920): 
> Gdk-WARNING **: gnome-settings-daemon: Fatal IO error 11 (Resource 
> temporarily unavailable) on X server :1024.
> Feb 23 13:47:45 i10pc82 org.a11y.atspi.Registry[889]: XIO:  fatal IO error 11 
> (Resource temporarily unavailable) on X server ":1024"
> Feb 23 13:47:45 i10pc82 org.a11y.atspi.Registry[889]:   after 21 requests 
> (21 known processed) with 0 events remaining.
> Feb 23 13:47:45 i10pc82 gnome-session-binary[836]: WARNING: App 
> 'gnome-settings-daemon.desktop' exited with code 1
> Feb 23 13:47:45 i10pc82 gnome-session[836]: gnome-session-binary[836]: 
> WARNING: App 'gnome-settings-daemon.desktop' exited with code 1
> Feb 23 13:47:45 i10pc82 gnome-session[836]: (gnome-shell:844): mutter-ERROR 
> **: Connection to xwayland lost
> Feb 23 13:47:45 i10pc82 kernel: traps: gnome-shell[844] trap int3 
> ip:7fc30b86287b sp:7ffc0fa3af30 error:0
> Feb 23 13:47:45 i10pc82 gnome-session[836]: ** (gnome-settings-daemon:995): 
> WARNING **: Unable to initialize GTK+
> Feb 23 13:47:45 i10pc82 gnome-session[836]: gnome-session-binary[836]: 
> WARNING: App 'gnome-settings-daemon.desktop' exited with code 1
> Feb 23 13:47:45 i10pc82 gnome-session-binary[836]: WARNING: App 
> 'gnome-settings-daemon.desktop' exited with code 1
> Feb 23 13:47:45 i10pc82 gnome-session-binary[836]: Unrecoverable failure in 
> required component gnome-shell-wayland.desktop
>
> I'm not sure if this should be filed against gnome-session, gnome-shell or 
> some
> other package but since the segmentation fault is occurring in Xwayland I
> decided to file the issue here.
>
> The issue also looks very similar to #814982, but seems to be triggered by
> some other update since it never occurred before today, and now it is 100%
> reproducible.  Package changes since last confirmed working state, from
> /var/log/aptitude, are listed below.
>

Bug#815666: xwayland: crashes when turning on screens after waking up from lockscreen

[Lorenz Hübschle-Schneider]

Package: xwayland
Version: 2:1.18.1-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

since today my machine is no longer lockable, as Xwayland segfaults upon waking
up whenever I lock the screen for more than a few seconds.  The precise
criterion for the crash happening or not is the monitors powering down. The
segfault occurs when the monitors power up again.  This renders my system
unlockable as gnome-session now uses Xwayland by default.

>From the journal:

Feb 23 13:47:45 i10pc82 gnome-session[836]: (EE)
Feb 23 13:47:45 i10pc82 gnome-session[836]: (EE) Backtrace:
Feb 23 13:47:45 i10pc82 gnome-session[836]: (EE) 0: /usr/bin/Xwayland 
(xorg_backtrace+0x4e) [0x55e3df37cb0e]
Feb 23 13:47:45 i10pc82 gnome-session[836]: (EE) 1: /usr/bin/Xwayland 
(0x55e3df1e2000+0x19ee99) [0x55e3df380e99]
Feb 23 13:47:45 i10pc82 gnome-session[836]: (EE) 2: 
/lib/x86_64-linux-gnu/libc.so.6 (0x7ff802838000+0x33590) [0x7ff80286b590]
Feb 23 13:47:45 i10pc82 gnome-session[836]: (EE) 3: /usr/bin/Xwayland 
(MakeAtom+0x30) [0x55e3df3352f0]
Feb 23 13:47:45 i10pc82 gnome-session[836]: (EE) 4: /usr/bin/Xwayland 
(0x55e3df1e2000+0xe7cd8) [0x55e3df2c9cd8]
Feb 23 13:47:45 i10pc82 gnome-session[836]: (EE) 5: /usr/bin/Xwayland 
(0x55e3df1e2000+0xe8739) [0x55e3df2ca739]
Feb 23 13:47:45 i10pc82 gnome-session[836]: (EE) 6: /usr/bin/Xwayland 
(0x55e3df1e2000+0xe8d5b) [0x55e3df2cad5b]
Feb 23 13:47:45 i10pc82 gnome-session[836]: (EE) 7: /usr/bin/Xwayland 
(0x55e3df1e2000+0x164dcf) [0x55e3df346dcf]
Feb 23 13:47:45 i10pc82 gnome-session[836]: (EE) 8: /usr/bin/Xwayland 
(0x55e3df1e2000+0x168de3) [0x55e3df34ade3]
Feb 23 13:47:45 i10pc82 gnome-session[836]: (EE) 9: 
/lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf0) [0x7ff802858870]
Feb 23 13:47:45 i10pc82 gnome-session[836]: (EE) 10: /usr/bin/Xwayland 
(_start+0x29) [0x55e3df21b019]
Feb 23 13:47:45 i10pc82 gnome-session[836]: (EE)
Feb 23 13:47:45 i10pc82 gnome-session[836]: (EE) Segmentation fault at address 
0x0
Feb 23 13:47:45 i10pc82 gnome-session[836]: (EE)
Feb 23 13:47:45 i10pc82 gnome-session[836]: Fatal server error:
Feb 23 13:47:45 i10pc82 gnome-session[836]: (EE) Caught signal 11 (Segmentation 
fault). Server aborting
Feb 23 13:47:45 i10pc82 gnome-session[836]: (EE)
Feb 23 13:47:45 i10pc82 gnome-session[836]: (gnome-settings-daemon:920): 
Gdk-WARNING **: gnome-settings-daemon: Fatal IO error 11 (Resource temporarily 
unavailable) on X server :1024.
Feb 23 13:47:45 i10pc82 org.a11y.atspi.Registry[889]: XIO:  fatal IO error 11 
(Resource temporarily unavailable) on X server ":1024"
Feb 23 13:47:45 i10pc82 org.a11y.atspi.Registry[889]:   after 21 requests 
(21 known processed) with 0 events remaining.
Feb 23 13:47:45 i10pc82 gnome-session-binary[836]: WARNING: App 
'gnome-settings-daemon.desktop' exited with code 1
Feb 23 13:47:45 i10pc82 gnome-session[836]: gnome-session-binary[836]: WARNING: 
App 'gnome-settings-daemon.desktop' exited with code 1
Feb 23 13:47:45 i10pc82 gnome-session[836]: (gnome-shell:844): mutter-ERROR **: 
Connection to xwayland lost
Feb 23 13:47:45 i10pc82 kernel: traps: gnome-shell[844] trap int3 
ip:7fc30b86287b sp:7ffc0fa3af30 error:0
Feb 23 13:47:45 i10pc82 gnome-session[836]: ** (gnome-settings-daemon:995): 
WARNING **: Unable to initialize GTK+
Feb 23 13:47:45 i10pc82 gnome-session[836]: gnome-session-binary[836]: WARNING: 
App 'gnome-settings-daemon.desktop' exited with code 1
Feb 23 13:47:45 i10pc82 gnome-session-binary[836]: WARNING: App 
'gnome-settings-daemon.desktop' exited with code 1
Feb 23 13:47:45 i10pc82 gnome-session-binary[836]: Unrecoverable failure in 
required component gnome-shell-wayland.desktop

I'm not sure if this should be filed against gnome-session, gnome-shell or some
other package but since the segmentation fault is occurring in Xwayland I
decided to file the issue here.

The issue also looks very similar to #814982, but seems to be triggered by
some other update since it never occurred before today, and now it is 100%
reproducible.  Package changes since last confirmed working state, from
/var/log/aptitude, are listed below.

Thanks a lot in advance

Cheers
Lorenz

Aptitude 0.7.5: log report
Mon, Feb 22 2016 17:41:48 +0100

  IMPORTANT: this log only lists intended actions; actions which fail
  due to dpkg problems may not be completed.

Will install 263 packages, and remove 3 packages.
220 MB of disk space will be used

[REMOVE, NOT USED] libquvi-scripts:amd64 0.4.21-2
[REMOVE, NOT USED] libquvi7:amd64 0.4.1-3
[REMOVE, NOT USED] linux-perf-4.3:amd64 4.3.1-2
[INSTALL, DEPENDENCIES] linux-headers-4.4.0-1-amd64:amd64 4.4.2-3
[INSTALL, DEPENDENCIES] linux-headers-4.4.0-1-common:amd64 4.4.2-3
[INSTALL, DEPENDENCIES] linux-image-4.4.0-1-amd64:amd64 4.4.2-3
[INSTALL, DEPENDENCIES] linux-kbuild-4.4:i386 4.4-4
[INSTALL, DEPENDENCIES] linux-perf-4.4:amd64 4.4-4
[UPGRADE] afl:amd64 1.96b-1 -> 1.96b-2
[UPGRADE] afl-clang:amd64 1.96b-1 -> 1.96b-2
[UPGR

Bug#813375: sympa is not enabled in systemd after installation

[Sabine Lorenz]

Package: sympa
Version: 6.1.23~dfsg-2
Severity: normal

Dear Maintainer,

After installing Sympa 6.1.23 as package on a Debian Jessie server we noticed 
that there was no systemd-command in postinst-script and that sympa was not 
enabled (we expected something like "systemctl enable sympa" in the scripts and 
couldn't find a systemd-file in the upstream code).
So we had to enable it manually. 
Is that a bug in Debian package or is it a fault on our part?

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

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

Versions of packages sympa depends on:
ii  adduser3.113+nmu3
ii  ca-certificates20141019+deb8u1
ii  dbconfig-common1.8.47+nmu3+deb8u1
ii  debconf [debconf-2.0]  1.5.56
ii  exim4-daemon-light [mail-transport-agent]  4.84-8+deb8u2
ii  libarchive-zip-perl1.39-1
ii  libc6  2.19-18+deb8u2
ii  libcgi-fast-perl   1:2.04-1
ii  libcgi-pm-perl 4.09-1
ii  libdbd-mysql-perl  4.028-2+b1
ii  libdbd-pg-perl 3.4.2-1
ii  libdbd-sqlite3-perl1.44-1
ii  libdbd-sybase-perl 1.14-1+b2
ii  libdbi-perl1.631-3+b1
ii  libfcgi-perl   0.77-1+b1
ii  libfile-copy-recursive-perl0.38-1
ii  libhtml-format-perl2.11-1
ii  libhtml-stripscripts-parser-perl   1.03-1
ii  libhtml-tree-perl  5.03-1
ii  libintl-perl   1.23-1
ii  libio-stringy-perl 2.110-5
ii  libmailtools-perl  2.13-1
ii  libmime-charset-perl   1.011.1-1
ii  libmime-encwords-perl  1.014.3-1
ii  libmime-lite-html-perl 1.24-1
ii  libmime-tools-perl 5.505-1
ii  libmsgcat-perl 1.03-6+b1
ii  libnet-ldap-perl   1:0.6400+dfsg-2
ii  libnet-netmask-perl1.9021-1
ii  libregexp-common-perl  2013031301-1
ii  libsoap-lite-perl  1.11-1
ii  libtemplate-perl   2.24-1.2+b1
ii  libterm-progressbar-perl   2.16-1
ii  libunicode-linebreak-perl  0.0.20140601-2
ii  libxml-libxml-perl 2.0116+dfsg-1+deb8u1
ii  lsb-base   4.1+Debian13+nmu1
ii  mhonarc2.6.19-1
ii  perl   5.20.2-3+deb8u3
ii  perl-modules   5.20.2-3+deb8u3
ii  rsyslog [system-log-daemon]8.4.2-1+deb8u2
ii  sqlite33.8.7.1-1+deb8u1

Versions of packages sympa recommends:
ii  apache2-suexec2.4.10-10+deb8u4
ii  apache2-suexec-pristine [apache2-suexec]  2.4.10-10+deb8u4
ii  doc-base  0.10.6
ii  libapache2-mod-fcgid  1:2.3.9-1+b1
ii  libcrypt-ciphersaber-perl 0.61-4
ii  libfile-nfslock-perl  1.24-1
ii  libio-socket-ssl-perl 2.002-2+deb8u1
ii  libmail-dkim-perl 0.40-1
ii  locales   2.19-18+deb8u2
ii  logrotate 3.8.7-1+b1
ii  mysql-server  5.5.47-0+deb8u1

Versions of packages sympa suggests:
ii  apache2 [httpd-cgi]  2.4.10-10+deb8u4
pn  libauthcas-perl  
pn  libdbd-oracle-perl   
pn  libtext-wrap-perl
ii  openssl  1.0.1k-3+deb8u2

-- Configuration Files:
/etc/logrotate.d/sympa changed:
/var/log/sympa/sympa.log {
daily
missingok
notifempty
rotate 7
size=100k
compress
delaycompress
create 640 sympa adm
postrotate
invoke-rc.d --quiet sympa reload > /dev/null
invoke-rc.d --quiet rsyslog rotate > /dev/null || true
endscript
}

/etc/sympa/topics.conf changed:
scc
title   SCC
Presseverteiler
title.dePresseverteiler


-- debconf information:
  sympa/mysql/admin-pass: (password omitted)
  sympa/app-password-confirm: (password omitted)
  sympa/pgsql/admin-pass: (password omitted)
  sympa/password-confirm: (password omitted)
  sympa/mysql/app-pass: (password omitted)
  sympa/pgsql/app-pass: (password omitted)
  sympa/internal/skip-preseed: false
  sympa/database-type: mysql
  sympa/dbconfig-remove:
  sympa/pgsql/admin-user: postgres