Bug#1081132: Small correction...
Dear Frank B. Brokken, you wrote:
> The following source file (e.g., interface.cc) defines the module:
>
> module Module;
> export int value;
This must be:
export module Module;
export int value;
--
Frank B. Brokken
(+31) 6 5353 2509
PGP Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#1081132: g++-14: Modules compiled with --std=c++23 can't be used with --std=c++26 and v.v.
Package: g++-14
Version: 14.2.0-3
Severity: normal
Dear Maintainer,
* What led up to the situation?
When trying to import a module in a C++ source file when --std=c++23 was
specified when the module was compiled and --std=c++26 is specified when the
source file is compiled the compiler shows the following error message:
Module: error: language dialect differs ‘C++23/coroutines’, expected
‘C++26/coroutines’
Module: error: failed to read compiled module: Bad file data
Module: note: compiled module file is ‘gcm.cache/Module.gcm’
Module: fatal error: returning to the gate for a mechanical issue
compilation terminated.
When --std=c++26 was specified when the module was compiled the compiler does
not show an error message.
* What exactly did you do (or not do) that was effective (or
ineffective)?
The following source file (e.g., interface.cc) defines the module:
module Module;
export int value;
and the module is used in the following source file (e.g., fun.cc):
import Module;
void fun()
{
value = 10;
}
'interface.cc' was compiled using using
g++ --std=c++23 -fmodules-ts -c interface.cc
'fun.cc' was compiled using using
g++ --std=c++26 -fmodules-ts -c fun.cc
* What was the outcome of this action?
when compiling 'interface.cc' and 'fun.cc' using the mentioned g++ commands
the abovementioned error is reported. When using c++26 when compiling
interface.cc and c++23 when compiling fun.cc a comparable error is
reported. When specifying the same standard (either c++23 or c++26 when
compiling both files no error is reported.
* What outcome did you expect instead?
Normally specifying a more recent C++ standard then files compiled with an
older standard can still be used. I would have expected the same situation
when compiling/using modules. Maybe it's just the switch from c++23 to c++26,
and will the error disappear when combining c++26 and the standard following
c++26, but if not, then we may have to recompile all already compiled modules
or all source files using modules once a new standard becomes available, which
is -let's say- inconvenient.
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.10.6-amd64 (SMP w/2 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 g++-14 depends on:
ii g++-14-x86-64-linux-gnu 14.2.0-3
ii gcc-14 14.2.0-3
ii gcc-14-base 14.2.0-3
g++-14 recommends no packages.
Versions of packages g++-14 suggests:
pn g++-14-multilib
pn gcc-14-doc
-- no debconf information
Bug#1073932: libstdc++-14-dev: 'using' specification results in compiler error when specifying -fmodules-ts
Package: libstdc++-14-dev
Version: 14-20240330-1
Severity: normal
Tags: upstream
Dear Maintainer,
* What led up to the situation?
When specifying a 'using' declaration the compiler produces an error when the
-fmodules-ts flag is used.
* What exactly did you do (or not do) that was effective (or
ineffective)?
The following program compiles correctly when -fmodules is *not* specified,
and produces an error when -fmodules *is* specified. In the latter case: if
instead of the #include directives 'import' statements (like 'import
;' are used the same error results. But when '#include ' (or
'import ;' is omitted compilation using the -fmodules-ts flag
correctly completes.
The following source file (between === lines) was compiled by calling:
g++ --std=c++23 -Wall -fmodules-ts -freport-bug -c main.cc
===
#include
#include
int main()
{
using VectorInt = std::vector;
VectorInt vi(3);
}
===
* What was the outcome of this action?
main.cc: In function ‘int main()’:
main.cc:6:38: error: wrong number of template arguments (1, should be 2)
6 | using VectorInt = std::vector;
| ^
In file included from /usr/include/c++/14/ostream:43,
from /usr/include/c++/14/iostream:41,
of module /usr/include/c++/14/iostream, imported at main.cc:1:
/usr/include/c++/14/format:2577:36: note: provided for ‘template
class std::vector’
2577 | template class vector;
|^~
main.cc:6:28: error: ‘’ in namespace ‘std’ does not name a
type
6 | using VectorInt = std::vector;
|^~~
main.cc:8:5: error: ‘VectorInt’ was not declared in this scope
8 | VectorInt vi(3);
| ^
* What outcome did you expect instead?
The same as when -fmodule-ts is not specified: errorless compilation
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.7.12-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libstdc++-14-dev depends on:
ii gcc-14-base14-20240330-1
ii libc6-dev 2.38-13
ii libgcc-14-dev 14-20240330-1
ii libstdc++6 14-20240330-1
libstdc++-14-dev recommends no packages.
Versions of packages libstdc++-14-dev suggests:
pn libstdc++-14-doc
-- no debconf information
Bug#1073925: libstdc++-14-dev: Using multiple import statements generates an internal compiler error
Package: libstdc++-14-dev
Version: 14-20240330-1
Severity: normal
Tags: upstream
Dear Maintainer,
* What led up to the situation?
Importing multiple module-compiled system headers using compilation commands
like
g++ --std=c++23 -Wall -fmodules-ts -x c++-system-header vector
and importing those compiled system headers in a program results in an
internal compiler error when 'import ;' is also used.
* What exactly did you do (or not do) that was effective (or
ineffective)?
First the system headers where compiled using the abovementioned commad.
Then the compiled headers (like vector.gcm) were made available via the
program's gcm.cache subdirectory. The program was compiled using
g++ --std=c++23 -Wall -fmodules-ts -freport-bug -c main.cc
The following program compiled OK:
import ;
import ;
//import ;
int main()
{
std::vector vect;
}
But when activating 'import ;' compilation fails and the compiler
reports an internal compiler error.
There's no internal compiler error when only vector and memory are imported
(i.e., only using these import statements):
import ;
import ;
but once 'import ;' is also specified the internal compiler error
results.
* What was the outcome of this action?
The compiler, when importing string, vector, and memory, produced the
following output (shown between the lines):
===
In file included from /usr/include/c++/14/format:49,
from /usr/include/c++/14/ostream:43,
from /usr/include/c++/14/bits/unique_ptr.h:43,
from /usr/include/c++/14/memory:78,
of module /usr/include/c++/14/memory, imported at main.cc:7:
/usr/include/c++/14/span: In instantiation of ‘constexpr std::span<_Type,
18446744073709551615> std::span<_Type, _Extent>::subspan(size_type, size_type)
const [with _Type = wchar_t; long unsigned int _Extent = 18446744073709551615;
size_type = long unsigned int]’:
/usr/include/c++/14/format:2671:31: required from ‘constexpr std::span<_Type,
18446744073709551615> std::__format::_Sink<_CharT>::_M_unused() const [with
_CharT = wchar_t]’
2671 | { return _M_span.subspan(_M_next - _M_span.begin()); }
|~~~^~~
/usr/include/c++/14/format:2735:13: required from
‘std::__format::_Sink<_CharT>::_Reservation
std::__format::_Sink<_CharT>::_M_reserve(std::size_t) [with _CharT = wchar_t;
std::size_t = long unsigned int]’
2735 | if (__n <= _M_unused().size())
|^
/usr/include/c++/14/format:2733:7: required from here
2733 | _M_reserve(size_t __n)
| ^~
/usr/include/c++/14/span:439:49: internal compiler error: in insert, at
cp/module.cc:4929
439 | return {this->data() + __offset, __count};
| ^
0x76cb4f trees_in::insert(tree_node*)
../../src/gcc/cp/module.cc:4929
0x76cb4f trees_in::insert(tree_node*)
../../src/gcc/cp/module.cc:4927
0x100da8a trees_in::add_indirect_tpl_parms(tree_node*)
../../src/gcc/cp/module.cc:7353
0x100dbf0 trees_in::add_indirects(tree_node*)
../../src/gcc/cp/module.cc:7419
0x102c17f trees_in::tree_node(bool)
../../src/gcc/cp/module.cc:9964
0x1032d99 module_state::read_cluster(unsigned int)
../../src/gcc/cp/module.cc:14977
0x103364d module_state::load_section(unsigned int, binding_slot*)
../../src/gcc/cp/module.cc:18477
0x103370e module_state::lazy_load(unsigned int, binding_slot*)
../../src/gcc/cp/module.cc:19161
0x1036afc lazy_load_pendings(tree_node*)
../../src/gcc/cp/module.cc:19262
0x10f8887 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../src/gcc/cp/pt.cc:10030
0x10f9fdf tsubst_aggr_type_1
../../src/gcc/cp/pt.cc:14171
0x10fb182 tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.cc:16783
0x10fa5eb tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.cc:16231
0x10ffe94 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.cc:13891
0xf330c2 normalize_concept_check
../../src/gcc/cp/constraint.cc:761
0xf330c2 normalize_atom
../../src/gcc/cp/constraint.cc:816
0xf330c2 normalize_expression
../../src/gcc/cp/constraint.cc:886
0xf33800 normalize_logical_operation
../../src/gcc/cp/constraint.cc:693
0xf337a5 normalize_logical_operation
../../src/gcc/cp/constraint.cc:692
0xf33709 normalize_concept_check
../../src/gcc/cp/constraint.cc:795
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See for instructions.
===
* What outcome did you expect instead?
I expected that the program would also successfully compile when ,
and were imported.
As a more extensive test I also c
Bug#1068068: bobcat, time_t transition lead to apparent ABI break (was: Need rebootstrapping on armel and armhf).
Dear Peter Green, you wrote: > > Also, the bootstrapping procedure is only required when icmake isn't > > available ... Thanks for your bugreport: I'm about to update icmake so that the circular dependency between bobcat and icmake is removed. Shortly after icmake's update bobcat will also be updated. -- Frank B. Brokken (+31) 6 5353 2509 PGP Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA signature.asc Description: PGP signature
Bug#1068068: Need rebootstrapping on armel and armhf
Dear Andrey Rakhmatullin, you wrote: > > Package: icmake,libbobcat6 > Severity: serious > Tags: ftbfs > > As src:icmake B-D:libbobcat-dev, src:bobcat B-D:icmake, there seems to be zero > packaging-level support for bootstrapping, the packages are not > cross-buildable > and the upstream bootstrapping instructions are too tedious, I'm filing this > for visibility (as there are ~14 packages B-D:libbobcat-dev). Thanks for your bug report. You write: > there seems to be zero packaging-level support for bootstrapping, the > packages are not cross-buildable and the upstream bootstrapping instructions > are too tedious, So far no issues were encountered when the bootstrapping procedure as described in the README.bobatbootstrap file in icmake's src distribution is followed. If you could be a bit more specific about what you mean by 'bootstrapping instructions are too tedious' then I'm sure those instructions can be changed so that they're less tedious. Wrt the package not being cross-buildable: The https://packages.debian.org/sid/libbobcat-dev shows the following lines for armel and armhf: armel 6.04.00-1 1,604.2 kB 8,598.0 kB [list of files] armhf 6.04.00-1 1,608.4 kB 8,126.0 kB [list of files] although I also see packages for which version 6.04.00-1+b2 or 6.04.00-1+b4 is listed. So maybe for unstable some issues recently appeared? Also, the bootstrapping procedure is only required when icmake isn't avaialble yet. For the construction of the bobcat library icmake 11.01.02-1 is required, and icmake.01.02-1 needs libbobcat-dev >= 5.07.00, which is available since bullseye (oldstable). So maybe you can also provide some info about why the bootstrapping procedure is needed/used? In any case: the dependence on icmake when constructing the full bobcat library could be avoided, but I'd rather not do that once icmake *is* available. So please advise. -- Frank B. Brokken (+31) 6 5353 2509 PGP Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA signature.asc Description: PGP signature
Bug#1049986: ITP: filtermail -- Filtermail filters incoming e-mail as accepted, spam, or ignored
Package: wnpp Severity: wishlist Owner: Frank Brokken X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: filtermail Version : 1.02.00 Upstream Contact: Frank B. Brokken * URL : https://fbb-git.gitlab.io/filtermail * License : GPL Programming Lang: C++ Description : Filtermail filters incoming e-mail as accepted, spam, or ignored Filtermail filters incoming e-mail as either accepted, spam, or ignored e-mail. It uses rule files, which are inspected in sequence until the incoming e-mail matches a rule. Once that happens the rule's associated action (accept, spam, or ignore) is executed. If the e-mail is not matched by any rule then the e-mail is accepted. Accepted e-mail normally is appended to the mail file which is used by the incoming mail server when receiving mail for the current user. E.g., if the user's username is frank then incoming mail is appended to the file /var/mail/frank. Users may also define directories to contain saved e-mails (e.g., ~/Mail), and filtermail can be configured to append e-mail considered as spam to, e.g., ~/Mail/spam. Likewise, e-mail matching the 'ignore' criteria could be appended to ~/Mail/ignore. Instead of appending the complete e-mail to its destination file the received e-mail's From: and Subject: headers can be appended to its destination file. Alternatively, such e-mail can also be ignored, losing it completely. Filtermail uses three types of files: * The configuration file contains values of options with are generally used (covered in the man-page's sections CONFIGURATION and OPTIONS); * Mail filtering rules are hierarchically ordered in the rules file: incoming mail is sequentially matched against the patterns defined in files specified in the rules file until a match is found. Once a match has been found the rule's action (accept, ignore or spam) is executed, ending the filtering process; * Each file specified in the rules file defines matching patterns, which are tested sequentially. Testing those patterns ends once the incoming mail matches a pattern. In addition to the filtermail program itself a small support program 'inspect' is part of filtermail: inspect expects a received e-mail file at its standard input. Mail handling programs (e.g., mutt(1)) allow its users to pipe an e-mail file to a program, inspecting the received e-mail. Depending on the content of the Received: headers inspect's output shows the domain name of the sender, its IP address, its country of origin and the cidr-range containing the received IP address. If the received e-mail is considered conspicuous (e.g., spam or mail to ignore) then the mail's details, e.g. its cidr range. could be added to the file recognizing spam-rated e-mail. - why is this package useful/relevant? The main reason for developing filtermail was the fact that I frequently receive mail which is either spam or which is completely irrelevant and annoying. Previously I used a bash-script to filter such mail, but that script eventually was hard to maintain. A compilable program offers, IMHO, better facilities for maintenance and modifications so I wrote filtermail. Over the past three months it performed its job as expected. E.g., of the about 300 e-mails I received in the category 'igored' were all correctly categorized. - it a dependency for another package? No, it's a stand-alone program - do you use it? Yes, I do - if there are other packages providing similar functionality, how does it compare? There exists a program 'mailfilter' focusing on handling pop-accounts and also offering ways to recognize e-mail as spam. Filtermail, on the other hand, uses the 'ignore' category in addition to the 'spam' category and primarily aims at categorizing (in various forms) incoming e-mail. - how do you plan to maintain it? I have a long history of building and maintaining programs, many of them are also registered as Debian packages. I handle the maintenance of the programs myself, and almost all my direct contact with Debian is via Tony Mancill (tmanc...@debian.org) who is a Debian developer. When there's a new version of one of my Debian provided programs I prepare the required update, upload it to salsa, and send Tony an e-mail asking him to verify the latest update. Filtermail's website is at https://fbb-git.gitlab.io/filtermail/ where you also find links to the man-pages, to its repository, and to a list of programs I developed, most of them are available as Debian packages. - do you need a sponsor? If I'm correct then the 'sponsor' is a Debian maintainer who's willing to adopt a program for Debian. If so, then yes, I do. I hope you like filtermail!
Bug#1001646: libgeoip1 can't determine the country of an ipaddress, but www.maxmind.com does report it
Package: libgeoip1
Version: 1.6.12-8
Severity: normal
Dear Maintainer,
* What led up to the situation?
Our Internet provider assigned us address 185.202.110.161. The following
minimal C++ program reports:
'185.202.110.161 not found in GeopIP database':
int main()
{
char const *ip = "185.202.110.161";
GeoIP *gi = GeoIP_open("/usr/share/GeoIP/GeoIP.dat",
GEOIP_MEMORY_CACHE);
if (!gi)
return 1;
char const *country = GeoIP_country_code_by_addr(gi, ip);
if (!country)
cout << ip << " not found in GeopIP database\n";
}
* What exactly did you do (or not do) that was effective (or
ineffective)?
Since libgeoip1 lists www.maxmind.com] as its 'External Resource', I entered
the above address at https://www.maxmind.com/en/home
* What was the outcome of this action?
The page https://www.maxmind.com/en/geoip2-precision-demo was opened and
showed the correct country and ISP.
* What outcome did you expect instead?
Since www.maxmind.com correctly reported details like the address's country
and ISP, I had expected that libgeoip1 would also produce the correct
country. I tried several other (existing) addresses using the above program,
and it correctly produced the countries of those addresses
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.15.0-2-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libgeoip1 depends on:
ii libc6 2.32-5
Versions of packages libgeoip1 recommends:
ii geoip-database 20191224-3
Versions of packages libgeoip1 suggests:
ii geoip-bin 1.6.12-8
-- no debconf information
Bug#985214: g++-11 internal error and fails to precompile a concept
Dear Matthias Klose, you wrote:
>
> (2) now shows a proper error, as shown below.
>
> Please could you report the other issues upstream?
OK.
--
Frank B. Brokken
(+31) 6 5353 2509
PGP Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#953419: cups: unable to print after a recent update
Dear Brian Potkin, you wrote: > > On Mon, Mar 09, 2020 at 01:48:58PM +0100, Frank Brokken wrote: > > >* What outcome did you expect instead? > > > > After the update I expected the print commands to continue working > > All present and future bugs in HPLIP can be avoided after reading > > https://wiki.debian.org/CUPSDriverlessPrinting > > I would use the driverless command and lpadmin to set up a queue. Hi Brian, Thanks for your reply. Unfortunately, now I'm left in a somewhat confused state. It's possible that I overlooked some important update item, but normally when updating programs continue to work, and if a reconfiguration is necessary then that's clearly shown in, e.g., the changelog. If I correctly understand your (above) advice then you ask me to read a document of some 20 sections, explaining the concept of 'CUPSDriverlessPrinting'. It's a thorough document, but maybe a bit over the top for users who would merely like to be able to continue printing? I've now downgraded hplip to the stable version, and all's working again. But I think an upgrade to the version in 'testing' is preferable, since my computer's normal distribution is 'testing'. Is there maybe some quick (step-by-step) upgrading guide explaining how to upgrade from the stable-release software to the testing-release software without encountering print-failures? I think such a guide would be really useful. Please advise, -- Frank B. Brokken (+31) 6 5353 2509 PGP Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#948766: flexc++ FTBFS in sid
Dear tony mancill, you wrote: > > Source: flexc++ > Version: 2.07.06-1 > Severity: important > > flexc++ FTBFS in sid with the following error: > ... > > mv: cannot stat 'flextypes/flextypes.ih.gch': No such file or directory > > Fatal: builtin_execute - program indicates failure (status 256) For the sake of completeness: same cause as the compilation error encountered with bisonc++: requires a minor fix in /usr/lib/icmake/icmbuild: it'll be available later today. Cheers, -- Frank B. Brokken (+31) 6 5353 2509 PGP Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#948765: stealth FTBFS in unstable
Dear tony mancill, you wrote: > > Source: stealth > Severity: important > > I noticed that stealth fails to build from source in Debian sid. The > build fails with the following error: > ... > > mv: cannot stat 'syslogstruct/syslogstruct.ih.gch': No such file or > > directory > > Fatal: builtin_execute - program indicates failure (status 256) For the sake of completeness: same cause as the compilation error encountered with bisonc++: requires a minor fix in /usr/lib/icmake/icmbuild: it'll be available later today. Cheers, -- Frank B. Brokken (+31) 6 5353 2509 PGP Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#948768: bisonc++ FTBFS in sid
Dear tony mancill, you wrote: > > Source: bisonc++ > Version: 6.03.00-1 > Severity: important > > bisonc++ FTBFS in sid with the following error: > > > RECOMPILE: main.cc > > g++ -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong > > -Wformat -Werror=format-security -Wall --std=c++2a -D_FORTIFY_SOURCE=2 -c > > -o tmp/main.o main.cc > > > > chdir tmp > > g++ -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong > > -Wformat -Werror=format-security -Wall --std=c++2a -D_FORTIFY_SOURCE=2 -o > > bin/binary main.o -lmodules -L. -lbobcat -Wl,-z,relro -Wl,-z,now -Wl,-z,now > > mv: cannot stat 'enumsolution/enumsolution.ih.gch': No such file or > > directory > > Fatal: builtin_execute - program indicates failure (status 256) > > The build failure appears to be the same as that observed for flexc++ > and stealth, so perhaps there is a common root cause in the build chain. > I've filed this bug along with the others to track it down. Oops... The bug is caused by a small flaw in icmake's 9.03.00's /usr/lib/icmake/icmbuild script. It's easily fixed and I'll prepare icmake 9.03.01 later today. Cheers, -- Frank B. Brokken (+31) 6 5353 2509 PGP Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#941655: libreoffice-impress: Exported html pages have black backgrounds
Dear Rene Engelhard, you wrote: > On Sat, Oct 12, 2019 at 01:37:50PM +0200, Rene Engelhard wrote: > > On Sat, Oct 12, 2019 at 01:34:44PM +0200, Rene Engelhard wrote: > > > See http://people.debian.org/~rene/libreoffice/6.3 > > > (apt-gettable via "deb http://people.debian.org/~rene/libreoffice/6.3 ./" > > > in sources.list, but you should know that..) > > > > Sorry, sent too fast, it's building and I forgot I deleted the older > > snapshot which was there. Will be there if the build finishes and I > > uploaded it, though. > > It's now there. OK, after removing the current Debian testing version and installing the snapshot versions everything looks good again. Many thanks for your help! -- Frank B. Brokken (+31) 6 5353 2509 PGP Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#941655: libreoffice-impress: Exported html pages have black backgrounds
Dear Rene Engelhard, you wrote: > > [ always keep the bug in the Cc so that discussions about the bug are > recorded ] You're absolutely right: I simply did a reply in my previous answer. Sorry about that. > On Sat, Oct 12, 2019 at 05:38:38PM +0200, Frank B. Brokken wrote: > > By desktop you mean window manager? That's afterstep (2.2.12-12+b1). There's > > No, I mean desktop. Oh. Well, in that case: the computer I used, and have been using previously when everything worked fine, is an Acer travelmate P 276, but see also below: my office's desktop also shows the bug. > ... > And here I actually meant vcl, not vlc. Aka libreoffice-gtk, -gtk3, > -qt5, -kde5. > > But given yu use afterstep I believe you have neither installed not > explicitely choosen one of those. Correct. Since installing libreoffice doesn't automatically install that package as well, it's apparently not required. Also, since it hasn't been installed before when exporting html worked OK, I guess it's unlikely that that's the cause of the problem. > Which makes this definitely unreproducible here, since that "gen"eric > one was what I tried in my chroot. That's a pity (i.e., that you can't reproduce the problem). At my office I have an ordinary desktop computer (I don't have its brand name handy) and that one I used to file the bug. So there are two completely different computer systems that produced the bug, which previously wasn't encountered. Any suggestions as to how to proceed from here? -- Frank B. Brokken (+31) 6 5353 2509 PGP Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#941554: yodl: build-depend on texlive-plain-generic, not obsolete texlive-generic-recommended
Dear Steve Langasek, you wrote: > Package: yodl > Version: 4.02.01-2 > Severity: serious > Tags: patch > User: ubuntu-de...@lists.ubuntu.com > Usertags: origin-ubuntu eoan ubuntu-patch > > Dear maintainers, > > The texlive-generic-recommended transitional package has been dropped from > texlive-base in sid. Please update your build-dependency to > texlive-plain-generic instead. Thanks for the bug report: I'll handle that either today or tomorrow. -- Frank B. Brokken (+31) 6 5353 2509 PGP Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#922788: mark yodl Multi-Arch: foreign
Dear Helmut Grohne, you wrote: > Package: yodl > Version: 4.02.00-3 > Tags: patch > User: helm...@debian.org > Usertags: rebootstrap > Control: affects -1 + src:rsync > > rsync fails to cross build from source, because it fails running yodl. > Typically this means that rsync should use the build architecture yodl > rather than the host architecture yodl. One way to get there is marking > yodl Multi-Arch: foreign. Such a marking is correct, becaue yodl deals > with architecture-independent file formats. The input format is textual > as are most output formats. Please consider applying the attached patch. > > Helmut Thanks for your bug report. I'll process it no later than this weekend. Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#914625: Natlog fails to start due to a typo.
Dear abe...@gmx.com, you wrote: > > Package: natlog > Version: 1.02.03-1+b1 > > Natlog's init script fails to start the service. The reason is simply > that in the change from oldstable to stable natlog's binary moved > from /usr/sbin to /usr/bin, but the init script does not reflect that > change. > > Simply changing DAEMON=/usr/sbin/$NAME to DAEMON=/usr/bin/$NAME > in /etc/init.d/natlog fixes the issue. > > Bug initially reported to a downstream distribution, forwarded here > after reproducing it in vanilla Debian live. Thanks for the bug report (and also for the provided fix :-) I'll prepare a new version asap. Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#910146: bisonc++-doc: broken symlinks: /usr/share/doc/bisonc++-doc/demos/{manual,calculator/scanner/lexer}
Dear Andreas Beckmann, you wrote:
> Package: bisonc++-doc
> Version: 6.02.00-1
> during a test with piuparts I noticed your package ships (or creates)
> a broken symlink.
Thanks for the bug report. I'll probably have it fixed by tomorrow.
Cheers,
--
Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#901119: yodl: FTBFS when built with dpkg-buildpackage -A
Dear Santiago Vila, you wrote: > Sorry, there was a typo in the bug report. I meant "buster" of course. Ah, muy bien. Thanks for the clarification. > The reason for this is that -A was never tried with the current > version (4.02.00-2). > > You can avoid this type of bugs to propagate to testing by uploading > in source-only form (dpkg-buildpackage -S). That way we would get > official build logs here for the arch:all autobuilder: > > https://buildd.debian.org/status/package.php?p=yodl Thx for the advice! -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#901119: yodl: FTBFS when built with dpkg-buildpackage -A
Dear Santiago Vila, you wrote: > > Package: src:yodl > Version: 4.02.00-2 > Severity: serious > > Dear maintainer: > > I tried to build this package in stretch with "dpkg-buildpackage -A" > but it failed: (etc) Dear Santiago, Thx for the bug report. I'll have a look at it asap. As a side note: As `stretch' is the current stable distribution I'm slightly curious as to what may be have caused this error. Maybe -A has never been used? Anyway, I'll check things out. Maybe it's only required to define the missing target in debian/rules :-) Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#887731: bisonc++ FTBFS with yodl 4.02.00-2
Dear Adrian Bunk, you wrote: > > Source: bisonc++ > Version: 6.00.00-2 > Severity: serious > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/bisonc++.html > > ... > ./build man > mkdir -p tmp/man tmp/manhtml > yodl2man -o ../../tmp/man/bisonc++.1 bisonc++.yo > Yodl2man 4.02.00 > Yodl: including file ../../release.yo > bisonc++.yo:30: DEFINEMACRO: `tr' multiply defined Thanks! This is comparable to what you noticed yesterday with the C++ Annotations. I'll probably have it fixed by tomorrow. -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#887581: c++-annotations FTBFS with yodl 4.02.00-2
Dear Adrian Bunk, you wrote: > > Source: c++-annotations > Version: 10.9.0-1 > Severity: serious > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/c++-annotations.html > > ... > yodl2txt --no-warnings -o ../tmp/docs/txt/cplusplus.txt -l3 cplusplus > Yodl2html 4.02.00 > Yodl: including file preamble > preamble.yo:208: DEFINEMACRO: `nbsp' multiply defined Oops... Thanks: I'll fix that later today. -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#879013: pinentry-qt: _glapi_tls_Current not in libGL.so.1
Dear Daniel Kahn Gillmor, you wrote: > ... I've > gone ahead and reassigned this bug to libglvnd0-nvidia, but i don't have > the version information to know specifically which versions caused the > problems. Maybe you can document that here so that it can be tracked > down? Sure: this is what /var/log/apt/history.log tells me: Start-Date: 2017-10-19 11:32:52 Install: libglvnd0:amd64 (0.2.999+git20170802-5) Remove: libglvnd0-nvidia:amd64 (375.82-5) End-Date: 2017-10-19 11:32:54 If you need more info, don't hesitate to ask. -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA signature.asc Description: PGP signature
Bug#879013: pinentry-qt: _glapi_tls_Current not in libGL.so.1
Dear Daniel Kahn Gillmor, you wrote: > Control: tags 879013 + moreinfo unreproducible > > Hi Frank-- Hi Daniel, Thanks for the quick response! > Can you confirm this with pinentry directly? > > ... > > Could you show me a comparable transcript? I could, but it's probably not needed anymore, as I think I located the problem: I ran pinentry-qt on another computer of mine, where it ran OK. The libGL.so.1.0.0 libraries on both computers were identical, so I used ldd to determine which libs were used by libGL.so.1.0.0. Then I noticed that /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 on both computers differed: the computer where pinentry-qt did *not* work had: 711864 Jul 20 05:28 libGLdispatch.so.0 whereas on the one where pinentry-qt *did* work showed: lrwxrwxrwx 1 22 Sep 28 22:04 /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 -> libGLdispatch.so.0.0.0 -rw-r--r-- 1 612808 Sep 28 22:04 /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0.0.0 On the one where it did *not* work libglvnd0-nvidia was installed, and that one prevented libGLdispatch from being upgraded. I replaced libglvnd0-nvidia by libglvnd0, and that solved the issue. Hm, non-free software... So, apologies for the fuzz, which clearly was not caused by pinentry-qt, and so I suggest to close this bugreport as well. If you need any additional information, please let me know. Kind regards, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA signature.asc Description: PGP signature
Bug#878936: Solved: gpg - Inaccessible keys (?) after upgrade
Dear maintainer(s), Wrt the bugreport I filed yesterday: after closely reading Gnu's gnupg documentation I solved the problem I encountered yesterday, so I think this issue can be closed. My current gpg.conf file now merely needs use-agent (and so `pinentry-mode loopback' was removed). My gpg-agent.conf file now contains default-cache-ttl 1200 pinentry-program /usr/bin/pinentry-curses and so the line `allow-loopback-pinentry' was removed (the more generic specification `pinentry-program /usr/bin/pinentry' probably also works, but so far I didn't configure that) In addition, whenever I open a new terminal (xterm, rxvt, virtual terminal) the session's startup script executes (for bash): GPG_TTY=`tty` # note the backticks! export GPG_TTY For tcsh it is: setenv GPG_TTY `tty`# note the backticks! After these specifications gpg again worked as before. Kind regards, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#872792: openssl caused the problem: withdrawing the bug report
Dear maintainer, As I wrote in my previous e-mail: > Once I know more I'll let you know. The client computer that suddenly couldn't use pop3s anymore is a Windows system. I turns out that that system required an explicit update and some registry manipulations to enable TSL 2.0. Once that was realized everything worked again as usual. As this solves the problem, and also clarifies what caused it, I hereby request you to close or drop my bug report. Kind regards, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#872792: Some additional info: openssl update
Dear maintainer,
Wrt the bug report I filed this morning: while looking for more
information I just came across a changelog.Debian item in the openssl package,
dated August 7th, 2017: Kurt Roeckx wrote that TLS 1.0 and 1.1 are disabled in
the openssl package. I still have to figure out whether that update has
introduced the problem, but considering that these changes were installed
yesterday in my computer it's likely that it has. Once I know more I'll let
you know.
Kind regards,
--
Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#872792: tls_process_client_hello: version too low
Package: stunnel4 Version: 3:5.39-2 Severity: normal Dear Maintainer, * What led up to the situation? Yesterday I ran `aptitude upgrade' after not having been able to upgrade packages for about a month. Since the upgrade using stunnel4's service pop3s fails with the following info in tunnel.log, using the debug=7 specification: 2017.08.21 11:40:08 LOG7[main]: Found 1 ready file descriptor(s) 2017.08.21 11:40:08 LOG7[main]: FD=4 events=0x2001 revents=0x0 2017.08.21 11:40:08 LOG7[main]: FD=7 events=0x2001 revents=0x1 2017.08.21 11:40:08 LOG7[main]: Service [pop3s] accepted (FD=3) from 89.200.38.152:56146 2017.08.21 11:40:08 LOG7[1]: Service [pop3s] started 2017.08.21 11:40:08 LOG7[1]: Option TCP_NODELAY set on local socket 2017.08.21 11:40:08 LOG5[1]: Service [pop3s] accepted connection from 89.200.38.152:56146 2017.08.21 11:40:08 LOG6[1]: Peer certificate not required 2017.08.21 11:40:08 LOG7[1]: TLS state (accept): before SSL initialization 2017.08.21 11:40:08 LOG7[1]: TLS state (accept): before SSL initialization 2017.08.21 11:40:08 LOG7[1]: TLS alert (write): fatal: protocol version 2017.08.21 11:40:08 LOG3[1]: SSL_accept: 1417D18C: error:1417D18C:SSL routines:tls_process_client_hello:version too low 2017.08.21 11:40:08 LOG5[1]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket 2017.08.21 11:40:08 LOG7[1]: Local descriptor (FD=3) closed 2017.08.21 11:40:08 LOG7[1]: Service [pop3s] finished (0 left) * What exactly did you do (or not do) that was effective (or ineffective)? I searched for the `version too low' message on the Internet, but except for messages ealier this year about stunnel4 being killed by shadowserver.org, which do not provide suggestions about how to solve the issue nothing useful was found. Also, the changelog and changelog.Debian files did not contain information about this message. * What was the outcome of this action? The problem remains. * What outcome did you expect instead? I hoped to find some information about what causes this problem, and preferably also some information about how to solve the problem. Maybe I missed the obvious, if so, or if you need any additional information, 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.12.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages stunnel4 depends on: ii adduser 3.116 ii libc62.24-14 ii libssl1.11.1.0f-4 ii libsystemd0 234-2 ii libwrap0 7.6.q-26 ii lsb-base 9.20161125 ii netbase 5.4 ii openssl 1.1.0f-4 ii perl 5.26.0-5 stunnel4 recommends no packages. Versions of packages stunnel4 suggests: pn logcheck-database -- Configuration Files: /etc/default/stunnel4 changed [not included] /etc/logrotate.d/stunnel4 changed [not included] -- no debconf information
Bug#871210: stealth: FTBFS: ! LaTeX Error: Lonely item--perhaps a missing list environment.
Dear Lucas Nussbaum, you wrote: > > Source: stealth > Version: 4.01.05-2 > Severity: serious > Tags: buster sid > User: debian...@lists.debian.org > Usertags: qa-ftbfs-20170805 qa-ftbfs > Justification: FTBFS on amd64 > > Hi, > > During a rebuild of all packages in sid, your package failed to build on > amd64. Hi Lucas, Thanks for your bug report. I'll check it out asap. -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#860306: [pkg-dhcp-devel] Bug#860306: isc-dhcp-client: Repeatedly received DHCPNAK or no DHCPOFFERS; other computers work OK
Dear Mike, Here's a follow-up on my yesterday 8:53 (+200) e-mail: > next week I'll be able to test the dhcp connection on the 2nd network I wrote > about, and I'll let you know the results. Well, this moring I was able to test the connection to the second network I wrote about. Before that I had completely deinstalled avahi-daemon, and shortly after that I already noticed a marked increase in speed when establishing a DHCP connection to several other networks. This moring, when I tried to connect to that 2nd network (to which I coudln't connect anymore in the recent past) a connection was now *immediately* established. So, although I won't be able to test connecting to the first network that caused problems (that one's in India, while I'm in the Netherlands ;-), I'm now fairly confident that in fact avahi-daemon was causing the problems. So I suggest that my bug report is closed: my apologies if my initial report already made you search for possible causes, and thank you for your helpful earlier replies. Unrelated to isc-dhcp-client: I still don't know why avahi-daemon was initially installed. I noticed that it's recommened by cups, but it really doesn't appear to do any good Thanks again, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#860306: [pkg-dhcp-devel] Bug#860306: isc-dhcp-client: Repeatedly received DHCPNAK or no DHCPOFFERS; other computers work OK
Dear Michael Gilbert, you wrote:
>
> Also, consider googling for why you might receive a DHCP NAK and see
> if any of those reasons explain your problem.
Hi Mike,
Thanks for both replies. After the initial bugreport I did some googling about
avahi, the upshoot of which being that I already removed avahi-daemon. Early
next week I'll be able to test the dhcp connection on the 2nd network I wrote
about, and I'll let you know the results.
Thanks again,
--
Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#859109: stealth: FTBFS on hurd-i386
Dear Svante Signell, you wrote: > Source: stealth > Version: 4.01.05-1 > Severity: important > Tags: patch, upstream > User: debian-h...@lists.debian.org > Usertags: hurd > > Hi, > > stealth currently FTBFS on GNU/Hurd due to a PATH_MAX issue. The attached > patch > fixes this issue by using getcwd(3) with arguments NULL,0 supported by all > recent versions of glibc. Thanks for the report (and the proposed patch). Right now I'm abroad and cannot put effort in fixing the bug, bug next week I'll be back and I'll prepare a fix. Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA signature.asc Description: PGP signature
Bug#848960: xserver-xorg segfaults after starting afterstep
History of previous conversations with Emilio Pozuelo (accidentally not posted to 848...@bugs.debian.org): Fri, 23 Dec 2016 00:04:49 +0100 Emilio suggested to obtain a backtrace, using the info at https://www.x.org/wiki/Development/Documentation/ServerDebugging/ Wed, 11 Jan 2017 13:30:05 +0100 Frank observed that xserver-xorg-core-dbg, suggested by the info at the above URL, is not mentioned at https://packages.debian.org for xserver-xorg-core 2:1.19.0-3 Wed, 11 Jan 2017 13:41:47 +0100 Emilio advised to look at https://wiki.debian.org/AutomaticDebugPackages for links to more recent debug packages. Based on what I found at that wiki I added deb http://debug.mirrors.debian.org/debian-debug/ testing-debug main to /etc/apt/sources.list and installed xserver-xorg-core-dbgsym, xserver-xorg-video-ati-dbg (and by implication xserver-xorg-video-radeon-dbg), and xserver-xorg-video-nouveau-dbg. I'm afraid that what follows ends in something like an anti-climax, but here we go: Next I started the debug session. Here's the transcript: GNU gdb (Debian 7.12-4) 7.12 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... "/usr/bin/Xorg": not in executable format: File format not recognized Attaching to process 8247 [New LWP 8251] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 0x7fe479ae2fd3 in epoll_wait () at ../sysdeps/unix/syscall-template.S:84 84 ../sysdeps/unix/syscall-template.S: No such file or directory. (gdb) cont Continuing. Thread 1 "Xorg" received signal SIGHUP, Hangup. [ I ended the session ] 0x7fe479ae2fd3 in epoll_wait () at ../sysdeps/unix/syscall-template.S:84 84 in ../sysdeps/unix/syscall-template.S (gdb) cont Continuing. [Thread 0x7fe46e0a8700 (LWP 8251) exited] [ I completed the logout ] [New Thread 0x7fe46e0a8700 (LWP 12395)] quit ^C Thread 1 "Xorg" received signal SIGINT, Interrupt. 0x7fe479ae2fd3 in epoll_wait () at ../sysdeps/unix/syscall-template.S:84 84 in ../sysdeps/unix/syscall-template.S (gdb) detach Detaching from program: /usr/lib/xorg/Xorg, process 8247 (gdb) quit This time all actions successfully completed. No crash occurred. After killing xdm and Xorg and restarting xdm the session didn't crash. I tried that several times in a row, and all sessions ran OK. Next, I deinstalled xserver-xorg-core-dbgsym and restarted xdm/Xorg The session ran OK: no crashes. Then I deinstalled xserver-xorg-video-ati-dbg (and by implication xserver-xorg-video-radeon-dbg) and restarted xdm/Xorg Once again: the session ran OK, no crashes. The only dbg package now left is xserver-xorg-video-nouveau-dbg. I deinstalled it and restarted xdm/Xorg Contrary to my expectations, this session ran OK as well. As a final test I rebooted my computer. After the reboot I opened another X session using afterstep and no problems were encountered. So, I have absolutely no idea what caused the crashes I experienced in December, and neither do I know why no crashes occurred when using fvwm as window manager. But since the problem doesn't manifest itself anymore, there's clearly no way to debug it and consequently I suggest to end this bug report. Emilio, thank you for your cooperation, so far. -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#826572: Follow up on my earlier bug-report
Dear Anonio, I'm somewhat confused. Earlier this week I noticed that mutt's pgp handling stopped working given that my .muttrc contained configuration lines like set pgp_decrypt_command ="/usr/bin/gpg --passphrase-fd 0 --no-verbose --quiet --batch --output - %f" PGP could again be used after replacing those lines by set crypt_use_gpgme But then I noticed that that line conflicted with mutt's S/MIME handling (for which my .muttrc has comparable configuration lines). After commenting out the 'set crypt_use_gpgme' line S/MIME handling was working again. But I just noticed that gpg-handling *also* seems to be working fine. So: Without 'set crypt_use_gpgme' and without explicit gpg-handling settings but with S/MIME settings both S/MIME and GPG are apparently working fine. Maybe the gpg-configuration lines are no longer required? I don't know, and this is what somewhat confuses me. But since both appear to be working fine, I think there's no real need for keeping bug report #826572 open. Assuming that I'm not overlooking something trivial, then as far as I'm concerned it can be closed: apologies for the confusion. If you need any additional info from me, please let me know. Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA signature.asc Description: PGP signature
Bug#814438: stealth: FTBFS when built with dpkg-buildpackage -A (binary build with no binary artifacts)
Dear Santiago Vila, you wrote: > tags 814438 + patch > thanks > > The following patch switches debian/rules to "dh" and also fixes this > bug as a side effect. > > Thanks. Hi Santiago, Muchas gracias por `el patch' ;-) I just applied your patch and fixed some typos in the upstream sources, resulting in Stealth 4.01.05 and Debian version 4.01.05-1: the new version closing 814438 should arrive shortly. Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA signature.asc Description: PGP signature
Bug#823043: zsh FTBFS since yodl 3.08.00-1 in the same way that c++-annotations FTBFSed with 3.07.00-1 (was: Re: Bug#823043 closed by f.b.brok...@rug.nl (Frank B. Brokken) (Bug#823043: fixed in yodl 3
Dear Axel Beckert, you wrote: > Hi Frank, Hi Axel, You wrote: > I'm not 100% sure what's going on, but it seems to me that while > c++-annotations indeed FTBFS with 3.07.00-1 and builds fine again with > 3.08.00-1 (verified it :-), it's the opposite way round with zsh: > > It builds fine with yodl 3.07.00-1, but FTBFS with 3.08.00-1 as > follows: > > ...Zsh Yodl-to-man converter > Including file Zsh/zftpsys.yo > yodl -k -L -o ../../Doc/zshzle.1 -I../../Doc:. -w zman.yo version.yo > ../../Doc/zshzle.yo > Zsh Yodl-to-man converter > Including file Zsh/zle.yo > yodl -k -L -o ../../Doc/zshall.1 -I../../Doc -DZSHALL -w zman.yo version.yo > zsh.yo > `ZSHALL' (symbol) multiply defined > `ZSHALL' (symbol) multiply defined > `ZSHALL' (symbol) multiply defined > Error(s) in command line arguments. Terminating > ... Thanks for reporting this bug: I just downloaded the zsh source package and can reproduce the error. I'll have a look at what's going, and report back to you once I know more. Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA signature.asc Description: PGP signature
Bug#823043: c++-annotations: FTBFS: `APATH' (symbol) multiply defined
Dear Chris Lamb, you wrote: > Source: c++-annotations > Version: 10.5.0-1 > Severity: serious > Justification: fails to build from source > User: reproducible-bui...@lists.alioth.debian.org > Usertags: ftbfs > X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org > > Dear Maintainer, > > c++-annotations fails to build from source in unstable/amd64: Hi Chris, Thanks for your bug report. It looks like you encountered a real bug, and I'm still somewhat in the dark as to why it never has been observed before. Because of that (i.e., me satisfying my own curiosity) I'll need a bit more time to submit a fix, but at least I think I've located the cause of the problem. I'll probably have a fix ready by Monday or a bit earlier. One minor thing: it's not an Annotations issue, but a bug in the Yodl package. I suggest you (or Tony, or George, who receive CCs) reassign this bug to yodl, since that's where the fix is required. Thanks again, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA signature.asc Description: PGP signature
Bug#822519: bobcat: FTBFS: /usr/bin/yodl indicates failure
Dear Martin Michlmayr, you wrote: > > Package: bobcat > Version: 4.01.04-1 > Severity: serious > > Hi Frank, here's a build failure of bobcat. I don't know if it's a > regression in yodl or if something has to change in bobcat, but in any > case, bobcat fails to build from source in unstable (FTBFS): Thanks again! I overlooked your e-mail, but I was informed by Tony about it. It's the same issue as with bisonc++, and right now I'm preparing a fix, which should be ready within the hour. Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA signature.asc Description: PGP signature
Bug#822410: bisonc++: FTBFS: failure of system call / usage: ...
Dear Martin Michlmayr, you wrote:
> Yeah, that's the whole point of these archive rebuilds of unstable
> that various people in Debian do -- to rebuild everything in unstable
> and to catch build failures because of something changed in unstable
> (e.g. toolchain, libraries, other tools).
Agree 100%. And the fix is on its way :-)
Thanks again!
--
Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#822410: bisonc++: FTBFS: failure of system call / usage: ...
Dear Martin Michlmayr, you wrote: > Looks like Tony can reproduce it. I just wanted to add briefly that > this has nothing to do with HPE Helion. It's a normal Debian > installation and a normal Debian sid chroot using sbuild. Oops, guys: OK, hold your fire: the flaw is at my side: I missed that Martin already used yodl 3.07.01, and while reading Tony's mail I noticed that Tony *did* use the latest Yodl version. When I do that too, I also reproduced the error. So I think the bug can safely be reassigned to yodl, and I also think it can quickly be fixed. Thanks for the quick reply, guys: I'll do my best to come up with the fix equallly quick :-) Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA signature.asc Description: PGP signature
Bug#822410: bisonc++: FTBFS: failure of system call / usage: ...
Dear Martin Michlmayr, you wrote: > > Package: bisonc++ > Version: 5.00.00-1 > Severity: serious > > This package fails to build in unstable: > > > sbuild (Debian sbuild) 0.68.0 (15 Jan 2016) on dl580gen9-02.hlinux > ... > > Yodl: including file algorithm/ruleprec.yo > > Yodl: including file algorithm/condep.yo > > Yodl: including file algorithm/reduce.yo > > usage: [-a] [-N] [-n] [-s] [-t] [-S] [-T] marker file > > See also: `man yodlverbinsert' > > Yodl: including file algorithm/mysterious.yo ... > > Fatal: system - failure of system call (status 256) > > debian/rules:41: recipe for target 'build-indep' failed > > make: *** [build-indep] Error 1 > > -- > Martin Michlmayr > Linux for HPE Helion, Hewlett Packard Enterprise Hi Martin, Thanks for the bug report. Ususally a bug report provides me with clear hints about its causes, but this time I'm at a loss. Building the manual on amd64 archs works OK, and I have no access to a HPE Helion machine, so it's hard to reproduce the bug. I'm also wondering why the bug appears when yodl processes algorithm/reduce.yo, and not earlier. E.g., the macro 'verbinsert' is called in documentation/manual/algorithm/reduce.yo, but before that in examples/rpndecl.yo:verbinsert(//DECL)(rpn/parser/grammar) examples/rpngram.yo:verbinsert(//RULES)(rpn/parser/grammar) examples/errors.yo: verbinsert(//LINE)(errorcalc/parser/grammar) and only then: algorithm/reduce.yo:verbinsert(-as4)(examples/rr1) But when used in reduce.yo another type of argument (-as4) is passed to yodlverbinsert than in the other three cases, where a //XXX marker is used (the short usage info displayed by yodlverbinsert suggests that a marker is required, but that's not actually true, cf. yodlverbinsert's man-page). There is of course a poor-man's solution: I build the documents and provide the pre-built documents with the debian package. But it would be nice to know why we get the FTBFS problem on the Helions. Maybe I could ask you to replace line 7 ofdocumentation/manual/algorithm/reduce.yo verbinsert(-as4)(examples/rr1) by VERBOSITY()(0x4) verbinsert(-as4)(examples/rr1) VERBOSITY()(NONE) and then run ./build manual in bisonc++'s base directory (where you also find a file named CLASSES) and send me the output? That might provide a little more info about what went wrong. For now, lacking access to a Helion machine, I'm afraid I have to ask you for some help Cheers, [Cc: Tony/George] -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA signature.asc Description: PGP signature
Bug#815407: xd: FTBFS on hurd-i386: error: 'PATH_MAX' was not declared in this scope
Dear Andreas Beckmann, you wrote: > > On 2016-02-21 12:30, Frank B. Brokken wrote: > > It should be trivially fixable: should be a matter of including > > in alternatives/alternatives.ih. (*should* because I don't > > Does that header exist on hurd-i386? Don't know, but the problem has been fixed in another way: by passing 0 (NULL) to realpath's 2nd argument an appropriately sized buffer is allocated by realpath, and there's no reference anymore to PATH_MAX. Problem solved :-) Thanks for the quick reply! -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#815407: xd: FTBFS on hurd-i386: error: 'PATH_MAX' was not declared in this scope
Dear Andreas Beckmann, you wrote: > If this isn't trivially fixable, please request the outdated binary > packages to be decrufted. It should be trivially fixable: should be a matter of including in alternatives/alternatives.ih. (*should* because I don't have access to a hurd machine, so I can't test the presumed fix directly). I'll try to prepare a new release today. Thanks! -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#808151: systemd: failed to start remount root and kernel file system
Dear Michael Biebl, you wrote: > Here is a more complete log excerpt for v228 (full log attached) > > > Dez 20 01:27:42 debian systemd[1]: -.mount: Changed dead -> mounted ... > > So the best guess is that the timing in v228 changed a little (some code > paths became faster). This would confirm Frank's findings that enabling > verbose output (which slows down boot a bit) made it less likely to hit. > > Martin has been working/debugging the tentative stuff in the past, so > maybe he has some insights here. > > We should probably also involve upstream at some point. OK, thanks for the help and (for me at least) final conclusion. For me personally the problem has been solved: for the time being I'm happy with 227, and I'm sure that the problem will soon be fixed. Thanks again for helping along! Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA signature.asc Description: PGP signature
Bug#808151: systemd: failed to start remount root and kernel file system
Hi Michael, I downgraded to the following versions of the following packages: libpam-systemd_227-2_i386.deb libudev1_227-2_i386.deb libsystemd-dev_227-2_i386.deb systemd-sysv_227-2_i386.deb libsystemd0_227-2_i386.deb systemd_227-2_i386.deb libudev-dev_227-2_i386.deb udev_227-2_i386.deb Thereafter I rebooted several times without encountering any problems. Also with reduced output (grub's option 'quiet') no problems were encountered. Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA signature.asc Description: PGP signature
Bug#808151: systemd: failed to start remount root and kernel file system
Hi Michael, The journalctl -alb output after adding: > Then add > [Service] > ExecStartPre=/bin/sh -c 'echo "before rootfs remount"; findmnt' > ExecStartPost=/bin/sh -c 'echo "after rootfs remount"; findmnt' and rebooting (until failure) is at https:/www.icce.rug.nl/systemd/alb-1650 It does contain the 'before rootfs' line, but the 'after rootfs' line isn't there: $ grep 'before rootfs' *1650 Dec 19 16:45:18 localhost.localdomain sh[430]: before rootfs remount Dec 19 16:45:20 localhost.localdomain sh[487]: before rootfs remount Dec 19 16:45:21 localhost.localdomain sh[516]: before rootfs remount Dec 19 16:45:24 localhost.localdomain sh[620]: before rootfs remount $ grep 'after rootfs' *1650 $ Next thing I'll try is to downgrade to 227-2. -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA signature.asc Description: PGP signature
Bug#808151: systemd: failed to start remount root and kernel file system
Dear Michael Biebl, you wrote: > > This information is available at https://www.icce.rug.nl/systemd in the > > files > > initramfs.debug and alb. > > Hm, unfortunately the journal dump is incomplete again. I have no idea why Remarkable. I made it available the way I got it, so that's apparently what there is. > > booting procedure. You're sure it can't be some timing problem? > > Well, what kind of timing problem do you have in mind? Don't know: I didn't design systemd. But if it's doing things in parallel then maybe on newer, faster, computers things might have completed, like remounting /usr rw before it's actually used. A race condition might then explain why the problem doesn't always show itself, and why chances of failure are reduced when more time is spent writing debug/verbose messages. > So far, the only thing I can say for sure looking at the initramfs log, > is that /usr has been mounted successfully in the initramfs. > > "Something" apparently causes /usr to be unmounted later on. Which part > and why that is, is not clear yet. > > Do you have any (custom) init scripts in /etc/rcS.d/ which fiddle around > with mount settings, run telinit or stuff like that? Nope. > I'm running out of ideas, tbh. Well, that's already a *lot* more than I could offer myself :-) But fortunately (for me, but hard to fix, I realize), the problem doesn't emerge all the time. If rebooting every now and then gets me a running system, then so be it. The FailureAction=reboot-force entry in systemd-remount-fs.service already has proven to be my friend :-) > If you suspect the remount service to be the cause for this, let's > output the mounts before and after > For that run > $ systemctl edit systemd-remount-fs.service When I issue that command I get the reply Warning: systemd-remount-fs.service changed on disk. Run 'systemctl daemon-reload' to reload units. I guess the warning is obvious as I edited the file /lib/systemd/system/local-fs.target.wants/systemd-remount-fs.service to prevent the reboot action. So I did as advised and reran the command, but got an empty file in my editor, while the following message was shown after ending the editor: Editing "/etc/systemd/system/systemd-remount-fs.service.d/override.conf" canceled: temporary file is empty. > Then add > [Service] > ExecStartPre=/bin/sh -c 'echo "before rootfs remount"; findmnt' > ExecStartPost=/bin/sh -c 'echo "after rootfs remount"; findmnt' > > Reboot and attach the journal log again. Instead of running the systemctl command I edited the file /lib/systemd/system/local-fs.target.wants/systemd-remount-fs.service and added the lines you suggested. My next e-mail is about the contents of journal log. Thereafter I'll try to downgrade to the previous version to see what happens then. -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA signature.asc Description: PGP signature
Bug#808151: systemd: failed to start remount root and kernel file system
Hi Michael, As announced in my previous e-mail: > I'll add the debug entry next (cf. your mail from Date: Fri, 18 Dec 2015 > 03:15:15 +0100) and let you know the results. This information is available at https://www.icce.rug.nl/systemd in the files initramfs.debug and alb. Maybe useful to note: it took like four or five reboot attempts before the booting process eventually failed. This time even more output than with using 'verbose' flashes by during the booting process, which somewhat slows down the booting procedure. You're sure it can't be some timing problem? -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA signature.asc Description: PGP signature
Bug#808151: systemd: failed to start remount root and kernel file system
Dear Michael Biebl, you wrote: > Am 18.12.2015 um 15:59 schrieb Frank B. Brokken: > > Is there a way to determine that? What I do to upgrade the system is run > > 'aptitude update' and then 'aptitude upgrade'. Is there a log somewhere that > > tells me what packages and versions were updated at what moments in time? > > /var/log/dpkg.log is a low-level log. > > and then there is one for aptitude at /var/log/aptitude Thanks: I made the logs available at https://www.icce.rug.nl/systemd > ... > Btw, you mentioned that this happened after an upgrade. Which previous > version did you run which worked fine? Which other packages were > upgraded along with it? Tue, Dec 1 2015 14:07:23 +0100: the aptitude log shows an upgrade from systemd 227-2 to 228-2 dpkg log: 2015-12-01 14:08:42 upgrade systemd:i386 227-2 228-2 dpkg log: 2015-12-03 08:30:01 upgrade systemd:i386 228-2 215-17+deb8u2 Thu, Dec 3 2015 08:31:37 +0100 the aptitude log shows an upgrade from systemd 215-17+deb8u2 -> 228-2 dpkg log: 2015-12-03 08:31:40 upgrade systemd:i386 215-17+deb8u2 228-2 and then, recently, by me trying to downgrade: dpkg log: 2015-12-17 12:59:12 upgrade systemd:i386 228-2 228-2 dpkg log: 2015-12-18 16:15:37 upgrade systemd:i386 228-2 215-17+deb8u2 dpkg log: 2015-12-18 16:17:11 upgrade systemd:i386 215-17+deb8u2 228-2 Before Dec 1 no updates were recorded for systemd or udev, and until the upgrades early December everything ran fine. > If you downgrade systemd/udev, does the problem go away? As I feared, downgrading is difficult because of the many reverse dependencies. I looked at ftp://ftp.de.debian.org/debian/pool/main/s/systemd/ which is the mirror I usually use for earlier .deb files, but the one before 228-2 is 215-17, and 227-2 is only available as source archives and not AFAICS as .deb packages. I'll add the debug entry next (cf. your mail from Date: Fri, 18 Dec 2015 03:15:15 +0100) and let you know the results. -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA signature.asc Description: PGP signature
Bug#808151: systemd: failed to start remount root and kernel file system
Dear Michael Biebl, you wrote: > The verbose debug log from the initramfs and systemd can maybe tell us > more. But looking at https://www.icce.rug.nl/systemd/journalctl, the > sda5 mount happens at line 773, the first errors start at line 785 and > the remount is at line 802. > So it looks like /usr is not mounted at the time > systemd-remount-fs.service is run. Right. That's consistent with the impression I got from the error messages. *Why* that is true, however, eludes me. > > What's also curious is, that the log doesn't seem to be complete. > Usually systemd's first log line is something like > > > Dez 18 07:03:47 pluto systemd[1]: systemd 228 running in system mode. (+PAM > > +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP > > +GCRYPT +GNUTLS +ACL +X > > Dez 18 07:03:47 pluto systemd[1]: Detected architecture x86-64. > > Those early boot messages seem to be missing completely. Well, I didn't edit anything. The information I generated is passed to you the way it was made available by the various programs/commands. > Btw, you mentioned that this happened after an upgrade. Which previous > version did you run which worked fine? Which other packages were > upgraded along with it? Is there a way to determine that? What I do to upgrade the system is run 'aptitude update' and then 'aptitude upgrade'. Is there a log somewhere that tells me what packages and versions were updated at what moments in time? > If you downgrade systemd/udev, does the problem go away? I thought about doing that, but was afraid for an avalanche of forced downgrades of packages that might now depend on the most recent udev and systemd versions. But I'll give it a try asap and let you know the results. -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#808151: systemd: failed to start remount root and kernel file system
Dear Michael Biebl, you wrote: > Well, /usr is mounted by the initramfs these days. So it should already > be available when systemd is started. If that fails, this is a bug which > needs to be addressed by initramfs-tools (or one of the hook scripts). > It wasn't clear so far that /usr hasn't been mounted at all. > > Is /usr on LVM, RAID, etc? No, nothing like that. And for what it's worth: the problem only appeared after I upgraded systemd last week. The laptop has nothing special in its setup, and has been working perfectly for years, until last week when systemd was renwed. I think in my bugreport I mentioned the problem that /usr wasn't mounted. In your next reply you wrote: > I'm a bit confused by those logs. They show that sda5 have been mounted. > > Dec 17 15:44:29 localhost.localdomain kernel: EXT4-fs (sda5): mounting > ext3 file system using the ext4 subsystem > Dec 17 15:44:29 localhost.localdomain kernel: EXT4-fs (sda5): mounted > filesystem with ordered data mode. Opts: (null) > > I figure /dev/sda5 is your /usr partition? Just to be sure, please > attach ls -la /dev/disk/by-uuid/ I seem to remember that message, in particular the Opts: (null) remark, and I think at that point /usr was mounted by me fron the systemd shell. Also, couldn't it be that initramfs *did* do the mount, but that remounting it rw, als reported in the error message is the problem? Also, to me it appears remarkable that by removing the 'quiet' from the kernel parameters, so that things go a bit slower because of the extra messages that are displayed the frequency of failing boot procedures is greatly diminished. I'm considering trying to add 'verbose' to grub's parameters to see if that produces more output and maybe further reduces the frequency, but I haven't had the time to do that yet. Something on the TODO list :-) Anyway, here's the ls -la output: total 0 drwxr-xr-x 2 root root 200 Dec 18 13:05 ./ drwxr-xr-x 5 root root 100 Dec 18 13:02 ../ lrwxrwxrwx 1 root root 10 Dec 18 13:02 04b82e8b-f871-4abb-978a-44ae44c5d1f7 -> ../../sda1 lrwxrwxrwx 1 root root 10 Dec 18 13:02 595bcdbf-6436-45a7-99d2-297a3dd85930 -> ../../sda6 lrwxrwxrwx 1 root root 10 Dec 18 13:02 693c71eb-d411-4ee0-a1b3-c577df02e01b -> ../../sda9 lrwxrwxrwx 1 root root 10 Dec 18 13:02 6bcb2a05-33c9-402b-8093-e6a35ffd7aa1 -> ../../sda8 lrwxrwxrwx 1 root root 11 Dec 18 13:05 82e52787-6072-4af9-a5e6-2d88c365e62b -> ../../loop0 lrwxrwxrwx 1 root root 10 Dec 18 13:02 c5591eff-0a6c-4310-bb11-7d5535f7da7b -> ../../sda7 lrwxrwxrwx 1 root root 10 Dec 18 13:05 e289e4ad-be1d-42a8-9b38-f4dad9473520 -> ../../dm-0 lrwxrwxrwx 1 root root 10 Dec 18 13:02 ea8202e7-4564-424c-af70-a6a640fafb65 -> ../../sda5 ~ I'll do the 'debug' addition later this weekend, like you requested. Finally, you asked: > Do you have any custom udev rules in /etc/udev/rules.d? I don't think so, looking at the time stamps nothing has been changed there for years: total 10 drwxr-xr-x 2 root root 3072 Dec 6 2014 ./ drwxr-xr-x 4 root root 1024 Dec 3 08:34 ../ -rw-r--r-- 1 root root 115 Dec 6 2014 70-automount.rules -rw-r--r-- 1 root root 3841 Dec 6 2014 70-persistent-cd.rules -rw-r--r-- 1 root root 895 Feb 26 2013 70-persistent-net.rules And I definitely didn't recently change there any files, so again: the problem appeared out of the blue since last weeks upgrade. I hope the above gives you at least some additional info. As I wrote: I'll do the 'debug' addition tomorrow. Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#808151: systemd: failed to start remount root and kernel file system
Dear Michael Biebl, you wrote: > Am 17.12.2015 um 13:46 schrieb Frank B. Brokken: > > halt. No reboot (e.g. ctrl-alt-del) is possible and there's no rescue > > shell> > What exactly do you mean with halt? The systems completely locks up so > you can't use the keyboard and switch to tty9? No, that's not what happens. I mean that doing a reboot using ctrl-alt-del isn't possible. Switching VTs is no problem, but except for VT1 nothing was being shown. But maybe I overlooked things when I sent you the previous reply: see below. > That would sound like a kernel problem. > > might my problem not simply be some timing problem? > > Can you make a screenshot or a video from the boot process with "quiet" > removed from the kernel command line. I did. Not only that, I also tried to reboot again and this time I was able to run the commands you asked before from tty9: systemctl status systemd-analyze dump journalctl -alb This time the debug shell prompt was available at tty9, although booting failed. And in line with my previous findings, systemd-analyze and journalctl weren't available, as they live in /usr/bin, and /usr hadn't been mounted. But after mounting /usr from tty9 and then using the mount command systemd-analyze and journalctl were available, so I also have the output from those commands for you. The output, and the mp4 movie I made during the booting process are a bit too large for the e-mail, but they are available for download/inspection at https://www.icce.rug.nl/systemd/ Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA signature.asc Description: PGP signature
Bug#808151: systemd: failed to start remount root and kernel file system
Dear Michael Biebl, you wrote: > What happens afterwards? Are you dropped into the rescue shell? Afterwards (i.e., after the initial failure message) the system tries to continue booting, but shows lots of failure messages, eventually grinding to a halt. No reboot (e.g. ctrl-alt-del) is possible and there's no rescue shell. > If not, try to enable the debug shell by adding "systemd.debug-shell" to > the kernel command line. This will give you a root shell on tty9. Unfortunately, it doesn't, since the system halts (I first removed the automatic reboot on failure). However, during the process I observed that setting systemd.debug-shell and removing the default 'quiet' specification from grub's /etc/default/grub (so, now it specifies: GRUB_CMDLINE_LINUX_DEFAULT="systemd.debug-shell" greatly reduces the chances of a failing boot. Not completely, but greatly. Still, when rebooting fails there's just the plain halt, w/o a debug shell. Since removing the quiet also produces a lot more output on the screen, might my problem not simply be some timing problem? -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA signature.asc Description: PGP signature
Bug#808016: bisonc++: FTBFS: [icmake/readlog, line 5] Error: conflicting operand types for fgets
Dear Chris Lamb, you wrote: > Source: bisonc++ > Version: 4.11.00-1 > Severity: serious > Justification: fails to build from source > User: reproducible-bui...@lists.alioth.debian.org > Usertags: ftbfs > X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org > > Dear Maintainer, > > bisonc++ fails to build from source in unstable/amd64: Ha! I beat you here by 1/2 day :-) Yesterday I prepared a new release, among other adapting the scripts to icmake 8.00.04 and updated the Debian files accordingly. We're now at bisonc++ 4.13.00, and the new package should be available RSN. @Tony: could you add a Closed #808016 entry to Debian's changelog, please? scripts and > > [..] > > # Add here commands to clean up after the build process. > ./build clean > [icmake/md, line 15] Warning: `sizeof' is deprecated. Use `listlen' > ... > 2 error(s) detected > debian/rules:52: recipe for target 'clean' failed > make: *** [clean] Error 1 > > [..] Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#807746: guncat: FTBFS: "CXX multiply defined"
Dear Chris Lamb, you wrote: > guncat fails to build from source in unstable/amd64: > ./build clean > [icmconf, line 21] Error: CXX multiply defined > [icmconf, line 30] Error: LDFLAGS multiply defined > debian/rules:49: recipe for target 'clean' failed > make: *** [clean] Error 1 Thanks! The update adapting the icmake 8.00.04 will arrive shortly -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#807734: bobcat: FTBFS: Error: double quote at end of string not found
Dear Chris Lamb, you wrote: > bobcat fails to build from source in unstable/amd64: > ./build clean > [./build, line 38] Error: double quote at end of string not found > [./build, line 38] Error: Syntax error at `#include' > debian/rules:34: recipe for target 'clean' failed Thanks! That's a plain old typo. But an update also including the required changes for the icmake 8.00.04 upgrade is being prepared right now. -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#807672: natlog: FTBFS: [/usr/bin/icmbuild, line 166] Error: idx undefined
Dear Chris Lamb, you wrote:
> natlog fails to build from source in unstable/amd64:
Yes, it's a hard life
But no kidding: thanks for the update. The build-problems are caused by
natlog's build script not yet being updated to the latest icmake version.
I'm working on that right now, and I'll raise natlog in my personal priority
stack ;-)
In the meantime, you could change 'sizeof' into 'listlen', as suggested:
> [icmake/md, line 15] Warning: `sizeof' is deprecated. Use `listlen'
> [/usr/bin/icmbuild, line 166] Error: idx undefined
> [/usr/bin/icmbuild, line 166] Error: Incorrect returntype for function
> 'find()'
and this error is simply fixed by moving the 'int idx' definition in the for
statement to right above the for statement. The following change should be all
that's required:
int idx;// definition moved out of the next for-statement
for (idx = listlen(haystack); idx--; )
But I'll handle this bug ASAP.
Cheers,
--
Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#805881: Build error on some configs
Dear Sebastien Bacher, you wrote: > > Package: bobcat > Version: 4.01.03-2 > > That package fails to build on Ubuntu (unsure what's the difference with > Debian, maybe toolchain), recent sync example > https://launchpadlibrarian.net/227370551/buildlog_ubuntu-xenial-i386.bobcat_4.01.03-2_BUILDING.txt.gz > > "process/os/59start2.o: In function `std::thread::thread (&)(FBB::Process*), FBB::Process*>(void (&)(FBB::Process*), > FBB::Process*&&)': > /usr/include/c++/5/thread:137: undefined reference to `pthread_create' > sharedcondition/os/70condition1.o: In function > `FBB::SharedCondition::Condition::Condition()':" > > > Seems like somebody applied that change to fix the issue > http://launchpadlibrarian.net/157657756/bobcat_3.18.01-1_3.18.01-1ubuntu1.diff.gz > > There is no reason the fix should be specific to Ubuntu, maybe it could > be included in Debian? Thanks for your report, but unfortunately it's not clear to me what the problem is. The undefined reference to pthread_create is a linker error, but pthread_create is, or at least should be, available in the pthread library. But in order to make this available the compilations should use -pthread, which bobcat's building process does. Maybe you can provide some additional clarifications? Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#805396: xd: mistake in man page
Dear green, you wrote: > Long explanation: > There appears to be a mistake in the OPTIONS section of the man page, > under the "--directories inclusion" paragraph: > > "There is also a configuration file directive _directives_ (see > below)". > > The directive mentioned below (in the CONFIGURATION FILE section) is > "directories" rather than "directives". Thanks for the bug report. I'll fix it in XD's next release. Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#790985: bobcat: library transition may be needed when GCC 5 is the default
Dear tony mancill, you wrote: > Frank, George, > > I've pushed a new branch to alioth for this upload. The branch name is > bobcat-gcc5abi. > > Please let know if you have any concerns, otherwise, I'll plan to upload > the evening of August 11th (here in GMT-0700). No problems from my side, thanks for the assistance :-) Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA signature.asc Description: Digital signature
Bug#790985: bobcat: library transition may be needed when GCC 5 is the default
Dear Julien Cristau, you wrote: > Control: severity -1 serious > Control: tag -1 confirmed > > On Tue, Jul 7, 2015 at 20:47:28 +0200, Frank B. Brokken wrote: > > > > - Rebuild the library using g++/g++-5 from experimental. Note that > > >most likely all C++ libraries within the build dependencies need > > >a rebuild too. You can find the log for a rebuild in > > > https://people.debian.org/~doko/logs/gcc5-20150701/ > > >Search for "BEGIN GCC CXX11" in the log. > > > > > > - Decide if the symbols matching __cxx11 or B5cxx11 are part of the > > >library API, and are used by the reverse dependencies of the > > >library. > > > > [...] > > > > Thx for the bug report. Right now I'm abroad, and unable to do any > > maintenance > > until I'm back by the end of July. By then I'll have a close look at the > > points you're mentioning. > > > > Thanks again! > > > Confirmed that public symbols are changing with the g++ 5 rebuild; a > patch to rename the library package is available at > https://launchpad.net/ubuntu/+source/bobcat/3.25.01-2ubuntu2 Thanks for the bug report. We're still working out how to handle this issue. The plan is to do an so bump to version 4 of the bobcat library. Some time ago (early August) Debian's experimental distro offered a g++ 5 release that indeed created a library in which the public symbols were changed. We think that bumping the so version, in line with an earlier e-mail by Matthias, effectively handlres the new symbols issue. However, by now the g++ 5 compiler no longer is available in Debian's experimental distribution, but only in Debian's stretch (testing) and sid(unstable) distros, and these compilers don't use the new naming conventions. Right now Tony and I are figuring out a strategy for handling this complication, but we're not done yet. This reaction is primarily to inform you that we're not ignoring the issue, but in fact are actively trying to find an adequate solution. Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#794666: c++-annotations-pdf: a mistake in this example
Dear Usama Makhzoum, you wrote:
>
> Package: c++-annotations-pdf
> Version: 9.9.1-2
> Severity: important
> Tags: newcomer
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where appropriate ***
>
> in cplusplus.pdf, page 80 (actually it the 102th page, you know!), the second
> example of stoi function
> it is:
>
>value = stoi(string(" 123", 0, 5)); // assigns value 38
>
>* What outcome did you expect instead?
> it is :
> value = stoi(string(" 123"), 0, 5); // assigns value
Thanks for the bug report: you're right: it's a typo. It'll be fixed in the
next release. BTW: if you encounter more typos like these, don't hesitate to
send me an e-mail. Submitting such typos as Debian bug-reports is a bit heavy,
I think. But thanks anyway :-)
--
Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#772662: xd: No option for case-insensitive matching.
Dear Alex Rozenshteyn, you wrote: > > Package: xd > Version: 3.22.09-2 > Severity: wishlist > Tags: upstream > > Dear Maintainer, > > Xd serves as a good alternative and complement to autojump, but I would find > it > quite useful if there were an option to ignore case. For example, I have a > directory structure similar to: > $HOME/Documents/School/TAing/OOSE > and I feel like it would be better if I could type `xd .dsto` instead of > `xd .DSTO`. Thank you for a nice suggestion! I must add that I *never* personally encountered this issue since I tend to avoid capitals in directory names. I guess that's why I never implemented a case sensitivity flag. But it shouldn't be too difficult to add it to xd. Hang in there for a little while: since we're nearing Xmas maybe I can give you an optionally case insensitive xd as a Xmas gift ;-) -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#759248: ssh-cron: FTBFS - missing -lpthread
Dear Michael Tautschnig, you wrote: > Package: ssh-cron > Version: 0.91.02-1 > Severity: serious > Usertags: goto-cc > > During a rebuild of all Debian packages in a clean sid chroot (using > cowbuilder > and pbuilder) the build failed with the following error. > ... > It seems -lpthread is missing from the build command line. Hm, maybe (some) architecture dependency. Anyway, I'll fix this tomorrow. Thanks for the report! -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA signature.asc Description: Digital signature
Bug#745355: stealth: fails to build with clang instead of gcc
Dear Nicolas S??velin-Radiguet, you wrote: > Source: stealth > Version: 2.11.03-2 > Severity: minor > Tags: patch > User: pkg-llvm-t...@lists.alioth.debian.org > Usertags: clang-ftbfs > > Dear Maintainer, > > Your package fails to build with clang instead of gcc. [ambiguous declaration] > The attached patch fixes it. Thanks for reporting this compilation problem and for supporting the patch. I'll prepare a new release shortly. Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#725323: rxvt: -geometry setting not recognized by executed commands
Package: rxvt Version: 1:2.7.10-5 Severity: normal Dear Maintainer, When using rxvt, until recently -geometry settings were inherited by called programs. E.g., when calling rxvt -geometry 80x50 -e man man the man-page was displayed over 80 lines. Currently, only about 25 lines are displayed with the man page help line (i.e., the line showing ... press h for help, etc) on the last line, in the middle of the window. When paging through the man-page the page layout is completely lost, and subsequent pages are shown below the initial 25 lines. Larger number of lines show similar output. The problem is observed with other programs as well: less, mutt, etc., all these programs do not appear to inherit rxvt's geometry anymore. When using xterm the problem does not manifest itself, so I guess the problem lies with rxvt. E.g., after xterm -geometry 80x50 -e man man the man-page is nicely displayed over 50 lines, and when paging through the man-page subsequent blocks of 50 lines are shown. Frank B. Brokken. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.10-3-686-pae (SMP w/2 CPU cores) Locale: LANG=POSIX, LC_CTYPE=POSIX (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to POSIX) Shell: /bin/sh linked to /bin/dash Versions of packages rxvt depends on: ii libc6 2.17-93 ii libx11-6 2:1.6.1-1 ii libxpm4 1:3.5.10-1 rxvt recommends no packages. rxvt suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#722166: bobcat: Please do not write timestamps in gzip files
Dear J?r?my Bobbio, you wrote: > ... > For the latter to work, we need to eliminate any variations coming from > external factors, like timestamps. > > Hope that helps, Absolutely, Thanks for the speedy clarification! Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#722166: bobcat: Please do not write timestamps in gzip files
Dear J??r??my Bobbio, you wrote: > Control: tags -1 + patch > > tony mancill: > > Thanks for the suggestion and for looking into the cause of the issue > > with the bobcat build. I'm suspect that Frank, the upstream developer, > > will be willing to address this in a future upstream release. Of course I am. Could somebody please enlighten me what the problem actually is? This is the first time in my l-o-o-o-o-ng life that I learn about a thing called a `timestamp of a gzip file' and that it may cause problems. I'll adapt the upstream sources later this week. Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#712562: yodl: Re-emerging .//xlatin1.tex not found bug
Package: yodl
Version: 3.02.0-1
Severity: normal
For an as yet unknown reason the file xlatin1.tex, which is included in yodl's
latex conversion is included as .//xlatin1.tex. This problem appeared earlier,
and was repaired in 2.14.3. If the bug haunts you, simply replace (in
/usr/share/yodl/std.latex.yo):
NOTRANS(\input{.//xlatin1.tex})\
by
NOTRANS(\input{/usr/share/yodl/xlatin1.tex})\
I'll prepare a new release fixing this problem ASAP.
Frank.
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=POSIX (charmap=ANSI_X3.4-1968) (ignored: LC_ALL
set to POSIX)
Shell: /bin/sh linked to /bin/dash
Versions of packages yodl depends on:
ii libc6 2.17-3
yodl recommends no packages.
Versions of packages yodl suggests:
ii yodl-doc 3.02.0-1
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#711694: src:stealth: uses deprecated find -perm +0123
Dear tony mancill, you wrote: > On 06/08/2013 12:26 PM, Adam Borowski wrote: > > An incoming version of findutils drops the syntax of find -perm +0123, > > which contradicts POSIX and thus has been deprecated since 2005. The > > replacement is -perm /0123. Hi Tony/Adam, Thanks for the report. I've repaired the docs according to Adam's observation. The upstream GIT repo (at sourceforge) is now up-to-date; early next week I'll prepare a new Debian Stealth release, and I'll upload the new version files to SF as well. Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#703245: ekiga: Manual missing / not found by Help/F1
Package: ekiga Version: 4.0.1-1 Severity: normal Dear Maintainer, Ekiga's manual is not available. According to the man-page: DOCUMENTATION More documentation is available in the manual available through Ekiga's Help menu. It was also absent in wheezy's version, which was one of the reasons why I installed the version in experimental. Also: according to ekiga.org/documentation: Ekiga ships with a manual which is translated in nearly 20 languages. But this manual is not found in /usr/share/ekiga. The README.Debian file refers to the faq, the mailing list and an irc channel, which are no substitutes for a manual. The wiki explicitly informs us: User manual ??? Please do not update this section. Updating the Ekiga manual distributed with the application is preferable. But the manual appears to be missing (and the one shown at the Wiki link doesn't reflect the current situation; e.g., ekiga doesn't show a Tools menu entry in either the wheezy or experimental distributions). -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages ekiga depends on: ii gconf-service 3.2.5-1+build1 ii gconf2 3.2.5-1+build1 ii gnome-icon-theme3.6.0-1 ii libatk1.0-0 2.4.0-2 ii libavahi-client30.6.31-1 ii libavahi-common30.6.31-1 ii libavahi-glib1 0.6.31-1 ii libboost-signals1.49.0 1.49.0-3.2 ii libc6 2.17-0experimental2 ii libcairo2 1.12.2-3 ii libdbus-1-3 1.6.8-1 ii libdbus-glib-1-20.100.2-1 ii libfontconfig1 2.9.0-7.1 ii libfreetype62.4.9-1.1 ii libgcc1 1:4.8-20130315-1 ii libgconf-2-43.2.5-1+build1 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-02.33.12+really2.32.4-5 ii libgtk2.0-0 2.24.10-2 ii libidn111.25-2 ii libldap-2.4-2 2.4.31-1 ii libloudmouth1-0 1.4.3-9 ii libnotify4 0.7.5-1 ii libopal3.10.10 3.10.10~dfsg-1 ii libpango1.0-0 1.30.0-1 ii libpt2.10.102.10.10~dfsg-1 ii libsasl2-2 2.1.25.dfsg1-6 ii libspeexdsp11.2~rc1-7 ii libstdc++6 4.8-20130315-1 ii libx11-62:1.5.0-1 ii libxext62:1.3.1-2 ii libxml2 2.8.0+dfsg1-7+nmu1 ii libxv1 2:1.0.7-1 Versions of packages ekiga recommends: ii gvfs 1.12.3-4 pn yelp Versions of packages ekiga suggests: pn asterisk pn ekiga-plugin-evolution pn gnugk pn mediaproxy pn rtpproxy pn ser pn siproxd pn yate -- no debconf information -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#694875: sendmailconfig breaks with 93: local: ... bad variable name
Package: sendmail Version: 8.14.4-2.1 Severity: important Dear Maintainer, After trying sendmailconfig on various virtualbox debian installations, I observed the same result when running sendmailconfig on a non-virtual installation. The error occurs after running sendmailconfig accepting sendmail.conf, but not sendmail.mc: Configure sendmail with the existing /etc/mail/sendmail.conf? [Y] Reading configuration from /etc/mail/sendmail.conf. Validating configuration. Writing configuration to /etc/mail/sendmail.conf. Writing /etc/cron.d/sendmail. Configure sendmail with the existing /etc/mail/sendmail.mc? [Y] n Following this, all default answers were accepted, until reaching the 'Alternate Names' question. After showing the question, the script aborts as follows: === Alternate Names --- In addition to the canonical mail name `transfix.rc.rug.nl', you can add any number of additional alternate names to recognize for receiving mail. If other hosts are MXed to you for local mail, this is where you should list them. This list is saved into the file /etc/mail/local-host-names so it can be changed later as needed. To answer this question, separate each alternate name with a space, or answer `NONE' to eliminate all alternate names. /usr/sbin/sendmailconfig: 93: local: transfix.oostum.north: bad variable name === The problem is reproducible, and it probably is caused by the script's top line: !#/bin/sh When changing it to #!/bin/bash the script correctly completes (but see below), so apparently there is some incompatibility with /bin/dash which is used by Debian as its default system shell. The problem also occurs on fresh Debian installations in a virtualbox environment, where I didn't asked for /bin/dash to be used as /bin/sh. After changing the script's top line to #!/bin/bash the script completes, but produces an error I've previously encountered as well: === Warning: These messages were issued while creating sendmail.cf make sure they are benign before starting sendmail! Errors in generating sendmail.cf *** ERROR: FEATURE() should be before MAILER() *** ERROR: FEATURE() should be before MAILER() *** MAILER(`local') must appear after FEATURE(`allmasquerade')*** ERROR: FEATURE() should be before MAILER() *** MAILER(`local') must appear after FEATURE(`always_add_domain')*** ERROR: FEATURE() should be before MAILER() *** ERROR: FEATURE() should be before MAILER() *** ERROR: FEATURE() should be before MAILER() *** FEATURE(smrsh) must occur before MAILER(local) *** ERROR: MAILER(local) already included *** ERROR: MAILER(smtp) already included === The script writes the Default Mailer setup before the local config, which contains features, e.g., dnl # Default Mailer setup MAILER_DEFINITIONS MAILER(`local')dnl MAILER(`smtp')dnl LOCAL_CONFIG FEATURE(`masquerade_envelope')dnl FEATURE(`allmasquerade')dnl FEATURE(`always_add_domain')dnl (more features follow) After moving the MAILER_DEFINITIONS specs to below the LOCAL_CONFIG the problems were gone (but the script adds a mere LOCAL_CONFIG line below the MAILER_DEFINITIONS) -- Package-specific info: Ouput of /usr/share/bug/sendmail/script: ls -alR /etc/mail: /etc/mail: total 229 drwxr-sr-x 7 smmta smmsp 1024 Dec 1 16:08 . drwxr-xr-x 142 root root 12288 Nov 27 12:26 .. -rwxr-xr-- 1 root smmsp 10015 Jul 8 18:12 Makefile -rw--- 1 root root 4261 Jul 8 18:12 access -rw-r- 1 smmta smmsp 3072 Jul 8 18:13 access.db -rw-r--r-- 1 root root281 Mar 1 2009 address.resolve lrwxrwxrwx 1 root smmsp10 Jul 8 17:40 aliases -> ../aliases -rw-r- 1 smmta smmsp 3072 Jul 8 18:13 aliases.db -rw-r--r-- 1 root root 3239 Jul 8 18:12 databases -rw-r--r-- 1 root root 5657 Mar 1 2009 helpfile -rw-r--r-- 1 root smmsp55 Jul 5 2011 local-host-names drwxr-sr-x 2 smmta smmsp 1024 Apr 18 2009 m4 drwxr-xr-x 2 root root 1024 Jul 8 17:40 peers drwxr-xr-x 2 root smmsp 1024 May 9 2012 sasl -rw-r--r-- 1 root smmsp 63777 Jul 8 18:12 sendmail.cf -rw-r--r-- 1 root root 12236 Dec 1 16:08 sendmail.conf -rw-r--r-- 1 root smmsp 4394 Jul 8 18:12 sendmail.mc -rw-r--r-- 1 root root149 Mar 1 2009 service.switch -rw-r--r-- 1 root root180 Mar 1 2009 service.switch-nodns drwxr-sr-x 2 smmta smmsp 1024 Jul 8 17:40 smrsh -rw-r--r-- 1 root smmsp 44021 Jul 8 18:12 submit.cf -rw-r--r-- 1 root root 44010 May 27 2012 submit.cf.old -rw-r--r-- 1 root smmsp 2375 Jul 8 18:12 submit.mc -rw-r--r-- 1 root root 2376 May 9 2012 submit.mc.new drwxr-xr-x 2 smmta smmsp 1024 Jul 8 17:40 tls -rw-r--r-- 1 root smmsp11 Jul 5 2011 trusted-users /etc/mail/m4: total 2 drwxr-sr-x 2 smmta smmsp 1
Bug#682640: Processed: tagging 682640
Dear Debian Bug Tracking System, you wrote:
>
>
> Processing commands for cont...@bugs.debian.org:
>
> > tags 682640 + confirmed
> Bug #682640 [src:c++-annotations] c++-annotations: FTBFS: htmlindex causes
segmentation fault
Lucas Nussbaum reported:
...
> mv _cplusplus02.html cplusplus02.html
> ../../../scripts/patchhtml < cplusplus01.html > _cplusplus01.html
> mv _cplusplus01.html cplusplus01.html
> ../../../scripts/patchhtml < cplusplus.html > _cplusplus.html
> mv _cplusplus.html cplusplus.html
> touch ../../html-stamp
> ../../../scripts/htmlcontentspage > contents.html
> grep '^ cplusplus.index
> ../../bin/htmlindex < cplusplus.index > cppindex.html
> Segmentation fault
> system - failure of system call (status 35584)
> system - failure of system call (status 35584)
> make: *** [build-stamp] Error 1
The segfault is most likely caused by an outdated libbobcat-dev library in
debian/control, which we forgot to update. It should have been:
libbobcat-dev (>= 3.10.01)
I just ran ./build docs on amd64, using this bobcat version, and the segfault
disappeared:
...
mv _cplusplus01.html cplusplus01.html
../../../scripts/patchhtml < cplusplus.html > _cplusplus.html
mv _cplusplus.html cplusplus.html
touch ../../html-stamp
../../../scripts/htmlcontentspage > contents.html
grep '^ cplusplus.index
../../bin/htmlindex < cplusplus.index > cppindex.html
File cplusplus.html at 0
File cplusplus02.html at 1
File cplusplus03.html at 2
File cplusplus04.html at 3
File cplusplus05.html at 4
File cplusplus06.html at 5
File cplusplus07.html at 6
File cplusplus08.html at 7
File cplusplus09.html at 8
File cplusplus10.html at 9
File cplusplus11.html at 10
File cplusplus12.html at 11
File cplusplus13.html at 12
File cplusplus14.html at 13
File cplusplus15.html at 14
File cplusplus16.html at 15
File cplusplus17.html at 16
File cplusplus18.html at 17
File cplusplus19.html at 18
File cplusplus20.html at 19
File cplusplus21.html at 20
File cplusplus22.html at 21
File cplusplus23.html at 22
../../bin/rmindexlines < cplusplus23.html > _cplusplus23.html
mv _cplusplus23.html cplusplus23.html
...
We'll prepare a new control file asap.
Cheers,
--
Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#677315: chkrootkit: The tty of user process(es) were not found
Package: chkrootkit Version: 0.49-4.1 Severity: normal Dear Maintainer, Since a couple of days chkrootkit reports the following problem in its e-mail message: /etc/cron.daily/chkrootkit: ERROR: chkrootkit output was not as expected. The difference is: ---[ BEGIN: diff -u /var/log/chkrootkit/log.expected +/var/log/chkrootkit/log.today ] --- --- /var/log/chkrootkit/log.expected2012-05-24 08:39:08.0 +0200 +++ /var/log/chkrootkit/log.today 2012-06-13 07:35:13.0 +0200 @@ -4,4 +4,4 @@ The tty of the following user process(es) were not found in /var/run/utmp ! ! RUID PID TTYCMD -! root# tty7 /usr/bin/X :0 vt7 -nolisten tcp -auth +/var/lib/xdm/authdir/authfiles/A:0-5iDcpG +! root# tty7 /usr/bin/X :0 vt7 -nolisten tcp -auth +/var/lib/xdm/authdir/authfiles/A:0-CdMT49 ---[ END: diff -u /var/log/chkrootkit/log.expected /var/log/chkrootkit/log.today +] --- To update the expected output, run (as root) # cp -a -f /var/log/chkrootkit/log.today /var/log/chkrootkit/log.expected # (note that unedited output is in /var/log/chkrootkit/log.today.raw) According to a google search the problem apppears to have occurred in the past as well, so maybe this is a old bug popping up again. I ran chkrootkit -e /usr/bin/X which doesn't solve the problem. Maybe I overlooked something? I couldn't find a suggestion about how to prevent the problem in chkroot's docs in /usr/share/doc/chkrootkit. Cheers, Frank Brokken. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-2-686-pae (SMP w/2 CPU cores) Locale: LANG=POSIX, LC_CTYPE=POSIX (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to POSIX) Shell: /bin/sh linked to /bin/dash Versions of packages chkrootkit depends on: ii binutils 2.22-6.1 ii debconf [debconf-2.0] 1.5.43 ii libc6 2.13-33 ii net-tools 1.60-24.1 ii procps 1:3.3.2-3 chkrootkit recommends no packages. chkrootkit suggests no packages. -- debconf information: chkrootkit/run_daily_opts: -q chkrootkit/run_daily: false chkrootkit/diff_mode: false -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#613651: ITP: oxref -- cross reference utility
Package: wnpp Severity: wishlist Owner: "Frank B. Brokken" * Package name: oxref Version : 0.90.00 Upstream Author : Frank B. Brokken * URL : https://oosix.icce.rug.nl/svnroot/oxref/ * License : GPL Programming Lang: C++ Description : cross reference utility The program oxref writes to the standard output stream a cross reference of symbols defined in unstripped object files and/or libraries. It demangles C++ symbols and can (probably) be used for a large range of languages. Oxref does not interpret the object files and libraries itself, but calls objdump(1) to do so. The output produced by objdump is then filtered by oxref, generating the cross reference listing. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#608183: Resolve unresolved symbols in shared libraries
Dear George Danchev, you wrote: > Matthias Klose writes: > > so, no need to add --no-as-needed. The three bugs are: > > > > - use g++ instead of gcc > > - use the correct -z defs option > > - link with -lcrypto. > > > > Ah, that's it. Thank you, Matthias! > > Frank, I just tested the attached patch (same as Matthias' one, except the > log > part stripped), and I believe this could be shipped with the next upstream > release. Have your time, check it out, and let us know what your findings > are. Findings are positive: I just did a complete bobcat rebuild, added --as-needed to be sure my ld uses that one as well, and the construction proceeded flawlessly. Also, thanks to the note about using g++ to create the shared lib the earlier warnings have disappeared. So, Matthias, once again: thanks for pointing this out to me and thanks for your help along the way; also: George, thanks for doing a pre-test. I'll let you (=George) know when the next release is available (soon). Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#608183: Resolve unresolved symbols in shared libraries
Dear Matthias Klose, you wrote: > > this has nothing to do with --as-needed or --no-as-needed. you don't > link with -lstdc++, therefore use the g++ driver, not the gcc > driver. Ok, that's clear and it's certainly true and an improvement, but it doesn't solve the undefined references when building lcgen. Using --no-as-needed does, apparently, although I'm not convinced that it solves the problem. It probably only bypasses it. Or does it...? Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#608183: Resolve unresolved symbols in shared libraries
Dear Matthias Klose, you wrote: > > tag 608183 + patch > user ubuntu-de...@lists.ubuntu.com > usertags 608183 + origin-ubuntu natty ubuntu-patch > thanks > > the shared library has to be linked with g++, not gcc. I missed this posting, somehow, but it doesn't solve the issue: the library construction can be done by gcc as well as by g++. It doesn't end the unresolved references to the ssl symbols when constructing bobcatlcgen. For now, I'll stick to --no-as-needed (see my previous posting). Since it looks as though this (i.e., using --no-as-needed) solves the issue, I'll prepare an update tomorrow unless I hear about complications that I've missed. Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#608145: bobcat build failure with ld --as needed
Dear George Danchev, you wrote: > Hi All, Hi George, thanks for joining the discussion! > > the correct tweak for icmake/libraries should be: > > run(GCC + " -shared -Wl,-z,def,-soname," + libsomajor + > " -o " + destDir + libsoshared + " */os/*.o " + g_sharedLibReq ); Changing the library construction command according to the patch runs fine, but still causes problems with that --as-needed flag. I've been looking for more info about that flag but not very much is available. Also, I don't see where this --as-needed flag enters either our bobcat library construction or the construction of bobcatlcgen. The ld man-page doesn't show, but I guess it's possible (as the man page refers to more extensive ld-info pages) to set up a default --as-needed option for ld, maybe using the environment. But I've no idea how to solve the problem caused by the --as-needed flag, except maybe the following: add --no-as-needed to the bobcat library construction command. E.g., gcc -shared -Wl,--no-as-needed,-z,def,-soname,libbobcat.so.2 -o tmp/lib/libbobcat.so.2.10.02 */os/*.o -lX11 -lssl -lreadline -lmilter -L/usr/lib/libmilter This seems to work (i.e., I didn't use a globally set --as-needed option), so until we have more information about the way --as-needed works and how we can prevent unresolved references I'd suggest to add the --no-as-needed ld option to the library construction command. Any further thoughts about this? Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#608145: bobcat build failure with ld --as needed
Dear Matthias Klose, you wrote: > > I can't see that. could you attach your build log? Maybe not the full log (if you think I should I'll do so, but the initial phase merely consists of compiling the sources. I've added one compilation to show what's going on: The compilation: g++ --std=c++0x -c -o pattern/oa/51pattern1.o -isystem tmp -Wall -O2 pattern/pattern1.cc Static lib construction: ar cru tmp/lib/libbobcat.a */oa/*.o ranlib tmp/lib/libbobcat.a rm */oa/*.o Dynamic lib construction: Compilation: g++ --std=c++0x -c -o pattern/os/51pattern1.o -isystem tmp -Wall -O2 -fPIC pattern/pattern1.cc Library construction: gcc -Xlinker --as-needed -shared -Wl,-z,def,-soname,libbobcat.so.2 */os/*.o -lmilter -L/usr/lib/libmilter -lX11 -lssl -lreadline -o tmp/lib/libbobcat.so.2.10.02 chmod -x libbobcat.so.2.10.02 ln -sf libbobcat.so.2.10.02 libbobcat.so.2 ln -sf libbobcat.so.2 libbobcat.so ldd reports as expected: ldd tmp/lib/libbobcat.so.2 linux-gate.so.1 => (0xb7841000) libmilter.so.1.0.1 => /usr/lib/libmilter.so.1.0.1 (0xb7797000) libX11.so.6 => /usr/lib/libX11.so.6 (0xb767a000) libreadline.so.6 => /lib/libreadline.so.6 (0xb7644000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7628000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb74e2000) libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb74c9000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb74b) libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb74ab000) libncurses.so.5 => /lib/libncurses.so.5 (0xb7471000) /lib/ld-linux.so.2 (0xb7842000) libXau.so.6 => /usr/lib/libXau.so.6 (0xb746e000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7469000) > the patch does apply, but I still see the wrong order on the command > line. Either I'm doing something stupid, or I patch the wrong place. Please advise on the above dynamic lib. construction command. To me it looks as though the libraries follow the object files. Now the lcgen construction: g++ --std=c++0x -c -o lc/lcgen/o/999version.o -isystem tmp -Wall -O2 lc/lcgen/version.cc g++ --std=c++0x -c -o lc/lcgen/o/999usage.o -isystem tmp -Wall -O2 lc/lcgen/usage.cc g++ --std=c++0x -c -o lc/lcgen/o/999typelist.o -isystem tmp -Wall -O2 lc/lcgen/typelist.cc (etc, all sources are compiled) rm -f lc/lcgen/o/999main.o g++ --std=c++0x -isystem tmp -o tmp/bin/bobcatlcgen lc/lcgen/main.cc lc/lcgen/o/* -lbobcat -Ltmp/lib/ tmp/lib//libbobcat.so: undefined reference to `OpenSSL_add_all_digests' tmp/lib//libbobcat.so: undefined reference to `BN_init' tmp/lib//libbobcat.so: undefined reference to `BN_num_bits' tmp/lib//libbobcat.so: undefined reference to `BN_exp' tmp/lib//libbobcat.so: undefined reference to `HMAC_CTX_init' tmp/lib//libbobcat.so: undefined reference to `BN_bn2dec' tmp/lib//libbobcat.so: undefined reference to `EVP_CIPHER_CTX_block_size' (etc, more unresolved refs follow) Interestingly, however, the following command *did* succeed: g++ --std=c++0x -isystem tmp -o tmp/bin/bobcatlcgen lc/lcgen/main.cc lc/lcgen/o/* -L/usr/lib -lbobcat -Ltmp/lib/ I added the path to where the ssl lib (etc) lives: -L/usr/lib. Why this works I don't know. According to ld's man page the -L is added to the ld search path, and the libs found by ld by default, as shown by ldconfig -p, include /usr/lib. Maybe the additional -L flag provides a hint? If you think I should provide more info, please let me know. Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#608145: bobcat build failure with ld --as needed
Dear Matthias Klose, you wrote: > ... > > I can't see that. could you attach your build log? That would be a lot of output. Rather than doing that right now, please give me some time to do it all again from scratch; also I'll have a close look at your patch. Then I'll get back to you with the results. Maybe all's solved after that. Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#608145: bobcat build failure with ld --as needed
Dear Matthias Klose, you wrote: > > >> > >>^^^ the mistake is that shared libraries are placed before the > >>object files on the command line. > > ^^^ this is the think to fix I did, but nothing changed. Here is what I just used to create the library: gcc -shared -Wl,-z,def,-soname,libbobcat.so.2 */os/*.o -lmilter -L/usr/lib/libmilter -lX11 -lssl -lreadline -o tmp/lib/libbobcat.so.2.10.02 With the --as-needed option the problem remained. > >I'm not sure why you're using ld --as-needed. When I add -Xlinker --as-needed > >to the library construction phase lcgen indeed fails to link. > > hmm, no, it should not fail. how does it for you? Well, --as-needed causes problems, irrespective of the location of the object files. > > right, but the shared library uses ssl symbols. You do link with it, True, but if I were the linker then to resolve the externals I would start with the explicitly mentioned object modules, and then I'd go looking for the external refs in the provided libs. Then those objects would be added (either explicitly as with static linking) or on-the-spot (with dynamic linking), and I wouldn't come across the ssl lib that way. Originally we didn't explicitly mention these additional libs when building bobcat, but then the additional libs had to mentioned explicitly when linking programs against bobcat. That irritating requirement ended after adding the extra libraries to bobcat's lib construction. But now the --as-needed flag spoils the soup ;-) > well, I think I attached a patch what is the correct solution, but > the somewhat unfamiliar build system doesn't like that patch in this > place, or it requires another similiar one which I am still missing. Ok, thanks for the patch. I thought you wrote it didn't work, but I'll have a closer look at it soon. Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#608145: bobcat build failure with ld --as needed
Dear Matthias Klose, you wrote: > Package: bobcat > Version: 2.10.01-2 > Severity: normal > User: ubuntu-de...@lists.ubuntu.com > Usertags: origin-ubuntu natty > User: debian-...@lists.debian.org > Usertags: ld-as-needed > > with ld --as-needed fails to build with: > > gcc -shared -Wl,-z,def,-soname,libbobcat.so.2 -lmilter > -L/usr/lib/libmilter -lX11 -lssl -lreadline -o > tmp/lib/libbobcat.so.2.10.02 */os/*.o > > ^^^ the mistake is that shared libraries are placed before the > object files on the command line. > > chmod -x libbobcat.so.2.10.02 > ln -sf libbobcat.so.2.10.02 libbobcat.so.2 > ln -sf libbobcat.so.2 libbobcat.so > ./build lcgen > > and the fails later with ... > > g++ --std=c++0x -isystem tmp -o tmp/bin/bobcatlcgen lc/lcgen/main.cc > lc/lcgen/o/* -lbobcat -Ltmp/lib/ > tmp/lib//libbobcat.so: undefined reference to `OpenSSL_add_all_digests' > tmp/lib//libbobcat.so: undefined reference to `history_length' > tmp/lib//libbobcat.so: undefined reference to `BN_init' > tmp/lib//libbobcat.so: undefined reference to `BN_num_bits' > tmp/lib//libbobcat.so: undefined reference to `BN_exp' > [...] > > attached is what I would suspect would fix the problem but it > doesn't. any further ideas? I'm not sure why you're using ld --as-needed. When I add -Xlinker --as-needed to the library construction phase lcgen indeed fails to link. When adding the libraries defining the missing entries (e.g., -lssl) to the lcgen link command the lcgen program links fine: g++ --std=c++0x -isystem tmp -o tmp/bin/bobcatlcgen lc/lcgen/main.cc lc/lcgen/o/* -lssl -lbobcat -Ltmp/lib/ I guess you will experience the same problem with other programs depending on bobcat. I don't know why linking against ssl is required: lcgen doesn't use the ssl lib, and objdump processing the generated lcgen program doesn't show any ssl references. But it does want to link against, e.g., libreadline, libX11 and libssl, which are required by bobcat. Something to figure out What you want/would expect is that bobcat's additional libraries are only needed if there are external references to code from those libraries. Which isn't the case with lcgen. So, in short: - if don't know why you want to use --as-needed, if you don't use it the linking proceeds fine, and although the executable doesn't need symbols from these libraries the executable links against the dynamic libs required by bobcat. - right now I have no other solution but to avoid --as-needed. I'll keep your problem in mind and if/when I have a solution I'll let you know. Thanks for bringing this problem to my attention. Once I have a solution (other than: don't use --as-needed) I'll let you know. -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#599594: openvas-client: No connection to the remote host using the specified protocol version
Package: openvas-client Version: 2.0.5-1 Severity: important When trying to connect to the openvas-server from the openvas-client certificate authentication is problematic. Here's what I did after installing openvas-client and openvas-server: As root: 1. - verified that /var/lib/openvas/CA has the appropriate certificates: -rw-r--r-- 1 root root 1525 Oct 9 08:51 cacert.pem -rw-r--r-- 1 root root 4376 Oct 9 08:51 servercert.pem - used openvas-mkcert-client to create a client certificate - moved the contents of the generated /tmp/openvas-mkcert. directory to ~/.openvas, changing the owner/group accordingly - copied /var/lib/openvas/CA/cacert.pem to the user's .openvas directory, changing owner/group accordingly 2. verified that the contents of (in my case) /var/lib/openvas/users/frank/auth/dname which is: /C=NL/L=Oostum/O=RUG/OU=CIT/ CN=frank/emailaddress=f.b.brok...@rug.nl matches the contents of the information in the certificate ~/.openvas/cert_frank.pem. E.g., the certificate shows: Validity Not Before: Oct 9 09:09:58 2010 GMT Not After : Oct 9 09:09:58 2011 GMT Subject: C=NL, L=Oostum, O=RUG, OU=CIT, CN=frank/emailaddress=f.b.brok...@rug.nl As user 'frank': 1. started openvas-client and clicked the 'connect' button 2. specified (as stored by openvas-client in ~/.openvasrc): trusted_ca = /home/frank/.openvas/cacert.pem cert_file = /home/frank/.openvas/cert_frank.pem key_file = /home/frank/.openvas/key_frank.pem use_client_cert = yes nessusd_port = 9390 paranoia_level = 3 3. Pressed OK in the 'Connect to OpenVAS Server' window, and got the error message Sat Oct 9 11:47:31 2010] Error: Unable to establish a connection to the remote host using the specified protocol version! 4. Opened the Preferences window, and saw as Protocol version 1.0, but this cannot be changed. I found no information about a protocol version in /etc/openvas/openvasd.conf, or in the openvas-client and openvasd man pages. The openvas-server is at version 2.0.3-3, so client and server versions seem to match. The openvas/openvasd.messages log file shows connections from the localhost. E.g., it contains: [Sat Oct 9 10:57:51 2010][28399] openvasd 2.0.3. started [Sat Oct 9 11:28:30 2010][28399] connection from 127.0.0.1 [Sat Oct 9 11:32:10 2010][28399] connection from 127.0.0.1 [Sat Oct 9 11:47:30 2010][28399] connection from 127.0.0.1 Changing the 'paranoia level' to 1 or 2 doesn't change things. Then I created a user using password authentication and this time connection to the server succeeded. Since using certificates, as generated by openvas itself appears not to work -I probably missed something trivial here, but found no clue as to what it might be- I filed this as an important bug. I'm still assuming I overlooked something small here, but if so it might be helpful to increase the visibility of that small item. However, I did find the reported error in the openvas FAQ, but there a mismatch between client and server versions is reported as the cause of the problem. E.g., ... Your client (or server) is too old. Make sure the major version numbers of the client and server match. For example, OpenVAS-Client and OpenVAS-server should both be version 2.x. This message may vary depending on the combination of the client and server that is running. Some OS distributions ship incompatible client and server combinations. But this doesn't seem to be true here as the major versions are identical: $ dpkg -s openvas-client Package: openvas-client Status: install ok installed Version: 2.0.5-1 $dpkg -s openvas-server Package: openvas-server Status: install ok installed Version: 2.0.3-3 I'm looking forward to receiving any advice you might provide Frank Brokken. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages openvas-client depends on: ii libatk1.0-01.30.0-1 The ATK accessibility toolkit ii libc6 2.11.2-6 Embedded GNU C Library: Shared lib ii libcairo2 1.8.10-6 The Cairo 2D vector graphics libra ii libfontconfig1 2.8.0-2.1 generic font configuration library ii libfreetype6 2.4.2-1 FreeType 2 font engine, shared lib ii libgd2-xpm 2.0.36~rc1~dfsg-4 GD Graphics Library version 2 ii libgdchart-gd2-noxpm 0.11.5-7 Gene
Bug#595924: c++-annotations: 8.3.0 available at http://cppannotations.sourceforge.net
Package: c++-annotations Version: 8.2.0-1 Severity: normal Version 8.3.0-1 is already available at http://cppannotations.sourceforge.net. It cannot yet be added to the Debian archive due to the archives's current freezing state. Version 8.3.0-1 solves the FTBFS bug (#564969) filed against the C++ Annotations and c++-annotations-pdf_8.3.0-1_all.deb found at SourceForge does not suffer from pdf errors caused by the current Debian version of the poppler-utils. The html, pdf, and ps .deb files as well as the .dsc file (signed by me) can currently be downloaded from the SourceForge site, as well as c++-annotations_8.3.0.orig.tar.gz. F. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to POSIX) Shell: /bin/sh linked to /bin/dash Versions of packages c++-annotations depends on: ii c++-annotations-contrib 8.2.0-1Extensive tutorial and documentati ii c++-annotations-dvi 8.2.0-1Extensive tutorial and documentati ii c++-annotations-html 8.3.0-1Extensive tutorial and documentati ii c++-annotations-latex 8.2.0-1Extensive tutorial and documentati ii c++-annotations-pdf 8.2.0-1Extensive tutorial and documentati ii c++-annotations-ps8.2.0-1Extensive tutorial and documentati ii c++-annotations-txt 8.2.0-1Extensive tutorial and documentati c++-annotations recommends no packages. Versions of packages c++-annotations suggests: ii bisonc++ 2.8.0-1Bison-style parser generator for C -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#592737: bisonc++: Some S/R conflicts are not properly recognized
Package: bisonc++ Version: 2.7.0-2 Severity: normal Bisonc++ 2.7.0 has problems with solving shift/reduce (S/R) conflicts in grammars having production rules not containing terminal tokens and not using %prec directives. These problems have been solved in Bisonc++ 2.8.0, which is already available at https://sourceforge.net/projects/bisoncpp/ but which cannot yet be added to the Debian archive because of the archives's current freezing state. If you want to upgrade already now from 2.7.0 to 2.8.0 go to the above web location, select 'View all files', select the 2.8.0 directory, and download bisonc++_2.8.0-1_i386.deb (and optionally bisonc++-doc_2.8.0-1_all.deb). Then use, e.g., dpkg -i bisonc++_2.8.0-1_i386.deb to upgrade to version 2.8.0. Here are the changelogs for version 2.8.0: * Grammars having states consisting of items in which a reduction from a (series of) non-terminals is indicated have automatically a higher precedence than items in which a shift is required. Therefore, in these cases the S/R conflict is solved by a reduce, rather than a shift. See README.states-and-conflicts, srconflict/visitreduction.cc and the Bisonc++ manual, section 'Rule precedence' for examples and further information. These grammars are now showing S/R conflicts, which remained undetected in earlier versions of Bisonc++. The example was brought to my attention by Ramanand Mandayam (thanks, Ramanand!). * To the set of regression tests another test was added containing a grammar having two S/R conflicts resulting from automatically selecting reductions rather than shifts. This test was named 'mandayam'. * Output generated by --verbose and --construction now shows in more detail how S/R conflicts are handled. The Bisonc++ manual also received an additional section explaining when reduces are used with certain S/R conflicts. * Previously the documentation stated that --construction writes the construction process to stdout, whereas it is written to the same file as used by --verbose. This is now repaired. * The meaning/use of the data members of all classes are now described at the data members in all the classes' header files. Once the freezing state has been lifted bisonc++ 2.8.0 will be offered to Debian, clearing this bugreport. Frank B. Brokken Thu, 12 Aug 2010 15:48:13 +0200 -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to POSIX) Shell: /bin/sh linked to /bin/dash Versions of packages bisonc++ depends on: ii libbobcat2 2.08.01-1run-time (shared) Bobcat library ii libc6 2.11.2-2 Embedded GNU C Library: Shared lib ii libgcc1 1:4.5-20100404-1 GCC support library ii libstdc++6 4.5-20100404-1 The GNU Standard C++ Library v3 bisonc++ recommends no packages. Versions of packages bisonc++ suggests: pn bison (no description available) ii bisonc++-doc 2.8.0-1Bison-style parser generator for C -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#562851: hal: load average constantly at about 1.00
Package: hal Version: 0.5.14-1 Severity: normal When running hal the load average on this acer travelmate 5730 is constantly at about 1.00. Shutting down hal reduces the load to near zero values. Top constantly shows udevd running, and I initially expected udevd to be the source of the problem. I purged all software depending on hal from my system (in addition to hal mainly gdm and software depending on gdm) and the problem was gone. After a fresh hal reinstallation the load returned to 1.00 values. Other (desktop) computers I maintain that are running hal do not show the high load. Stopping hal reduces the load (of cource rendering the computer useless). Stopping gdm does not reduce the load. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.30-2-686 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages hal depends on: ii adduser 3.111 add and remove users and groups ii dbus 1.2.16-2simple interprocess messaging syst ii hal-info 20091130-1 Hardware Abstraction Layer - fdi f ii libblkid12.16.2-0block device id library ii libc62.10.2-2GNU C Library: Shared libraries ii libdbus-1-3 1.2.16-2simple interprocess messaging syst ii libdbus-glib-1-2 0.82-2 simple interprocess messaging syst ii libexpat12.0.1-6 XML parsing C library - runtime li ii libglib2.0-0 2.22.3-1The GLib library of C routines ii libhal-storage1 0.5.14-1Hardware Abstraction Layer - share ii libhal1 0.5.14-1Hardware Abstraction Layer - share ii libusb-0.1-4 2:0.1.12-13 userspace USB programming library ii lsb-base 3.2-23 Linux Standard Base 3.2 init scrip ii mount2.16.2-0Tools for mounting and manipulatin ii pciutils 1:3.1.4-4 Linux PCI Utilities ii udev 149-1 /dev/ and hotplug management daemo ii usbutils 0.86-2 Linux USB utilities Versions of packages hal recommends: ii consolekit 0.4.1-2 framework for defining and trackin ii eject 2.1.5+deb1+cvs20081104-7 ejects CDs and operates CD-Changer ii pm-utils1.2.6.1-3utilities and scripts for power ma Versions of packages hal suggests: pn gnome-device-manager (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550084: xkb-data: Following upgrade several KP-keys lost their functions
Package: xkb-data Version: 1.6-1 Severity: normal Following an upgrade (done on a weekly basis, so I'm pretty certain about the time frame) around August 23rd several keys of my KP-section lost their previously working functions. In particular: Key:Produces: - KP_Divide Insert Keys in between the alfanum. keys (left) and numeric keypad (right): PageUp KP_Divide PageDown Home End Meta_L LeftLeft Right Break Up DownMeta_R Furthermore, the R-control key stopped producing the control-key and I remapped them to several others, e.g., I had to do: /usr/bin/xmodmap -e 'keycode 105 = Control_R' /usr/bin/xmodmap -e 'add Control = Control_R' /usr/bin/xmodmap -e 'add Control = Control_L' /usr/bin/xmodmap -e 'keycode 104 = KP_Enter' We have tried to change the kbd layout from us to nl (dutch) using setxkbmap -layout nl but that showed a completely different mapping, but still incorrect. Here is the contents of my xorg.conf keyboard section: Section "InputDevice" Identifier "Generic Keyboard" Driver "kbd" Option "XkbRules" "xorg" Option "XkbModel" "pc104" Option "XkbLayout" "us" Option "AutoRepeat" "300 30" EndSection and here it's interesting to note that the autorepeat setting that worked before August 23rd apparently is now not recognized anymore (I reactivate it again after starting an X session using /usr/bin/xset r rate 350 30 That works, but again: autorepeat used to be recognized from xorg.conf before august 23rd. So, what might have gone wrong here? -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.30-1-686 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to POSIX) Shell: /bin/sh linked to /bin/dash -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#548582: chkrootkit: Chkrootkit isn't quiet with -q and excluded suspicious files
Package: chkrootkit
Version: 0.49-3
Severity: normal
When running chkrootkit with options
RUN_DAILY_OPTS="-n -q -e false-positive-path"
it finds the false positive. It isn't reported (which is OK) but the banner
The following suspicious files and directories were found:
is printed (and, e.g., sent by mail to the sysadmin). The banner is followed
by an empty list if the false positive is the only element it
finds. Cf. chkrootkit's script near line 725 (my comments start in column 1):
if [ "${files}" = "" -a "${dirs}" = "" ]
then
if [ "${QUIET}" != "t" ]; then echo "nothing found"; fi
else
At this point the banner is printed, but all files/dirs might be excluded,
resulting in an empty list. Then chkrootkit merely displays the banner:
if [ "${QUIET}" = "t" ]; then
printn "The following suspicious files and directories were found:"
fi
echo
if [ -n "${EXCLUDES}" ]; then
for name in $files; do
for exclude in $EXCLUDES; do
if [ $name = $exclude ]; then continue 2; fi
done
This might never be reached...
echo $name
done
for name in $dirs; do
for exclude in $EXCLUDES; do
if [ $name = $exclude ]; then continue 2; fi
done
This might never be reached...
echo $name
done
else
echo ${files}
echo ${dirs}
fi
fi
A simple (not the most elegant) fix would be to check for the banner having
been displayed and display it only once. Easy to do by putting its code in a
function and call that function before files/dirs are displayed. Assuming the
function is called showBanner() then the above could become:
if [ "${files}" = "" -a "${dirs}" = "" ]
then
if [ "${QUIET}" != "t" ]; then echo "nothing found"; fi
else
if [ -n "${EXCLUDES}" ]; then
for name in $files; do
for exclude in $EXCLUDES; do
if [ $name = $exclude ]; then continue 2; fi
done
showBanner
echo $name
done
for name in $dirs; do
for exclude in $EXCLUDES; do
if [ $name = $exclude ]; then continue 2; fi
done
showbanner
echo $name
done
else
showbanner
echo ${files}
echo ${dirs}
fi
fi
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.30-1-686 (SMP w/2 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=POSIX (charmap=ANSI_X3.4-1968) (ignored: LC_ALL
set to POSIX)
Shell: /bin/sh linked to /bin/bash
Versions of packages chkrootkit depends on:
ii binutils 2.19.91.20090910-1 The GNU assembler, linker and bina
ii debconf [debconf-2.0] 1.5.27 Debian configuration management sy
ii libc6 2.9-25 GNU C Library: Shared libraries
ii net-tools 1.60-23The NET-3 networking toolkit
ii procps1:3.2.8-1 /proc file system utilities
chkrootkit recommends no packages.
chkrootkit suggests no packages.
-- debconf information excluded
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#546374: bobcat FTBFS because of new gcc4.4
Hi Stefan, Never ming my last posting: I saw the patch at bugs.debian.org. Still wondering why it didn't show up with 4.4.1, though... New version is in the making :-) Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: 8E36 9FC4 1DAA FCDF 1A0D B19F DAC4 BE50 38C6 6170 Starting 2009/10/01: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#546374: bobcat FTBFS because of new gcc4.4
Dear Stefan Ebner, you wrote: > > Package: bobcat > Version: 2.02.03-1 > > > Hi! > > Version 2.02.03-1 just FTBFS after latest archive rebuild in Ubuntu. > The reason is that we are using new gcc4.4 which is somewhat more strict. > Attached is a patch that _should_ fix the issue with your current version > 2.04.01-1 but I can't testbuild because of build-dependecy issues > (We'll stick with > 2.02.03-1 in Ubuntu for the next release and the patch works here so > I ported it > to your version) Hi Stefan, Thanks for letting me know and for creating the patch. Unfortunately, for some reason, the patch didn't make it to my mailbox. Maybe it was dropped somewhere? I just reran the build script on my sources, using g++-4.4 (Debian 4.4.1-1) 4.4.1 and gcc-4.4 (Debian 4.4.1-1) 4.4.1 and nothing remarkably happened, so I'm really curious about what might have happened. If you could please send me the patch once again? I'd appreciate that. Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: 8E36 9FC4 1DAA FCDF 1A0D B19F DAC4 BE50 38C6 6170 Starting 2009/10/01: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#525746: Log for failed build of bobcat_2.02.02-1 (dist=unstable4)
Dear Martin Michlmayr, you wrote: > > found 525746 2.02.02-1 > thanks > > This is still there. @#...@$%^ !!! You're right. I missed the one in the multistreambuf header itself. My apologies for that. A new version is coming up in a minute (or so) Thanks for reopening the bug. [Cc: George Danchev, Tony Mancill] -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: 8E36 9FC4 1DAA FCDF 1A0D B19F DAC4 BE50 38C6 6170 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#505868: lintian: Lintian reports unusual interpreter for /usr/bin/icmake
Package: lintian Version: 1.24.2.1 Severity: wishlist Lintian reports an unusual-interpreter warning for icmake-scripts (cf. the icmake Debian package), but icmake scripts can be used with a #!/usr/bin/icmake header line calling icmake to process the script. E.g., the warning reported by Lintian could be: W: tcshconfig: unusual-interpreter ./usr/bin/ds #!/usr/bin/icmake I would appreciate it if Lintian would recognize icmake as a `usual interpreter' :-) Cheers, Frank B. Brokken. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores) Locale: LANG=POSIX, LC_CTYPE=POSIX (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages lintian depends on: ii binutils2.18.1~cvs20080103-7 The GNU assembler, linker and bina ii diffstat1.45-2 produces graph of changes introduc ii dpkg-dev1.14.22 Debian package development tools ii file4.26-1 Determines file type using "magic" ii gettext 0.17-4 GNU Internationalization utilities ii intltool-debian 0.35.0+20060710.1Help i18n of RFC822 compliant conf ii libparse-debianchan 1.1.1-2 parse Debian changelogs and output ii libtimedate-perl1.1600-9 Time and date functions for Perl ii liburi-perl 1.35.dfsg.1-1Manipulates and accesses URI strin ii man-db 2.5.2-3 on-line manual pager ii perl [libdigest-sha 5.10.0-16Larry Wall's Practical Extraction lintian recommends no packages. Versions of packages lintian suggests: pn binutils-multiarch (no description available) pn libtext-template-perl (no description available) ii man-db2.5.2-3on-line manual pager -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#504603: libbobcat1: shlibs file fails to reflect ABI additions
Dear Aaron M. Ucko, you wrote: > > Package: libbobcat1 > Version: 1.21.1-1 > Severity: serious > Justification: Policy 8.6 > > libbobcat1's shlibs file leads to unversioned dependencies on the > library, ... > > In this case, though, I would suggest simply adding -V to your call to > dh_makeshlibs, such that packages built against libbobcat1 always > depend on at least the upstream version against which they were built. Dear Aaron, Thank you for filing this bug against Bobcat. You're of course absolutely right and I think your suggestion is a valuable one that can easily be met in future releases. Actually the bug filed against xd clarified the (dependency) bug that had crept into the dependencies list. The problem will be attacked along two main approaches: 1. paying more attention to ABI and API breakages; 2. making sure that (at least my :-) packages clearly display the bobcat version against which the package should be linked. This reply was (of course) not written to close the bug; it was primarily sent to let you and others know that I'm aware of the problem and that for now using the latest (now 1.21.1) Bobcat version with packages that depend on Bobcat should be enough to avoid problems. Current work in progress on Bobcat will probably result in version 2.01.1 from which point on more thorough attention will be paid to version dependencies. Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: 8E36 9FC4 1DAA FCDF 1A0D B19F DAC4 BE50 38C6 6170 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#504185: Yeah, that fixed it
Dear Ethan Glasser-Camp, you wrote:
>
> Thanks, that was it :)
My pleasure. An upgrade fixing this problem is in the pipeline.
Cheers,
--
Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: 8E36 9FC4 1DAA FCDF 1A0D B19F DAC4 BE50 38C6 6170
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#504185: [xd] undefined symbol: _ZNK3FBB6OneKey6verifyEv
Dear Ethan Glasser-Camp, you wrote: > > Package: xd > Version: 3.00.1-1 > ... > I tried to use xd as documented in the manpage: > > $ xd ulb > ... > xd: symbol lookup error: xd: undefined symbol: _ZNK3FBB6OneKey6verifyEv > ... > libbobcat1 | 1.18.1-1 Thank you for using xd and for sending in this bugreport. Most likely your problem is caused by the version of of the bobcat library that's installed on your system. The package information shows that bobcat 1.20.1 is required. I suggest that you upgrade to a more recent version of the library (it's available in the sid distribution). Apparently a flaw in the Debian package as the package info does not show a minimum release level, but the build-information mentions at least version 1.20.1. Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: 8E36 9FC4 1DAA FCDF 1A0D B19F DAC4 BE50 38C6 6170 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#502503: sendmail: trusted user not recognized
Package: sendmail Version: 8.14.3-5 Severity: normal Trusted users specified by either confTRUSTED_USERS or trusted-users file are apparently not recognized. I've used FEATURE(use_ct_file)dnl with trusted-users containing majordom as well as define(`confTRUSTED_USERS',`majordom') but whenever mail is sent by majordomo messages like ... sendmail[32069]: m9H6KRGC032069: Authentication-Warning: ...: majordom set sender to [EMAIL PROTECTED] using -f continue to appear in the logs and distributed headers. Privacy Options used are: O PrivacyOptions=noexpn,novrfy,noverb,noetrn,needmailhelo,needexpnhelo,needvrfyhelo,nobodyreturn -- Package-specific info: Ouput of /usr/share/bug/sendmail/script: ls -alR /etc/mail: /etc/mail: total 298 drwxr-sr-x 8 smmta smmsp 1024 Sep 20 22:53 . drwxr-xr-x 108 root root 8192 Oct 17 07:36 .. -rw-r--r-- 1 root root 35 Mar 22 2000 All2Users -rw-r--r-- 1 root root 41 Mar 22 2000 AllUsers -rwxr-xr-- 1 root smmsp 10819 Sep 20 22:53 Makefile -rw--- 1 root root 1073 Sep 20 22:53 access -rw-r- 1 smmta smmsp 3072 Sep 20 22:53 access.db -rw-r--r-- 1 root root281 Oct 29 2004 address.resolve -rw-r- 1 root smmsp 1407 Feb 7 2008 aliases -rw-r- 1 smmta smmsp 3072 Sep 20 22:53 aliases.db -rw-r--r-- 1 root root 3323 Sep 20 22:53 databases -rw-r- 1 mail mail 0 Aug 10 2001 dialup.m4 -rw-r--r-- 1 root smmsp 129 Sep 6 12:34 genericstable -rw-r- 1 root smmsp 3072 Sep 20 22:53 genericstable.db -rw-r--r-- 1 root root 9328 Sep 20 2007 greylist.conf -rw-r--r-- 1 mail mail 5657 Jul 30 2007 helpfile -rw-r--r-- 1 root root 17 Dec 18 2002 local-host-names drwxr-sr-x 2 smmta smmsp 1024 Nov 12 2004 m4 drwxr-xr-x 2 root root 1024 Jul 29 09:35 peers -rw-r- 1 mail mail 0 Aug 10 2001 provider.m4 -rw-r--r-- 1 root root 15 Jun 17 2002 relay-domains drwxr-xr-x 2 root smmsp 1024 Oct 29 2004 sasl -rw-r--r-- 1 root smmsp31 Feb 3 2005 sendmail.cG -rw-r--r-- 1 root smmsp 61436 Sep 20 22:53 sendmail.cf -rw-r--r-- 1 root root 61232 Jul 29 09:35 sendmail.cf.old -rw-r--r-- 1 root root 12237 Sep 20 22:53 sendmail.conf -rw-r--r-- 1 root smmsp 2449 Sep 20 22:53 sendmail.mc -rw-r--r-- 1 root root764 Dec 18 2002 sendmail.mc2 -rw-r--r-- 1 root root149 Oct 25 1999 service.switch -rw-r--r-- 1 root root180 Oct 25 1999 service.switch-nodns drwxr-sr-x 2 smmta smmsp 1024 Sep 18 13:41 smrsh drwxr-xr-x 2 root smmsp 1024 Dec 2 2002 ssl.org -rw-r--r-- 1 root smmsp 43733 Sep 20 22:53 submit.cf -rw-r--r-- 1 root root 43738 Jul 29 09:35 submit.cf.old -rw-r--r-- 1 root smmsp 2064 Sep 20 22:53 submit.mc -rw-r--r-- 1 root smmsp38 May 30 2002 suffixusers drwxr-xr-x 3 smmta smmsp 1024 Nov 12 2004 tls -rw-r--r-- 1 mail mail 6 Aug 14 2001 trusted-users /etc/mail/m4: total 3 drwxr-sr-x 2 smmta smmsp 1024 Nov 12 2004 . drwxr-sr-x 8 smmta smmsp 1024 Sep 20 22:53 .. -rw-r- 1 root smmsp 784 Mar 27 2008 dialup.m4 -rw-r- 1 root smmsp0 Aug 10 2001 provider.m4 /etc/mail/peers: total 3 drwxr-xr-x 2 root root 1024 Jul 29 09:35 . drwxr-sr-x 8 smmta smmsp 1024 Sep 20 22:53 .. -rw-r--r-- 1 root root 328 Jul 18 2001 provider /etc/mail/sasl: total 2 drwxr-xr-x 2 root smmsp 1024 Oct 29 2004 . drwxr-sr-x 8 smmta smmsp 1024 Sep 20 22:53 .. /etc/mail/smrsh: total 2 drwxr-sr-x 2 smmta smmsp 1024 Sep 18 13:41 . drwxr-sr-x 8 smmta smmsp 1024 Sep 20 22:53 .. lrwxrwxrwx 1 root root22 Nov 12 2004 filter -> /home/frank/bin/filter lrwxrwxrwx 1 root smmsp 25 Sep 20 2006 filternew -> /home/frank/bin/filternew lrwxrwxrwx 1 root smmsp 30 Aug 21 2007 filtervacation -> /home/frank/bin/filtervacation lrwxrwxrwx 1 root root26 Nov 12 2004 mail.local -> /usr/lib/sm.bin/mail.local lrwxrwxrwx 1 root root17 Nov 12 2004 procmail -> /usr/bin/procmail lrwxrwxrwx 1 root root25 Jan 14 2005 setuidcall -> /usr/local/bin/setuidcall lrwxrwxrwx 1 root smmsp 13 Mar 2 2006 sudo -> /usr/bin/sudo /etc/mail/ssl.org: total 12 drwxr-xr-x 2 root smmsp 1024 Dec 2 2002 . drwxr-sr-x 8 smmta smmsp 1024 Sep 20 22:53 .. -rw-r--r-- 1 root root 7 Dec 2 2002 no_prompt -rw--- 1 root root 1444 Dec 2 2002 sendmail-client.cfg -rw-r--r-- 1 root smmsp 875 Dec 2 2002 sendmail-client.crt -rw--- 1 root root 668 Dec 2 2002 sendmail-client.csr -rw-r- 1 root smmsp 887 Dec 2 2002 sendmail-common.key -rw--- 1 root root 0 Dec 2 2002 sendmail-common.prm -rw--- 1 root root 1444 Dec 2 2002 sendmail-server.cfg -rw-r--r-- 1 root smmsp 875 Dec 2 2002 sendmail-server.crt -rw--- 1 root root 668 Dec 2 2002 sendmail-server.csr /etc/mail/tls: total 17 drwxr-xr-x 3 smmta smmsp 1024 Nov 12 2004 . drwxr-sr-x 8 smmta smmsp 1024 Sep 20 22:53 .. -rw-r--r-- 1 root root 7 Apr 22 2002 no_prompt -rw--- 1 root root 1444 Apr 22 2002 sendm
Bug#499421: ecasound: manpage contains garbage
Dear Junichi and Adrian, Thanks for filing the Yodl bug report. You have a valid point (and I must admit I never considered that somebody might run yodl as the same user in parallel runs...). I also think that the problem is less severe than `serious' since the yodl2whatever script provides options allowing for this situation. Nevertheless, while I prepare a more elegant way to handle the problems you reported I suggest you use the options provided by yodl2whatever. Here are some considerations: By default the user name is used in the tmp files to prevent the tmp directory from getting clobbered by all kinds of leftovers from earlier runs. Although that file is intended for consumption by yodlpost sometimes it's read by humans as well. But that's the exception so it's probably more useful to remove it by default. Currently, the yodl2whatever script provides the --unique flag, which *will* create a unique filename (but the file will outlive the yodl run, so you'll have to do some cleaning up, I guess). In addition, the --tmp= option is provided, so you could define different locations for, e.g., a man-page run and a html-run like this: For the man-page run: yodl2man --tmp=/tmp/adrian/man manpage.yo or yodl2man --unique --tmp=/tmp/adrian/man manpage.yo and for the html-document: yodl2html --tmp=/tmp/adrian/html htmlpage.yo or yodl2html --unique --tmp=/tmp/adrian/html htmlpage.yo I hope this reply solves the acute problem. If not, expect a new yodl release in a few days. Thanks again for the report, Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl:11371/ Key Fingerprint: 8E36 9FC4 1DAA FCDF 1A0D B19F DAC4 BE50 38C6 6170 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#498777: sysklogd: uninitialized value error in syslogd-listfiles
Package: sysklogd Version: 1.5-5 Severity: normal When /usr/sbin/syslogd-listfiles is run the following message is generated on several computers: Use of uninitialized value in numeric ge (>=) at /usr/sbin/syslogd-listfiles line 129. All systems on which this script is run use lenny, and diff for syslogd-listfiles on systems that do and don't report the message shows no differences. I did a reinstall for syslogd but this did not solve the problem. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.21.1 (SMP w/1 CPU core; PREEMPT) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages sysklogd depends on: ii klogd [linux-kernel-log-daemo 1.5-5 Kernel Logging Daemon ii libc6 2.7-13 GNU C Library: Shared libraries sysklogd recommends no packages. sysklogd suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
