from:"Frank Brokken"

Bug#995757: module: inline class member function cannot use an extern thread_local int

2021-10-05 Thread Frank Brokken

Package: g++-11
Version: 11.2.0-7
Severity: normal

Dear Maintainer,

   * What led up to the situation?

While developing a module whose interface declares an extern thread_local int
and a class whose member accesses that int the compiler produces an internal
compiler error. The bug is observed when the member's implementation is
provided as an inline function, below the interface. If either instead of
'extern thread_local int' an 'extern int' is declared or if instead of an
inline function the function's implementation is provided in-class the
compiler bug isn't observed.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Here's the demo source:


/*
Define not THREAD_LOCAL and not INCLASS:no error
Define not THREAD_LOCAL and INCLASS:no error
Define THTREAD_LOCAL and not INCLASS:   internal compiler error
Define THTREAD_LOCAL and INCLASS:   no  error
*/

#define THREAD_LOCAL
#define INCLASS

module;

#include 

export module DemoMod;

export
{
#ifdef THREAD_LOCAL
extern thread_local int g_errno;
#else
extern int g_errno;
#endif

struct Demo
{
#ifdef INCLASS
void member()
{
g_errno = 0;
}
#else
void member();
#endif

};

#ifndef INCLASS
inline void Demo::member()
{
g_errno = 0;
}
#endif

}   // end export block



   * What was the outcome of this action?

If INCLASS is not defined then the compiler produces the following bugreport:


demo.cc:15:8: internal compiler error: in tree_node, at cp/module.cc:9061
   15 | export module DemoMod;
  |^~
0x9d4646 trees_out::tree_node(tree_node*)
../../src/gcc/cp/module.cc:9061
0x9d29fa trees_out::core_vals(tree_node*)
../../src/gcc/cp/module.cc:5915
0x9d313e trees_out::tree_node_vals(tree_node*)
../../src/gcc/cp/module.cc:7056
0x9d5aff trees_out::tree_value(tree_node*)
../../src/gcc/cp/module.cc:8892
0x9d466d trees_out::tree_node(tree_node*)
../../src/gcc/cp/module.cc:9090
0x9d29fa trees_out::core_vals(tree_node*)
../../src/gcc/cp/module.cc:5915
0x9d313e trees_out::tree_node_vals(tree_node*)
../../src/gcc/cp/module.cc:7056
0x9d5aff trees_out::tree_value(tree_node*)
../../src/gcc/cp/module.cc:8892
0x9d466d trees_out::tree_node(tree_node*)
../../src/gcc/cp/module.cc:9090
0x9d29fa trees_out::core_vals(tree_node*)
../../src/gcc/cp/module.cc:5915
0x9d313e trees_out::tree_node_vals(tree_node*)
../../src/gcc/cp/module.cc:7056
0x9d5aff trees_out::tree_value(tree_node*)
../../src/gcc/cp/module.cc:8892
0x9d466d trees_out::tree_node(tree_node*)
../../src/gcc/cp/module.cc:9090
0x9d29fa trees_out::core_vals(tree_node*)
../../src/gcc/cp/module.cc:5915
0x9d313e trees_out::tree_node_vals(tree_node*)
../../src/gcc/cp/module.cc:7056
0x9d5aff trees_out::tree_value(tree_node*)
../../src/gcc/cp/module.cc:8892
0x9d466d trees_out::tree_node(tree_node*)
../../src/gcc/cp/module.cc:9090
0x9d29fa trees_out::core_vals(tree_node*)
../../src/gcc/cp/module.cc:5915
0x9d313e trees_out::tree_node_vals(tree_node*)
../../src/gcc/cp/module.cc:7056
0x9d5aff trees_out::tree_value(tree_node*)
../../src/gcc/cp/module.cc:8892
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


   * What outcome did you expect instead?

I would have expected that the compiler would correctly compile the source
file for all four combinations of defining THREAD_LOCAL and INCLASS


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

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

Versions of packages g++-11 depends on:
ii  gcc-1111.2.0-7
ii  gcc-11-base   11.2.0-7
ii  libc6 2.32-4
ii  libgmp10  2:6.2.1+dfsg-2
ii  libisl23  0.23-1
ii  libmpc3   1.2.0-1
ii  libmpfr6  4.1.0-3
ii  libstdc++-11-dev  11.2.0-7
ii  libzstd1  1.4.8+dfsg-2.1
ii  zlib1g1:1.2.11.dfsg-2

g++-11 recommends no packages.

Versions of packages g++-11 suggests:
pn  g++-11-multilib  
pn  gcc-11-doc   

-- no debconf information

Bug#995000: g++-11: module partition defining a class won't compile

2021-09-24 Thread Frank Brokken

Package: g++-11
Version: 11.2.0-4
Severity: normal

Dear Maintainer,

   * What led up to the situation?

While performing some tests using modules I first defined a module defining a
class type. Its compilation completed flawlessly. Next I defined a module
partition defining a class type. It's compilation failed.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

First the module that was successfully compiled:

I defined the following module interface (in, e.g., 'module.cc'):

-
export module mod;

export class Data
{
int d_value = 10;

public:
int value() const;
};
-

and the implementation of value() (in, e.g., 'value.cc'):

-
module mod;

int Data::value() const
{
return d_value;
}
-

to compile I issued:

g++-11 -c -std=c++20 -fmodules-ts module.cc value.cc

compilation completed flawlessly.


Next the module partition whose compilation failed:

