Bug#796145: Adoption
On Sunday 30 August 2015 12:15:38 J.S.Júnior wrote: I want adoption this package https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796145 Or, help you. But you send RFH []`s Excellent! Thanks for your interest. libburn, libisofs, libisoburn are team-maintained, so please have a look at the pkg-libburnia project on alioth. Bonus, Thomas Schmitt (in CC:) who is also upstream of these has recently joined the packaging projects as well as the mailing list. I'm pretty sure he would appreciate some Debian packaging help. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu
Bug#796145: O: libburn -- command line CD/DVD/BD writing tool
Package: wnpp Severity: normal I intend to orphan the libburn package. I simply don't have the time and energy to maintain it. The package description is: cdrskin strives to be a second source for the services traditionally provided by cdrecord. Currently it does CD-R and CD-RW this way. Overwritable media DVD-RAM, DVD+RW, DVD-RW, and BD-RE are handled differently than with cdrecord-ProDVD in order to offer TAO-like single track recording. Sequential DVD-R[W], DVD+R, DVD+R DL are handled like CD-R[W] with TAO and multi-session. Additionally cdrskin offers cdrecord-ProDVD-like mode DAO with DVD-R[W]. . This is a burner only application. If you want a burner and image manipulation application, please install xorriso package.
Bug#796147: O: libisoburn -- debugging symbols for libisoburn and xorriso
Package: wnpp Severity: normal I intend to orphan the libisoburn package. I simply don't have the time and energy to maintain it. The package description is: libisoburn is a frontend for the libraries libburn and libisofs. It handles the creation, loading, manipulation and burning of ISO-9660 filesystem images. This library provides a low-level API, called libisoburn API, which encapsulates the API of libburn and libisofs, and a higher level API, called xorriso API which encapsulates the API of libburn, libisofs, and libisoburn, and is also used by the xorriso program itself. . This package contains debugging files useful for investigating any problems with the binaries found in the libisoburn library and the xorriso application.
Bug#796146: O: libisofs -- debugging symbols for libisofs
Package: wnpp Severity: normal I intend to orphan the libisofs package. I simply don't have the time and energy t maintain it. The package description is: libisofs creates ISO images which can then be burnt with cdrskin or other software. . This package contains debugging files used to investigate problems with binaries included in the libisofs packages.
Bug#718151: libburn: FTBFS: Failed to install docs
On Sunday 04 August 2013 08:42:41 Thomas Schmitt wrote: Hi, Matthias Klose wrote: fix it in libburn or disable building the docs. upstream did tell you that they didn't want to update that for newer doxygen versions. Matthias, I forgot to mention that doxygen gets stuck, even after I update the configuration file with doxygen [-s] -u. That was the reason to reassign this one against doxygen package. If you have a better idea how to update the configuration file, please let us know. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718151: doxygen loops when passing foo(0) to findParameterList
On Sunday 04 August 2013 14:31:06 Helmut Grohne wrote: Control: clone 718151 -1 Control: reassign -1 doxygen 1.8.4-1 Control: severity -1 normal Control: retitle -1 doxygen loops when passing foo(0) to findParameterList On Sat, Aug 03, 2013 at 11:21:11PM +0200, Matthias Klose wrote: fix it in libburn Matthias, The fix should be in doxygen proper, since it should not just hang when faced with odd input! Workaround is another thing, but then again, chances are very high that multiple packages are affected by this doxygen FAIL, so it is not only libburn when a workaround is possibly be needed. or disable building the docs. I won't even comment that. upstream did tell you that they didn't want to update that for newer doxygen versions. Sorry, but this is all plain wrong. Thomas did not tell such things, we are well in touch, and I also have write access to the upstream repo, so the above statement is sure void. There is absolutely no reason to reassign this to doxygen. I'd rather have that with doxygen on time, before more packages figure out that they are also affected by this doxygen 1.8.4 FAIL. While the report was not overly helpful, part of the issue is with doxygen. I looked into the issue and pull in doxygen-deve...@lists.sourceforge.net for further assistance. Helmut, Thanks for your understanding. I disagree a bit with the report was not overly helpful because I provided the affected version of doxygen, the version of the libburn (resp. the public header) which provokes this FAIL in doxygen, and I also mentioned that the FAIL is reliably reproducible (Sorry, I'm in VAC, properly documented, so I can not go further into tracking doxygen entrails). I also disagree with the statement that part of the issue is with doxygen... the whole FAIL is with doxygen, because however awkward the header is, doxygen should not get stuck, even in a endless loop. So the issue at hand is that doxygen does not terminate when building the documentation for libburn. On interrupting doxygen after leaving it running for some time you will see a traceback like this: #0 findParameterList (name=...) at util.cpp:1848 #1 0x005f894f in resolveRef (scName=0x0, name=0x1657d30 burn_abort(0), inSeeBlock=false, resContext=0x7fff9a4e8c40, resMember=0x7fff9a4e8c48, lookForSpecialization=true, currentFile=0x1603fc0, checkScope=true) at util.cpp:4363 #2 0x006a608c in handleLinkedWord (parent=0x1c8f4c0, children=...) at docparser.cpp:1030 #3 0x006b832e in DocPara::parse (this=0x1c8f480) at docparser.cpp:6311 #4 0x006b257e in DocSimpleSect::parse (this=0x1c8f410, userTitle=false, needsSeparator=false) at docparser.cpp:4570 #5 0x006b3436 in DocPara::handleSimpleSection (this=0x16594c0, t=DocSimpleSect::Since, xmlContext=false) at docparser.cpp:4887 #6 0x006b59bf in DocPara::handleCommand (this=0x16594c0, cmdName=...) at docparser.cpp:5399 #7 0x006b8a4e in DocPara::parse (this=0x16594c0) at docparser.cpp:6478 #8 0x006b9abb in DocRoot::parse (this=0x1651080) at docparser.cpp:6843 #9 0x006ba35b in validatingParseDoc (fileName=0x164f620 .../libburn/libburn.h, startLine=3608, ctx=0x156b7e0, md=0x183a3a0, input=0x1653f80 Either by setting an own handler or\nby activating the built-in signal handler.\n\nA function parameter handle of NULL activates the built-in abort handler. \nDepending on mode it may cancel all drive op..., indexWords=true, isExample=false, exampleName=0x0, singleLine=false, linkFromIndex=false) at docparser.cpp:7085 #10 0x00574224 in OutputList::generateDoc (this=0x18790e0, fileName=0x164f620 .../libburn/libburn.h, startLine=3608, ctx=0x156b7e0, md=0x183a3a0, docStr=..., indexWords=true, isExample=false, exampleName=0x0, singleLine=false, linkFromIndex=false) at outputlist.cpp:153 #11 0x0055e4a0 in MemberDef::writeDocumentation (this=0x183a3a0, ml=0x17405b0, ol=..., scName=0x1641150 libburn.h, container=0x1603fc0, inGroup=false, showEnumValues=false, showInline=false) at memberdef.cpp:2745 #12 0x0056aff5 in MemberList::writeDocumentation (this=0x17405b0, ol=..., scopeName=0x1641150 libburn.h, container=0x1603fc0, title=0x163d660 Function Documentation, showEnumValues=false, showInline=false) at memberlist.cpp:655 #13 0x00446904 in FileDef::writeMemberDocumentation (this=0x1603fc0, ol=..., lt=MemberListType_docFuncMembers, title=...) at filedef.cpp:1742 #14 0x0044263f in FileDef::writeDocumentation (this=0x1603fc0, ol=...) at filedef.cpp:685 #15 0x0042364f in generateFileDocs () at doxygen.cpp:7842 #16 0x00430ab7 in generateOutput () at doxygen.cpp:11231 #17 0x004032c6 in main (argc=2, argv=0x7fff9a4e9818) at main.cpp:38 Indeed the issue lies within findParameterList. The name parameter passed to resolvRef as a c string is passed to the former function as a QString, but its value still
Bug#718151: doxygen being stuck by libburn header file
Hi Matthias and Helmut, the doxygen 1.8.4-1 is being stuck while processing libburn header. This is reliably reproducible (something has changed in the doxygen parser in 1.8.4-1) with libburn (1.2.2-2). Its override_dh_installdocs make target simply executes: doxygen doc/doxygen.conf and doxygen 1.8.4 always gets stuck at the same point of parsing the header file. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683626: xchat: Perl plugin to href suspected ints to bugs.d.o (stats included as well)
Package: xchat
Version: 2.8.8-6
Followup-For: Bug #683626
Dear Maintainer,
Attached is an improved version of the above plugin. I've already been
using it for the last week. Added are more facilities to gather stats.
# Copyright (c) 2012 - George Danchev danc...@spnet.net
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see http://www.gnu.org/licenses/.
use strict;
use warnings;
use Fcntl;
my $time_start = localtime();
my $self = int2bdo;
my $vers = 0.2;
my $seve = $self . / . $vers;
my $logf = .xchat2/ . $self . .log;
my %cmd = (
STAT = $self . _stat,
ZERO = $self . _zero,
VERB = $self . _verb,
HELP = $self . _help,
);
my ($opt_STAT, $opt_VERB, $opt_HELP) = (undef, 0, undef);
my $desc = Suspicious ints 2 bugs.d.o/int (verbosity:$opt_VERB; for help type
to self: $cmd{'HELP'});
my $burl = http://bugs.debian.org;;
my %freq = ( # NONE_0 = 0,
SURE_1 = 0,
SURE_2 = 0,
WILD_3 = 0,
WILD_4 = 0,
WILD_5 = 0,
WILD_6 = 0,
);
sub readlog();
### init
Xchat::register($self, $vers, $desc);
Xchat::hook_print('Channel Message', \hrefbugs);
Xchat::hook_print('Your Message', \hrefbugs);
Xchat::hook_print('Your Message', \dispatch);
Xchat::print(Loaded $seve - $desc);
readlog();
###
sub readlog() {
if ( sysopen(LOG, $logf, O_RDONLY) ) {
while (LOG) {
chomp;
next if ( /^\s*$/ or /^\s*#\s*/ );
if ( /^\s*(\S+)\s+(\d+)/ ) {
my ($k, $v) = ($1, $2);
if (exists $freq{$k}) {
$freq{$k} = $v;
Xchat::print($seve: loaded $k $v from $logf);
}
}
}
close(LOG);
}
else {
Xchat::print($seve: $logf can not be opened);
}
return Xchat::EAT_NONE;
}
###
sub writelog() {
if ( sysopen(LOG, $logf, O_CREAT | O_WRONLY | O_TRUNC) ) {
my $time_written = localtime();
print LOG # $self $vers\n;
print LOG # $time_start - started\n;
print LOG # $time_written - last written\n;
foreach my $key (sort { $freq{$b} = $freq{$a} } keys %freq) {
print LOG $key $freq{$key}\n;
}
close(LOG);
}
}
###
sub print_line() {
Xchat::print(- x 20);
}
###
sub percfre($) {
my $fre = shift;
my $hits = 0;
map { $hits += $_ } values %freq;
return $hits ? sprintf(%.1f , ($fre/$hits)*100.0) : 0;
}
###
sub hrefbugs() {
my $in = $_[0][1];
W: while ( $in =~
/(?:\#([123456789]{1}\d+)) # 1. sure guess
|(?:bug\s*\#?([123456789]{1}\d+)) # 2. sure guess
|(?:^([123456789]{1}\d+)\.?$) # 3. wild guess
|(?:\s([123456789]{1}\d+)\.?$) # 4. wild guess
|(?:([123456789]{1}\d+)^.\d)# 5. wild guess - skip common
'version 1.2' pattern
|(?:\s([123456789]{1}\d+)\s)# 6. wild guess - too much noise,
but ...
/xgi
) {
my ($nam, $fre, $bug) = (undef, undef, undef);
if(defined($1)) {
($nam, $fre, $bug) = ( 'sure_1', ++$freq{'SURE_1'}, $1);
}
elsif (defined($2)) {
($nam, $fre, $bug) = ( 'sure_2', ++$freq{'SURE_2'}, $2);
}
elsif (defined($3)) {
($nam, $fre, $bug) = ( 'WILD_3', ++$freq{'WILD_3'}, $3);
}
elsif (defined($4)) {
($nam, $fre, $bug) = ( 'WILD_4', ++$freq{'WILD_4'}, $4);
}
elsif (defined($5)) {
($nam, $fre, $bug) = ( 'WILD_5', ++$freq{'WILD_5'}, $5);
}
elsif (defined($6)) {
($nam, $fre, $bug) = ( 'WILD_6', ++$freq{'WILD_6'}, $6);
}
else { # no-op
($nam, $fre, $bug) = (undef, undef, undef);
}
if (defined($nam) and defined($fre) and defined($bug) ) {
my @top = sort { $b = $a } values %freq;
my $rank = 0;
for ($rank=0; $rank scalar @top; $rank++) {
if ( $top[$rank] eq $fre ) {
$rank++;
last;
}
}
if ($opt_VERB) {
my $perc = percfre($fre);
Xchat::print(BUGUESS by $seve: rank:$rank name:$nam freq:$fre
($perc%) url: $burl/$bug);
}
else {
Xchat::print(BUGUESS by $seve: $burl/$bug);
}
}
}
writelog();
return Xchat::EAT_NONE;
}
###
sub showstat() {
my $time_now = localtime();
print_line
Bug#683626: xchat: Perl plugin to href suspected ints to bugs.d.o (stats included as well)
Package: xchat
Version: 2.8.8-6
Severity: wishlist
Tags: patch
Dear Maintainer,
Please find the attached perl plugin script, which is supposed to
guess whether ints communicated to the channels are meant as
bugs.d.o/int. Commands, as well stats are pass via query to self.
Further suggestions, flames, improvements welcome :)
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages xchat depends on:
ii libatk1.0-0 2.4.0-2
ii libc6 2.13-35
ii libcairo2 1.12.2-2
ii libdbus-1-3 1.6.2-2
ii libdbus-glib-1-20.100-1
ii libfontconfig1 2.9.0-7
ii libfreetype62.4.9-1
ii libgdk-pixbuf2.0-0 2.26.1-1
ii libglib2.0-02.32.3-1
ii libgtk2.0-0 2.24.10-1
ii libpango1.0-0 1.30.0-1
ii libperl5.14 5.14.2-12
ii libsexy20.1.11-2+b1
ii libssl1.0.0 1.0.1c-4
ii libx11-62:1.5.0-1
ii libxml2 2.8.0+dfsg1-5
ii xchat-common2.8.8-6
Versions of packages xchat recommends:
ii alsa-utils 1.0.25-3
ii libnotify-bin 0.7.5-1
ii libnotify1 0.5.0-2
ii libpython2.7 2.7.3-2
ii tcl8.5 8.5.11-2
ii xdg-utils 1.1.0~rc1+git20111210-6
xchat suggests no packages.
-- no debconf information
# Copyright (c) 2012 - George Danchev danc...@spnet.net
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see http://www.gnu.org/licenses/.
use strict;
use warnings;
my $time_start = localtime();
my $self = int2bdo;
my $vers = 0.1;
my $seve = $self . / . $vers;
my %cmd = (
STAT = $self . _stat,
VERB = $self . _verb,
HELP = $self . _help,
);
my ($opt_STAT, $opt_VERB, $opt_HELP) = (undef, 0, undef);
my $desc = Suspicious ints 2 bugs.d.o/int (verbosity:$opt_VERB; for help type
to self: $cmd{'HELP'});
my $burl = http://bugs.debian.org;;
my %freq = ( # NONE_0 = 0,
SURE_1 = 0,
SURE_2 = 0,
WILD_3 = 0,
WILD_4 = 0,
WILD_5 = 0,
WILD_6 = 0,
);
### init
Xchat::register($self, $vers, $desc);
Xchat::hook_print('Channel Message', \hrefbugs);
Xchat::hook_print('Your Message', \hrefbugs);
Xchat::hook_print('Your Message', \dispatch);
Xchat::print(Loaded $seve - $desc);
##
sub print_line {
Xchat::print(- x 20);
}
###
sub percfre($) {
my $fre = shift;
my $hits = 0;
map { $hits += $_ } values %freq;
return $hits ? sprintf(%.1f , ($fre/$hits)*100.0) : 0;
}
###
sub hrefbugs {
W:
while ( $_[0][1] =~
/(?:\#([123456789]{1}\d+)) # 1. sure guess
|(?:bug\s*\#?([123456789]{1}\d+)) # 2. sure guess
|(?:^([123456789]{1}\d+)\.?$) # 3. wild guess
|(?:\s([123456789]{1}\d+)\.?$) # 4. wild guess
|(?:([123456789]{1}\d+)^.\d)# 5. wild guess - skip common
'version 1.2' pattern
|(?:\s([123456789]{1}\d+)\s)# 6. wild guess - too much noise,
but ...
/xgi
) {
my ($nam, $fre, $bug) = (undef, undef, undef);
if(defined($1)) {
($nam, $fre, $bug) = ( 'sure_1', ++$freq{'SURE_1'}, $1);
}
elsif (defined($2)) {
($nam, $fre, $bug) = ( 'sure_2', ++$freq{'SURE_2'}, $2);
}
elsif (defined($3)) {
($nam, $fre, $bug) = ( 'WILD_3', ++$freq{'WILD_3'}, $3);
}
elsif (defined($4)) {
($nam, $fre, $bug) = ( 'WILD_4', ++$freq{'WILD_4'}, $4);
}
elsif (defined($5)) {
($nam, $fre, $bug) = ( 'WILD_5', ++$freq{'WILD_5'}, $5);
}
elsif (defined($6)) {
($nam, $fre, $bug) = ( 'WILD_6', ++$freq{'WILD_6'}, $6);
}
else { # no-op
($nam, $fre, $bug) = (undef, undef, undef);
}
if (defined($nam) and defined($fre) and defined($bug) ) {
my @top = sort { $b = $a } values %freq;
my $rank = 0;
for ($rank=0; $rank scalar @top; $rank++) {
if ( $top[$rank] eq $fre ) {
$rank++;
last;
}
}
if ($opt_VERB) {
my $perc = percfre($fre);
Xchat::print(BUGUESS by $seve: rank:$rank name:$nam freq:$fre
($perc%) url: $burl/$bug
Bug#683251: unblock: libisoburn/1.2.2-2
On Wednesday 01 August 2012 22:32:59 Julien Cristau wrote: Hi, On Mon, Jul 30, 2012 at 09:54:50 +0200, George Danchev wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hi, [ please Cc me on replies, I'm not subscribed to -release ] I would like to upload to sid a bug fix against libisoburn/1.2.2-1, which we would like to further have in wheezy as well. I'm now waiting for a green light to upload to sid. Full debdiff, along with explanations, is attached. Go ahead. Cheers, Julien Accepted libisoburn 1.2.2-2 (source all amd64). Successfully built everywhere as well. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Bug#679254: [Pkg-libburnia-devel] libisofs
Just bouncing this one to serve as a reference, since I forgot to do it in the first place when replying. Further discissions will take plane in the pkg- list. On Wednesday 01 August 2012 21:28:22 bash.d wrote: Hello, George Danchev, I would like to help you maintaining the libisofs-package. I already replied to the BTS entry, but have not yet received any response. If you are interested, please answer me. Thank you and regards, Hi Sebastian, [I added pkg-libburnia-devel@ in CC, where Thomas Schmitt is also subscribed] Thank you for your offer to help, it is really appreciated. It is of course my fault of not paying attention close to RFH#679254, but you did it right pinging my on private. Thanks! The three libraries of libburn (RFH#679249), libisofs, and libisoburn (RFH#679265) are best to be maintained together, and involve quite some interaction with upstream, which is fortunately very responsive and helpful. See http://libburnia-project.org for details, and the upstream list is libburn-hack...@pykix.org. For libisofs in particular, there is an effort to complete the hybrid fs part, which involves HFS+ (see libisofs/hfsplus*.c|h in bzr) and HFS (no plus) - no code yet. ISO9660/HFS hybrid is used for the production of Debian PowerPC images, and in order to replace the old and almost unmaintained genisoimage, it would be nice to have this one properly implemented, verified and deployed. (actually these are HFS#630351 and UDF#630863, the latter being a goal in the distant future). The libburnia libraries are covered by in-house test suite called 'releng': See, README, TODO and CHECKLIST, as well as the code at: http://libburnia-project.org/browser/libisoburn/trunk/releng Extending and running this test suite is a good way to build trust that no or less regressions would occur. Then comes the debian-cd task, which is the largest stress-test suite for xorriso (and resp. libisofs in particular) currently known to us, so it is also nice to pay attention to debian-cd BTS record for relevant bugs, the debian-cd mailing list for relevant complaints, and debian-cd live logs as well: http://cdbuilder.debian.org/cdimage-log/ (also see analysis.html) Last, but not least, it is also nice to try to help applications which are trying to make proper use (or resp. abuse) of libburnia libraries to find their way. For instance, see brasero BTS record. To summarize: there is a plenty of code work, thrice as much testing and bug triaging and sorting out (coupled and decoupled) issues or non-issues... and I'm pretty sure Thomas can add some more points as well. While it is true that libburn/libisofs/libisoburn currently bear almost perfectly clean BTS log record, it took, takes, and will take a fair amount of time to preserve this state as it is. So, feel free to pick your niche to contribute to the project :) -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683248: libisoburn: SIGSEGV by uninitialized local variable with -check_media patch_lba0=on
Source: libisoburn
Version: 1.2.2-1
Severity: normal
Tags: upstream patch
As written by Thomas Schmitt:
I just commited a bug fix (written before i got those drugs) which
would be of interest for the stabilized libburnia-1.2.2 of Debian.
The fix is worthwhile, because the bug is nasty albeit rarely occuring.
I encountered a SIGSEGV by dereferring NULL, but it could have been any
other random stack value instead. So the bug has some potential.
The risk of introducing regressions is low.
See: http://libburnia-project.org/changeset/4809
and - if not too inconvenient - the small beautification of
http://libburnia-project.org/changeset/4810
The adjusted patch against 1.2.2 is attached.
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
--- libisoburn-1.2.2.orig/xorriso/write_run.c
+++ libisoburn-1.2.2/xorriso/write_run.c
@@ -2357,7 +2357,7 @@ int Xorriso_update_iso_lba0(struct Xorri
int ret, full_size, i;
char *headpt;
struct burn_drive_info *dinfo;
- struct burn_drive *drive;
+ struct burn_drive *drive = NULL;
off_t seek_ret, to_write;
int tag_type;
uint32_t pos, range_start, range_size, next_tag;
@@ -2387,8 +2387,9 @@ int Xorriso_update_iso_lba0(struct Xorri
if(!(flag 2)) {
/* head_buffer was not filled yet. Read it from output media. */
- if(burn_drive_get_drive_role(drive) == 5) /* write-only */
- return(2);
+ if(drive != NULL)
+ if(burn_drive_get_drive_role(drive) == 5) /* write-only */
+ return(2);
if(job != NULL job-data_to_fd = 0) {
if((flag 8) job-sector_map != NULL) {
ret= Sectorbitmap_bytes_are_set(job-sector_map,
@@ -2416,16 +2417,18 @@ int Xorriso_update_iso_lba0(struct Xorri
Xorriso_msgs_submit(xorriso, 0, xorriso-info_text, errno, FAILURE,0);
return(0);
}
- ret= isoburn_read_iso_head(drive, 0, isosize, head_buffer, 1 13);
+ ret= isoburn_read_iso_head(NULL, 0, isosize, head_buffer, 1 13);
if(ret=0) {
Xorriso_process_msg_queues(xorriso,0);
sprintf(xorriso-info_text,
- Alleged session start does not like ISO 9660.);
+ Alleged session start does not look like ISO 9660.);
Xorriso_msgs_submit(xorriso, 0, xorriso-info_text, errno, FAILURE,0);
return(0);
}
} else {
- ret= isoburn_read_iso_head(drive, iso_lba, isosize, head_buffer, 2);
+ ret= 0;
+ if(drive != NULL)
+ ret= isoburn_read_iso_head(drive, iso_lba, isosize, head_buffer, 2);
if(ret=0) {
Xorriso_process_msg_queues(xorriso,0);
sprintf(xorriso-info_text,
Bug#683251: unblock: libisoburn/1.2.2-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Hi, [ please Cc me on replies, I'm not subscribed to -release ]
I would like to upload to sid a bug fix against libisoburn/1.2.2-1,
which we would like to further have in wheezy as well. I'm now waiting
for a green light to upload to sid. Full debdiff, along with explanations,
is attached.
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
diff -Nru libisoburn-1.2.2/debian/changelog libisoburn-1.2.2/debian/changelog
--- libisoburn-1.2.2/debian/changelog 2012-04-03 21:27:52.0 +0200
+++ libisoburn-1.2.2/debian/changelog 2012-07-30 09:34:57.0 +0200
@@ -1,3 +1,12 @@
+libisoburn (1.2.2-2) unstable; urgency=low
+
+ * Bug fix patch: SIGSEGV-by-uninitialized-local-variable
+Prevent a SIGSEGV due to usage of uninitialized local variable
+with -check_media patch_lba0=on option. Regression introduced
+by version 1.0.6 (Closes: #683248)
+
+ -- George Danchev danc...@spnet.net Fri, 27 Jul 2012 10:26:57 +0200
+
libisoburn (1.2.2-1) unstable; urgency=low
* New upstream release
diff -Nru libisoburn-1.2.2/debian/patches/series libisoburn-1.2.2/debian/patches/series
--- libisoburn-1.2.2/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ libisoburn-1.2.2/debian/patches/series 2012-07-30 09:34:57.0 +0200
@@ -0,0 +1 @@
+SIGSEGV-by-uninitialized-local-variable
diff -Nru libisoburn-1.2.2/debian/patches/SIGSEGV-by-uninitialized-local-variable libisoburn-1.2.2/debian/patches/SIGSEGV-by-uninitialized-local-variable
--- libisoburn-1.2.2/debian/patches/SIGSEGV-by-uninitialized-local-variable 1970-01-01 01:00:00.0 +0100
+++ libisoburn-1.2.2/debian/patches/SIGSEGV-by-uninitialized-local-variable 2012-07-30 09:34:57.0 +0200
@@ -0,0 +1,57 @@
+Description: SIGSEGV by uninitialized local variable with -check_media patch_lba0=on
+ The fix is worthwhile, because the bug is nasty albeit rarely occuring.
+ I encountered a SIGSEGV by dereferring NULL, but it could have been any
+ other random stack value instead. So the bug has some potential.
+ The risk of introducing regressions is low.
+Author: Thomas Schmitt scdbac...@gmx.net
+Origin: upstream, http://libburnia-project.org/changeset/4809
+Bug-Debian: http://bugs.debian.org/683248
+Forwarded: not-needed
+Reviewed-By: George Danchev danc...@spnet.net
+Last-Update: 2012-30-07
+
+--- libisoburn-1.2.2.orig/xorriso/write_run.c
libisoburn-1.2.2/xorriso/write_run.c
+@@ -2357,7 +2357,7 @@ int Xorriso_update_iso_lba0(struct Xorri
+ int ret, full_size, i;
+ char *headpt;
+ struct burn_drive_info *dinfo;
+- struct burn_drive *drive;
++ struct burn_drive *drive = NULL;
+ off_t seek_ret, to_write;
+ int tag_type;
+ uint32_t pos, range_start, range_size, next_tag;
+@@ -2387,8 +2387,9 @@ int Xorriso_update_iso_lba0(struct Xorri
+
+ if(!(flag 2)) {
+/* head_buffer was not filled yet. Read it from output media. */
+- if(burn_drive_get_drive_role(drive) == 5) /* write-only */
+- return(2);
++ if(drive != NULL)
++ if(burn_drive_get_drive_role(drive) == 5) /* write-only */
++ return(2);
+if(job != NULL job-data_to_fd = 0) {
+ if((flag 8) job-sector_map != NULL) {
+ret= Sectorbitmap_bytes_are_set(job-sector_map,
+@@ -2416,16 +2417,18 @@ int Xorriso_update_iso_lba0(struct Xorri
+Xorriso_msgs_submit(xorriso, 0, xorriso-info_text, errno, FAILURE,0);
+return(0);
+ }
+- ret= isoburn_read_iso_head(drive, 0, isosize, head_buffer, 1 13);
++ ret= isoburn_read_iso_head(NULL, 0, isosize, head_buffer, 1 13);
+ if(ret=0) {
+Xorriso_process_msg_queues(xorriso,0);
+sprintf(xorriso-info_text,
+- Alleged session start does not like ISO 9660.);
++ Alleged session start does not look like ISO 9660.);
+Xorriso_msgs_submit(xorriso, 0, xorriso-info_text, errno, FAILURE,0);
+return(0);
+ }
+} else {
+- ret= isoburn_read_iso_head(drive, iso_lba, isosize, head_buffer, 2);
++ ret= 0;
++ if(drive != NULL)
++ ret= isoburn_read_iso_head(drive, iso_lba, isosize, head_buffer, 2);
+ if(ret=0) {
+Xorriso_process_msg_queues(xorriso,0);
+sprintf(xorriso-info_text,
Bug#681694: brasero: Properly watch the child process state
Source: brasero
Version: 3.4.1-2
Severity: normal
Tags: upstream patch
Dear Maintainer,
Please consider answering these questions, where appropriate ***
In libbrasero-burn/burn-process.c:brasero_process_watch_child (gpointer data)
waitpid() could have returned positive value (child's pid) due to the
child's change of state, e.g. child being signalled for any (obscure)
reason (SIGPIPE, SIGSTOP, etc), and also child's exit status is being
blindly examined by flat WEXITSTATUS(status), instead of first checking
WIFEXITED(status) for returning true, i.e. that the child has actually exited.
This could lead to unnoticed problem with the child process state. For
instance, I think the log message [1] of process finished with status
0 could be pretty much bogus in this particular case shown in the log with
a burn failure halfway around ~49-50%. (see the tail of waitpid(2) for a good
example of a diligent parent waiting for their possibly naughty child)
[1] https://launchpadlibrarian.net/71440716/brasero_log.txt
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
-- no debconf information
--- brasero-3.4.1.orig/libbrasero-burn/burn-process.c
+++ brasero-3.4.1/libbrasero-burn/burn-process.c
@@ -294,12 +294,40 @@ brasero_process_watch_child (gpointer da
* brasero_job_finished/_error is called before the pipes are closed so
* as to let plugins read stderr / stdout till the end and set a better
* error message or simply decide all went well, in one word override */
- priv-return_status = WEXITSTATUS (status);
+/*
+ priv-return_status = WEXITSTATUS (status);
+*/
priv-watch = 0;
priv-pid = 0;
-
+ if (WIFEXITED(status)) { /* WEXITSTATUS macro should only be used if WIFEXITED returned true */
+ priv-return_status = WEXITSTATUS (status);
+ BRASERO_JOB_LOG (data, child process exited with status %d, WEXITSTATUS (status));
+ }
+ else if (WIFSIGNALED(status)) { /* there is no meaningful child return status */
+ int errsv = errno; /* unrecoverable error */
+ priv-error = g_error_new (BRASERO_BURN_ERROR, BRASERO_BURN_ERROR_GENERAL,
+ _(child process killed by signal %d. Error (%s)), WTERMSIG(status), g_strerror (errsv));
+ BRASERO_JOB_LOG (data, child process killed by signal %d, WTERMSIG(status));
+ return FALSE; /* not to be called by g_timeout_add() anymore */
+ }
+ else if (WIFSTOPPED(status)) { /* there is no meaningful child return status */
+ int errsv = errno; /* unrecoverable error or maybe try to send SIGCONT to the child? */
+ priv-error = g_error_new (BRASERO_BURN_ERROR, BRASERO_BURN_ERROR_GENERAL,
+ _(child process stopped by signal %d. Error (%s)), WSTOPSIG(status), g_strerror (errsv));
+ BRASERO_JOB_LOG (data, child process stopped by signal %d, WSTOPSIG(status));
+ return FALSE; /* not to be called by g_timeout_add() anymore */
+ }
+ else {
+ int errsv = errno; /* unrecoverable error */
+ priv-error = g_error_new (BRASERO_BURN_ERROR, BRASERO_BURN_ERROR_GENERAL,
+ _(child process unhandled Error (%s)), g_strerror (errsv));
+ BRASERO_JOB_LOG (data, child process unhandled Error (%s), g_strerror (errsv));
+ return FALSE; /* not to be called by g_timeout_add() anymore */
+ }
+
+/*
BRASERO_JOB_LOG (data, process finished with status %i, WEXITSTATUS (status));
-
+*/
result = brasero_process_finished (data);
if (result == BRASERO_BURN_RETRY) {
GError *error = NULL;
Bug#681178: unblock: libburn/1.2.2-2
On Thursday 12 July 2012 06:38:15 Philipp Kern wrote: On Wed, Jul 11, 2012 at 08:27:23AM +0200, George Danchev wrote: I've got three minor bugfixes from not yet released libburn 1.2.4, which I'd like to apply to libburn/1.2.2-1. I've not yet uploaded libburn 1.2.2-2, so this is a request for upload to sid and unblock. Both, Thomas Schmitt and I agree we want them in wheezy. Our test suite found in libisoburn/releng, which tries to cover most of the libburn, libisofs, libisoburn functionality reveals no regressions. Please go ahead. I cannot do the unblock right away though. Please ping after it got accepted. libburn/1.2.2-2 got accepted and successfully built everywhere. thanks -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Bug#681178: unblock: libburn/1.2.2-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hi, [ please Cc me on replies, I'm not subscribed to -release ] I've got three minor bugfixes from not yet released libburn 1.2.4, which I'd like to apply to libburn/1.2.2-1. I've not yet uploaded libburn 1.2.2-2, so this is a request for upload to sid and unblock. Both, Thomas Schmitt and I agree we want them in wheezy. Our test suite found in libisoburn/releng, which tries to cover most of the libburn, libisofs, libisoburn functionality reveals no regressions. Full debdiff attached, changelog follows inline: libburn (1.2.2-2) unstable; urgency=low * Bugfix patch (Closes: #680910) 01_sao-tracks-started-by-audio-pause: CD SAO sessions with data tracks was started by an audio pause. Affected is an old Sony CD burner, refusing to burn SAO. * Bugfix patch (Closes: #680911) 02_sao-2-sectors-short-fix: CD tracks are perceived 2 sectors too short. A correclty burnt CD media in SAO mode, will not be recognized as correct burn by xorriso inspection, which believes that the track size is two sectors shorter, where it is not. * Bugfix patch (Closes: #680968) 03_cdrskin-sigsegv-track-source-added-no-drive-available cdrskin could SIGSEGV if track source was added when no drive was available. -- George Danchev danc...@spnet.net Mon, 09 Jul 2012 10:47:15 +0200 unblock libburn/1.2.2-2 -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash diff -Nru libburn-1.2.2/debian/changelog libburn-1.2.2/debian/changelog --- libburn-1.2.2/debian/changelog 2012-04-03 15:24:18.0 +0200 +++ libburn-1.2.2/debian/changelog 2012-07-10 17:42:31.0 +0200 @@ -1,3 +1,22 @@ +libburn (1.2.2-2) unstable; urgency=low + + * Bugfix patch (Closes: #680910) +01_sao-tracks-started-by-audio-pause: +CD SAO sessions with data tracks was started by an audio pause. +Affected is an old Sony CD burner, refusing to burn SAO. + * Bugfix patch (Closes: #680911) +02_sao-2-sectors-short-fix: +CD tracks are perceived 2 sectors too short. +A correclty burnt CD media in SAO mode, will not be recognized +as correct burn by xorriso inspection, which believes that the +track size is two sectors shorter, where it is not. + * Bugfix patch (Closes: #680968) +03_cdrskin-sigsegv-track-source-added-no-drive-available +cdrskin could SIGSEGV if track source was added when no drive +was available. + + -- George Danchev danc...@spnet.net Mon, 09 Jul 2012 10:47:15 +0200 + libburn (1.2.2-1) unstable; urgency=low * New upstream release diff -Nru libburn-1.2.2/debian/patches/01_sao-tracks-started-by-audio-pause libburn-1.2.2/debian/patches/01_sao-tracks-started-by-audio-pause --- libburn-1.2.2/debian/patches/01_sao-tracks-started-by-audio-pause 1970-01-01 01:00:00.0 +0100 +++ libburn-1.2.2/debian/patches/01_sao-tracks-started-by-audio-pause 2012-07-10 17:42:31.0 +0200 @@ -0,0 +1,99 @@ +Description: CD SAO sessions with data tracks was started by an audio pause. + Affected is an old Sony CD burner, refusing to burn SAO. +Author: Thomas Schmitt scdbac...@gmx.net +Origin: upstream, http://libburnia-project.org/changeset/4744 +Bug: none +Bug-Debian: http://bugs.debian.org/680910 +Forwarded: not-needed +Reviewed-By: George Danchev danc...@spnet.net +Last-Update: 2012-07-10 + +--- libburn-1.2.2.orig/doc/cookbook.txt libburn-1.2.2/doc/cookbook.txt +@@ -296,8 +296,9 @@ A pre-gap of 2 seconds is mandatory only + post-gap may be needed with further tracks if they have neighbors with + different DATA FORM values. (Such mixing is not yet supported by libburn.) + +-DATA FORM is 00h for audio payload, 01h for audio pause, 10h for data, +-41h for CD-TEXT in Lead-in. ++DATA FORM is 00h for audio payload, 01h for audio pause (Lead-in and Lead-out), ++10h for data, 14h for data pause (Lead-in and Lead-out). ++This shall be ored with 40h for CD-TEXT in Lead-in. + (mmc5r03c.pdf 6.33.3.11 CD-DA Data Form, 6.33.3.12 CD-ROM mode 1 Form) + + SCMS value 80h in conjunction with bit5 of CTL is an indicator for exhausted +@@ -318,7 +319,8 @@ The next entry (eventually being the fir + Its content is + (CTL|ADR ,00h,00h, DATA FORM ,00h,00h,00h,00h) + With the CTL|ADR for the first track: 41h for data, 01h for audio. +-DATA FORM is 41h if CD-TEXT shall be stored in Lean-in. Else it is 01h. ++DATA FORM is pause (audio=01h, data=14h). Ored with 40h if CD-TEXT shall ++be stored in Lean-in. + + The LBA for the first write is negative: -150. This corresponds to MSF address + 00h:00h:00h. All addresses are to be given in MSF format. +@@ -354,8 +356,9 @@ A track must at least contain 300 payloa
Bug#681189: snappy-player: SIGSEGV on close when run for the first time, hence ~/.config/snappy/ is not present yet
Source: snappy-player
Version: 0.2-1
Severity: normal
Tags: upstream patch
Dear Maintainer,
$ snappy Vinid\ \\ State-V\ -\ Belief.mp3
Loading: file:///root/Music/Vinid State-V - Belief.mp3
Loading ui!
(snappy:28960): GLib-GObject-CRITICAL **: g_object_ref: assertion
G_IS_OBJECT (object)' failed
** (snappy:28960): WARNING **: Problem inhibiting the screensaver:
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name
org.gnome.SessionManager does not exist
closing snappy
Segmentation fault
[ gdb foo... skipped ]
$ ls $HOME/.config/snappy
Supposedly you all have had ~/.config/snappy/ already in place for
a long time, so you haven't noticed the FAIL.
The attached patch fixes this for me. Please add to patches/series,
and sort out the header fields of the diff, when BTS entry returns.
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Description: short summary of the patch
TODO: Put a short summary on the line above and replace this paragraph
with a longer explanation of this change. Complete the meta-information
with other relevant fields (see below for details). To make it easier, the
information below has been extracted from the changelog. Adjust it or drop
it.
.
snappy-player (0.2-1) unstable; urgency=low
.
* New upstream release, Mrs. Robinson, you're trying to seduce me.:
+ debian/control:
- Build-depend on GLib = 2.26 for GDBus, libxtst and
gst-plugins-base = 0.10.30.
Author: Sebastian Dröge sl...@debian.org
---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:
Origin: vendor|upstream|other, url of original patch
Bug: url in upstream bugtracker
Bug-Debian: http://bugs.debian.org/bugnumber
Bug-Ubuntu: https://launchpad.net/bugs/bugnumber
Forwarded: no|not-needed|url proving that it has been forwarded
Reviewed-By: name and email of someone who approved the patch
Last-Update: -MM-DD
--- snappy-player-0.2.orig/src/gst_engine.c
+++ snappy-player-0.2/src/gst_engine.c
@@ -277,6 +277,19 @@ remove_uri_unfinished_playback (GstEngin
/* Config file path */
config_dir = g_get_user_config_dir ();
+
+ /* Self config directory, i.e. .config/snappy/ */
+ struct stat st_self;
+ if ( 0 != stat(g_strdup_printf(%s/snappy, config_dir), st_self)) {
+ if ( 0 != mkdir( g_strdup_printf(%s/snappy, config_dir), 0777))
+ perror(Failed to create ~/.config/snappy/ directory);
+ }
+ else if (!S_ISDIR(st_self.st_mode)) {
+ errno = ENOTDIR;
+ perror(~/config/snappy/ already exists);
+ }
+
+ /* History file */
path = g_strdup_printf (%s/snappy/history, config_dir);
/* Remove key from history file */
@@ -285,10 +298,14 @@ remove_uri_unfinished_playback (GstEngin
/* Save gkeyfile to a file */
data = g_key_file_to_data (keyfile, NULL, NULL);
- file = fopen (path, w);
- fputs (data, file);
- fclose (file);
-
+ if (NULL != (file = fopen (path, w))) {
+fputs (data, file);
+fclose (file);
+ }
+ else {
+g_print(unable to open file: %s\n, path);
+ }
+
g_free (data);
g_free (path);
Bug#681202: snappy-player: snappy player lacks a man page
Source: snappy-player Version: 0.2-1 Severity: normal Dear Maintainer, Thank you for this nice and lean player. However, providing a (even short) man page, would be really nice and helpful. Package description claims that: Everything is available through both the mouse and keyboards for usability comfort..., but are the users supposed to dig the source in order to find out how to control the player via the keyboard. Also, policy #12.1 stipulates that the lack of a man page is considered a bug and should be reported to the BTS. So, here is a man page nag. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681204: snappy-player: SIGSEGV if recently viewed URIs list is empty
Source: snappy-player
Version: 0.2-1
Severity: normal
Tags: upstream patch
Dear Maintainer,
$ cat ~/.config/snappy/history
$
$ snappy -r
These are the recently viewed URIs:
Segmentation fault
$ rm -rf .config/snappy/
george@sid:~$ snappy -r
These are the recently viewed URIs:
Segmentation fault
george@sid:/tmp/snappy-player-0.2/src$ gdb ./snappy
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 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.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /tmp/snappy-player-0.2/src/snappy...done.
(gdb) run -r
Starting program: /tmp/snappy-player-0.2/src/snappy -r
[Thread debugging using libthread_db enabled]
Using host libthread_db library
/lib/x86_64-linux-gnu/libthread_db.so.1.
These are the recently viewed URIs:
Program received signal SIGSEGV, Segmentation fault.
process_args (argc=1, argv=0x7fffe3f8,
file_list=file_list@entry=0x7fffe2a0,
fullscreen=fullscreen@entry=0x7fffe2d8,
secret=secret@entry=0x7fffe2dc, context=context@entry=0x6108b0)
at snappy.c:96
96 for (c = 0; recent[c] != NULL; c++) {
(gdb) list
91
92 g_print (These are the recently viewed URIs: \n\n);
93
94 recent = get_recently_viewed ();
95
96 for (c = 0; recent[c] != NULL; c++) {
97if (c 9)
98 g_print (0%d: %s \n, c + 1, recent[c]);
99else
100 g_print (%d: %s \n, c + 1, recent[c]);
(gdb) p recent
$1 = (gchar **) 0x0
(gdb)
The attached patch fixes this for me. Please fix the diff headers
when BTS bug number entry is returned (add to series as well).
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Description: short summary of the patch
TODO: Put a short summary on the line above and replace this paragraph
with a longer explanation of this change. Complete the meta-information
with other relevant fields (see below for details). To make it easier, the
information below has been extracted from the changelog. Adjust it or drop
it.
.
snappy-player (0.2-1) unstable; urgency=low
.
* New upstream release, Mrs. Robinson, you're trying to seduce me.:
+ debian/control:
- Build-depend on GLib = 2.26 for GDBus, libxtst and
gst-plugins-base = 0.10.30.
Author: Sebastian Dröge sl...@debian.org
---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:
Origin: vendor|upstream|other, url of original patch
Bug: url in upstream bugtracker
Bug-Debian: http://bugs.debian.org/bugnumber
Bug-Ubuntu: https://launchpad.net/bugs/bugnumber
Forwarded: no|not-needed|url proving that it has been forwarded
Reviewed-By: name and email of someone who approved the patch
Last-Update: -MM-DD
--- snappy-player-0.2.orig/src/snappy.c
+++ snappy-player-0.2/src/snappy.c
@@ -89,9 +89,13 @@ process_args (int argc, char *argv[],
if (recent) {
gchar **recent = NULL;
-g_print (These are the recently viewed URIs: \n\n);
-
recent = get_recently_viewed ();
+if(!recent) {
+ g_print (There are no recently viewed URIs.\n\n);
+ goto quit;
+}
+
+g_print (These are the recently viewed URIs: \n\n);
for (c = 0; recent[c] != NULL; c++) {
if (c 9)
Bug#680910: libburn: CD SAO sessions with data tracks started by an audio pause
Source: libburn
Version: 1.2.2-1
Severity: normal
Tags: upstream patch
CD SAO sessions with data tracks started by an audio pause.
This affects an old Sony CD burner which refuses to burn SAO.
Upstream fix: http://libburnia-project.org/changeset/4744
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
--- libburn-1.2.2.orig/doc/cookbook.txt
+++ libburn-1.2.2/doc/cookbook.txt
@@ -296,8 +296,9 @@ A pre-gap of 2 seconds is mandatory only
post-gap may be needed with further tracks if they have neighbors with
different DATA FORM values. (Such mixing is not yet supported by libburn.)
-DATA FORM is 00h for audio payload, 01h for audio pause, 10h for data,
-41h for CD-TEXT in Lead-in.
+DATA FORM is 00h for audio payload, 01h for audio pause (Lead-in and Lead-out),
+10h for data, 14h for data pause (Lead-in and Lead-out).
+This shall be ored with 40h for CD-TEXT in Lead-in.
(mmc5r03c.pdf 6.33.3.11 CD-DA Data Form, 6.33.3.12 CD-ROM mode 1 Form)
SCMS value 80h in conjunction with bit5 of CTL is an indicator for exhausted
@@ -318,7 +319,8 @@ The next entry (eventually being the fir
Its content is
(CTL|ADR ,00h,00h, DATA FORM ,00h,00h,00h,00h)
With the CTL|ADR for the first track: 41h for data, 01h for audio.
-DATA FORM is 41h if CD-TEXT shall be stored in Lean-in. Else it is 01h.
+DATA FORM is pause (audio=01h, data=14h). Ored with 40h if CD-TEXT shall
+be stored in Lean-in.
The LBA for the first write is negative: -150. This corresponds to MSF address
00h:00h:00h. All addresses are to be given in MSF format.
@@ -354,8 +356,9 @@ A track must at least contain 300 payloa
(mmc5r03c.pdf 6.33.3.6)
At the end of the session there is a lead-out entry
-(CTL|ADR,AAh,01h,01h,00h,MIN,SEC,FRAME)
+(CTL|ADR,AAh,01h,DATA FORM,00h,MIN,SEC,FRAME)
marking the end of the last track. (With libburn CTL is as of the last track.)
+DATA FORM is 01h for audio, 14h for data.
---
--- libburn-1.2.2.orig/libburn/write.c
+++ libburn-1.2.2/libburn/write.c
@@ -508,11 +508,13 @@ struct cue_sheet *burn_create_toc_entrie
Track mode has unusable value, 0, 0);
goto failed;
}
+ if (tar[0]-mode BURN_AUDIO)
+ leadin_form = 0x01;
+ else
+ leadin_form = 0x14;
if (o-num_text_packs 0) {
- leadin_form = 0x41;
+ leadin_form |= 0x40;
} else {
- leadin_form = 0x01;
-
/* Check for CD-TEXT in session. Not the final creation,
because the cue sheet content might be needed for CD-TEXT
pack type 0x88 TOC.
@@ -522,7 +524,7 @@ struct cue_sheet *burn_create_toc_entrie
if (ret 0)
goto failed;
else if (ret 0)
-leadin_form = 0x41;
+leadin_form |= 0x40;
}
}
@@ -803,7 +805,9 @@ XXX this is untested :)
e[2].pmin = m;
e[2].psec = s;
e[2].pframe = f;
- ret = add_cue(sheet, ctladr | 1, 0xAA, 1, 1, 0, runtime);
+
+ ret = add_cue(sheet, ctladr | 1, 0xAA, 1, leadin_form 0x3f,
+ 0, runtime);
if (ret = 0)
goto failed;
return sheet;
--- libburn-1.2.2.orig/libburn/mmc.c
+++ libburn-1.2.2/libburn/mmc.c
@@ -908,6 +908,12 @@ int mmc_write(struct burn_drive *d, int
extern int burn_sg_log_scsi;
#endif
+/*
+fprintf(stderr, libburn_DEBUG: buffer sectors= %d bytes= %d\n,
+buf-sectors, buf-bytes);
+*/
+
+
c = (d-casual_command);
#ifdef Libburn_log_in_and_out_streaM
Bug#680911: libburn: CD tracks are perceived 2 sectors too short
Source: libburn
Version: 1.2.2-1
Severity: normal
Tags: upstream patch
Info gathered with long conversations with Thomas:
CD tracks are perceived 2 sectors too short. Nice with TAO, bad with SAO.
The returned values of two different MMC track information commands differ
by 2. On Samsung and on LG drives. Must be a feature, but would be correct
only for TAO tracks.
Also, wodim -sao and libburn SAO produce CDs with the same effect. So it
seems not to be a critical bug at burn time. It will confuse brasero users
who manage to talk it into SAO and then want to inspect the CD by xorriso.
xorriso : WARNING : Session 1 bears ISO image size 13456s larger than track
size 13454s
xorriso believes that the MMC table-of-content says 13454 blocks.
But I can read 13456 without error. By xorriso, by dd, by mount and diff -r.
The CD is burnt fine, but xorriso does not know it.
This shows up if one burns to blank CD by:
wodim -nopad -sao
or by:
xorriso -padding 0
or if one forces Brasero into SAO
or (probably) if one burns with Brasero and intermediate disc storage.
Upstream fix: http://libburnia-project.org/changeset/4778
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
--- libburn-1.2.2.orig/libburn/structure.c
+++ libburn-1.2.2/libburn/structure.c
@@ -794,7 +794,9 @@ int burn_disc_cd_toc_extensions(struct b
if (ret 0) {
ret = mmc_four_char_to_int(
buf-data + 24);
- if (ret prev_entry-track_blocks)
+ if (ret prev_entry-track_blocks
+ ((!drive-current_is_cd_profile) ||
+ ret prev_entry-track_blocks - 2))
prev_entry-track_blocks = ret;
}
prev_entry-extensions_valid |= 1;
Bug#680968: libburn: cdrskin SIGSEGV if track source was added when no drive was available
Source: libburn
Version: 1.2.2-1
Severity: normal
Tags: upstream patch
cdrskin could SIGSEGV if track source was added when no drive was available.
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Description: cdrskin SIGSEGV if track source was added when no drive was available
Author: Thomas Schmitt scdbac...@gmx.net
Origin: upstream, http://libburnia-project.org/changeset/4698
Bug: none
Bug-Debian: http://bugs.debian.org/bugnumber
Forwarded: not-needed
Reviewed-By: George Danchev danc...@spnet.net
Last-Update: 2012-07-10
--- libburn-1.2.2.orig/cdrskin/cdrskin.c
+++ libburn-1.2.2/cdrskin/cdrskin.c
@@ -1341,8 +1341,13 @@ int Cdrtrack_open_source_path(struct Cdr
else {
*fd= -1;
- Cdrskin_get_device_adr(track-boss,device_adr,raw_adr,
- no_convert_fs_adr,0);
+ ret= Cdrskin_get_device_adr(track-boss,device_adr,raw_adr,
+ no_convert_fs_adr,0);
+ if(ret = 0) {
+ fprintf(stderr,
+ cdrskin: FATAL : No drive found. Cannot prepare track.\n);
+ return(0);
+ }
/*
fprintf(stderr,
cdrskin: DEBUG : device_adr='%s' , raw_adr='%s' , ncfs=%d\n,
@@ -3706,12 +3711,25 @@ int Cdrskin_destroy(struct CdrskiN **o,
}
+int Cdrskin_assert_driveno(struct CdrskiN *skin, int flag)
+{
+ if(skin-driveno 0 || (unsigned int) skin-driveno = skin-n_drives) {
+ fprintf(stderr,
+ cdrskin: FATAL : No drive found. Cannot perform desired operation.\n);
+ return(0);
+ }
+ return(1);
+}
+
+
/** Return the addresses of the drive. device_adr is the libburn persistent
address of the drive, raw_adr is the address as given by the user.
*/
int Cdrskin_get_device_adr(struct CdrskiN *skin,
char **device_adr, char **raw_adr, int *no_convert_fs_adr, int flag)
{
+ if(skin-driveno 0 || (unsigned int) skin-driveno = skin-n_drives)
+ return(0);
burn_drive_get_adr(skin-drives[skin-driveno],skin-device_adr);
*device_adr= skin-device_adr;
*raw_adr= skin-preskin-raw_device_adr;
@@ -3782,6 +3800,10 @@ int Cdrskin_attach_fifo(struct CdrskiN *
int profile_number;
char profile_name[80];
+ ret= Cdrskin_assert_driveno(skin, 0);
+ if(ret = 0)
+ return(ret);
+
/* Refuse here and thus use libburn fifo only with single track, non-CD */
ret= burn_disc_get_profile(skin-drives[skin-driveno].drive,
profile_number, profile_name);
@@ -3960,6 +3982,9 @@ int Cdrskin_grab_drive(struct CdrskiN *s
drive= NULL;
skin-grabbed_drive= drive;
} else {
+ ret= Cdrskin_assert_driveno(skin, 0);
+ if(ret = 0)
+ return(ret);
drive= skin-drives[skin-driveno].drive;
skin-grabbed_drive= drive;
}
@@ -8720,12 +8745,15 @@ int Cdrskin_create(struct CdrskiN **o, s
{*exit_value= 2; goto ex;}
}
skin-n_drives= 1;
+ skin-driveno= 0;
burn_drive_release(skin-drives[0].drive, 0);
} else {
while (!burn_drive_scan((skin-drives), (skin-n_drives))) {
usleep(2);
/* ??? set a timeout ? */
}
+ if(skin-n_drives = 0)
+ skin-driveno= -1;
}
burn_msgs_set_severities(skin-preskin-queue_severity,
Bug#680989: brasero: [libburnia plugin] Use traditional trailing padding of 300kB for TAO tracks
@param t the track to define @param offset The lib will write this many 0s before start of data @param tail The number of extra 0s to write after data @param pad 1 means the lib should pad the last sector with 0s if the track isn't exactly sector sized. (otherwise the lib will begin reading from the next track) @param mode data format (bitfield) */ void burn_track_define_data(struct burn_track *t, int offset, int tail, int pad, int mode); It cannot harm to set parameter pad to 1. But libisofs will anyway only produce complete sectors of 2048 bytes. Important is parameter tail. Author: Thomas Schmitt scdbac...@gmx.net Bug-Debian: http://bugs.debian.org/679311 --- The information above should follow the Patch Tagging Guidelines, please checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here are templates for supplementary fields that you might want to add: Origin: vendor|upstream|other, url of original patch Bug: url in upstream bugtracker Bug-Debian: http://bugs.debian.org/bugnumber Bug-Ubuntu: https://launchpad.net/bugs/bugnumber Forwarded: no|not-needed|url proving that it has been forwarded Reviewed-By: George Danchev danc...@spnet.net Last-Update: 2012-07-10 --- brasero-3.4.1.orig/plugins/libburnia/burn-libburn.c +++ brasero-3.4.1/plugins/libburnia/burn-libburn.c @@ -267,7 +267,7 @@ brasero_libburn_add_fd_track (struct bur BraseroBurnResult result; track = burn_track_create (); - burn_track_define_data (track, 0, 0, 0, mode); + burn_track_define_data (track, 0, 300*1024, 0, mode); src = brasero_libburn_create_fd_source (fd, size, pvd); result = brasero_libburn_add_track (session, track, src, mode, error);
Bug#617409: [Pkg-libburnia-devel] Bug#617409: brasero: Brasero corrupts all blank CD-R when burning (was: additional info)
On Saturday 07 July 2012 19:28:53 Thomas Schmitt wrote:
Hi,
Simon Wenner wrote:
xorriso seems to work as expected.
Your report and the one of Alain Rpnpif support the theory that your drives
dislike CD write type TAO with your particular CD media or in general.
I failed to force Brasero into using the other write type. (Details below.)
I see in Brasero 2.30.3 source code in file
./plugins/libburnia/burn-libburn.c
if (flags BRASERO_BURN_FLAG_DAO)
burn_write_opts_set_write_type (opts,
BURN_WRITE_SAO,
BURN_BLOCK_SAO);
else {
burn_write_opts_set_write_type (opts,
BURN_WRITE_TAO,
BURN_BLOCK_MODE1);
If you can modify that code, so that both become
BURN_WRITE_SAO,
BURN_BLOCK_SAO);
then you cripple it for appendable CD and some DVD, but would force it to
use SAO on blank CDs.
I am willing to bet 1 eurocent on this CD being readable.
Let's see :)
George or Paul:
Can you provide Simon and Alain with a patch that does this to the Debian
source of Brasero in Wheezy ?
Just change all calls of burn_write_opts_set_write_type() to send the
same parameters as the one with BURN_WRITE_SAO.
get the source package (apt-get source) and just edit
plugins/libburnia/burn-libburn.c then
george@sid:/tmp/brasero-3.4.1$ dpkg-source --commit
dpkg-source: info: local changes detected, the modified files are:
brasero-3.4.1/plugins/libburnia/burn-libburn.c
Enter the desired patch name: libburn-cd-sao
dpkg-source: info: local changes have been recorded in a new patch:
brasero-3.4.1/debian/patches/libburn-cd-sao
The modification is already applied, thus build with:
george@sid:/tmp/brasero-3.4.1$ dpkg-buildpackage
(Program will be usable just for testing with blank CD, not for production.
A proposal for a better remedy would follow in case of success.)
Lengthy reasoning and experiments:
The version distributed by Debian is based on the same libburn
and the same libisofs as Brasero.
But better check this by ldd:
On my sid, these are as expected:
$ ldd /usr/bin/xorriso | grep libisofs
# ldd /usr/bin/xorriso | grep libisofs
libisofs.so.6 = /usr/lib/libisofs.so.6 (0x7f913488b000)
$ ldd /usr/lib/brasero-0/plugins/libbrasero-libisofs.so | grep libisofs
# ldd /usr/lib/brasero3-1/plugins/libbrasero-libisofs.so | grep libisofs
libisofs.so.6 = /usr/lib/libisofs.so.6 (0x7f2945053000)
$ ldd /usr/bin/xorriso | grep libburn
# ldd /usr/bin/xorriso | grep libburn
libburn.so.4 = /usr/lib/libburn.so.4 (0x7fa403dc2000)
$ ldd /usr/lib/brasero-0/plugins/libbrasero-libburn.so | grep libburn
# ldd /usr/lib/brasero3-1/plugins/libbrasero-libburn.so | grep libburn
libburn.so.4 = /usr/lib/libburn.so.4 (0x7fa6810c)
--
pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617409: [Pkg-libburnia-devel] Bug#617409: brasero: Brasero corrupts all blank CD-R when burning (was: additional info)
On Friday 06 July 2012 16:43:07 Thomas Schmitt wrote: Hi, Thomas, thank you performing these tests. I think you've done enough already :) in order to apply George's patch anyway, i have tried to disable libburn so that growisofs would be used with DVD. No success. Both, growisofs and libburn are enabled but also greyed, so that i cannot change their checkboxes. Hm, did you try to mess up with gconf-editor (package of the same name)? You can start it, and search for brasero string, that is Ctrl+F... then find brasero/config/priorities and adjust the weights of growisofs and libisofs plugins, so these being higher than the rest. It is not like I'm an expert in this particlar area:P Whatever, just in case it brings any new insight: $ cd brasero-2.30.3 $ mv ~/check-child-status debian/patches/check-child-status $ echo check-child-status debian/patches/series $ dpkg-buildpackage ... time enough for a tea break ... # apt-get --purge remove brasero # apt-get install libbrasero-media0 # dpkg -i brasero_2.30.3-2_amd64.deb $ brasero Well, it still burns readable DVD. How to get a log file ? Just try burning another DVD, fail, and get offered to save a log. Hm, uses libburn and libisofs and you observed a fail? Life is so easy ... :)) It still uses libburn, not growisofs. But no further insight: + BRASERO_JOB_LOG (data, process exited with status %d, WEXITSTATUS (status)); + BRASERO_JOB_LOG (data, process killed by signal %d, WTERMSIG(status)); + BRASERO_JOB_LOG (data, process stopped by signal %d, WSTOPSIG(status)); The word process does not appear in the log of the failed run. It did not get that far, i assume. + printf(process exited, status=%d\n, WEXITSTATUS(status)); + printf(process killed by signal %d\n, WTERMSIG(status)); + printf(process stopped by signal %d\n, WSTOPSIG(status)); Nothing to see of those in xterm where i started brasero. Not with the successful runs either. As I get it from the code brasero_process_watch_child() routine, containing those prints, would only be called when external applications like growisofs are being started in the child process (there are also routines to read their stdout and stderr). Hence, there is no chance to see them in your libburn+libisofs test above. OTOH, in the log file [1] where growisofs was engaged you can see: BraseroGrowisofs process finished with status 0 which is spitted by the original routine brasero_process_watch_child() ... if (waitpid (priv-pid, status, WNOHANG) = 0) return TRUE; priv-return_status = WEXITSTATUS (status); priv-watch = 0; priv-pid = 0; BRASERO_JOB_LOG (data, process finished with status %i, WEXITSTATUS (status)); ... and where is it not actually wait()'ed properly, since the waitpid() could have returned positive value (child's pid) due to the child's change of state, e.g. child being signalled for any (obscure) reason (SIGPIPE, SIGKILL, etc), and also child's exit status is being blindly examined by flat WEXITSTATUS(status), instead of first checking WIFEXITED(status) for returning true, i.e. that the child has actually exited. Thus, the above log message of process finished with status 0 is pretty much bogus in this particular case shown in the log with the burn failure halfway around ~49-50%. (see the tail of waitpid(2) for a good example of a diligent parent waiting for their possibly naughty child) [1] https://launchpadlibrarian.net/71440716/brasero_log.txt -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617409: [Pkg-libburnia-devel] Bug#617409: brasero: Road map (was: Brasero corrupts all blank CD-R when burning)
On Friday 06 July 2012 18:11:19 Alain Rpnpif wrote: Hello, Sorry for the time to reply. I was busy. Hi Alain, and thanks for the feedback! Le 6 juillet 2012, Paul Menzel a écrit : thank you for your effort. Unfortunately no one affected by this problem has replied yet. (Although we should give them some more time to reply. Other things might be more important currently.) I have also this issue. Until then I suggest to not bother anymore with that problem. If we do not get anymore replies during the next two weeks, I suggest to split up the Debian bug report. The first one of rpnpif, downgrade the severity to important and mark it as unreproducible as it worked for you. Simon’s answer is probably the other bug about stopping at half time/size which also is dealt with at the Launchpad report. This seems to be an issue with newer versions and that help and more information are needed to fix it. You are perhaps right with the speed that it should not be the problem. Nod. xorriso works fine for me with CD-RW and CD-R. This is quite useful piece of information! This would keep us sane... well at least we are not on crack with the underlying libburnia libraries :) I have tried the George's patch. This works fine for CR-RW only but not with CD-R (I have crashed 2 CD-R to confirm). With CD-R, some files are full of 00H. Interesting. Now there is something I don't really get: You were using libisofs plugin to talk to the growisofs plugin engaging growisofs as burner application. But to my best knowledge growisofs is only able to burn on DVDs? Could this explain a possible growisofs failure when faced with the task to burn non-DVDs? I'd expected growisofs to be tested with DVDs and to succeed indeed. Btw, any log messages like this one: https://launchpadlibrarian.net/71440716/brasero_log.txt or any printf's on the terminal you have started brasero on? But I have a message at the end of compilation that give the list of the patches and that said for each, that they are removed. Normal ? It is expected. You can also see 'dpkg-source: info:' messages at the begining, saying that unapplied patches listed in 'series' are being applied. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617409: [Pkg-libburnia-devel] Bug#617409: brasero: Brasero corrupts all blank CD-R when burning (was: additional info)
On Friday 06 July 2012 20:09:10 Thomas Schmitt wrote: Hi, I roughly understand your theory about WEXITSTATUS. It would explain why Brasero stops to transfer more data. But without being able to engage growisofs, it will be hard to examine. Ahem, and looking at http://fy.chalmers.se/~appro/linux/DVD+RW/ I get that growisofs is not recommended for burning CD-R[W]... hence it might fail quite miserably when faced with CD-* media; it is however quite good for handling DVD+RW and DVD-RW media. A. Yes. It should be explicitly noted that growisofs is a front-end to mkisofs, i.e. invokes mkisofs to perform the actual ISO9660 file system layout. Secondly, the DVD burners available on the market can burn even CD-R[W] media and cdrecord is the tool for this job. So how do i upgrade libisofs, libburn and Brasero to sid ? Upgrading to the versrions of sid would be a different round (if you're willing to upgrade to - completely or whatever is also dragged to as dependencies from sid). I still think your squeeze version of brasero is prone to the growisofs failure others are observing. How do i enable use of growisofs ? from zless /usr/share/doc/brasero/README I can see two ways: configuration and removal. Notes on plugins for advanced users 1. configuration From the UI you can only configure (choose to use or not to use mostly) non essential plugins; that is all those that don't burn, blank, or image. If you really want to choose which of the latters you want brasero to use, one simple solution is to remove the offending plugin from brasero plugin directory (install_path/lib/brasero/plugins/) if you're sure that you won't want to use it. You can also set priorities between plugins. They all have a hardcoded priority that can be overriden through Gconf. Each plugin has a key in /apps/brasero/config/priority. If you set this key to -1 this turns off the plugin. If you set this key to 0 this leaves the internal hardcoded priority - the default that basically lets brasero decide what's best. If you set this key to more than 0 then that priority will become the one of the plugin - the higher, the more it has chance to be picked up. So set all burning plugins to -1, except growisofs, which should be set to 1 or 2 as well as libisofs one should be set to. Btw, /usr/lib/brasero3-1/plugins is where my brasero plugins are found. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617409: [Pkg-libburnia-devel] Bug#617409: brasero: Brasero corrupts all blank CD-R when burning (was: additional info)
On Thursday 05 July 2012 08:47:15 Thomas Schmitt wrote:
Hi,
Hi All,
i am currently the developer of libburn and libisofs.
https://bugzilla.gnome.org/show_bug.cgi?id=655601
I know about such problems, but i do not know how to get into a
discussion with Brasero developers.
My impression is that the libisofs plugin causes libisofs to end
prematurely. libburn is less of a suspect here.
I have seen burn logs where burning ends after about 50 % of
the expected output was produced by libisofs. I.e. libisofs would
want to write more, but for some reason libburn is urged to finish
burning (or falsely decides that burning is done).
https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/780117
https://launchpadlibrarian.net/71440716/brasero_log.txt
have:
BraseroLibisofs Finished track successfully
BraseroLibisofs disconnecting BraseroLibisofs from BraseroGrowisofs
...
BraseroGrowisofs stdout: 3866984448/7761410048 (49.8%) @4.0x, remaining
12:06 RBU 40.9% UBU 100.0% BraseroGrowisofs called
brasero_job_get_action
BraseroGrowisofs called brasero_job_set_current_action
BraseroGrowisofs stderr: /dev/sr0: flushing cache
...
BraseroGrowisofs stderr: HUP
Note that libburn is not involved here. Only libisofs. Burning is done
via growisofs.
Further it seems that BraseroLibisofs is the one which decides when
the connection between both shall end.
But in
http://bugzilla-attachments.gnome.org/attachment.cgi?id=205344
the work of libisofs seems to get completed.
brasero (libisofs)DEBUG : Processed 138390 of 138390 KB (100 %)
So this might be two different problems.
(In this run, libburn was indeed in charge of writing to media.)
-
I am not aware of any changes in libisofs or libburn which about a year
ago could have introduced such problems.
The combination of libisofs and libburn works fine in xorriso.
xorriso does several backups per day for me, which then get thoroughly
checked for readability and correct content.
If somebody shows up who understands the code of the libisofs plugin
and could make experiments, then i would be glad to help with finding
the cause of the problem.
Same issue already reported long ago at:
https://mail.gnome.org/archives/brasero-list/2011-July/msg4.html
actors: libisofs and growisofs brasero plugins
symptoms: 50% finished at ~49%
Looking at the logs and the brasero plugins code, the main suspect most likely
hidden at:
1) erroneous read of growisofs std out, wrt written data, and buffer filling,
hence a premature leave might occur:
plugins/growisofs/burn-growisofs.c
static BraseroBurnResult
brasero_growisofs_read_stdout (BraseroProcess *process, const gchar *line)
{
int perc_1, perc_2;
int speed_1, speed_2;
long long b_written, b_total;
/* Newer growisofs version have a different line pattern that shows
* drive buffer filling. */
if (sscanf (line, %10lld/%lld (%4d.%1d%%) @%2d.%1dx, remaining %*d:
%*d,
b_written, b_total, perc_1, perc_2, speed_1,
speed_2) == 6) {
BraseroJobAction action;
brasero_job_get_action (BRASERO_JOB (process), action);
if (action == BRASERO_JOB_ACTION_ERASE b_written = 65536)
{
/* we nullified 65536 that's enough. A signal SIGTERM
* will be sent in process.c. That's not the best way
* to do it but it works. */
brasero_job_finished_session (BRASERO_JOB (process));
return BRASERO_BURN_OK;
}
2) premature ending of the libisofs thread:
static gpointer
brasero_libisofs_thread_started (gpointer data) {
...
if (brasero_job_get_fd_out (BRASERO_JOB (self), NULL) ==
BRASERO_BURN_OK)
brasero_libisofs_write_image_to_fd_thread (self);
...
Nothing more concrete norrowed down yet
--
pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617409: [Pkg-libburnia-devel] Bug#617409: brasero: Brasero corrupts all blank CD-R when burning (was: additional info)
Hi,
I'd suggest the attached patch to be applied, so we can better see what
happens to the growisofs child process.
The code unconditinally calls WEXITSTATUS (status) without making sure that
WIFEXITED has returned true. This is undefined... but whatever - a separate
issue. (also I don't actually like brasero_process_watch_child() to be
utilized like that: g_timeout_add (500, brasero_process_watch_child, process);
but this could be tweaked later)
Reporters, could you please do the following:
apt-get source brasero
apt-get build-dep brasero
put the attached patch in debian/patches/
echo check-child-status debian/patches/series
dpkg-buildpackage
and install this one... then try to reproduce the promlem, and get us the logs
so we can better see what is going on with our beloved growisofs process.
--
pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu
--- brasero-3.4.1.orig/libbrasero-burn/burn-process.c
+++ brasero-3.4.1/libbrasero-burn/burn-process.c
@@ -294,12 +294,27 @@ brasero_process_watch_child (gpointer da
* brasero_job_finished/_error is called before the pipes are closed so
* as to let plugins read stderr / stdout till the end and set a better
* error message or simply decide all went well, in one word override */
- priv-return_status = WEXITSTATUS (status);
+/*
+ priv-return_status = WEXITSTATUS (status);
+*/
priv-watch = 0;
priv-pid = 0;
-
+ if (WIFEXITED(status)) { /* WEXITSTATUS macro should only be used if
WIFEXITED returned true */
+ printf(process exited, status=%d\n, WEXITSTATUS(status));
+ priv-return_status = WEXITSTATUS (status);
+ BRASERO_JOB_LOG (data, process exited with status %d,
WEXITSTATUS (status));
+ }
+ else if (WIFSIGNALED(status)) {
+ printf(process killed by signal %d\n, WTERMSIG(status));
+ BRASERO_JOB_LOG (data, process killed by signal %d,
WTERMSIG(status));
+ }
+ else if (WIFSTOPPED(status)) {
+ printf(process stopped by signal %d\n, WSTOPSIG(status));
+ BRASERO_JOB_LOG (data, process stopped by signal %d,
WSTOPSIG(status));
+ }
+/*
BRASERO_JOB_LOG (data, process finished with status %i, WEXITSTATUS
(status));
-
+*/
result = brasero_process_finished (data);
if (result == BRASERO_BURN_RETRY) {
GError *error = NULL;
Bug#617409: [Pkg-libburnia-devel] Bug#617409: Applying George’s patch (was: brasero: Brasero corrupts all blank CD-R when burning)
On Thursday 05 July 2012 21:14:51 Paul Menzel wrote: Dear Thomas, Dear Paul, Maybe you can also give more punctual instructions where to click on that brasero interface thing so we can re-produce the bug as you do. Then, you can try to confirm whether this bug is still present in the brasero package in sid, testing or stable... and contrast their performance to a locally patched package by the patch given at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=617409#44 Logs are very welcome. (currently I don't have a burner to walk these steps myself) PS: Somehow the Debian bug report address was not in CC but it was archived [1] anyway. Did you put it in BCC? Anyway, I added it back to the CC list. Yeah, someone uses a naughty mailer :) -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679927: debian-goodies: [new tool] show enhancements of a package(s), by default of all installed packages
Hi Axel, I introduced an explicit option Show enhancements of all installed packages, since this could be a slow operation depending on how many installed packages are found out, hence it does not make sense to invoke it by default. I also corrected few minor things. Latest version attached. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu check-enhancements Description: application/shellscript
Bug#679927: debian-goodies: [new tool] show enhancements of a package(s), by default of all installed packages
Hi Axel, I got a helpful nagging session on irc [1]... some minor detials are tweaked. New version attached. However, people raised fair concerns that having that implemented in apt would be better, will reach much more user base and of course be faster. I'm still not sure whether aptitude can do that, I haven't used it for a while. [1] IRC log excerpt: ansgar flightplan: Isn't there a aptitude search pattern for such things? There is one for Provides already. ansgar In any case an option in apt or aptitude to search for Enhances is probably better than yet another extra command. ansgar flightplan: Well, if you integrate it into apt/aptitude it will also be easier to find and likely assume less about implementation details (it also handles options that say where the state is stored). -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu check-enhancements Description: application/shellscript
Bug#679927: debian-goodies: [new tool] show enhancements of a package(s), by default of all installed packages
Source: debian-goodies
Severity: wishlist
Tags: patch
Hi Javier and Axel,
Attached is a tiny tool which I use to find out enhacements of a
given package(s), by default all installed packages. I don't actually
care about the name, so change as you find fit. Please, include it in
debian-goodies if you find it helpful.
To give you an impression:
# ./check-enhancements apt git bzr
Package apt could be Enhanced by:
netselect-apt:Installed: (none) Candidate: 0.3.ds1-25
Package git could be Enhanced by:
git-ftp: Installed: (none) Candidate: 0.7.4+git20120528-1
git2cl: Installed: (none) Candidate: 2.0+git200808271242-1
Package bzr could be Enhanced by:
bzr-cvsps-import: Installed: (none) Candidate:
0.0.1~bzr71-1
bzr-email:Installed: 0.0.1~bzr57-2Candidate:
0.0.1~bzr57-2
bzr-explorer: Installed: (none) Candidate: 1.3.0~bzr556-1
bzr-fastimport: Installed: (none) Candidate: 0.13.0-2
bzr-grep: Installed: (none) Candidate: 0.4.0+bzr147-1
bzr-gtk: Installed: (none) Candidate: 0.103.0+bzr792-3
bzr-loom: Installed: (none) Candidate: 2.2.0-2
bzr-pipeline: Installed: (none) Candidate: 1.4-3
bzr-rewrite: Installed: (none) Candidate: 0.6.3+bzr256-1
bzr-search: Installed: (none) Candidate: 1.7.0~bzr94-1
bzr-stats:Installed: (none) Candidate: 0.1.0+bzr48-2
bzr-upload: Installed: (none) Candidate: 1.1.0-2
bzr-xmloutput:Installed: (none) Candidate: 0.8.8+bzr162-3
loggerhead: Installed: (none) Candidate: 1.19~bzr461-1
qbzr: Installed: (none) Candidate: 0.22.2-1
wikkid: Installed: (none) Candidate: 0.1+bzr69-1
#!/bin/bash
# Copyright (C) 2012 George Danchev danc...@spnet.net
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2, or (at your option)
# any later version.
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
# 02111-1307, USA.
SELF=$(basename $0)
print_help() {
cat HLP
${SELF} show enhancement(s) of a given package,
by default of all installed packages.
Usage:
${SELF}
${SELF} pkg1 pkgN
HLP
}
pkgs_enhancing_pkg_status() {
# Figure out package Enhances:'ing installed package
EN=`grep-dctrl -n -s Package -F Enhances -X ${1} /var/lib/apt/lists/*Packages`
case $? in
0) echo -e \nPackage $1 could be Enhanced by: ;;
1) continue ;;
*) echo Error exit 1 ;;
esac
for e in `echo ${EN} | sort | uniq | xargs` # now sort and unify
do
# Figure out whether those enhancements are installed
apt-cache policy ${e} | head -3 | paste -s
done
}
# main
case $1 in
-h|-help|--help) print_help exit 0
;;
) # Get all installed packages
for installed in `grep-status -FStatus install ok installed -n -s Package | sort | uniq | xargs`
do
pkgs_enhancing_pkg_status $installed
done
;;
*) # Process packages given on cmdline
for arg in $@
do
pkgs_enhancing_pkg_status $arg
done
;;
esac
Bug#679927: debian-goodies: [new tool] show enhancements of a package(s), by default of all installed packages
On Monday 02 July 2012 17:37:16 Axel Beckert wrote: Hi George! George Danchev wrote: Attached is a tiny tool which I use to find out enhacements of a given package(s), by default all installed packages. Neat! The only thing, I'd change is that it should only show non-installed enhancements by default IMHO. Regards, Axel Makes sense. Reworked and attached: # ./check-enhancements -h check-enhancements 0.1 - show enhancement(s) packages of a given package or a given set of packages given on the cmdline. If given no packages, process all installed packages. Options: Program options start with dash or double dash, otherwise it is interpreted as package name. -ie|--ie|-installed-enhancements|--installed-enhancements -h|-help|--help -verbose|--verbose Usage: # check enhancement(s) of all installed packages check-enhancements # check enhancement(s) of selected package(s) check-enhancements pkg1 pkgN # ./check-enhancements apt # ./check-enhancements apt -ie apt: netselect-apt: Installed: 0.3.ds1-25 Candidate: 0.3.ds1-25 # ./check-enhancements apt --ie --verbose Package apt could be Enhanced by: apt: netselect-apt: Installed: 0.3.ds1-25 Candidate: 0.3.ds1-25 # ./check-enhancements git --ie --verbose Package git could be Enhanced by: git: git-ftp: Installed: (none) Candidate: 0.7.4+git20120528-1 git: git2cl: Installed: (none) Candidate: 2.0+git200808271242-1 # ./check-enhancements git --verbose Package git could be Enhanced by: git: git-ftp: Installed: (none) Candidate: 0.7.4+git20120528-1 git: git2cl: Installed: (none) Candidate: 2.0+git200808271242-1 # ./check-enhancements bzr bzr: bzr-cvsps-import:Installed: (none) Candidate: 0.0.1~bzr71-1 bzr: bzr-explorer:Installed: (none) Candidate: 1.3.0~bzr556-1 bzr: bzr-fastimport: Installed: (none) Candidate: 0.13.0-2 bzr: bzr-grep:Installed: (none) Candidate: 0.4.0+bzr147-1 bzr: bzr-gtk: Installed: (none) Candidate: 0.103.0+bzr792-3 bzr: bzr-loom:Installed: (none) Candidate: 2.2.0-2 bzr: bzr-pipeline:Installed: (none) Candidate: 1.4-3 bzr: bzr-rewrite: Installed: (none) Candidate: 0.6.3+bzr256-1 bzr: bzr-search: Installed: (none) Candidate: 1.7.0~bzr94-1 bzr: bzr-stats: Installed: (none) Candidate: 0.1.0+bzr48-2 bzr: bzr-upload: Installed: (none) Candidate: 1.1.0-2 bzr: bzr-xmloutput: Installed: (none) Candidate: 0.8.8+bzr162-3 bzr: loggerhead: Installed: (none) Candidate: 1.19~bzr461-1 bzr: qbzr:Installed: (none) Candidate: 0.22.2-1 bzr: wikkid: Installed: (none) Candidate: 0.1+bzr69-1 # ./check-enhancements bzr -ie --verbose Package bzr could be Enhanced by: bzr: bzr-cvsps-import:Installed: (none) Candidate: 0.0.1~bzr71-1 bzr: bzr-email: Installed: 0.0.1~bzr57-2Candidate: 0.0.1~bzr57-2 bzr: bzr-explorer:Installed: (none) Candidate: 1.3.0~bzr556-1 bzr: bzr-fastimport: Installed: (none) Candidate: 0.13.0-2 bzr: bzr-grep:Installed: (none) Candidate: 0.4.0+bzr147-1 bzr: bzr-gtk: Installed: (none) Candidate: 0.103.0+bzr792-3 bzr: bzr-loom:Installed: (none) Candidate: 2.2.0-2 bzr: bzr-pipeline:Installed: (none) Candidate: 1.4-3 bzr: bzr-rewrite: Installed: (none) Candidate: 0.6.3+bzr256-1 bzr: bzr-search: Installed: (none) Candidate: 1.7.0~bzr94-1 bzr: bzr-stats: Installed: (none) Candidate: 0.1.0+bzr48-2 bzr: bzr-upload: Installed: (none) Candidate: 1.1.0-2 bzr: bzr-xmloutput: Installed: (none) Candidate: 0.8.8+bzr162-3 bzr: loggerhead: Installed: (none) Candidate: 1.19~bzr461-1 bzr: qbzr:Installed: (none) Candidate: 0.22.2-1 bzr: wikkid: Installed: (none) Candidate: 0.1+bzr69-1 -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu check-enhancements Description: application/shellscript signature.asc Description: This is a digitally signed message part.
Bug#679374: devscripts: [rc-alert] please exit on unknown option
Package: devscripts
Version: 2.11.9
Severity: minor
Dear Devscripts Maintainers,
In a offline session I typoed rc-alert --hepl,
whereupon wget call attempt kicked in:
Unknown option: hepl
rc-alert: wget failed!
(in a online session) followed by excessive bug list, instead
of just barfing at me and/or showing me the help blurb:
diff --git a/scripts/rc-alert.pl b/scripts/rc-alert.pl
index 610cc65..63c099e 100755
--- a/scripts/rc-alert.pl
+++ b/scripts/rc-alert.pl
@@ -138,7 +138,7 @@ GetOptions(help|h = \$opt_help,
popcon = \$popcon,
pc-vote = \$popcon_by_vote,
pc-local = \$popcon_local,
- );
+ ) or exit 1;
if ($opt_help) { print $usage; exit 0; }
if ($opt_version) { print $version; exit 0; }
Or even more lazy:
- );
+ ) or print $usage and exit 1;
so the reader won't get a chance to re-type and typ0 it
once again, but just the help :P
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679217: libevent: memleaks - scoped cleanup on bailing out
Source: libevent
Version: 2.0.19-stable-3
Severity: normal
Tags: upstream patch
Hi Anibal,
Attached are two trivial tweaks [1] to free memory allocated
inside routines. Explanations are in the patch headers proper.
While they look trivial, I can quite judge the impact, since I
don't have a clear idea how often are these called and fail to
reclaim the allocated memory on bail-out.
[1] I did dpkg-source --commit for you, please poke upstream,
and add to series if you find them appropriate, also adjusting
patch headers with the info further returned by BTS.
Description: free handle is request_new fails
Trivial clean up on bailing out
.
libevent (2.0.19-stable-3) unstable; urgency=low
.
* [ceb52d98] DH compatibility level is 9
* [7792ab18] Support multiarch (Closes: #675320)
Author: Anibal Monsalve Salazar ani...@debian.org
Bug-Debian: http://bugs.debian.org/675320
---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:
Origin: vendor|upstream|other, url of original patch
Bug: url in upstream bugtracker
Bug-Debian: http://bugs.debian.org/bugnumber
Bug-Ubuntu: https://launchpad.net/bugs/bugnumber
Forwarded: no|not-needed|url proving that it has been forwarded
Reviewed-By: name and email of someone who approved the patch
Last-Update: -MM-DD
--- libevent-2.0.19-stable.orig/evdns.c
+++ libevent-2.0.19-stable/evdns.c
@@ -2291,7 +2291,10 @@ nameserver_send_probe(struct nameserver
handle = mm_calloc(1, sizeof(*handle));
if (!handle) return;
req = request_new(ns-base, handle, TYPE_A, google.com, DNS_QUERY_NO_SEARCH, nameserver_probe_callback, ns);
- if (!req) return;
+ if (!req) {
+ mm_free(handle);
+ return;
+ }
ns-probe_request = handle;
/* we force this into the inflight queue no matter what */
request_trans_id_set(req, transaction_id_pick(ns-base));
Description: free req when bailing out and returning NULL
I can see the comment of uncertaincy /* XXX Should we dealloc req? If yes, how? */
but I think req should be nevertheless freed by mm_free() on bailing out and
returning NULL from search_request_new(), as req was allocated by mm_malloc in
request_new(). This is the trivial scoped cleaning.
Further, the callers of search_request_new() are supposed to check its return
value against NULL. Not done yet, but should trivial to add.
.
libevent (2.0.19-stable-3) unstable; urgency=low
.
* [ceb52d98] DH compatibility level is 9
* [7792ab18] Support multiarch (Closes: #675320)
Author: Anibal Monsalve Salazar ani...@debian.org
Bug-Debian: http://bugs.debian.org/675320
---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:
Origin: vendor|upstream|other, url of original patch
Bug: url in upstream bugtracker
Bug-Debian: http://bugs.debian.org/bugnumber
Bug-Ubuntu: https://launchpad.net/bugs/bugnumber
Forwarded: no|not-needed|url proving that it has been forwarded
Reviewed-By: name and email of someone who approved the patch
Last-Update: -MM-DD
--- libevent-2.0.19-stable.orig/evdns.c
+++ libevent-2.0.19-stable/evdns.c
@@ -3158,6 +3158,8 @@ search_request_new(struct evdns_base *ba
handle-search_origname = mm_strdup(name);
if (handle-search_origname == NULL) {
/* XXX Should we dealloc req? If yes, how? */
+ if (req)
+mm_free(req);
return NULL;
}
handle-search_state = base-global_search_state;
Bug#679249: RFH: libburn -- library to provide CD/DVD writing functions
Package: wnpp Severity: normal I request assistance with maintaining the libburn package. I currently lack the sufficient time, and burning devices to provide adequate testing of its optical burning capabilities, although the software is in quite mature state. In this case the burning applicaiton is cdrskin. Upstream is responsive. There is an alioth project could be reached at: pkg-libburnia-de...@lists.alioth.debian.org Co-maintainers welcome. The package description is: libburn is a library for reading, mastering and writing optical discs. Supported media are: CD-R, CD-RW, DVD-RAM, DVD+RW, DVD+R, DVD+R/DL, DVD-RW, DVD-R, DVD-R/DL, BD-R, BD-RE. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679254: RFH: libisofs -- library to create ISO9660 images
Package: wnpp Severity: normal I request assistance with maintaining the libisofs package. I currently lack the time to maintain this package alone. The major drain of time is following various image specs, following the upstream VCS, and further discussions. One interesting aspect is that libisofs links with libjte in order to produce jigdo representation at the same time while producing the iso image itself (state stable). Further developments are ongoing to produce ISO9660/HFS(+) hybrids, see #630351 for some details, which is also of interest of debian-cd task (currently performed by genisoimage for Debian PowerPC images offered) This would take quite some effort in testing and proving it correct. Upstream is responsive. The alioth project could be reached at: pkg-libburnia-de...@lists.alioth.debian.org Co-maintainers welcome. The package description is: libisofs creates ISO images which can then be burnt with cdrskin or other software. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679265: RFH: libisoburn -- command line ISO-9660 and Rock Ridge manipulation tool
Package: wnpp Severity: normal I request assistance with maintaining the libisoburn package. I currently lack the time to maintain this package alone. This includes a high-level library along with a versatile app called xorriso for burning and image production. It has grown a tremendous amount of options, to the point of being language interpreter on its own right, also featuring other program option personalities (like these of mkisofs, cdrecord). This is the hardest part to thoroughly test. Debian-cd image production is in the hands of xorriso, except for the PowerPC images due to lack of ISO9660/HFS(+) support which is currently emerging. Upstream conversations and following upstream VCS are almost a must. Upstream is responsive. The alioth project could be reached at: pkg-libburnia-de...@lists.alioth.debian.org Co-maintainers welcome. The package description is: xorriso is a command line and dialog application, which creates, loads, manipulates, and writes ISO-9660 file system images with Rock Ridge extensions. . It maps file objects from POSIX compliant file systems into Rock Ridge enhanced ISO-9660 file systems and features session-wise manipulation of such file systems. It can load the management information of existing ISO images and write the resulting session to optical medium or as file system objects. . Supported optical media types: - CD-R, CD-RW - DVD-R, DVD-R DL, DVD-RW, DVD+R, DVD+R DL, DVD+RW, DVD-RAM - BD-R, BD-RE . Some interesting features: - Emulation of the mkisofs and cdrecord programs. - Data backup and restore capabilities - compression, ACLs, and filters. - Isohybrid MBR with partition offset - features booting ISOLINUX from USB sticks, or from other devices that appear to PC-BIOS as hard disks. The images carry a conventional partition table for a USB stick; the first partition reports the size of the ISO image, but starts at a non-zero address. It is nevertheless still mountable. - Jigdo Template Export - jigdo representation of the resulting ISO-9660 image, generated on the fly. . Test suite: xorriso source code comes with a release engineering test-suite called `releng', which aims to cover most of the functionality of the xorriso and the underlying libraries of libburn, libisofs, and libisoburn. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630351: xorriso: Add support for ISO9660/HFS hybrid images
Package: xorriso Version: 1.2.2-1 Followup-For: Bug #630351 JFTR: Production of iso and jigdo succeeded: $ grep -i timestamp xorriso/xorriso_timestamp.h #define Xorriso_timestamP 2012.06.22.125623 (development snapshot, not in sid yet) mount -o loop debian-6.0.5-powerpc-businesscard.iso /mnt/test-powerpc jigdo-gen-md5-list /mnt/test-powerpc /tmp/test-powerpc.md5 xorriso/xorriso \ -as mkisofs \ -joliet-long \ -r \ -V 'Debian testing ppc 1' \ -o repacked.iso \ --iso-level 2 \ -hfsplus \ -hfsplus-file-creator-type UNIX tbxi /install/ofboot.b \ -hfsplus-file-creator-type UNIX boot /install/yaboot \ -hfsplus-file-creator-type UNIX boot /install/powerpc/vmlinux \ -hfsplus-file-creator-type UNIX boot /install/powerpc64/vmlinux \ -hfsplus-file-creator-type UNIX conf /etc/yaboot.conf \ -hfsplus-file-creator-type UNIX conf /install/yaboot.conf \ -hfs-bless-by p /install \ -chrp-boot-part \ \ -jigdo-template-compress gzip \ -checksum_algorithm_iso md5,sha1,sha256,sha512 \ -checksum_algorithm_template md5,sha512 \ -jigdo-jigdo repacked.jigdo \ -jigdo-template repacked.template \ -jigdo-map Debian=/mnt/test-powerpc \ -jigdo-exclude boot/syslinux \ -md5-list /tmp/test-powerpc.md5 \ -jigdo-min-file-size 0 \ \ /mnt/test-powerpc \ -- \ -print '=== Creator Type:' \ -find / -has_hfs_crtp - - -exec get_hfs_crtp -- \ -print '=== Blessings:' \ -find / -has_hfs_bless any -exec get_hfs_bless -- jigit-mkimage \ -t repacked.template \ -j repacked.jigdo \ -m Debian=/mnt/test-powerpc \ -o repacked.rebuilt Writing to 'stdio:repacked.iso' completed successfully. diff -qs repacked.iso repacked.rebuilt Files repacked.iso and repacked.rebuilt are identical -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630351: xorriso: Add support for ISO9660/HFS hybrid images
Package: xorriso Version: 1.2.2-1 Followup-For: Bug #630351 Discussion towards latest developments: https://lists.debian.org/debian-cd/2012/06/msg00036.html also CC'ed: https://lists.debian.org/debian-powerpc/2012/06/msg00030.html https://lists.debian.org/debian-boot/2012/06/msg00637.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677759: postinst: line 58: /etc/selinux/default/setrans.conf: No such file or directory
Package: policycoreutils Version: 2.1.10-8 Severity: important Dear Maintainer, upgrading fails with the following error: Setting up policycoreutils (2.1.10-8) ... /var/lib/dpkg/info/policycoreutils.postinst: line 58: /etc/selinux/default/setrans.conf: No such file or directory dpkg: error processing policycoreutils (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: policycoreutils E: Sub-process /usr/bin/dpkg returned an error code (1) postinst:58 bears TRANS=/etc/selinux/default/setrans.conf sed -e s/^s0=$/s0=SystemLow/ $TRANS $TRANS.new mv $TRANS.new $TRANS there is no default in there $ ls /etc/selinux/ config refpolicy-targeted restorecond.conf restorecond_user.conf semanage.conf -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages policycoreutils depends on: ii dpkg 1.16.4.2 ii libaudit0 1:1.7.18-1.1 ii libc6 2.13-33 ii libcap-ng00.6.6-1 ii libcap2 1:2.22-1.1 ii libcgroup10.37.1-2 ii libdbus-1-3 1.6.0-1 ii libdbus-glib-1-2 0.98-1 ii libglib2.0-0 2.32.3-1 ii libpam0g 1.1.3-7.1 ii libpcre3 1:8.30-5 ii libselinux1 2.1.9-5 ii libsemanage1 2.1.6-6 ii libsepol1 2.1.4-3 ii lsb-base 4.1+Debian7 ii psmisc22.17-2 ii python2.7.3~rc2-1 ii python-ipy1:0.75-1 ii python-selinux2.1.9-5 ii python-semanage 2.1.6-6 ii python-sepolgen 1.1.5-3 ii python-setools3.3.7-2 ii python2.6 2.6.7-4 ii python2.7 2.7.3-1 Versions of packages policycoreutils recommends: pn selinux-policy-default none Versions of packages policycoreutils suggests: pn selinux-policy-dev none -- 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#677024: pgadmin3: Inaccurate Vcs-field information
Source: pgadmin3 Severity: normal Dear Maintainer, debcheckout gets me: pgadmin3 (1.12.2-2) unstable; urgency=low Tue, 05 Apr 2011 07:55:32 +0200 while the latest source package found in sid bears: pgadmin3 (1.14.2-1) unstable; urgency=low Tue, 29 May 2012 10:02:27 +0200 It would be very helpful to get Vcs field matching the Vcs repo actually used, or remove the Vcs fields altogether. Contrasting what you get from the claimed Vcs against the latest source package actually unloaded to sid (or experimental) is a waste of time. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- 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#676538: pgadmin3: Linked against dbg libraries.
On Monday 11 June 2012 10:51:34 Gerfried Fuchs wrote: tags 676538 - patch thanks * George Danchev danc...@spnet.net [2012-06-09 12:31:08 CEST]: dropping libwxgtk2.8-dbg from build-depends and also dropping the configure option --enable-debug is enough to get pgadmin3 stripped and not depending on any *dbg packages, as well as providing detached debugging symbols with pgadmin3-dbg. The simple patch is now attached. Actually, no, it isn't. Have you tried it? That will bring us back #652099, an empty -dbg package. Actually, I haven't tried to load the symbols in gdb, but now I did and I can see that there are none to load from /usr/lib/debug/usr/bin/pgadmin3. This is due to -g not being passed if BUILD_DEBUG is not defined, since --enable-debug is not passed. So far so good, the offending snippet found in acinclude.m4 and configure is: CFLAGS=`echo $CFLAGS | sed -e s/-g //g` CXXFLAGS=`echo $CXXFLAGS | sed -e s/-g //g` The easiest way to bypass their stripping of -g by debian/rules would be to change: CFLAGS = -Wall -g CXXFLAGS = -Wall -g to: CFLAGS = -Wall -ggdb CXXFLAGS = -Wall -ggdb Then -ggdb propages and gdb can happily read them: $ gdb pgadmin3 GNU gdb (GDB) 7.4.1-debian Copyright (C) 2012 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. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/bin/pgadmin3...Reading symbols from /usr/lib/debug/usr/bin/pgadmin3...done. done. A possibly annoying detail for the debug package (pgadmin3-dbg)would be that a single build is used for both debug and non-debug variants and build with -O2 (-ggdb -O2) which may lead to unexpected results for the debugging variant [1]. Of course, this could be dealt with by unconditionally building the source package with -O0. [1] -02 is not that aggressive, but anyway from gcc man-page: GCC allows you to use -g with -O. The shortcuts taken by optimized code may occasionally produce surprising results: some variables you declared may not exist at all; flow of control may briefly move where you did not expect it; some statements may not be executed because they compute constant results or their values were already at hand; some statements may execute in different places because they were moved out of loops. I am willing to reopen #647916 and tag it wontfixed and drop the -dbg package if there isn't a solution to this. Also, this misleading wx-dbg package might be the reason for #676626, so that part should get rid of anyway. My fault to believe that the -dbg namespace is all the same. Thanks for the headsup, will get rid of the -dbg package if no other solution pops up soon, want 1.14.2 in wheezy. You're welcome. I want that in wheezy too and I hope you will find the above cheat appealing. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676538: pgadmin3: Linked against dbg libraries.
CFLAGS = -Wall -ggdb CXXFLAGS = -Wall -ggdb Actually bypassing their sed by using the default level -g2 would be more appropriate as a match for -g. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676538: pgadmin3: Linked against dbg libraries.
On Monday 11 June 2012 13:17:35 Gerfried Fuchs wrote: --cut-- A possibly annoying detail for the debug package (pgadmin3-dbg)would be that a single build is used for both debug and non-debug variants and build with -O2 (-ggdb -O2) which may lead to unexpected results for the debugging variant [1]. Of course, this could be dealt with by unconditionally building the source package with -O0. I wonder how that is any different to any other -dbg package. From what I understand, -O2 is the default to compile with unless DEB_BUILD_OPTIONS does include noopt. See debian-policy 4.9.1 debian/rules and DEB_BUILD_OPTIONS. Yeah, I know... I only mentioned that because pgadmin3's --enable-debug uses -g -O0 for building for some reason, thus in some rare cases -O0 vs. -02 might make a difference for -g (although I don't have any hard data to back up such a claim for pgadmin3 sources), while on the vast majority of packages -O2 combined with -g would be just fine. Thus handling it on per package basis is not entirely baseless. Whatever, I guess that punishing the -dbg package with -g -O2 instead of punishing the non-dbg package with -O0, is an appropriate course of action. Users can always fetch the source and rebuild with noopt if they want to skip -O2 optimizations while debugging. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676538: pgadmin3: Linked against dbg libraries.
Package: pgadmin3
Version: 1.14.0-2
Tags: patch
Followup-For: Bug #676538
Hi,
dropping libwxgtk2.8-dbg from build-depends and also dropping the
configure option --enable-debug is enough to get pgadmin3 stripped and
not depending on any *dbg packages, as well as providing detached
debugging symbols with pgadmin3-dbg. The simple patch is now attached.
diff -Naur pgadmin3-1.14.2.orig/debian/control pgadmin3-1.14.2/debian/control
--- pgadmin3-1.14.2.orig/debian/control 2012-06-09 10:11:02.0 +
+++ pgadmin3-1.14.2/debian/control 2012-06-09 10:11:24.0 +
@@ -4,7 +4,7 @@
Maintainer: Gerfried Fuchs rho...@debian.org
Build-Depends: debhelper (= 7), libpq-dev (= 8.1), devscripts,
libwxgtk2.8-dev, libxml2-dev, libxslt1-dev, dpkg-dev (= 1.13.19),
- autotools-dev, postgresql-server-dev-all (= 117~), quilt, libwxgtk2.8-dbg
+ autotools-dev, postgresql-server-dev-all (= 117~), quilt
Standards-Version: 3.9.3
Homepage: http://www.pgadmin.org/
Vcs-Svn: svn://svn.debian.org/svn/pkg-postgresql/trunk/pgadmin3/
diff -Naur pgadmin3-1.14.2.orig/debian/rules pgadmin3-1.14.2/debian/rules
--- pgadmin3-1.14.2.orig/debian/rules 2012-06-09 10:11:02.0 +
+++ pgadmin3-1.14.2/debian/rules 2012-06-09 10:11:28.0 +
@@ -56,8 +56,7 @@
--mandir=\$${prefix}/share/man \
--infodir=\$${prefix}/share/info \
--disable-dependency-tracking \
- --with-wx=/usr \
- --enable-debug
+ --with-wx=/usr
build: build-arch build-indep
build-arch: build-stamp
Bug#676538: pgadmin3: Linked against dbg libraries.
Package: pgadmin3 Version: 1.14.0-2 Followup-For: Bug #676538 The applied solution to resolve the bug #652099 [1] (dbg package doesn't provide debugging symbols) led to non-debug package of 'pgadmin3' depending on megs of wx*-dbg's. What needs to be done is to build it twice: * once with --disable-debug (for pgadmin3) * and once again with --enable-debug (resp. pgadmin3-dbg) [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652099 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676538: pgadmin3: Linked against dbg libraries.
Package: pgadmin3 Version: 1.14.0-2 Followup-For: Bug #676538 After a short discussion in irc#d-devel [1] it turns out that: * Nothing built with wx*-dbg should ever get uploaded, since the configure option --enable-debug of pgadmin also imply quite a different runtime behaviour. These are not simply detached debugging symbols, but also additional code is also engaged. Hence, please don't build with --enable-debug. * Building it once with CC -g (for the debug package) and then simply stripping that with dh_strip (for the non-debug one) would nicely avoid the double build, and still get us debug and non-debug variants. [1] irc session log flightplan Myon: I just Followup-For: Bug #676538 [ suggested building it twice --(disable|enable)-debug ] ron flightplan: eww no. things shouldn't be shipping wx-dbg versions in the distro :( Myon flightplan: what's wrong with simply building it once, and then using dh_strip? ron Myon: the wx-dbg packages are thpethial flightplan Myon: yeah, that's better Myon thpwhat? ron it's not just -g. it's a bunch of extra runtime code too. and they aren't binary compatible with the non -dbg builds Myon hmm flightplan ron: then we should simply get rid of pgadmin3-dbg? Myon well, that doesn't prevent pgadmin3 from providing standard debugging symbols, does it? ron the name confusion is awkward, but they were named that long before we had detached symbol -dbg packages ron ol was going to change that for the next release ron flightplan: yes. nothing built with wx-dbg should ever get uploaded. but building pgadmin with -g and the normal wx packages is fine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673656: debian-cd: post-squeeze debian-cd should also depends on xorriso
Package: debian-cd Version: 3.1.8 Severity: normal Hi, Post-squeeze debian-cd should also depends on xorriso. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages debian-cd depends on: ii apt 0.9.3 ii bc 1.06.95-2+b1 ii bzip21.0.6-1 ii cpp 4:4.7.0-6 ii curl 7.25.0-1 ii dctrl-tools [grep-dctrl] 2.22 ii dpkg-dev 1.16.3 ii genisoimage 9:1.1.11-2 ii libcompress-zlib-perl2.037-1 ii libdigest-md5-perl none ii libio-compress-perl [libcompress-zlib-perl] 2.052-1 ii lynx 2.8.8dev.12-2 ii lynx-cur 2.8.8dev.12-2 ii make 3.81-8.2 ii perl [libdigest-sha-perl]5.14.2-10 ii tofrodos 1.7.9.debian.1-1 Versions of packages debian-cd recommends: ii hfsutils 3.2.6-11 ii netpbm 2:10.0-15+b1 ii syslinux-common 2:4.05+dfsg-4 debian-cd 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#672562: transition: bobcat
On Wednesday 16 May 2012 16:44:40 Cyril Brulebois wrote: tag 672562 pending thanks Cyril Brulebois k...@debian.org (14/05/2012): This looks like quite self-contained, so I might get back to you soon to get this transition started. Ping me back by wednesday if you didn't hear from me by then. I thought I sent you a mail with a green light but apparently failed to do so properly. Please go ahead with an upload to unstable. Okay, bobcat uploaded. Should we do anything further wrt to scheduling binNMUs? -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672562: transition: bobcat
On Monday 14 May 2012 03:10:58 Cyril Brulebois wrote: George Danchev danc...@spnet.net (13/05/2012): Just to add few more hopefully helpful bits. 1) the changelog of not yet uploaded package to sid, waiting for your green light: Thanks, that's appreciated. You're welcome. [given the huge amount of packages, bugs, and maintainers Release Teams deals with, it is worth to *at least try* to proactively provide you accurate and relevant information concerning the emerging transition] bobcat (3.00.02-1) unstable; urgency=low * New upstream release (bumps the soname version). + Arg, ArgConfig and ConfigFile use the bridge design pattern. + Programs depending on the Bobcat library must be recompiled. * Rename the library package libbobcat2 to libbobcat3 to reflect the soname bump (no further relationships are needed, since libbobcat2 and libbobcat3 do not ship common files). * Drop unneeded and errant relationships of Provides|Conflicts|Replaces: libbobcat1 previosly added to the library package section (post lenny). * Likewise, drop Provides|Conflicts|Replaces: libbobcat1-dev relationships from the -dev package section (libbobcat1-dev is a non-virtual package in lenny, which has been subsequently renamed to libbobcat-dev in squeeze). 2) the ben file: title = bobcat; is_affected = .build-depends ~ /libbobcat-dev/; is_bad = .depends ~ /libbobcat2/; is_good = .depends ~ /libbobcat3/; Tracker is up at: http://release.debian.org/transitions/html/bobcat.html Great. Thanks. In your first mail: All of these built successfully against the new bobcat library, even though ccbuild required a minor tweak [1] to succeed due to unrelated FTBFS with newer GCC, reported as #667132. I think it would be nice if this could be fixed ASAP, so that it's ready to be binNMU'd when the time comes, and so that we discover new failures early, if any. Ok, the ccbuild FTBFS issue with GCC.4.7 ~ Agreed, and looking at #667132 bug log, I can see that this bug is also dealt with upstream and the maintainer (CC'ed) claimed ETA for the fix 2012-05-19. Jari, are you going to patch the cbuild package currently found in sid or are you goind to upload a new and fixed upstream version? This looks like quite self-contained, so I might get back to you soon to get this transition started. Ping me back by wednesday if you didn't hear from me by then. Granted. We will get back to you in case of communication interruptions :) I should have also mentioned it in the first place (my bad), but we also have new upstream versions for the rest of the packages (all under our control, co- maitainers Frank and Tony are CC'ed), so we would like to upload them as well, in hope to see them in wheezy, after the new bobcat hits sid, instead of simply binNMUing their versions in sid. These new package versions were also successfully tested against the new bobcat library package in a clean current sid chroot, resp. GCC (Debian 4.7.0-8) 4.7.0. Their upstream changelogs, as compared to the versions currently found in sid, read: ~ bisonc++ (4.01.00) * Repaired a long-existing bug due to which some S/R conflicts are solved by a reduce, where a shift should have been used. See README.states-and-conflicts for details. * Removed line-numbers from final warning/error messages * This version requires Bobcat = 3.00.00 ~ flexc++ (0.98.00) * Implemented the --case-insensitive option (and directive), generating a scanner ignoring letter casing. * Several cosmetic changes were implemented flexc++ (0.97.30) * This version depends on Bobcat = 3.00.00 ~ oxref (0.90.10) * Depends on Bobcat 3.00.02 * Removed superfluous header (undoing the needless 0.90.04 modification). oxref (0.90.04) * Added missing header ~ stealth (2.03.00) * Spurious [Fatal] message when starting stealth are prevented * This version expects Bobcat = 3.00.00 stealth (2.02.02) * Recompilation and minor modifications to prepare for g++ 4.7 * YEARS updated ~ xd (3.22.04) * New upstream release, cosmetic changes (removed 3.22.03 headers again) xd (3.22.03) * Added missing headers I hope it won't be too much of a stress for autobuilders to handle all of these sourceful uploads, once the new bobcat gets built everywhere. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Bug#672562: transition: bobcat
JFTR (as it was perfectly clear from my first mail) The versions currently found in sid of: bisonc++ flexc++ oxref stealth xd ccbuild aside, due to FTBFS with GCC 4.7 #667132 were also successfully built against the new bobcat 3.00.02-1 package in a clean current sid chroot, resp. GCC (Debian 4.7.0-8) 4.7.0. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672562: transition: bobcat
Just to add few more hopefully helpful bits. 1) the changelog of not yet uploaded package to sid, waiting for your green light: bobcat (3.00.02-1) unstable; urgency=low * New upstream release (bumps the soname version). + Arg, ArgConfig and ConfigFile use the bridge design pattern. + Programs depending on the Bobcat library must be recompiled. * Rename the library package libbobcat2 to libbobcat3 to reflect the soname bump (no further relationships are needed, since libbobcat2 and libbobcat3 do not ship common files). * Drop unneeded and errant relationships of Provides|Conflicts|Replaces: libbobcat1 previosly added to the library package section (post lenny). * Likewise, drop Provides|Conflicts|Replaces: libbobcat1-dev relationships from the -dev package section (libbobcat1-dev is a non-virtual package in lenny, which has been subsequently renamed to libbobcat-dev in squeeze). 2) the ben file: title = bobcat; is_affected = .build-depends ~ /libbobcat-dev/; is_bad = .depends ~ /libbobcat2/; is_good = .depends ~ /libbobcat3/; -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672562: transition: bobcat
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Dear Release Team, The new bobcat library (3.00.02) bumps soname version. We have prepared a new package and tested in as well (JFTR: debcheckout and get-orig-source work as expected) The following packages build-depend on bobcat: bisonc++ ccbuild flexc++ oxref stealth xd All of these built successfully against the new bobcat library, even though ccbuild required a minor tweak [1] to succeed due to unrelated FTBFS with newer GCC, reported as #667132. [1] diff -Naur ccbuild-2.0.2.orig/src/system/dotgraphForAll.cc ccbuild-2.0.2/src/system/dotgraphForAll.cc --- ccbuild-2.0.2.orig/src/system/dotgraphForAll.cc 2012-05-12 08:19:50.0 +0300 +++ ccbuild-2.0.2/src/system/dotgraphForAll.cc 2012-05-12 08:23:54.0 +0300 @@ -47,12 +47,12 @@ if(Options::simulate) continue; -ofstream file(output.c_str(), ios::trunc); -if(!file.is_open()) +ofstream file_ofs(output.c_str(), ios::trunc); +if(!file_ofs.is_open()) continue; -dotgraphFor(target, file); -file.close(); +dotgraphFor(target, file_ofs); +file_ofs.close(); } } -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664634: RFS: engauge-digitizer/5.0-2 [RC]
On Monday 19 March 2012 15:52:38 Tobias Winchen wrote: Dear mentors, Hi Tobias, I am looking for a sponsor for my package engauge-digitizer * Added patch fixing passing double as qreal. Closes: #656943 (FTBFS on armel and armhf) While the original reporter of bug #656943 did his best to prepare a patch which follows DEP-3 [1], he didn't have in advance all the required information to complete the patch header fields (e.g. bug number) as prescirbed by DEP-3, also claimed by the patch itself. OTOH, you have all the needed data to complete, at least: Origin: http://bugs.debian.org/656943 Bug-Debian: http://bugs.debian.org/656943 Reviewed-By: Tobias Winchen winc...@physik.rwth-aachen.de Last-Update: 2012-03-19 and optionally, the Forwarded field, see DEP-3. You can also drop the redundant line of: Bug-Debian: http://bugs.debian.org/??; right after the Description field. [1] http://dep.debian.net/deps/dep3/ -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#662968: RFS: shc/3.8.7-1
Hi Vibhav, Please have a look at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=327263 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508109 -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#655529: warning: file///cdrom/pool/main/m/manpages_3.27-1_all.deb was corrupt (was: Re: Processed: reassign 655529 to debian-cd)
retitle 655529 warning: file///cdrom/pool/main/m/manpages_3.27-1_all.deb was corrupt thanks Hi, This looks like incorrectly burnt optical media. Please try to use 'check_debian_iso' script to verify the ISO image you've downloaded and the optical media you've burnt, as described at: http://www.debian.org/CD/faq/#verify * get the check_debian_iso script from the URL shown there * get http://cdimage.debian.org/debian-cd/6.0.3/i386/iso-dvd/MD5SUMS (check the gpg signature as described at: http://www.debian.org/CD/verify) 1) Check the ISO image itself: ./check_debian_iso MD5SUMS debian-6.0.3-i386-DVD-1.iso alternatively: # md5sum debian-6.0.3-i386-DVD-1.iso should result in: aad89cd0b6c1b454c554b37ee6034041 2) Check the optical media: ./check_debian_iso MD5SUMS debian-6.0.3-i386-DVD-1.iso /dev/dvd note: /dev/dvd is the device file you your DVD writer. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652498: [Pkg-libburnia-devel] Bug#652498: FATAL : Cannot reserve track of 7932674048 bytes
close 652498 thanks I will have to see if I can borrow a newer drive from my sister over x-mas (depends on if she brings it). From looking at the scsi log and what you said I don't believe this is a software fault so feel free to close the bug. Okay, closing the bug. JFTR to summarize: burning a single layer media succeeded with both xorriso and growisofs; burning double layer media failed with both. The SCSI log of the failed double layer run or xorriso revealed that the write error is due to a problem with the media or drive, most likely the drive does not like such a modern media. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#450876: Orphaning ara
retitle 450876 O: ara -- utility for searching the Debian package database thanks I'm hereby orphaning ara, due to lack of time and limited usage of it on my side. The package description is: Command line utility for searching the Debian package database ara is a utility for searching the Debian package database using boolean regexp queries. ara can perform sophisticated searches on that database. It is possible to use any field of the package database as a search criterion and any boolean combination thereof. ara can also call APT (or any user-configurable command) to install or remove packages matching a query. There is also a separate alioth project for it: https://alioth.debian.org/projects/ara/ as well as a webpage http://ara.alioth.debian.org/ Perhaps ara is best to be added to the git repo of Debian OCaml Task Force. If you adopt this package, you should also adopt it upstream. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#632865: xorrisofs produces corrupted images
On Wednesday, July 06, 2011 08:13:05 PM Thomas Schmitt wrote: Hi, Hi, Can you confirm that the following produces an ISO image ? xorrisofs dummy/ | cat dummy.iso (Here xorriso talks to a pipe, not a disk file. With -o it would talk to a file descriptor which it opened itself.) Yes, this works as expected. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630863: xorriso: Add support for UDF
Package: xorriso Version: 1.0.8.pl00-4 Severity: wishlist Tags: upstream This bug is intended to track the evaluation of UDF support in xorriso. The goal is to (re-)use existing building blocks instead of reinventing the wheel once again. Whether or not it will be supported is unclear yet. So far I can see signs of UDF support in: udftools - should split a shared library. libcdio - read-only support. It might turned out that leaving the UDF (read-write) support to udftools would be more appropriate. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages xorriso depends on: ii libacl1 2.2.49-5 Access control list shared library ii libattr11:2.4.44-3 Extended attribute shared library ii libburn41.0.6.pl00-2 library to provide CD/DVD writing ii libc6 2.13-6 Embedded GNU C Library: Shared lib ii libisoburn1 1.0.8.pl00-4 library to handle creation and ins ii libisofs6 1.0.8-1 library to create ISO9660 images ii libjte1 1.19-1 Jigdo Template Export - runtime li ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime xorriso recommends no packages. Versions of packages xorriso suggests: ii cdck 0.7.0-4tool for verifying the quality of ii jigit 1.19-1 tools for working with jigdo files -- 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#630714: debian-cd: dot in directory names is a violation of ECMA-119 Paragraph 9.1.11
Package: debian-cd Version: 3.1.6 Severity: normal Hi, Debian-cd ISOLINUX setup uses the ECMA-119 names while booting (Linux later uses the Rock Ridge names by default) and putting and dot in directory names is a violation Paragraph 9.1.11 of ECMA-119. Currently debian images layout contains /install.amd/vmlinuz which leads to the following error while booting: Error message is: Could not find kernel image: /install.amd/vmlinuz libburnia versions currently in squeeze are: libisofs 0.6.32 libisoburn 0.5.6.pl00 (libburn is unrelated) These versions does not yet violate ECMA-119 by putting '.' into directory names, however this 'feature' is supported since libisoburn-1.0.0. There is an option -disallow_dir_id_ext of xorriso -as mkisofs to disable it if standards compliant ISO 9660 images are desired. Genisoimage flatly ignores this constraint. Reference: https://mailman-mail1.webfaction.com/pipermail/libburn-hackers/2011-June/000622.html Impact: I'm not sure how frustrating would be to avoid having dots in directory names anymore, but this bug should at least document the issue regardless of the further decisions. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages debian-cd depends on: ii apt 0.8.14.1 Advanced front-end for dpkg ii bc 1.06.95-2The GNU bc arbitrary precision cal ii cpp 4:4.6.0-5The GNU C preprocessor (cpp) ii curl7.21.6-1 Get a file from an HTTP, HTTPS or ii dctrl-tools [grep-dctrl 2.18 Command-line tools to process Debi ii dpkg-dev1.16.0.3 Debian package development tools ii genisoimage 9:1.1.11-1 Creates ISO-9660 CD-ROM filesystem ii libcompress-zlib-perl 2.035-1 Transitional dummy package for Com pn libdigest-md5-perl none (no description available) ii libio-compress-perl [li 2.035-1 bundle of IO::Compress modules ii lynx2.8.8dev.8-1 Text-mode WWW Browser (transitiona ii lynx-cur2.8.8dev.8-1 Text-mode WWW Browser with NLS sup ii make3.81-8.1 An utility for Directing compilati ii perl [libdigest-sha-per 5.12.3-7+b1 Larry Wall's Practical Extraction ii tofrodos1.7.8.debian.1-2 Converts DOS - Unix text files, Versions of packages debian-cd recommends: ii hfsutils 3.2.6-11 Tools for reading and writing Maci ii netpbm2:10.0-12.2+b1 Graphics conversion tools between ii syslinux-common 2:4.04+dfsg-2 collection of boot loaders (common debian-cd 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#630607: xorriso: padding and the cylinder size alignment regression
Package: xorriso Version: 1.0.8.pl00-4 Severity: normal Hi, there is really a bug with the padding and the cylinder size alignment. It must be a regression after fixing another regression. xorriso-1.0.4 aligns properly. But that seems to be due to a bug that prevented padding at all, and was fixed in 1.0.6. For proper cylinder alignment one currently has to use option -no-pad. In this case one should urge users to avoid CD write mode TAO or to use padsize=300k with their cdrecord compatible burn program. (It is only CD TAO that needs padding due to the Linux Read-Ahead Bug. BD, DVD or CD SAO are not prone to this.) I will now try to fix this flaw. Thanks for testing and reporting. Have a nice day :) Thomas -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages xorriso depends on: ii libacl1 2.2.49-5 Access control list shared library ii libattr11:2.4.44-3 Extended attribute shared library ii libburn41.0.6.pl00-2 library to provide CD/DVD writing ii libc6 2.13-6 Embedded GNU C Library: Shared lib ii libisoburn1 1.0.8.pl00-4 library to handle creation and ins ii libisofs6 1.0.8-1 library to create ISO9660 images ii libjte1 1.18-2 Jigdo Template Export - runtime li ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime xorriso recommends no packages. Versions of packages xorriso suggests: ii cdck 0.7.0-4tool for verifying the quality of ii jigit 1.18-2 tools for working with jigdo files -- 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#589532: still does not depend on xorriso, although it should
Followup-For: Bug #589532 Hi Colin, I agree that 'Depends: xorriso' is too strong for grub-common, but why not just split another binary package grub-image|-rescue (a better name could be suggeted) which contains grub-mkrescue and grub-mkimage and which package could depends on xorriso? Then grub-common could even suggest that hypothetical grub-image|-rescue package. It is clear that if people have such a package installed they want to create images. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#589532: still does not depend on xorriso, although it should
Followup-For: Bug #589532 I forgot to comment on the devscrpts use pattern, which tries to be as flexible as possible: install $ABC package to do $XYZ The wishlist item is that perhaps grub-mkrescue should explicitly advise installing the xorriso package if you don't have it. While the devscripts approach is fine for non urgent tasks devscripts provides, I believe a more safer approach should be taken when it comes to tasks of creating rescue images. There is a sutble scenario, a newbie might be trapped, when they are to be adviced by grub-mkrescue (while being in the middle of nowhere) to install xorriso and when no package repository could be reached for whatever trivial reasons. It is quite unlikely an experienced user to be trapped like that, but then again, they are very likely to find a decent way out. That being said, I'd go for putting an extra safety net to guarantee the successful operation completion on time, by splitting another grub-rescue binary package which would then depend on xorriso, to avoid subtle surprises. This way the intentions would better match the reality, in my opinion. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630351: xorriso: Add support for ISO9660/HFS hybrid images
Package: xorriso Version: 1.0.8.pl00-4 Severity: wishlist It remains to be investigated whether it would be appropriate to link with hfsutils. A request for splitting a separate libhfs library package has already been filed: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=437226 -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages xorriso depends on: ii libacl1 2.2.49-5 Access control list shared library ii libattr11:2.4.44-3 Extended attribute shared library ii libburn41.0.6.pl00-1 library to provide CD/DVD writing ii libc6 2.13-6 Embedded GNU C Library: Shared lib ii libisoburn1 1.0.8.pl00-4 library to handle creation and ins ii libisofs6 1.0.8-1 library to create ISO9660 images ii libjte1 1.18-2 Jigdo Template Export - runtime li ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime xorriso recommends no packages. Versions of packages xorriso suggests: ii cdck 0.7.0-4tool for verifying the quality of ii jigit 1.18-2 tools for working with jigdo files -- 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#519200: k3b: Should recognize xorriso as valid burner and image manipulation app
Package: k3b Version: 2.0.2-2 Followup-For: Bug #519200 Hi, k3b should also recognize xorriso as valid low level app for burning and image manipulation (cdrskin is a burner only app). Xorriso provides some cdrecord and mkisofs compatible option interface: xorriso -as cdrecord ... (or call it via xorrecord symlink instead) xorriso -as mksisofs ... (or call it via xorrisofs symlink instead) Another approach (which is more demanding) would be to use libisoburn API: /usr/include/libisoburn/libisoburn.h or even better the higher xorriso API: /usr/include/libisoburn/xorriso.h and link with libisoburn as well. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628559: srtp: Please do not build documentation package (arch:all) when dpkg-buildpackage -B is invoked
Source: srtp Version: 1.4.4~dfsg-7 Severity: normal Please do not unconditionally build documenttion package (arch:all) when it is not requested. This would save both machine and human time. Use case 1) Autobuilders call dpkg-buildpackage -B, no need to waste their time with dragging and installing useless build-depends Use case 2) Developer debugging the code is hardly interested in pulling and installing useless build-depends, as well as building the srtp-docs (arch:all) package every now and then. These should go to Build-Depends-Indep: doxygen-latex | doxygen, doxygen-latex | texlive-latex-recommended, texlive-fonts-recommended Moving them to -Indep led to the following error: make[2]: Entering directory /home/deb/debian/srtp-1.4.4~dfsg/doc' sed 's/LIBSRTPVERSION/1.4.4/' header.template header.tex doxygen make[2]: doxygen: Command not found make[2]: *** [libsrtpdoc] Error 127 make[2]: Leaving directory /home/deb/debian/srtp-1.4.4~dfsg/doc' make[1]: *** [libsrtpdoc] Error 2 make[1]: Leaving directory /home/deb/debian/srtp-1.4.4~dfsg' make: *** [build/srtp-docs] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 It is probably not a good idea to have alternatives listed in build dependencies, this makes things less reproducible. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.37-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628063: g++-4.6: inline causes virtual methods not to be considered on armel
Package: g++-4.6
Version: 4.6.0-9
Severity: normal
Meanningless inline requests should be ignored by the compiler,
but this is not the case on armel (armv5tel), symbols disappear
instead.
class C {
public:
C();
private:
virtual void foo();
};
inline C::C() {
}
#ifdef inline_this_virtual
inline
#endif
void C::foo() {
}
$ g++-4.6 -fPIC -shared -Wl,-z,defs -o testinl.so testinl.cc
$ objdump -T testinl.so | c++filt
testinl.so: file format elf32-littlearm
DYNAMIC SYMBOL TABLE:
0524 ld .init .init
8678 ld .jcr .jcr
w D *UND* __gmon_start__
w D *UND* _Jv_RegisterClasses
DO *UND* CXXABI_1.3 vtable for
__cxxabiv1::__class_type_info
w DF *UND* GLIBC_2.4 __cxa_finalize
0660 gDO .rodata0003 Basetypeinfo name for C
868c gDO .data.rel.ro 0008 Basetypeinfo for C
8680 gDO .data.rel.ro 000c Basevtable for C
87c0 gD *ABS* Base_bss_end__
87c0 gD *ABS* Base_end
87bc gD *ABS* Base_edata
87c0 gD *ABS* Base__bss_end__
87bc gD *ABS* Base__bss_start
0638 gDF .text 001c BaseC::foo()
0524 gDF .init Base_init
0654 gDF .fini Base_fini
87bc gD *ABS* Base__bss_start__
87c0 gD *ABS* Base__end__
$ g++-4.6 -fPIC -shared -Wl,-z,defs -o testinl.so testinl.cc
-Dinline_this_virtual
$ objdump -T testinl.so | c++filt
testinl.so: file format elf32-littlearm
DYNAMIC SYMBOL TABLE:
03b4 ld .init .init
84e0 ld .jcr .jcr
w D *UND* __gmon_start__
w D *UND* _Jv_RegisterClasses
w DF *UND* GLIBC_2.4 __cxa_finalize
860c gD *ABS* Base_bss_end__
860c gD *ABS* Base_end
8608 gD *ABS* Base_edata
860c gD *ABS* Base__bss_end__
8608 gD *ABS* Base__bss_start
03b4 gDF .init Base_init
04c8 gDF .fini Base_fini
8608 gD *ABS* Base__bss_start__
860c gD *ABS* Base__end__
Now, C::foo() is gone.
Note, that this subtlety is specific to the armel architecture only,
anywhere else C::foo() is not silently dropped.
References:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602817
http://gcc.gnu.org/ml/gcc-help/2011-05/msg00352.html
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.37-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages g++-4.6 depends on:
ii gcc-4.6 4.6.0-9 The GNU C compiler
ii gcc-4.6-base4.6.0-9 The GNU Compiler Collection (base
ii libc6 2.13-4 Embedded GNU C Library: Shared lib
ii libcloog-ppl0 0.15.9-3 the Chunky Loop Generator (runtime
ii libgmp102:5.0.1+dfsg-7 Multiprecision arithmetic library
ii libgmpxx4ldbl 2:5.0.1+dfsg-7 Multiprecision arithmetic library
ii libmpc2 0.9-3multiple precision complex floatin
ii libmpfr43.0.1-3 multiple precision floating-point
ii libppl-c4 0.11.2-3 Parma Polyhedra Library (C interfa
ii libppl9 0.11.2-3 Parma Polyhedra Library (runtime l
ii libstdc++6-4.6-dev 4.6.0-9 The GNU Standard C++ Library v3 (d
ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime
g++-4.6 recommends no packages.
Versions of packages g++-4.6 suggests:
ii g++-4.6-multilib 4.6.0-9The GNU C++ compiler (multilib fil
pn gcc-4.6-doc none (no description available)
pn libstdc++6-4.6-dbgnone (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#602817: Missing symbols on armel (stealth undefined references on armel)
Source: bobcat Followup-For: Bug #602817 gcc-help discussion starts at: http://gcc.gnu.org/ml/gcc-help/2011-05/msg00352.html the point is to reveal how guilty is the compiler (if at all) for not ignoring inline request with virtual methods on armel when there is no meaningful way to actually inline them. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579016: makes medium invisible
Package: brasero Followup-For: Bug #579016 Hi, Is there any chance to reproduce that one or follow the instructions given at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579016#26 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#625098: extrema: FTBFS: GRA_thiessenTriangulation.h:31:27: error: 'size_t' has not been declared
tags 625098 + patch
thanks
Hi,
including cstddef in src/Graphics/GRA_thiessenTriangulation.h is enough for
build to succeed, no other regressions are found by GCC 4.6; tested in a fresh
sid environment, thus easy to resolve. Since Alioth is currently down for
maintenance I can't check whether this has already been push in git.
--
pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu
diff -Naur extrema-4.4.5.dfsg.orig/src/Graphics/GRA_thiessenTriangulation.h extrema-4.4.5.dfsg/src/Graphics/GRA_thiessenTriangulation.h
--- extrema-4.4.5.dfsg.orig/src/Graphics/GRA_thiessenTriangulation.h 2011-05-21 10:02:31.0 +
+++ extrema-4.4.5.dfsg/src/Graphics/GRA_thiessenTriangulation.h 2011-05-21 10:02:46.0 +
@@ -19,6 +19,7 @@
#define GRA_THIESSENTRIANGULATION
#include vector
+#include cstddef
class GRA_thiessenTriangulation
{
Bug#626889: static members initialization causes a segfault
Source: bobcat Version: 2.15.01-1 Severity: critical This bug is to prevent that version of bobcat to enter testing as the dependent applications experience a segfault. A fixed version is being worked on and hopefully to be uploaded shortly. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522303: libburn problem (was: xfburn: Hangs when Burn Image pressed before drive has settled)
Hi, I've never been able to reproduce #522303, and attempts to squeeze more info from the reporter failed as well; It only happens once in a while, however. smells like a crappy drive or firmware to me or involves culprits I mentioned at the tail and never got replied [1]. Do any of you have any idea to squeeze something more out of that? [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522303#50 -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#625865: ITP: ocportal -- ocPortal is a Content Management System for building and maintaining a dynamic website
On Friday 06 May 2011 19:39:26 Tshepang Lekhonkhobe wrote: On Fri, 2011-05-06 at 13:24 -0300, Ben Armstrong wrote: On 05/06/2011 12:14 PM, Tshepang Lekhonkhobe wrote: Q: How many content management systems written in php does Debian need? A: How about zero? Not exactly helpful. When developers are passionately opposed to a particular technology (and not without reason here, I think,) they can be a bit blunt in expressing it. The list of these goes on and on ... and while I certainly would be more polite myself about expressing reservations about adding any more, I'm not going to fault others for expressing their dissent. The way you expressed your support seemed to me to gloss over the real cost of adding a new package to the archive without any coherent argument as to why this particular one was going to be no trouble at all (and/or worth the trouble because it's so special). Strange that you read 'support' into my responses. Actually I have never even heard of the proposed package, but that's not the point. I even mentioned that if the package sucketh (if the guy proposing it proves unreliable), then it can either remain in Unstable or be removed. Upload to 'unstable' and see how it goes could be quite suboptimal tactics most of the time. I'm not talking about that particular package, but not every package which flies in the free software skies deserves to be in Debian archive in my own opinion. Inclusions costs human time. You don't just blatantly oppose Debian inclusion without mentioning why. The great Josselin Mouette (yes, I really respect this guy for his tireless GNOME maintenance) just did that, and the rest of us are supposed to magically possess the history of PHP in Debian, and laugh it off. And no, you should fault others for expressing their dissent in this unproductive manner. Well, maybe if you look at that from a different angle, you can find it productive as in: don't spend your time packaging that particular one, as chances are very low for upload. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559620: valkyrie: Does not work with valgrind = 3.5.0
On Thursday 05 May 2011 14:08:07 you wrote: Hi! Thanks for pinging. I did not work on that bug because I did not have debian unstable at hand - and now I have. So I'll take care of it next week or so. And yes, it will be great if you can sponsor it when I finish. Hi, Okay that sounds good. I didn't sponsor the initial upload, it has been done by LI Daobing lidaob...@debian.org (also CC'ed) [1], but if he is not available for any reason, I'll have a look and hopefully upload to resolve that RC-bug as well. [1] I only sponsored 1.4.0-2 in order to fix RC#543108. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#604507: Current valkyrie version (2.0.0) fixes these issues
tags 604507 + fixed-upstream pending tags 625176 + pending thanks Hopefully the new upstream version will be uploaded shortly, fixing that bug as well as #559620 and #625176 (though I haven't check the latter bug myself) -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559620: valkyrie: Does not work with valgrind = 3.5.0
Hi maintainer, Are you working towards the resolution of that bug [1]. I'd like to see that bug removed, and I'm willing to have a look at the new package, if you don't have a sponsor. Please, let me know. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559620 -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623378: patch for #623378
On Monday 25 April 2011 18:38:56 Adam D. Barratt wrote: On Tue, 2011-04-19 at 22:22 -0400, Daniel Kahn Gillmor wrote: The patch Thomas Schmitt referred to from here: http://libburnia-project.org/changeset/3537/libburn/trunk is attached below in debdiff form (applies cleanly to 0.8.0.pl00-2), and resolves the permissions of test.iso from the simple use case: rm -f test.iso umask 022 mkdir test touch test/test xorriso -as mkisofs test -o test.iso I propose this patch for the next stable release to resolve #623378. If that's OK, please let me know and i'll upload to proposed-updates. Please go ahead; thanks. Uploaded. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Bug#623378: patch for #623378
On Wednesday 20 April 2011 05:22:35 Daniel Kahn Gillmor wrote: Hi, The patch Thomas Schmitt referred to from here: http://libburnia-project.org/changeset/3537/libburn/trunk is attached below in debdiff form (applies cleanly to 0.8.0.pl00-2), and resolves the permissions of test.iso from the simple use case: rm -f test.iso umask 022 mkdir test touch test/test xorriso -as mkisofs test -o test.iso I propose this patch for the next stable release to resolve #623378. If that's OK, please let me know and i'll upload to proposed-updates. Daniel, Thanks for the debdiff! The change is pretty safe in my opinion. P.S. sorry for the unsigned message of mine, as I'm on the road, away from my key... I'll see if I need to do something more when I get back. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623378: updating
On Tuesday 19 April 2011 21:52:15 you wrote: Hi, Reassigning #623378 from debirf to xorriso, noting that the problem appears to exist in the stable version of xorriso. You are correct, this was fixed after xorriso 0.5.6 (and long forgotten). Maybe there's a way to fix this with a targeted patch in a point release, if there is no clear reason for the ISOs to be created with too-tight permissions? Indeed, there is no clear reason towards so tight permissions, and should be fixed in the next point release. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622687: mkisofs emulation swallows some options in xorriso-1.0.6
Package: xorriso Version: 1.0.6.pl00-3 Just to have that flaw recorded. This is expected to be resolved very soon. Mail forwarded, as sent to me by Thomas Schmitt. -- Forwarded Message -- Hi, just in case you plan to install xorriso-1.0.6 for debian-cd: I will have to make an emergency release of libisoburn tomorrow. mkisofs emulation swallows some options which come after the arguments of options -iso-level , -o , -M , -C , -iso-level , -input-charset , -output-charset , -hide* Prone to be swallowed are above options, plus several others which are interpreted in the first pass over the options list. Especially in use with debian-cd might be -v -quiet -f Example of a swallow situation: xorriso -as mkisofs -o my.iso -v will skip over -v without performing it. Have a nice day :) Thomas - -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#621597: libisoburn: Getting rid of unneeded *.la / emptying dependency_libs
Likewise, la files will be dropped with the next upload, which would be a new upstream version to be release in few days. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#621672: libisofs: Getting rid of unneeded *.la / emptying dependency_libs
Hi, la files will be dropped with the next upload, which would be a new upstream version to be release in few days. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#489741: netpipes: timelimit shall die when impossible to run the command
Hi, Use case: mac@margarita:~$ touch /tmp/a mac@margarita:~$ timelimit 10 /tmp/a timelimit: Unable to exec /tmp/a (Permission denied) Here timelimit hangs forever... although the primary usage of timelimit is specifically to stop the command after a given time. There is a file conflict between netpipes and timelimit package, which is now resolved as timelimit package declaring a conflict with netpipes. OTOH, it seems that the timelimit application brought by netpipes package is inferior to the timelimit program provided by the timelimit package, and it (netpipes) is otherwise in need with a decent timelimit program, anyway. One way to resolve that (without duplicating already working code) is to drop or rename the timelimit app as brought by the netpipes package (I prefer the former) and 'depends/recommends/suggests' the timelimit package, whish should drop its conflict as well, and could also declare 'enhances' of netpipes.. Thoughts? -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#489741: netpipes: timelimit shall die when impossible to run the command
On Friday 01 April 2011 22:02:24 Mats Erik Andersson wrote: I agree that the possibly optimal resolution would be to inhibit the install of timelimit(1) as part of netpipes. Do grant me some time to evaluate both executables before I make my decision final and public. Of course, have your time. Also, we can take into account that no package currently in debian archive, depends or recommends or suggests netpipes, OHOT chrony package depends on timelimit package. Renaming or fading away timelimit from netpipes package, might break some local user scripts which rely on timelimit program provided by netpipes, but they seem to be broken already anyway, as this very bug report demonstrates it. You have my appreciation for directing me to this calamity. Yeah, I'd like to see this situation improved. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620155: please also install jigdo-gen-md5-list with jigit binary package
Package: jigit Version: 1.17-1 Severity: wishlist Hi, Please also install with the jigit binary package, these files from the source tree of jigit: libjte/bin/jigdo-gen-md5-list libjte/doc/jigdo-gen-md5-list.1 -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612302: xorriso: Newer upstream release available
Hi, JFYI: Latest (v 1.0.4) libburnia packages [1] are now uploaded. However, JTE (jigdo template export) support is not enabled yet, as libjte is not officially released upstream yet, nor merged with jigit package upstream. I intend to close this bug, once both of these are true: 1) when libjte is decided on upstream (yes, I'm involved, thus I share the responsibility too), packaged and uploaded to official debian archive. 2) then xorriso is linked with it, and uploaded as well. [1] libisoburn, libburn, libisofs -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612302: xorriso: Newer upstream release available
On Monday 07 February 2011 17:06:50 you wrote: xorriso 1.0.0 is available, and it's needed if you want to build Debian CD like the official one that we just released for Squeeze. It's a pity that Squeeze doesn't have the required version but better late than never. Yes, I know, and perhaps I need to provide some explanations after that. Some background: currently Debian images for x86 and amd64 are being produced by the latest version of GNU xorriso [1], which is not in Debian archive (not even meant to be) and is a project which accumulates the latest libburnia- project libraries - libburn, libisofs, libisoburn, and libjte [2] in one single tarball to ease the development/test cycles during the last months. All of the above (except libjte [2]) are found in Debian archive as separate source and resp. their binary packages, certainly outdated upstream versions because of the squeeze freeze. Libjte is Steve's code initially stuffed into genisoimage, which was beefed up by Thomas and me and it now shaped an independent library. Our latest plans [3] are to merge libjte into jigit package upstream, and upload that jigit version for Debian as well. Then we can start uploading latest libburn, libisofs (will need libjte) and libisoburn. Can you package the latest upstream version in sid? Thank you. Certainly. But first, we have some house-keeping to complete [3] (I'm sorry we didn't manage to complete all tasks in time and make it for the squeeze release) [1] http://www.gnu.org/software/xorriso/ [2] svn http://svn.openfmi.net/dev/people/danchev/jte [3] http://people.debian.org/~danchev/xorriso/theplan -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#610781: libarchive: Does not recognize d-i ISO images
On Monday 24 January 2011 16:16:22 Andreas Henriksson wrote: Hi, It might be a good idea to test in advance whether overwriting bytes 38919 to 40959 by zeros makes the image recognizable. (Byte numbers decimal starting at 0. Byte 38912 bears 255, 38913 bears 'C'.) Unfortunately additional problems has already been detected (by disabling the reserved bytes check). Please feel free to look at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610783 I haven't had any chance to determine if this is because of bugs in libarchive or another problem with the generated isos. Some more investigation with powerpc images which have been produced by genisoimage reveals that install directory is unpacked just fine: $ bsdtar xf debian-squeeze-di-rc2-powerpc-CD-1.iso $ ls install/ boot.msg ofboot.b pegasos powerpc powerpc64 yaboot yaboot.conf $ find install install install/yaboot.conf install/ofboot.b install/powerpc install/powerpc/vmlinux install/powerpc/vmlinuz-chrp.initrd install/powerpc/initrd.gz install/yaboot install/boot.msg install/pegasos install/powerpc64 install/powerpc64/vmlinux install/powerpc64/vmlinuz-chrp.initrd install/powerpc64/initrd.gz $ cat /mnt/test/.disk/mkisofs /home/debian-cd/build/debian-cd/../genisoimage ... -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#610781: libarchive: Does not recognize d-i ISO images
On Monday 24 January 2011 17:20:54 Samuel Thibault wrote: --cut-- Some more investigation with powerpc images which have been produced by genisoimage reveals that install directory is unpacked just fine: $ bsdtar xf debian-squeeze-di-rc2-powerpc-CD-1.iso Well, maybe, but my concern is with the i386 image: http://cdimage.debian.org/cdimage/squeeze_di_rc2/i386/iso-cd/debian-squeeze -di-rc2-i386-businesscard.iso Right, I was just comparing the results of the two generators. Apparently, Thomas already found and fixed one related issue with ours. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#610783: bsdtar: Doesn't extract the install* and isolinux* directories of d-i images
On Monday 24 January 2011 21:53:50 Thomas Schmitt wrote: Hi, (I changed the bug address to 610783@ as this is the bug we are talking about now) it seems the immediate reason is in libarchive/archive_read_support_format_iso9660.c:read_entries() which iterates over next_entry(iso9660) until a NULL or a non-directory appears. With an image created by mount -o loop /reiser/p/v/debian-squeeze-di-rc2-i386-businesscard.iso /mnt genisoimage -o debian-businesscard-genisoimage.iso \ -allow-leading-dots -J -R -graft-points /=/mnt i first see all 158 directories being enumerated and only then come the other files. With the image from xorriso i see the symbolic link 'debian' as second item, which ends the loop. After a few more directories comes the first regular file. The iteration sequence with the image from genisoimage is _not_ the sequence of directory entries in that image. At least in the root directory the sequences of directory entries are the same in both images. So next i will have to find out what determines the iteration sequence. But first i need some calories. At the head of that source file I read: * This module works by first reading the volume descriptors, then * building a list of directory entries, sorted by starting * sector. At each step, I look for the earliest dir entry that * hasn't yet been read, seek forward to that location and read * that entry. If it's a dir, I slurp in the new dir entries and * add them to the heap; if it's a regular file, I return the * corresponding archive_entry and wait for the client to request * the file body. This strategy allows us to read most compliant * CDs with a single pass through the data, as required by libarchive. This entry sequencing smells as an assumption to me. I'm not aware ECMA-119 to stipulate something like that. Am I missing something? -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- 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
On Tue, 28 Dec 2010 14:02:39 +0100, Matthias Klose d...@ubuntu.com wrote: Hi All, Thanks for the bug-report and the proposed fix. 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. you assume a lot about linking order, which might not be true for every linker. Okay, it is true that a common approach for linkers is to look for external symbols from left to right in the libraries list passed to the linker. Thus a library containing a definition of a function must be specified after any source or object files which use it. 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 ;-) Here is the difference: wrong order: $ gcc -shared -Wl,--as-needed -Wl,-z,def,-soname,libbobcat.so.2 -o tmp/lib/libbobcat.so.2.10.01 -lmilter -L/usr/lib/libmilter -lX11 -lssl -lreadline */os/*.o $ ldd tmp/lib/libbobcat.so.2.10.01 linux-gate.so.1 = (0xf77df000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0xf771a000) libc.so.6 = /lib/libc.so.6 (0xf75b9000) /lib/ld-linux.so.2 (0xf77e) correct order: $ gcc -shared -Wl,--as-needed -Wl,-z,def,-soname,libbobcat.so.2 -o tmp/lib/libbobcat.so.2.10.01 */os/*.o -lmilter -L/usr/lib/libmilter -lX11 -lssl -lreadline $ ldd tmp/lib/libbobcat.so.2.10.01linux-gate.so.1 = (0xf77bb000) libmilter.so.1.0.1 = /usr/lib/libmilter.so.1.0.1 (0xf7704000) libX11.so.6 = /usr/lib/libX11.so.6 (0xf75ec000) libreadline.so.6 = /lib/libreadline.so.6 (0xf75b7000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0xf759a000) libc.so.6 = /lib/libc.so.6 (0xf7439000) libpthread.so.0 = /lib/libpthread.so.0 (0xf741f000) libxcb.so.1 = /usr/lib/libxcb.so.1 (0xf7405000) libdl.so.2 = /lib/libdl.so.2 (0xf7401000) libncurses.so.5 = /lib/libncurses.so.5 (0xf73c8000) /lib/ld-linux.so.2 (0xf77bc000) libXau.so.6 = /usr/lib/libXau.so.6 (0xf73c4000) libXdmcp.so.6 = /usr/lib/libXdmcp.so.6 (0xf73be000) I agree, we need to fix the order of specified libraries. 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. 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. That was my question to you as the package maintainer. the correct tweak for icmake/libraries should be: run(GCC + -shared -Wl,-z,def,-soname, + libsomajor + -o + destDir + libsoshared + */os/*.o + g_sharedLibReq ); -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594704: Freeze exception for roxterm 1.18.5-2
George Danchev writes: Mehdi Dogguy writes: On 08/26/2010 10:52 PM, Tony Houghton wrote: It's been working without issues for me since I finalised the current version of the patch. Can you upload to unstable then? I'll let it age a bit and then unblock it. Ping me in two weeks. Okay. it is already in unstable as of today. We'll ping you once again in two weeks, but filing a bug just to register it with bts, just in case to guard against human memory faults at our side. As requested, this is a ping message to allow roxterm 1.18.5-2 to enter testing. It fixes the following bug #592984, no flows are found for now. Thanks. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Bug#565874: some more info on using growisofs with xorriso
Hi, Few more gestures which might be worth documenting in README.Debian, if you eventually plan to prepare a new upload for squeeze. If you want to use growisofs with xorriso for yourself, here is a possible procedure: Xorriso respects several names in argv[0], and changes its personality accordingly, where 'xorrisofs' means emulating mkisofs options, and 'xorrecord' resp. cdrecord options. Therefore it is possible to introduce 'xorrisofs' symlink pointing to xorriso (if it does not already exists on your system), and call it that way via 'xorrisofs' so it handles same options like mkisofs. The only exception is that xorriso does not produce DVD video images yet, because it does not emulate -udf and -dvd-video optons of mkisofs. $ ln -s /usr/bin/xorriso $HOME/xorrisofs $ export GENISOIMAGE=$HOME/xorrisofs Now, growisofs will call xorrisofs which points to xorriso, which in turn will behave like mkisofs, options-wise, except for -udf and -dvd-video. $ growisofs -Z /dev/dvd /some/files $ growisofs -M /dev/dvd /more/files P.S. Yes, I know it is xorriso package' job to provide these links in /usr/bin, so we might eventually upload that before or after squeeze, not decided yet. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565874: another deal: just spawn 'xorriso -as mkisofs' from growisofs.c
Hi, I can see that growisofs reads GENISOIMAGE environment variable (used to be MKISOFS, as upstream does) and if there its is used as image manipulation tool. This might not be extremely convenient, but is there as a fallback. However, we also have alternative image manipulator and burner apps like these provided by cdrskin and xorriso packages. Note, that xorriso is both image manipulator and burner application (cdrskin is burner-only) which could behave like mkisofs and few more options-wise. See -as personality in xorriso(1). Therefore it would make sense to just spawn 'xorriso -as mkisofs' instead of genisoimage from growisofs.c. I realize that changing the image manipulation tool to be spawned at this stage of the freeze might not be the safest thing to do, but we should do that in squeeze+1, at least. How does that sound? -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559102: FTBFS [hppa]: storage size of 'is' isn't known
tags 559102 patch thanks Hi, According to my understanding hppa is (also) IEEE754 compliant architecture, so the attached patch is in order. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu diff -Naur libtirpc-0.2.0.orig/src/xdr_float.c libtirpc-0.2.0/src/xdr_float.c --- libtirpc-0.2.0.orig/src/xdr_float.c 2010-08-29 08:59:15.0 +0300 +++ libtirpc-0.2.0/src/xdr_float.c 2010-08-29 08:59:55.0 +0300 @@ -59,7 +59,7 @@ defined(__arm32__) || defined(__ppc__) || defined(__ia64__) || \ defined(__arm26__) || defined(__sparc64__) || defined(__amd64__) || \ defined(__powerpc__) || defined(__s390__) || defined(__arm__) || \ -defined(__sh__) +defined(__sh__) || defined(__hppa__) #include bits/endian.h #define IEEEFP #endif
Bug#594704: Freeze exception for roxterm 1.18.5-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: freeze-exception Mehdi Dogguy writes: On 08/26/2010 10:52 PM, Tony Houghton wrote: It's been working without issues for me since I finalised the current version of the patch. Can you upload to unstable then? I'll let it age a bit and then unblock it. Ping me in two weeks. Okay. it is already in unstable as of today. We'll ping you once again in two weeks, but filing a bug just to register it with bts, just in case to guard against human memory faults at our side. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592616: pu: package bgoffice/3.0-9+lenny1
Adam D. Barratt writes: On Fri, August 27, 2010 10:28, Yavor Doganov wrote: Ð 10:03 +0100 на 27.08.2010 (пÑ), Adam D. Barratt напиÑа: On Fri, August 27, 2010 09:26, Yavor Doganov wrote: Sure, does this mean that with this change the update is approved and can be uploaded? I'd prefer a look at an updated debdiff first; I don't envisage there being any other issues though. OK, here it is. Please go ahead. Regards, Adam Uploaded. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