I defined (in a difference directory as used for the above source files)
the following module partition interface (e.g., 'partition.cc)':

-
export module mod:partition;

export class Data
{
int d_value = 10;

public:
int value() const;
};
-

and the implementation of value() (in, e.g., 'value.cc'):

-
module mod:partition;

int Data::value() const
{
return d_value;
}
-

to compile I issued:

g++-11 -c -std=c++20 -fmodules-ts partition.cc value.cc

compilation of value failed.

   * What was the outcome of this action?

The compiler produced the following error messages:

value.cc:3:5: error: ‘Data’ has not been declared
3 | int Data::value() const
  | ^~~~
value.cc:3:19: error: non-member function ‘int value()’ cannot have 
cv-qualifier
3 | int Data::value() const
  |   ^
value.cc: In function ‘int value()’:
value.cc:5:12: error: ‘d_value’ was not declared in this scope; did you 
mean ‘value’?
5 | return d_value;
  |^~~

   * What outcome did you expect instead?

Since the compilation of the plain module completed without errors, and
since a partition is a subsection of a module, without any special
restrictions w.r.t the kind of elements it can contain, I would have expected
that the compilation of the partition's 'value.cc' would succeed as well. It's
OK to define mere variables or functions in partitions, but currently
implementations of members of classes whose interfaces are provided in module
partition interface files produces errors, which comes as a surprise.


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

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

Versions of packages g++-11 depends on:
ii  gcc-1111.2.0-4
ii  gcc-11-base   11.2.0-4
ii  libc6 2.32-4
ii  libgmp10  2:6.2.1+dfsg-2
ii  libisl23  0.23-1
ii  libmpc3   1.2.0-1
ii  libmpfr6  4.1.0-3
ii  libstdc++-11-dev  11.2.0-4
ii  libzstd1  1.4.8+dfsg-2.1
ii  zlib1g1:1.2.11.dfsg-2

g++-11 recommends no packages.

Versions of packages g++-11 suggests:
pn  g++-11-multilib  
pn  gcc-11-doc   

-- debconf-show failed

Bug#994292: g++-11: Segfault when defining a module exporting a std::string

2021-09-15 Thread Frank Brokken

Package: g++-11
Version: 11.2.0-4
Severity: normal

Dear Maintainer,

   * What led up to the situation?

When defining a simple module in which a std::string is exported the program
compiles correctly but segfaults when it's run. When (instead of a
std::string) objects like std::vector or std::ifstream are exported
the segfault isn't observed.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I defined the following module (mod.cc):

module;

#include 

export module mod;

export std::string modstr{ "hello" };

and the source file (main.cc) defining main():

#include 

import mod;

int main()
{
std::cout << modstr << '\n';
}

These files were compiled and linked calling:

g++  --std=c++20 -Wall -O2  -fmodules-ts  -c -o mod.o mod.cc
g++  --std=c++20 -Wall -O2  -fmodules-ts  -c -o main.o main.cc
g++  main.o mod.o


   * What was the outcome of this action?

Compilation and linking succeeded, but when calling ./a.out the output was:

Segmentation fault


   * What outcome did you expect instead?

Output to the std output stream of the line

hello

Additional information: 

When defining and exporting (and using in main()), e.g., 
std:vector array{ 1, 2, 3 }  or  std::ifstream str{ "mod.cc } no
segfault was observed. 

I found GCC Bugzilla – Bug 99569, where a module exports a function
returning a std::string, which program also segfaults, but apparently the
segfault is already encountered when defining a plain std::string module
object, and doesn't require an exported function

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

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

Versions of packages g++-11 depends on:
ii  gcc-1111.2.0-4
ii  gcc-11-base   11.2.0-4
ii  libc6 2.31-17
ii  libgmp10  2:6.2.1+dfsg-1
ii  libisl23  0.23-1
ii  libmpc3   1.2.0-1
ii  libmpfr6  4.1.0-3
ii  libstdc++-11-dev  11.2.0-4
ii  libzstd1  1.4.8+dfsg-2.1
ii  zlib1g1:1.2.11.dfsg-2

g++-11 recommends no packages.

Versions of packages g++-11 suggests:
pn  g++-11-multilib  
pn  gcc-11-doc   

-- no debconf information

Bug#985214: g++-11 internal error and fails to precompile a concept

2021-03-14 Thread Frank Brokken

Package: g++-11
Version: 11-20210306-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Following the installation of g++-11 a previously precompilable header file
can't be precompiled anymore, and in some cases the compiler reports an
internal error requesting to submit a bug report.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

After upgrading g++ to version 11.0.1 the compiler reports a problem when
precompiling the following header file (shown between the --
lines). Additional information is provided below the next *-ed question.

--
#ifndef INCLUDED_CSVTABINS_
#define INCLUDED_CSVTABINS_

// #include  instead of iosfwd makes no difference
#include 

template 
concept OstreamInsertable = 
requires(std::ostream , Type value)
{
out << value;
};

// when using typename instead of the above concept : no error(1)
// e.g., by activating the following #define
// #define OstreamInsertable typename

struct FMT
{
enum Align
{};

typedef FMT (*FMTFun)(unsigned, unsigned);
typedef FMT (*FMTHline)(unsigned);
};

class CSVTabIns
{
template 
friend void operator<<(CSVTabIns , Type const );

// when omitted: results in bugreport1  (2)
friend CSVTabIns <<(CSVTabIns , FMT const );   

friend void operator<<(CSVTabIns , FMT::FMTHline);
};

// when defined here: precompilation error  (3)
template 
inline void operator<<(CSVTabIns &, Type const )
{}

inline void operator<<(CSVTabIns , FMT::FMTHline hline)
{
// when the insertion is omitted: no precompilation error
tab << (*hline)(1);  // insert hline in the next column
}

// when defined here: no precompilation error   (4)
//template 
//inline void operator<<(CSVTabIns &, Type const )
//{}

#endif
--


   * What was the outcome of this action?

Points to note (see the (x) marked comment entries:

1: If the concept isn't used, but instead of using
'template '
the plain template header
'template '
is used compilation completes flawlessly.

Also, when using version 
g++-10 (Debian 10.2.1-6) 10.2.1 20210110
no problem is reported.


With g++-11 the received error message is:

csvtabins: In substitution of ‘template  requires  
OstreamOstreamInsertable void operator<<(CSVTabIns&&, const Type&) [with 
Type = FMT]’:
csvtabins:11:13:   required by substitution of ‘template  requires  
OstreamOstreamInsertable void operator<<(CSVTabIns&, const Type&) [with 
Type = FMT]’
csvtabins:45:22:   required from here
csvtabins:8:9:   required for the satisfaction of 
‘OstreamOstreamInsertable’ [with Type = FMT]
csvtabins:9:5:   in requirements with ‘std::ostream& out’, ‘Type value’ [with 
Type = FMT]
csvtabins:9:5: error: satisfaction of atomic constraint ‘requires(std::ostream& 
out, Type value) {out << value;} [with Type = Type]’ depends on itself
9 | requires(std::ostream , Type value)
  | ^~~
   10 | {
  | ~
   11 | out << value;
  | ~
   12 | };
  | ~

which, I'm afraid, doesn't help me to understand the nature of the
problem. In particular it's unclear what is meant by 'satisfaction of
atomic constraint ...  depends on itself'.

2: When the friend declaration below (2) is omitted, the compiler reports
an internal error requesting to submit a bug-report.
In particular, the compiler reports:

csvtabins:11:13: internal compiler error: in get, at cp/constraint.cc:2656
   11 | out << value;
...
0xc84ae6 tsubst_simple_requirement
../../src/gcc/cp/constraint.cc:1983
Please submit a full bug report,
with preprocessed source if appropriate.

To reduce the size of this bug-report: the compiler's full output can
be retrieved from 'https://www.icce.rug.nl/tmp/bugreport1'. The precompiled
header produced by the compiler when it generated bugreport1 can be retrieved
from 'https://www.icce.rug.nl/tmp/bugreport1-csvtabins.gch'.

When instead of g++-11 g++-10 (Debian 10.2.1-6) 10.2.1 20210110) is used
then no internal error emerges, but just a normal error about a missing
operator<<. E.g.:

csvtabins: In function ‘void operator<<(CSVTabIns&, FMT::FMTHline)’:
csvtabins:45:9: error: no match for ‘operator<<’ (operand types are ‘CSVTabIns’ 
and ‘FMT’)
   45 | tab << (*hline)(1);  // insert hline in the next column
  | ~~~ ^~ ~~~
  | |  |
  | CSVTabIns  FMT
...


3 and 4: Whether the compilation error is encountered or not depends on the
position of the 
template 
inline void operator<<(CSVTabIns &, Type const )
{}
template definition. When

Bug#953419: cups: unable to print after a recent update

2020-03-09 Thread Frank Brokken

Package: cups
Version: 2.3.1-7
Severity: important

Dear Maintainer,

Subject: cups: unable to print after a recent update
Package: cups
Version: 2.3.1-11
Severity: important

Dear Maintainer,

   * What led up to the situation?

After a recent upgrade files could no longer be printed. Printing a test page
through the printer's direct web-interface still works, as does using its
document scan facilities (through xsane). Printing a test-page through the
cups interface no longer works, and neither does the lp command

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

The only thing that changed was a recent update. The debian packages are
regularly updated, usually once a week.

   * What was the outcome of this action?

After a recent update standard print commands no longer worked. When trying to
print a test-page printing is pending, and 'service cups status' reports:

service cups status
● cups.service - CUPS Scheduler
 Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor preset: 
enabled)
 Active: active (running) since Mon 2020-03-09 13:10:31 CET; 16min ago
TriggeredBy: ● cups.path
 ● cups.socket
   Docs: man:cupsd(8)
   Main PID: 13933 (cupsd)
  Tasks: 3 (limit: 4602)
 Memory: 33.0M
 CGroup: /system.slice/cups.service
 ├─13933 /usr/sbin/cupsd -l
 ├─14170 HP_OfficeJet_Pro_8710 606 frank semval.h 1 finishings=3 
number-up=1 sides=two-sided-long-edge 
job-uuid=urn:uuid:b9fe96d0-d6e7-31b2-7c2b-22d0a80a401a 
job-originating-host-name=localhost date-time-at-creation= date-time-at-proces>
 └─14171 
hp:/net/HP_OfficeJet_Pro_8710?hostname=printer.oostum.north 606 frank semval.h 
1 finishings=3 number-up=1 sides=two-sided-long-edge 
job-uuid=urn:uuid:b9fe96d0-d6e7-31b2-7c2b-22d0a80a401a 
job-originating-host-name=localhost date>

Mar 09 13:10:31 localhost.localdomain systemd[1]: Started CUPS Scheduler.
Mar 09 13:25:40 localhost.localdomain hp[13939]: io/hpmud/jd.c 94: unable to 
read device-id
Mar 09 13:25:40 localhost.localdomain hp[13939]: prnt/backend/hp.c 630: ERROR: 
5012 device communication error!
Mar 09 13:26:15 localhost.localdomain cupsd[13933]: pam_unix(cups:auth): 
Couldn't open /etc/securetty: No such file or directory
Mar 09 13:26:15 localhost.localdomain cupsd[13933]: pam_unix(cups:auth): 
Couldn't open /etc/securetty: No such file or directory

I've found several references to /etc/securetty, most of them indicating that
/etc/securetty isn't used anymore, but after asking cups to print a test page
it takes a long while (about 2 minutes) before 'service cups stop' completes.

After 'service cups stop'; 'touch /etc/securetty'; and 'service cups start'
the error message no longer appears in the 'service cups status' command, but
still nothing is printed.

   * What outcome did you expect instead?

After the update I expected the print commands to continue working


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

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

Versions of packages cups depends on:
ii  cups-client2.3.1-11
ii  cups-common2.3.1-11
ii  cups-core-drivers  2.3.1-11
ii  cups-daemon2.3.1-11
ii  cups-filters   1.27.2-1
ii  cups-ppdc  2.3.1-11
ii  cups-server-common 2.3.1-11
ii  debconf [debconf-2.0]  1.5.73
ii  ghostscript9.50~dfsg-5
ii  libavahi-client3   0.7-5
ii  libavahi-common3   0.7-5
ii  libc6  2.29-10
ii  libcups2   2.3.1-11
ii  libgcc-s1  10-20200222-1
ii  libstdc++6 10-20200222-1
ii  libusb-1.0-0   2:1.0.23-2
ii  poppler-utils  0.71.0-6
ii  procps 2:3.3.15-2+b1

Versions of packages cups recommends:
pn  avahi-daemon  
ii  colord1.4.3-4

Versions of packages cups suggests:
ii  cups-bsd   2.3.1-11
pn  cups-pdf   
pn  foomatic-db-compressed-ppds | foomatic-db  
ii  smbclient  2:4.11.5+dfsg-1
ii  udev   244.3-1

-- debconf information:
  cupsys/backend: lpd, socket, usb, snmp, dnssd
  cupsys/raw-print: true

Bug#941655: libreoffice-impress: Exported html pages have black backgrounds

2019-10-03 Thread Frank Brokken

Package: libreoffice-impress
Version: 1:6.3.2-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Exporting html pages of a libreoffice-impress document

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

For the purpose of this bugreport I created a small .odp file of two slides
Then alt-File, Export, and then pressed Export in the Export window.

   * What was the outcome of this action?

The html versions were saved, but all slides shown in the html files have a
black background 

   * What outcome did you expect instead?

The same background as in the presentation slides. In previous versions 
(version 1:6.1.5-3+deb10u4, the current stable version and before) exporting
html pages of the presentation went flawlessly. 

For your information: the demo slides and exported html pages are available in
https://www.icce.rug.nl/tmp/impress.tgz

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

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

Versions of packages libreoffice-impress depends on:
ii  libc62.29-2
ii  libepoxy01.5.3-0.1
ii  libetonyek-0.1-1 0.1.9-1
ii  libgcc1  1:9.2.1-8
ii  libmwaw-0.3-30.3.15-2
ii  libodfgen-0.1-1  0.1.7-1
ii  libreoffice-core 1:6.3.2-1
ii  libreoffice-draw 1:6.3.2-1
ii  librevenge-0.0-0 0.0.4-6+b1
ii  libstaroffice-0.0-0  0.0.6-1
ii  libstdc++6   9.2.1-8
ii  uno-libs36.3.2-1
ii  ure  6.3.2-1

libreoffice-impress recommends no packages.

Versions of packages libreoffice-impress suggests:
pn  bluez  

Versions of packages libreoffice-core depends on:
ii  fontconfig  2.13.1-2+b1
ii  fonts-opensymbol2:102.11+LibO6.3.2-1
ii  libboost-locale1.67.0   1.67.0-13
ii  libc6   2.29-2
ii  libcairo2   1.16.0-4
ii  libclucene-contribs1v5  2.3.3.4+dfsg-1+b1
ii  libclucene-core1v5  2.3.3.4+dfsg-1+b1
ii  libcmis-0.5-5v5 0.5.2-1
ii  libcups22.3.0-3
ii  libcurl3-gnutls 7.66.0-1
ii  libdbus-1-3 1.12.16-1
ii  libdconf1   0.34.0-1
ii  libeot0 0.01-5+b1
ii  libepoxy0   1.5.3-0.1
ii  libexpat1   2.2.7-2
ii  libexttextcat-2.0-0 3.4.5-1
ii  libfontconfig1  2.13.1-2+b1
ii  libfreetype62.9.1-4
ii  libgcc1 1:9.2.1-8
ii  libglib2.0-02.60.6-2
ii  libgpgmepp6 1.13.1-1
ii  libgraphite2-3  1.3.13-8
ii  libgstreamer-plugins-base1.0-0  1.14.4-2
ii  libgstreamer1.0-0   1.16.1-1
ii  libharfbuzz-icu02.6.1-3
ii  libharfbuzz0b   2.6.1-3
ii  libhunspell-1.7-0   1.7.0-2+b1
ii  libhyphen0  2.8.8-7
ii  libice6 2:1.0.9-2
ii  libicu6363.2-2
ii  libjpeg62-turbo 1:1.5.2-2+b1
ii  liblcms2-2  2.9-3+b1
ii  libldap-2.4-2   2.4.48+dfsg-1
ii  libmythes-1.2-0 2:1.2.4-3+b1
ii  libneon27-gnutls0.30.2-3
ii  libnspr42:4.21-2
ii  libnss3 2:3.45-1
ii  libnumbertext-1.0-0 1.0.5-3
ii  liborcus-0.14-0 0.14.1-6
ii  libpng16-16 1.6.37-1
ii  libpoppler820.71.0-5+b1
ii  librdf0 1.0.17-1.1+b1
ii  libreoffice-common  1:6.3.2-1
ii  librevenge-0.0-00.0.4-6+b1
ii  libsm6  2:1.2.3-1
ii  libstdc++6  9.2.1-8
ii  libx11-62:1.6.8-1
ii  libxext62:1.3.3-1+b2
ii  libxinerama12:1.1.4-2
ii  libxml2 2.9.4+dfsg1-7+b3
ii  libxmlsec1  1.2.28-2
ii  libxmlsec1-nss  1.2.28-2
ii  libxrandr2  2:1.5.1-1
ii  libxrender1 1:0.9.10-1
ii  libxslt1.1  1.1.32-2.1
ii  uno-libs3   6.3.2-1
ii  ure 6.3.2-1
ii  zlib1g  1:1.2.11.dfsg-1+b1

Versions of packages libreoffice-core recommends:
ii  gstreamer1.0-libav 1.15.0.1+git20180723+db823502-2
ii  gstreamer1.0-plugins-bad   1.14.4-1+b1
ii  gstreamer1.0-plugins-base  1.14.4-2
ii  gstreamer1.0-plugins-good  1.14.4-1
ii  gstreamer1.0-plugins-ugly  1.14.4-1
ii  libpaper-utils 1.1.28+b1

Versions of packages

Bug#920351: bash: exec in .profile suspends or loses stdin

2019-01-24 Thread Frank Brokken

Package: bash
Version: 5.0-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Yesterday I updated bash on several computers. In root's .profile I use the
following command to switch from bash to /usr/bin/tcsh:

exec /usr/bin/tcsh -l

After updating bash, when executing 'su -' the system responds with 
'Suspended (signal)'. 
The new shell (i.e., /usr/bin/tcsh) now is in the background and is
reactivated after issuing the command 'fg'


   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I updated Bash using the command 'aptitude safe-upgrade'. On another computer
(still using bash 4.4.23(1)) the exec ends execution of .profile and continues
with the new shell. 

On the updated computers, as a work-around, I removed the 'exec', and added
'exit 0' to .profile:

...
/usr/bin/tcsh -l
exit 0

This works, but the bash process continues to exist until eventually the tcsh
process ends.

As a side note: I could of course have specified /usr/bin/tcsh as root's shell
in /etc/password, but for various reasons that's not desirable. 

In /etc/password root's shell is specified as /bin/bash:

root:x:0:0:root:/root:/bin/bash

Bash itself is indeed at /bin/bash:

-rwxr-xr-x 1 root root 1168776 Jan 14 16:27 /bin/bash*

reporting its version as:

$ bash --version
GNU bash, version 5.0.0(1)-release (x86_64-pc-linux-gnu)


As another test I specified in .profile

exec /usr/local/bin/pause
echo beyond exec

where `pause' expects the user to press a key. Pause's prompt is shown, but
there's no waiting for input, and the echo text `beyond exec' isn't displayed:
apparently exec *does* end .profile's execution, but the replaced process
loses access to stdin.

   * What outcome did you expect instead?

I didn't find any entry about changes of the built-in exec command in either
the upstream changelog or the Debian changelog, and so I expected 

exec /usr/bin/tcsh -l

to work as before: at login shells switching to using the tcsh.

If you need any further info, please let me know.

Kind regards,
Frank B. Brokken.


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

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

Versions of packages bash depends on:
ii  base-files   10.1
ii  debianutils  4.8.6
ii  libc62.28-5
ii  libtinfo66.1+20181013-1

Versions of packages bash recommends:
ii  bash-completion  1:2.8-5

Versions of packages bash suggests:
pn  bash-doc  

-- no debconf information

Bug#879013: pinentry-qt: _glapi_tls_Current not in libGL.so.1

2017-10-18 Thread Frank Brokken

Package: pinentry-qt
Version: 1.0.0-3
Severity: important

Dear Maintainer,

   * What led up to the situation?

Updating the gnu packages.

   * What was the outcome of this action?

After pinentry-qt was upgraded it won't run anymore because it refers to a
symbol that does not exist in libGL.so.1:

pinentry-qt: symbol lookup error: /usr/lib/x86_64-linux-gnu/libGL.so.1:
undefined symbol: _glapi_tls_Current

libgGL.so.1 is in the libgl1 package, and currently has version 
0.2.999+git20170802-5 on my computer (libqt5gui5, listed as package on
which pinentry-qt depends, reports libgl1 as a package on which libqt5gui5
itself depends)

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

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

Versions of packages pinentry-qt depends on:
ii  libassuan0  2.4.3-3
ii  libc6   2.24-17
ii  libgcc1 1:7.2.0-8
ii  libgpg-error0   1.27-3
ii  libncursesw56.0+20170902-1
ii  libqt5core5a5.9.1+dfsg-9
ii  libqt5gui5  5.9.1+dfsg-9
ii  libqt5widgets5  5.9.1+dfsg-9
ii  libstdc++6  7.2.0-8
ii  libtinfo5   6.0+20170902-1

pinentry-qt recommends no packages.

Versions of packages pinentry-qt suggests:
pn  pinentry-doc  

-- no debconf information

Bug#878936: gpg: Inaccessible keys (?) after upgrade

2017-10-17 Thread Frank Brokken

Package: gpg
Version: 2.2.1-2
Severity: important

Dear Maintainer,

   * What led up to the situation?

This morning I performed aptitude update followed by aptitude upgrade.
/var/log/apt/history.log shows that various gpg programs were upgraded: 
gpg-wks-client:amd64 (2.2.1-1, 2.2.1-2), gpg-wks-server:amd64 (2.2.1-1,
2.2.1-2), gpg:amd64 (2.2.1-1, 2.2.1-2), gpgv:amd64 (2.2.1-1, 2.2.1-2),
gpg-agent:amd64 (2.2.1-1, 2.2.1-2), gpgconf:amd64 (2.2.1-1, 2.2.1-2).
gnupg-utils:amd64 (2.2.1-1, 2.2.1-2), gnupg-agent:amd64 (2.2.1-1, 2.2.1-2),
gnupg-l10n:amd64 (2.2.1-1, 2.2.1-2), gnupg2:amd64 (2.2.1-1, 2.2.1-2).

   * What was the outcome of this action?

Gpg could no longer be used. Either from the command line or when called from 
the mutt e-mail client.

When trying to decrypt an encrypted file gpg reports:

gpg: public key decryption failed: Inappropriate ioctl for device
gpg: decryption failed: No secret key

After issuing 

gpgconf --kill gpg-agent


gpg reports:

gpg: public key decryption failed: No pinentry
gpg: decryption failed: No secret key


My gpg-agent.conf file contains these lines:

default-cache-ttl 1200
pinentry-program /usr/bin/pinentry

The final lines in gpg.conf are:

use-agent


/usr/bin/pinentry is: 

/usr/bin/pinentry -> /etc/alternatives/pinentry

The latter links to:

/etc/alternatives/pinentry -> /usr/bin/pinentry-qt

And /usr/bin/pinentry-curses as well as /usr/bin/pinentry-qt exist. 

I found the suggestion to add the line 

pinentry-mode loopback

to gpg.conf, and

allow-loopback-pinentry 

to gpg-agent.conf. Although that results in a workable gpg, called from a
terminal, gpg can only be called from the mutt e-mail client for the duration
of the secret key's passphrase cache. Previously (before today's upgrade)
these problems were not encountered.

If you need any further information, please let me know.


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

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

Versions of packages gpg depends on:
ii  gpgconf2.2.1-2
ii  libassuan0 2.4.3-3
ii  libbz2-1.0 1.0.6-8.1
ii  libc6  2.24-17
ii  libgcrypt201.7.9-1
ii  libgpg-error0  1.27-3
ii  libreadline7   7.0-3
ii  libsqlite3-0   3.20.1-1
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages gpg recommends:
ii  gnupg  2.2.1-2

gpg suggests no packages.

-- no debconf information

Bug#860306: isc-dhcp-client: Repeatedly received DHCPNAK or no DHCPOFFERS; other computers work OK

2017-04-14 Thread Frank Brokken

Package: isc-dhcp-client
Version: 4.3.5-3
Severity: normal

Dear Maintainer,

This following bug report was created on the computer that experienced
problems with isc-dhcp-client, but has not external mail connectivity. I
completed the report, saved it, and included it below as the actual report. I
hope this is a workable work-around.

- - - - - - - - - - - - - - begin of original bug-report - - - - -

Package: isc-dhcp-client
Version: 4.3.5-3
Severity: normal

Dear Maintainer,

About a week ago isc-dhcp-client tried to connect to a network. It was the
first time I attempted to connect to that network, and while DHCP connections
usually work OK, this one resulted in repeated logs of DHCPNAK entries. Here
is an example:

Mar 30 13:00:20 localhost dhclient[4265]: Listening on 
LPF/wlp5s0/d8:fc:93:80:61:e1
Mar 30 13:00:20 localhost dhclient[4265]: Sending on   
LPF/wlp5s0/d8:fc:93:80:61:e1
Mar 30 13:00:20 localhost dhclient[4265]: Sending on   Socket/fallback
Mar 30 13:00:20 localhost dhclient[4265]: DHCPDISCOVER on wlp5s0 to 
255.255.255.255 port 67 interval 4
Mar 30 13:00:21 localhost dhclient[4265]: DHCPREQUEST of 192.168.61.234 on 
wlp5s0 to 255.255.255.255 port 67
Mar 30 13:00:21 localhost dhclient[4265]: DHCPOFFER of 192.168.61.234 from 
192.168.60.1
Mar 30 13:00:21 localhost dhclient[4265]: DHCPNAK from 192.168.60.1

Remarkably, two (android-based) cell-phones and a windows computer trying to
access that network at the same time successfully completed their DHCP
connections.


This morning I attempted to connect to a different network, also using
DHCP. This time it failed and the following entries were logged:

Apr 14 09:51:13 localhost dhclient[1570]: DHCPDISCOVER on wlp5s0 to 
255.255.255.255 port 67 interval 12
Apr 14 09:51:25 localhost dhclient[1570]: DHCPDISCOVER on wlp5s0 to 
255.255.255.255 port 67 interval 6
Apr 14 09:51:31 localhost dhclient[1570]: No DHCPOFFERS received.
Apr 14 09:51:31 localhost dhclient[1570]: No working leases in persistent 
database - sleeping.
Apr 14 09:51:31 localhost avahi-autoipd(wlp5s0)[4056]: Found user 
'avahi-autoipd' (UID 106) and group 'avahi-autoipd' (GID 111).
Apr 14 09:51:31 localhost avahi-autoipd(wlp5s0)[4056]: Successfully called 
chroot().
Apr 14 09:51:31 localhost avahi-autoipd(wlp5s0)[4056]: Successfully dropped 
root privileges.
Apr 14 09:51:31 localhost avahi-autoipd(wlp5s0)[4056]: Starting with address 
169.254.10.140
Apr 14 09:51:38 localhost avahi-autoipd(wlp5s0)[4056]: Callout BIND, address 
169.254.10.140 on interface wlp5s0
Apr 14 09:51:38 localhost avahi-daemon[479]: Joining mDNS multicast group on 
interface wlp5s0.IPv4 with address 169.254.10.140.
Apr 14 09:51:38 localhost avahi-daemon[479]: New relevant interface wlp5s0.IPv4 
for mDNS.
Apr 14 09:51:38 localhost avahi-daemon[479]: Registering new address record for 
169.254.10.140 on wlp5s0.IPv4.

Again, in the recent past connections to this network were successfully
established, and my cell-phone had no problems connecting to this
network. 

Last week I also tried to connect to this particular network, and then the
connection also wasn't established. In the past (say, a month or more ago) I
had no problems connecting to this network. Different from the previously
mentioned DHCPNAK-producing network this latter one is within reach, so I
could perform specific tests on the latter network, if that could provide
additional information.

So the main question is: isc-dhcp-client *usually* works OK, but I've now
encountered at least two networks where other computers successfully
esthablished their DHCP connections, but mine doesn't. The available 
documentation is sketchy: one suggestion I found in the dhcpclient.conf
man-page was to use an empty dhcpclient.conf file. So I did, but to no
avail. Am I missing something? What can I do to solve the problem?

As a side note: I'm also puzzled by the workings of the avahi daemon. It's
not clear what it's doing except for faking the above 169.254.10.140 address
and network. Should I deinstall avahi-daemon, since it appears to consume
resources but doesn't seem to do anything useful?...

That's about it. If there's anything I can do to help solving this issue,
please advise.

Kind regards,

Frank B. Brokken.

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

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

Versions of packages isc-dhcp-client depends on:
ii  debianutils   4.8.1
ii  iproute2  4.9.0-1
ii  libc6 2.24-9
ii  libdns-export162  1:9.10.3.dfsg.P4-12.1
ii  libisc-export160  1:9.10.3.dfsg.P4-12.1

Versions of packages isc-dhcp-client recommends:
ii  isc-dhcp-common  4.3.5-3

Versions of packages isc-dhcp-client suggests:
ii  avahi-autoipd 0.6.32-2
pn

Bug#848960: xserver-xorg segfaults after starting afterstep

2016-12-21 Thread Frank Brokken

Package: xserver-xorg
Version: 1:7.7+18
Severity: important

Dear Maintainer,

   * What led up to the situation?

Last week, after performing my weekly Debian update / upgrade session and
after rebooting my desktop computer the xserver segfaulted after logging in
and the (afterstep) window manager had started. Ususally it segfaults
immediately after starting up afterstep, occasionally after about 15 seconds
after showing afterstep's opening screen.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Assuming that the problem was related to the recent update I completely
removed xdm, xorg, xserver-xorg, and afterstep (and any libraries only used by
these packages) from my computer, and installed their stable versions (I'm
using Debian testing). The problem, however, remained.

Next I switched my window manager from afterstep to fvwm: the segfault no
longer appeared. Maybe the segfault somehow is related to using afterstep, but
in the end it's the X server that segfaults, which is why I filed the problem
as a xserver bug. 

I couldn't find hints as to what might be happening in the xserver-xorg log
(which is automatically included by reportbug in this bug report. If you want
a clean log file, generated after reinstalling the packages and rebooting,
then please let me know.

Xdm's log, however, did show the segfault:

Tue Dec 20 12:32:04 2016 xdm info (pid 16348): Starting
Tue Dec 20 12:32:04 2016 xdm info (pid 16348): Starting X server on :0

X.Org X Server 1.19.0
Release Date: 2016-11-15
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian
Current Operating System: Linux suffix 4.8.0-2-amd64 #1 SMP Debian 4.8.11-1 
(2016-12-02) x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.8.0-2-amd64 
root=UUID=92e1ce07-b39b-462f-aad2-236f67bd86ef ro quiet
Build Date: 23 November 2016  07:20:23PM
xorg-server 2:1.19.0-2 (https://www.debian.org/support) 
Current version of pixman: 0.34.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Tue Dec 20 12:32:04 2016
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
resize called 1680 1050
Tue Dec 20 12:32:05 2016 xdm info (pid 16358): sourcing /etc/X11/xdm/Xsetup
Tue Dec 20 12:32:17 2016 xdm info (pid 16358): sourcing 
/etc/X11/xdm/Xstartup
Tue Dec 20 12:32:17 2016 xdm info (pid 16374): executing session 
/etc/X11/xdm/Xsession
(EE) 
(EE) Backtrace:
(EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x4a) [0x55c9a2bfffea]
(EE) 1: /usr/lib/xorg/Xorg (0x55c9a2a47000+0x1bcd69) [0x55c9a2c03d69]
(EE) 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fd62c215000+0x11100) 
[0x7fd62c226100]
(EE) 3: ?? [0x55c9a52c1038]
(EE) 
(EE) Segmentation fault at address 0x55c9a52c1038
(EE) 
Fatal server error:
(EE) Caught signal 11 (Segmentation fault). Server aborting
(EE) 
(EE) 
Please consult the The X.Org Foundation support 
 at http://wiki.x.org
 for help. 
(EE) Please also check the log file at "/var/log/Xorg.0.log" for additional 
information.
(EE) 
(II) AIGLX: Suspending AIGLX clients for VT switch
(EE) Server terminated with error (1). Closing log file.
Tue Dec 20 12:32:39 2016 xdm info (pid 16358): sourcing /etc/X11/xdm/Xreset
Tue Dec 20 12:32:39 2016 xdm info (pid 16348): Starting X server on :0
Tue Dec 20 12:32:39 2016 xdm error (pid 16348): Server for display :0 
terminated unexpectedly: 1536
Tue Dec 20 12:32:39 2016 xdm info (pid 16348): Starting X server on :0

X.Org X Server 1.19.0
Release Date: 2016-11-15
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian
Current Operating System: Linux suffix 4.8.0-2-amd64 #1 SMP Debian 4.8.11-1 
(2016-12-02) x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.8.0-2-amd64 
root=UUID=92e1ce07-b39b-462f-aad2-236f67bd86ef ro quiet
Build Date: 23 November 2016  07:20:23PM
xorg-server 2:1.19.0-2 (https://www.debian.org/support) 
Current version of pixman: 0.34.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Tue Dec 20 12:32:39 2016
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
resize called 1680 1050
Tue Dec 20 12:32:40 2016 xdm info (pid 16587): sourcing

Bug#840850: mutt: Mutt can't find S/MIME key to sign messages

2016-10-15 Thread Frank Brokken

Package: mutt
Version: 1.7.0-6
Severity: normal

Dear Maintainer,

When trying to S/MIME sign a message mutt no longer finds my secret key
file. However, the locations of the key files were not changed, the key file
is still there, and until now I've had no probllems when S/MIE signing
messages. 

When trying to S/MIE sign a message mutt replies with:

secret key `6fe6935f.0' not found: End of file?

Maybe this is related to the recent change of how mutt handles PGP? Looking
for clues via Google didn't bring up any useful suggestions. 

My S/MIME certificate is valid, so that can't be the cause of the problem.


-- Package-specific info:
NeoMutt 20160916 (1.7.0)
Copyright (C) 1996-2016 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 4.7.0-1-amd64 (x86_64)
libidn: 1.33 (compiled with 1.33)
hcache backend: tokyocabinet 1.4.48

Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.2.0-4' 
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs 
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared 
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext 
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ 
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib 
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo 
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre --enable-java-home 
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64 
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--enable-objc-gc --enable-mu!
 ltiarch --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 
--enable-multilib --with-tune=generic --enable-checking=release 
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.2.0 20160914 (Debian 6.2.0-4) 

Configure options: '--build=x86_64-linux-gnu' '--prefix=/usr' 
'--includedir=\${prefix}/include' '--mandir=\${prefix}/share/man' 
'--infodir=\${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' 
'--disable-silent-rules' '--libdir=\${prefix}/lib/x86_64-linux-gnu' 
'--libexecdir=\${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' 
'--disable-dependency-tracking' '--with-mailpath=/var/mail' 
'--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache' 
'--enable-gpgme' '--enable-imap' '--enable-smtp' '--enable-pop' 
'--enable-sidebar' '--enable-nntp' '--enable-notmuch' '--disable-fmemopen' 
'--with-curses' '--with-gnutls' '--with-gss' '--with-idn' '--with-mixmaster' 
'--with-sasl' '--without-gdbm' '--without-bdb' '--without-qdbm' 
'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 
-fdebug-prefix-map=/build/mutt-WCcuvM/mutt-1.7.0=. -fPIE 
-fstack-protector-strong -Wformat -Werror=format-security' 'LDFLAGS=-fPIE -pie 
-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-tim!
 e -D_FORTIFY_SOURCE=2'

Compilation CFLAGS: -Wall -pedantic -Wno-long-long -g -O2 
-fdebug-prefix-map=/build/mutt-WCcuvM/mutt-1.7.0=. -fPIE 
-fstack-protector-strong -Wformat -Werror=format-security

Compile options:
+CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME +CRYPT_BACKEND_GPGME 
+DEBUG +DL_STANDALONE +ENABLE_NLS -EXACT_ADDRESS -HOMESPOOL -LOCALES_HACK 
-SUN_ATTACHMENT +HAVE_BKGDSET +HAVE_COLOR +HAVE_CURS_SET +HAVE_GETADDRINFO 
+HAVE_GETSID +HAVE_ICONV +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR 
+HAVE_LIBIDN +HAVE_META +HAVE_REGCOMP +HAVE_RESIZETERM +HAVE_START_COLOR 
+HAVE_TYPEAHEAD +HAVE_WC_FUNCS +ICONV_NONTRANS +USE_COMPRESSED +USE_DOTLOCK 
+USE_FCNTL -USE_FLOCK -USE_FMEMOPEN -USE_GNU_REGEX +USE_GSS +USE_HCACHE 
+USE_IMAP +USE_NOTMUCH +USE_NNTP +USE_POP +USE_SASL +USE_SETGID +USE_SIDEBAR 
+USE_SMTP +USE_SSL_GNUTLS -USE_SSL_OPENSSL 
-DOMAIN
MIXMASTER="mixmaster"
-ISPELL
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/usr/share/mutt"
SYSCONFDIR="/etc"
EXECSHELL="/bin/sh"

patch-attach-headers-color-neomutt
patch-compress-neomutt
patch-cond-date-neomutt
patch-encrypt-to-self-neomutt
patch-fmemopen-neomutt
patch-forgotten-attachments-neomutt
patch-ifdef-neomutt
patch-index-color-neomutt
patch-initials-neomutt
patch-keywords-neomutt
patch-limit-current-thread-neomutt
patch-lmdb-neomutt
patch-multiple-fcc-neomutt
patch-nested-if-neomutt
patch-new-mail-neomutt
patch-nntp-neomutt
patch-notmuch-neomutt
patch-progress-neomutt
patch-quasi-delete-neomutt
patch-reply-with-xorig-neomutt

Bug#826572: S/MIME: secret key not found when using gpgme

2016-06-06 Thread Frank Brokken

Package: mutt
Version: 1.6.0-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

After a mutt update the gpg configuration in .muttrc stopped working. Looking
for a solution I found the advice to specify 

set crypt_use_gpgme

instead. Although that did solve the gpg-problem, it also interfered with
S/MIME encryption. When trying to S/MIME sign a message I got the message

secret key 'xxx.f' not found: Invalid crypto engine?

Simply commenting out the 'set crypt_use_gpgme' configuration line re-allowed
me to use S/MIME signing again.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

1. removed the previous (now defunct) gpg-configuration in ~/.muttrc
2. inserted the line 'set crypt_use_gpgme'
3. in order to use S/MIME signing: comment out the 'set crypt_use_gpgme' line

   * What was the outcome of this action?

With the commented-out 'set crypt_use_gpgme' line S/MIME can be used, when
activating the coniguration line S/MIME can't be used; without the
coniguration line (and with the previously working PGP configuration lines)
GPG can't be used anymore.

   * What outcome did you expect instead?

I expected that replacing the PGP configuration lines by 'set crypt_use_gpgme'
would only affect GPG use, without interfering with using S/MIME. 

If you need any additional information, please let me know.


-- Package-specific info:
Mutt 1.6.0 (2016-04-01)
Copyright (C) 1996-2016 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 4.5.0-2-amd64 (x86_64)
ncurses: ncurses 6.0.20160319 (compiled with 6.0)
libidn: 1.32 (compiled with 1.32)
hcache backend: tokyocabinet 1.4.48

Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 5.3.1-15' 
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs 
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-5 --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib 
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo 
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home 
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with!
 -abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib 
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.3.1 20160421 (Debian 5.3.1-15) 

Configure options: '--prefix=/usr' '--sysconfdir=/etc' 
'--mandir=/usr/share/man' '--with-docdir=/usr/share/doc' 
'--with-mailpath=/var/mail' '--disable-dependency-tracking' 
'--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache' 
'--enable-gpgme' '--enable-imap' '--enable-smtp' '--enable-pop' '--with-curses' 
'--with-gnutls' '--with-gss' '--with-idn' '--with-mixmaster' '--with-sasl' 
'--without-gdbm' '--without-bdb' '--without-qdbm' '--build' 'x86_64-linux-gnu' 
'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wall' 'LDFLAGS=-Wl,-z,relro' 'CPPFLAGS=-Wdate-time 
-D_FORTIFY_SOURCE=2 -I/usr/include/qdbm'

Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wall

Compile options:
-DOMAIN
+DEBUG
-HOMESPOOL  +USE_SETGID  +USE_DOTLOCK  +DL_STANDALONE  +USE_FCNTL  -USE_FLOCK   
+USE_POP  +USE_IMAP  +USE_SMTP  
-USE_SSL_OPENSSL  +USE_SSL_GNUTLS  +USE_SASL  +USE_GSS  +HAVE_GETADDRINFO  
+HAVE_REGCOMP  -USE_GNU_REGEX  
+HAVE_COLOR  +HAVE_START_COLOR  +HAVE_TYPEAHEAD  +HAVE_BKGDSET  
+HAVE_CURS_SET  +HAVE_META  +HAVE_RESIZETERM  
+CRYPT_BACKEND_CLASSIC_PGP  +CRYPT_BACKEND_CLASSIC_SMIME  +CRYPT_BACKEND_GPGME  
-EXACT_ADDRESS  -SUN_ATTACHMENT  
+ENABLE_NLS  -LOCALES_HACK  +COMPRESSED  +HAVE_WC_FUNCS  +HAVE_LANGINFO_CODESET 
 +HAVE_LANGINFO_YESEXPR  
+HAVE_ICONV  -ICONV_NONTRANS  +HAVE_LIBIDN  +HAVE_GETSID  +USE_HCACHE  
-ISPELL
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/usr/share/mutt"
SYSCONFDIR="/etc"
EXECSHELL="/bin/sh"
MIXMASTER="mixmaster"
To contact the developers, please mail to .
To report a bug, please visit http://bugs.mutt.org/.

misc/am-maintainer-mode.patch
features/ifdef.patch

Bug#995757: module: inline class member function cannot use an extern thread_local int

Bug#995000: g++-11: module partition defining a class won't compile

Bug#994292: g++-11: Segfault when defining a module exporting a std::string

Bug#985214: g++-11 internal error and fails to precompile a concept

Bug#953419: cups: unable to print after a recent update

Bug#941655: libreoffice-impress: Exported html pages have black backgrounds

Bug#920351: bash: exec in .profile suspends or loses stdin

Bug#879013: pinentry-qt: _glapi_tls_Current not in libGL.so.1

Bug#878936: gpg: Inaccessible keys (?) after upgrade

Bug#860306: isc-dhcp-client: Repeatedly received DHCPNAK or no DHCPOFFERS; other computers work OK

Bug#848960: xserver-xorg segfaults after starting afterstep

Bug#840850: mutt: Mutt can't find S/MIME key to sign messages

Bug#826572: S/MIME: secret key not found when using gpgme

13 matches

Site Navigation

Mail list logo

Footer information