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-rc-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-rc-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 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-rc-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-rc-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-rc-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-rc-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-rc-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-rc-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-rc-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-rc-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-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#589851: RFS: bgoffice (QA upload, RC bugfix)
Yavor Doganov writes: Dear mentors, -- The upload would fix these bugs: 589851 http://mentors.debian.net/debian/pool/main/b/bgoffice/bgoffice_3.0-11.dsc Uploaded. Thank you for the fix. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Bug#564233: fim FTBFS on i386
Hi, Your new package does not seem to be accessible at: http://claudius.ce.uniroma2.it/~martone/tmp/ Please, upload to mentors.debian.net. If no one steps up, I'm willing to sponsor that too. Thank you. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564233: fim FTBFS on i386
Okay the site came back online and I managed to access it. Package uploaded. Thanks. P.S. You might have more success with mentors list while hunting for sponsors. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566694: FTBFS -- error: invalid conversion from 'const char*' to 'char*'
Package: kbedic
Version: 4.0-12
Severity: serious
Tags: patch
Hi,
Attached is a patch which fixes ftbfs. For reference, please see:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=564233#10
--
pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu
--- src/translator.cpp.orig 2010-01-24 18:07:28.0 +0200
+++ src/translator.cpp 2010-01-24 18:07:35.0 +0200
@@ -297,7 +297,7 @@
buf[i] = word[i];
}
else {
- p = strchr(ENG_CHARS, word[i]);
+ p = const_castchar*(strchr(ENG_CHARS, word[i]));
if (p != NULL) {
buf[i] = BUL_CHARS[p - ENG_CHARS];
}
@@ -325,7 +325,7 @@
char c;
while ((c = word[i]) != '\0') {
if (legalLatinInput) {
- p = strchr(BUL_CHARS, c);
+ p = const_castchar*(strchr(BUL_CHARS, c));
if (p != NULL) {
buf[j] = ENG_CHARS[p - BUL_CHARS];
j++;
Bug#550092: dia2code: Segmentation Fault into 64 bits systems
Hi, Could you please give some more information how to reproduce it: (since I'm unable to reproduce on amd64) * How you run dia2code * Attach the dia file if possible, that would be very helpful to reproduce, indeed. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564233: fim FTBFS on i386
tags 564233 patch thanks Hi, (this FTBFS everywhere /amd64 here/ with newer/stricter compiler) Patch attached. Rationale: there are two prototypes/overloads available: const char * strchr ( const char * str, int character ); char * strchr ( char * str, int character ); since your first argument given to strchr() in your code is const char * (that is 'cs'), the first function prototype matches which returns const char * and compiler rightfully complains because it is then assigned to char *. alternative resolution would be to const_cast the first argument, so that the second prototype matches, which wold then return non-const. --- src/DebugConsole.cpp.orig 2010-01-16 19:06:33.0 +0200 +++ src/DebugConsole.cpp 2010-01-16 19:06:38.0 +0200 @@ -119,7 +119,7 @@ if(!nc)return -1; nl=lines_count(cs,lwidth); // we count exactly the number of new entries needed in the arrays we have - if((s=strchr(cs,'\n'))!=NULL s!=cs)nl+=(ccol+(s-cs-1))/lwidth;// single line with \n or multiline + if((s=const_castchar*(strchr(cs,'\n')))!=NULL s!=cs)nl+=(ccol+(s-cs-1))/lwidth;// single line with \n or multiline else nl+=(strlen(cs)+ccol)/lwidth; // single line, with no terminators /*
Bug#561852: apt: Method http has died unexpectedly (undefined symbol:)
David Kalnischkies writes: Hi George Danchev, 2009/12/29 George Danchev danc...@spnet.net: It turns out that some previous version of apt (= 0.7.24) provide libapt-pkg- libc6.9-6.so.4.8.1 shared object, which according to objdump -T and readelf -s do not provide the missing symbol in question (_Z14maybe_add_authR3URISs). Correct, maybe_add_auth was added in rev 1561.3.1 of the debian-sid branch. (Seems to be we forget to bump the minor abi while trying hard to not break the major abi) but as the library and the user (method/http) are shipped in the same package the error is still a bit strange, especially as the http method is the most used acquire method and the call to maybe_add_auth is unconditional, so many (read: all) users should have faced this problem... Yes, I agree with that logic and actually very few users reported about behavior like that. So is this somehow reproducible? Since there are so many upgrade paths, I haven't been able to reproduce that starting to upgrade apt from a clean lenny, I tried several combinations with no luck. I wonder if the resetted shared object versioning has something to do with it, e.g: apt 0.7.24 libapt-pkg- libc6.9-6.so.4.8.0 apt = 0.7.24 libapt-pkg- libc6.9-6.so.4.8.1 and then again: apt = 0.7.25 libapt-pkg- libc6.9-6.so.4.8.0 that being said, I don't see many chances for libapt-pkg- libc6.9-6.so.4.8.1 and a previous version libapt-pkg- libc6.9-6.so.4.8.0 (with that symbol missing) to be left in place with a symlink and latest apt-get binary which is trying to resolve the missing symbol. (I reproduced it artificially extracting and putting in place libapt-pkg- libc6.9-6.so.4.8.1 from apt 0.7.24 when apt 0.7.25 was installed, but this is not so realistic as scenario) I would personally prefer to understand why this happen at all before closing the bug to be able to avoid such problems in the future. Yes, I can see your reasons... -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561852: apt: Method http has died unexpectedly (undefined symbol:)
Hi, It turns out that some previous version of apt (= 0.7.24) provide libapt-pkg- libc6.9-6.so.4.8.1 shared object, which according to objdump -T and readelf -s do not provide the missing symbol in question (_Z14maybe_add_authR3URISs). To force dynamic linker to resolve all symbols at program startup instead of when they are first referenced: LD_BIND_NOW=true apt-get update To produce a more verbose debugging about the dynamic linkage: (what object files linker picks up and which symbols are being resolved) on x86: LD_DEBUG=all /lib/ld-linux.so.2 /usr/bin/apt-get update on amd64: LD_DEBUG=all /lib/ld-linux-x86-64.so.2 /usr/bin/apt-get update Since that it a transient breakage, I think we can close that bug safely unless there is a possible upgrade path which could leave the system in a state such that apt-get executable could call maybe_add_auth function without being dynamically linked with the proper shared object providing that symbol (_Z14maybe_add_authR3URISs) as well. P.S. Many thanks to Wil van Lierop (dutchfish) and Ron Lee (ron) for taking part in hunting down that transient breakage on IRC. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562606: FTBFS: unknown options to dh_ocaml
Hi, Goswin, are you sure that you didn't have locally modified dh-ocaml (how many dh_ocaml's you have to begin with, since it has 3 options and your build lacks 2 of them;-) since ocaml 3.11.1-5 builds just fine in a clean amd64 sid chroot, here. Also your debhelper version 8.0.0~git.1 looks odd, never found in sid. Let me guess you are silently migrating dh_ocaml helper from dh-ocaml package to your local development debhelper version? Testing these in a chroot would save us some riddles, wouldn't it? -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562447: missing dependency of rubygems; failed to start
Package: god Version: 0.7.13-2 Severity: serious Justification: renders package unusable Hello, $ god /usr/bin/god:7:in `require': no such file to load -- rubygems (LoadError) from /usr/bin/god:7 Installing rubygems fixes that, but then again nothing seems to happen if I try to run it. Is there anything divine, I'm missing here? -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562447: missing dependency of rubygems; failed to start
At least --help works, but providing a man-page would be nice as per policy 12.1. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544664: dma: diff for NMU version 0.0.2009.07.17-2.1
tags 544664 + pending thanks Hi, Sorry for duplicated efforts due to us not keeping BTS inline. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#555120: aptitude-gtk doesn't start (GThread-ERROR **: GThread system may only be initialized once. aborting...)
On Sat, Dec 05, 2009 at 10:46:16PM +0200, George Danchev danc...@spnet.net was heard to say: Hi, the following patch fixes that crash on amd64. --- src/gtk/gui.cc.orig 2009-12-05 22:43:21.0 +0200 +++ src/gtk/gui.cc 2009-12-05 22:43:40.0 +0200 @@ -1769,7 +1769,7 @@ if(!gtk_init_check(argc, argv)) return false; -Glib::init(); +//Glib::init(); Odd, so Glib::init invokes thread_init, but only on amd64? The docs don't suggest this at all. thread_init's documentation shows how to check whether it's already been called, though, so maybe I can just do that. My impression is that Glib::thread_init() invokes Glib::init() on all arches, but calling them both is only fatal on certain ones, which does not mean it is correct to call both Glib::init() and Glib::thread_init() on arches where it is not fatal. I forgot to clarify that the above patch (which only invokes Glib:thread_init() ) works for me on x86 too and amd64. [1] only thread_init() is called, which should be enough: http://library.gnome.org/devel/glibmm/stable/thread_2thread_8cc- example.html#a11 -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#555120: aptitude-gtk doesn't start (GThread-ERROR **: GThread system may only be initialized once. aborting...)
Hi, This crash is reliably reproduced on amd64, but not on x86. It looks like the brokeness is in the main() function in src/gtk/gui.cc, in the call of Glib::thread_init(); That looks very odd: GThread system may only be initialized once. aborting... I'm not that into glib and glibmm, but I can perform further test for you if you need some more (bt is also attached). Reading symbols from /home/george/download/debian/aptitude-0.6.1.3/debian/aptitude- gtk/usr/bin/aptitude-gtk...done. (gdb) b gui.cc:1772 Breakpoint 1 at 0x57f11c: file gui.cc, line 1772. (gdb) r Starting program: /home/george/download/debian/aptitude-0.6.1.3/debian/aptitude- gtk/usr/bin/aptitude-gtk [Thread debugging using libthread_db enabled] [New Thread 0x7fffe72a6910 (LWP 7453)] Breakpoint 1, gui::main (argc=1, argv=0x7fffe378) at gui.cc:1772 1772Glib::init(); (gdb) n 1773Glib::thread_init(); (gdb) n GThread-ERROR **: GThread system may only be initialized once. aborting... Program received signal SIGABRT, Aborted. 0x70ff3f55 in *__GI_raise (sig=value optimized out) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. in ../nptl/sysdeps/unix/sysv/linux/raise.c Current language: auto The current source language is auto; currently c. (gdb) bt #0 0x70ff3f55 in *__GI_raise (sig=value optimized out) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x70ff6d90 in *__GI_abort () at abort.c:88 #2 0x75c5fca5 in g_logv () from /lib/libglib-2.0.so.0 #3 0x75c60043 in g_log () from /lib/libglib-2.0.so.0 #4 0x75a19aaa in g_thread_init () from /usr/lib/libgthread-2.0.so.0 #5 0x005909be in Glib::thread_init (vtable=0x0) at /usr/include/glibmm-2.4/glibmm/thread.h:792 #6 0x0057f12b in gui::main (argc=1, argv=0x7fffe378) at gui.cc:1773 #7 0x0043f6a5 in main (argc=1, argv=0x7fffe378) at main.cc:1128 -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu Reading symbols from /home/george/download/debian/aptitude-0.6.1.3/debian/aptitude-gtk/usr/bin/aptitude-gtk...done. (gdb) b gui.cc:1772 Breakpoint 1 at 0x57f11c: file gui.cc, line 1772. (gdb) r Starting program: /home/george/download/debian/aptitude-0.6.1.3/debian/aptitude-gtk/usr/bin/aptitude-gtk [Thread debugging using libthread_db enabled] [New Thread 0x7fffe72a6910 (LWP 7453)] Breakpoint 1, gui::main (argc=1, argv=0x7fffe378) at gui.cc:1772 1772Glib::init(); (gdb) n 1773Glib::thread_init(); (gdb) n GThread-ERROR **: GThread system may only be initialized once. aborting... Program received signal SIGABRT, Aborted. 0x70ff3f55 in *__GI_raise (sig=value optimized out) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. in ../nptl/sysdeps/unix/sysv/linux/raise.c Current language: auto The current source language is auto; currently c. (gdb) bt #0 0x70ff3f55 in *__GI_raise (sig=value optimized out) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x70ff6d90 in *__GI_abort () at abort.c:88 #2 0x75c5fca5 in g_logv () from /lib/libglib-2.0.so.0 #3 0x75c60043 in g_log () from /lib/libglib-2.0.so.0 #4 0x75a19aaa in g_thread_init () from /usr/lib/libgthread-2.0.so.0 #5 0x005909be in Glib::thread_init (vtable=0x0) at /usr/include/glibmm-2.4/glibmm/thread.h:792 #6 0x0057f12b in gui::main (argc=1, argv=0x7fffe378) at gui.cc:1773 #7 0x0043f6a5 in main (argc=1, argv=0x7fffe378) at main.cc:1128
Bug#555120: aptitude-gtk doesn't start (GThread-ERROR **: GThread system may only be initialized once. aborting...)
Hi, the following patch fixes that crash on amd64. --- src/gtk/gui.cc.orig 2009-12-05 22:43:21.0 +0200 +++ src/gtk/gui.cc 2009-12-05 22:43:40.0 +0200 @@ -1769,7 +1769,7 @@ if(!gtk_init_check(argc, argv)) return false; -Glib::init(); +//Glib::init(); Glib::thread_init(); background_events_dispatcher.connect(sigc::ptr_fun(run_background_events)); -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554823: switzerland: diff for NMU version 0.1.0-2.1
Hi Christoph, Note, that you can't just say BSP 2009 $Location in nmu changgelog and be done with it. All the changes applied with that revision should be properly documented. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558025: [kali] segfault at startup
I can confirm that 3.1-10 crashes on startup on x86, but not on amd64. I got the source in order to rebuilt with debugging symbols on x86, but then the app started just fine. My best bet is that something has changed within the underlying libraries, also looking at ltrace output: fl_set_object_lcol(0x9e2a500, 0, 0xbfbad678, 0x804bf28, 1) = 0x9e2a500 fl_initial_wingeometry(8, 8, 220, 670, 0x37f0c7f)= 220 fl_show_form(0x9e29a68, 0, 1, 0x8051237, 0x37f0c7f unfinished ... --- SIGSEGV (Segmentation fault) --- +++ killed by SIGSEGV +++ reveals that something has changed in the callback functions there. I'm curious if rebuilding on x86 would make that crash go away. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554785: autoclass -reports segfault on import example
tags 554785 patch
thanks
Hi Knut,
I'm not an autoclass expert, but gdb helped to track that down to calling stuff
via NULL pointer. Attached is a patch which fixes that segfault.
--
pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu
diff -Naur autoclass-3.3.4.orig/prog/io-results-bin.c autoclass-3.3.4/prog/io-results-bin.c
--- autoclass-3.3.4.orig/prog/io-results-bin.c 2009-11-28 16:30:04.0 +0200
+++ autoclass-3.3.4/prog/io-results-bin.c 2009-11-28 16:30:15.0 +0200
@@ -595,7 +595,7 @@
((expand_list[0] != END_OF_INT_LIST)
(member_int_list( clsf_index+1, expand_list) == TRUE {
expand_clsf( clsf, want_wts_p, update_wts_p);
- if(first_clsf-models != clsf-models) {
+ if(first_clsf clsf (first_clsf-models != clsf-models)) {
first_clsf-models = clsf-models;
}
Bug#554588: ftpgrab_0.1.4-1(ia64/unstable): FTBFS: no member 'sa_restorer'
Hi, This also FTBFS on hppa, hurd-i386 and kfreebsd-*. Looking at: usr/include/bits/sigaction.h (libc6.1-dev_2.10.1-5_ia64) I see that such a member is not provided on certain architectures. Perhaps instead of (in main.cc): #if !defined(__alpha) pipeAction.sa_restorer = NULL; #endif better test for supported architectures: defined(__sparc64__) || defined(__x86_64__) ... or even better, in my opinion that line could be safely removed, since initializing that member is not strictly needed. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549312: cdrom segfaults on several machines and architectures when reading
Could you please try that with apt 0.7.21. You could grab it as: bzr export . -r 1776 http://bzr.debian.org/apt/debian-sid/ -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512700: FTBFS on nearly all arches
On Friday 23 January 2009 00:31:15 Laurent Bigonville wrote: Package: sofia-sip Version: 1.12.10-2 Severity: serious Hi, Sofia-sip FTBFS on nearly all arches due to missing symbols in .symbols files Could you please fix it Hello, and thanks for reporting. It was failing because I passed -c4 to dpkg-gensymbols (by accident) before having the symbol files populated properly. I should have passed -c1 instead. I was also waiting for experimental.ftbfs.de to complete the failed -2 source package on all architectures in order to grab the symbol diffs from buildlogs. It is almost done, will upload fixed package soon. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511199: perspic: does not work at all: complains about find arguments /
Hi, and Word-Define; the latter shows a dialog, but interaction with it leads to a different crash. Agreed. There is a lots of potential for random crashes, mainly related to interface handling. Further a breaf peek at code reveals more flaws: peopen() return value not being inspected at all [ init.c:archive_init() ], but gladly used later on. There is probably more such examples. In my opinion this package should be removed from lenny, at least. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511261: CVE-2008-0049: Inproper certificate validation
Hello Wouter,
I'm not quite familiar with your app internals, but it seems your fix makes no
big difference between 0 and 1 return codes. You really want to use
EVP_VerifyFinal as openssl guys did it [1], and provide the above functioning
level with the all possible returns. Their doc suggests the same:
EVP_VerifyFinal() returns:
1 for a correct signature
0 for verfication failure
-1 if some other error occurred.
This is a short code snippet from openssl: apps/dgst.c around line ~458.
i = EVP_VerifyFinal(ctx, sigin, (unsigned int)siglen, key);
if(i 0)
BIO_printf(out, Verified OK\n);
else if(i == 0)
{
BIO_printf(out, Verification Failure\n);
return 1;
}
else
{
BIO_printf(bio_err, Error Verifying Data\n);
ERR_print_errors(bio_err);
return 1;
}
--
pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu
signature.asc
Description: This is a digitally signed message part.
Bug#509405: Partial solution
Hello, I installed this file in ~/.asoundrc: Can you please test that with the latest upstream svn trunk and branches/2.1 ? -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508551: merkaartor: crash on startup: QPaintEngine::setSystemClip: Should not be changed while engine is active
Hello, I believe that Sebastian used svn trunk rev12241, so I built that revision in hope to reproduce the same startup failure, but the app started just fine on my sid box. Both versions of merkaartor from sid and lenny work properly for me too. Sebastian, could you please install Debian's merkaartor packages from unstable and lenny and check them out, since that bug might not be relevant to Debian at all. Also did you use self-compiled version if Qt as described at: http://wiki.openstreetmap.org/index.php/Problem_uploading_with_Merkaartor Of course prompt cooperation is very welcome since we are trying to cut the number of the release critical bugs down, but that failure seems quite bogus to me. Christoph, if the reporter confirms that versions from lenny and sid work for him, I believe this bug could be closed. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#487353: trying to overwrite `/usr/include/Poco/NumberFormatter.h', which is also in package libpoco-dev
tags 487353 + fixed pending thanks In order to replace the whole libpoco-dev binary package I've added to libpoco5-dev: Provides: libpoco-dev Conflicts: libpoco-dev Replaces: libpoco-dev and uploaded it as -1.1. Sorry, for the quick NMU, but that issue was serious. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321449: gcc-snapshot for testing
On Friday 14 December 2007, Dmitry E. Oboukhov wrote: Hi, I needed to test the building of one of my packages with gcc4.3. However it turns out that gcc-snapshot from unstable contains the critical bug, which makes impossible using it. At the same time the previous version of the gcc-snapshot deb-package has been already deleted from unstable. You can have any previous version from http://snapshot.debian.net/ -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380587: Please go ahead
On Monday 11 September 2006 11:23, Ludovic Brenta wrote: The package is ready on my hard disk, but the upload has been delayed by the telephone company's inability to transfer my ADSL connection to my new home in a timely manner :( They're supposed to do the transfer today; then I have to make sure ADSL works, and I'll upload as soon as I can. Ah, I see, bad day ;-). In that case you might consider mailing your debian/ directory to a fellow DD (if it is not already kept in a public VCS), to upload instead of you (I don't think an NMU is needed in that case). Assuming there is get-orig-source target or exact instructions of how to get the upstream tarball. Just an idea. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380587: Please go ahead
Hello Ludovic, Please go ahead and upload GtkAda 2.8.1 package, this will unblock gnat-gps and probably some more. Why do you need to wait for Packages-arch-specific additions ? This should be doable at some later point if the package has not been picked up for build on certain archs. Probably binNMU if it is binNMU-safe. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380699: FTBFS: sh: latex: command not found
Hello Colin, Seems like we should build-depend on tetex-bin. I can prepare new upload to fix that FTBFS and #380377 also, and dupload it to -mentors. Please ping me if you don't have the time to complete it. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379722: bobcat: FTBFS: INSTALL.cf: not found
Hello Julien, Could you please elaborate on that FTBFS, since debian/rules build target passes just fine here, clean target is also fine. Perhaps if I know how you invoked the sbuild on bobcat package I can reproduce that ftbfs. Hm, did you run into free space shortage when the source package got uncompressed so that INSTALL.cf file was not there for you ? Thanks for your assistance. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379491: yate: FTBFS: build-dep on libortp2-dev is not available
On Monday 24 July 2006 13:13, Diana Cionoiu wrote: Hello Samuel, Yate 0.8.7 it's like 1.5 years old. We never recomand someone to use that, especially since Yate 1 it's out. Diana Cionoiu P.S. Please remove yate 0.8.7 from debian and replace it with yate 1 Hi, yate 1 is on its way to unstable, see build daemon' logs on various architectures at: http://buildd.debian.org/pkg.cgi?pkg=yate and its state in the unstable archive: http://packages.debian.org/yate -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#350739: #350739: cdrecord status?
* Joerg Schilling ([EMAIL PROTECTED]) wrote: Before writing more, it seems to be iomportant to mention a common missconception: Both, the CDDL and the GPL are _source_ licenses. Why do you say that ? This main problem is the distribution of the binary (Executable Versions) form! CDDL 1.0 says: 3.5. Distribution of Executable Versions. You may distribute the Executable form of the Covered Software under the terms of this License or under the terms of a license of Your choice, which may contain terms different from this License, provided that You are in compliance with the terms of this License and that the license for the Executable form does not attempt to limit or alter the recipients rights in the Source Code form from the rights set forth in this License. If You distribute the Covered Software in Executable form under a different license, You must make it absolutely clear that any terms which differ from this License are offered by You alone, not by the Initial Developer or Contributor. You hereby agree to indemnify the Initial Developer and every Contributor for any liability incurred by the Initial Developer or such Contributor as a result of any such terms You offer. So someone must decide the license of the distribution of the Covered Software in Executable form. Also this sort of indemnification is insane, but that is perfectly clear. They both _allow_ binary redistribution under certain conditions but it is definitely wrong to even think about: under what license might the resultant binary be. There is no binary license for the project but there is a permission to distribute/use binaries under certain conditions. You contradict to CDDL definitions then... your binaries are Executables (that is the Covered Software in any form other than Source Code.): from above: If You distribute the Covered Software in Executable form under a different license... Let me site you the definitions for Covered Software, Executable, and Original Software. 1.3. Covered Software means (a) the Original Software, or (b) Modifications, or (c) the combination of files containing Original Software with files containing Modifications, in each case including portions thereof. 1.4. Executable means the Covered Software in any form other than Source Code. 1.10. Original Software means the Source Code and Executable form of computer software code that is originally released under this License. And finally, CDDL 1.0 3.6. Larger Works. You may create a Larger Work by combining Covered Software with other code not governed by the terms of this License and distribute the Larger Work as a single product. In such a case, You must make sure the requirements of this License are fulfilled for the Covered Software. I don't think Debian can fulfil the requirements of this License (CDDL 1.0) because of indemnification mentioned above (at least) for the Executable form of the Covered Software (1.4. Executable means the Covered Software in any form other than Source Code.) -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#350739: #350739: cdrecord status?
On Monday 10 July 2006 20:31, Joerg Schilling wrote: George Danchev [EMAIL PROTECTED] wrote: Why do you say that ? This main problem is the distribution of the binary (Executable Versions) form! There is no problem with distributing executables as the CDDL and the GPL do not require contradictory conditions... You must give the licensee a copy of GPL: 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. But CDDL imposes further restrictions which are incompatible with GPL. You are changing your positions way too fast. In a previous message you said: cite1Both, the CDDL and the GPL are _source_ licenses. /cite1 And: cite2They both _allow_ binary redistribution under certain conditions but it is definitely wrong to even think about: under what license might the resultant binary be. There is no binary license for the project but there is a permission to distribute/use binaries under certain conditions. /cite2 Now you write: There is no problem with distributing executables as the CDDL and the GPL do not require contradictory conditions... I bet that your next conclusion will be: It is definitely wrong to even think about: under what license might the resultant binary be produced by source files where some of them are being licensed under GPL'ed and the rest are under the CDDL. Your only sane choice is to dual license the whole projects of yours under CDDL and GPL. Thus licensees either accept the CDDL and ignore GPL, or accept GPL and ignore CDDL for both the source code and executables. CDDL 1.0 says: 3.5. Distribution of Executable Versions. ... the Source Code form from the rights set forth in this License. If You distribute the Covered Software in Executable form under a different license, You must make it absolutely clear that any terms which differ from this License are offered by You alone, not by the Initial Developer or Contributor. You hereby agree to indemnify the Initial Developer and every Contributor for any liability incurred by the Initial Developer or such Contributor as a result of any such terms You offer. So someone must decide the license of the distribution of the Covered Software in Executable form. Also this sort of indemnification is insane, but that is perfectly clear. I don't think Debian can fulfil the requirements of this License (CDDL 1.0) because of indemnification mentioned above (at least) for the Executable form of the Covered Software (1.4. Executable means the Covered Software in any form other than Source Code.) You have been very unclear with your text, so I may only comment the part where you have been unambiguous. You imply that CDDL is unclear and ambiguous (since my text was being parts quoted from the CDDL and I think it has very clear wording. If Debian is in fear of the last two sentences from CDDL §3.5, then I see only one possible reason: Debian is planning to distribute the binary in a way that causes harm to the original developer or contributors. It boils down to how this hypothetical harm would be claimed and interpreted in your jurisdiction after user accepts your CDDL choice-of-venue-patched license. That's it is not acceptable for me as an end user. This gives a deep look inside Debian. Fix your baseless squint looking then. Anyway, I'm not a Debian Developer and can not talk on behalf of the Debian Project, but as a Debian user I can contribute to that discussion talking for myself. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
Bug#335278: shc -- #335278 broken packaging -- non-DD NMU prepared
On Friday 07 July 2006 12:38, Francisco Rosales wrote:
-cut--
Hello,
If the problem is about the copyright of the rc4 implementation,
then you must know the full history.
At some point in 1997 I decided to change from shc-2.7 to 3.0. The
idea was to change totally the way the script is hidden inside the binary.
I decide to use a very beautiful and tiny algorithm I seen published in
the news:
http://groups.google.com/group/comp.lang.c/msg/dce6ba2c5c8dd0d1
As you can see following the previous link, the published
implementation was 4 lines long (283 characters):
#define S,t=s[i],s[i]=s[j],s[j]=t, /* :usage: rc4 key file; @RSADSI */
main(int c,char**v){unsigned char*p=*++v,s[256],b[4096],i=0,j=0,t;c=
strlen(p);while(s[i]=i,++i);while(j+=s[i]+p[i%c]S++i);j=0;while(c=read
(0,p=b,4096)){while(c--){j+=s[++i]S*p++^=s[t+=s[i]];}write(1,b,p-b);}}
...and came with the following invitation:
Anyone fancy having a go at shrinking this C code? ...
There was no copyright notice, but obviously there was an explicit
invitation for everybody to take and to modify that code.
I took the invitation, not for shrinking but for improving
readability and usability. The resulting code, which is included in shc.c
file and in any .x.c generated file is:
static unsigned char stte[256], indx, jndx, kndx;
/*
* Reset arc4 stte.
*/
void stte_0(void)
{
indx = jndx = kndx = 0;
do {
stte[indx] = indx;
} while (++indx);
}
/*
* Set key. Can be used more than once.
*/
void key(void * str, int len)
{
unsigned char tmp, * ptr = (unsigned char *)str;
while (len 0) {
do {
tmp = stte[indx];
kndx += tmp;
kndx += ptr[(int)indx % len];
stte[indx] = stte[kndx];
stte[kndx] = tmp;
} while (++indx);
ptr += 256;
len -= 256;
}
}
/*
* Crypt data.
*/
void arc4(void * str, int len)
{
unsigned char tmp, * ptr = (unsigned char *)str;
while (len 0) {
indx++;
tmp = stte[indx];
jndx += tmp;
stte[indx] = stte[jndx];
stte[jndx] = tmp;
tmp += stte[indx];
*ptr ^= stte[tmp];
ptr++;
len--;
}
}
I sincerely think that this code is mostly mine.
Perhaps some i, j, s or p remains from the original, and obviously
I'm not the creator of the rc4 algorithm.
Very good. I do believe it is yours. What I wish to see in shc.c is the very
same words and explanations, that is, that the unknown-copyright
implementation has been re-implemented by you and the copyright notice applis
to it also. Since that appears to be true, it should be added there and get
the users aware of that very important detail from the legal POV.
Right, we are not discussing algorithm itself (it has already been in various
free software packages), but its implementation in shc.
Is almost impossible for John L. Allen (wherever he is) to
recognize that code as his code, and obviously his own (beautiful) 4 lines
of code wasn't created from nothing, and he isn't the creator of the rc4
algorithm neither.
So... I sincerely think that this code is mostly mine.
The disclaimer I put on top of shc.c,
/**
* This software contains the 'Alleged RC4' source code.
* The original source code was published on the Net by a group of
cypherpunks. * I picked up a modified version from the news.
* The copyright notice does not apply to that code.
*/
...and the header of the rc4 implementation,
/**
* 'Alleged RC4' Source Code picked up from the news.
* From: [EMAIL PROTECTED] (John L. Allen)
* Newsgroups: comp.lang.c
* Subject: Shrink this C code for fame and fun
* Date: 21 May 1996 10:49:37 -0400
*/
...were there basically because:
1)In 1997 I was not sure what could happen if I distribute
software
using (any implementation of) the rc4 algorithm.
I don't want the NSA of RSA people knock my door.
2)To state that somebody published an implementation before me.
3)To acknowledge that initial implementation.
Today, and being stricter with what I write, both comments could
be rewritten such as something similar to:
/**
* This software contains an ad hoc version of the 'Alleged RC4' algorithm.
* The original source code was published on the Net by a group of
cypherpunks. * A modified version was picked up from the news:
*From: [EMAIL PROTECTED] (John L. Allen)
*Newsgroups: comp.lang.c
*Subject: Shrink this C code for fame and fun
*Date: 21 May
Bug#335278: shc -- #335278 broken packaging -- non-DD NMU prepared
On Friday 07 July 2006 18:54, Francisco Rosales wrote: --cut-- Hi, I would add 'and is licensed also under GPL' or you think it is far too much as clarification. No problem. Thanks for your time. I really appreciate that ! Please, check the file: http://www.datsi.fi.upm.es/~frosal/sources/shc-3.8.6_shc.c.gz It contains the following message and the previous messages have been removed. Please, check the file an tell me if it is all right. /** * This software contains an ad hoc version of the 'Alleged RC4' algorithm, * which was anonymously posted on sci.crypt news by cypherpunks on Sep 1994. * * My implementation is a complete rewritten of the one found in We have a little typo here ... s/rewritten/rewrite/ * an unknown-copyright (283 characters) version picked up from: *From: [EMAIL PROTECTED] (John L. Allen) *Newsgroups: comp.lang.c *Subject: Shrink this C code for fame and fun *Date: 21 May 1996 10:49:37 -0400 * And it is licensed also under GPL. */ Looks pretty good to me. Alexander, What do you think ? Comments ? I will prepare a 3.8.6 package when it gets done and released upstream. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335278: shc -- #335278 broken packaging -- non-DD NMU prepared
On Saturday 01 July 2006 20:06, Alexander Schmehl wrote:
Hi!
* George Danchev [EMAIL PROTECTED] [060701 15:20]:
I hope that Alexander Schmehl is still willing to check it out and
upload. Should anything still to be corrented I'm willing to do so. The
new RC4 implementation is documented in debian/copyright, along with the
match script as well (that were the points Alexnder raised in his last
reviewing).
Currently I'm on the road without my gpg-key, so I can't upload anythign
right now. I'll be back on Tuesday evening / wednesday morning will
check it then (if I don't forget it, might be a got idea to send me an
reminder ;)
Alexander,
I found a compromise fix for the above break as to force the resulting
binary
(that produced by shc) to be always redistributable. You can dget packages
from: ftp://ftp.logos-bg.net/debian-addons-bg/dists/unstable/shc/
--
pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
diff -Naur shc-3.8.3/shc.c shc-3.8.3.dfsg/shc.c
--- shc-3.8.3/shc.c 2005-06-28 22:28:52.0 +0300
+++ shc-3.8.3.dfsg/shc.c 2006-07-04 12:35:06.0 +0300
@@ -1,10 +1,27 @@
/* shc.c */
-/**
- * This software contains the 'Alleged RC4' source code.
- * The original source code was published on the Net by a group of cypherpunks.
- * I picked up a modified version from the news.
- * The copyright notice does not apply to that code.
+/*-
+ * This software contains a clean-room implementation of Alleged RC4 (ARC4).
+ * The following copyright notice and license apply only to that code.
+ *
+ * Copyright (c) 2006 Brian M. Carlson
+ *
+ * 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; version 2 of the License, dated June
+ * 1991, with MD5 hash 8ca43cbc842c2336e835926c2166c28b.
+ *
+ * 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:
+ * Free Software Foundation, Inc.
+ * 51 Franklin St, Fifth Floor
+ * Boston, MA 02110-1301
+ * USA
*/
static const char my_name[] = shc;
static const char version[] = Version 3.8.3;
@@ -125,63 +142,85 @@
#include string.h,
#include time.h,
#include unistd.h,
-,
-/**,
- * 'Alleged RC4' Source Code picked up from the news.,
- * From: [EMAIL PROTECTED] (John L. Allen),
- * Newsgroups: comp.lang.c,
- * Subject: Shrink this C code for fame and fun,
- * Date: 21 May 1996 10:49:37 -0400,
+/*-,
+ * This software contains a clean-room implementation of Alleged RC4.,
+ * The following copyright notice and license apply only to that code.,
+ *,
+ * Copyright (c) 2006 Brian M. Carlson,
+ * ,
+ * 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; version 2 of the License, dated June,
+ * 1991, with MD5 hash 8ca43cbc842c2336e835926c2166c28b.,
+ * ,
+ * 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:,
+ * Free Software Foundation, Inc.,
+ * 51 Franklin St, Fifth Floor,
+ * Boston, MA 02110-1301,
+ * USA,
+ *,
+ * In addition, as a special exception, you may deal in this software as,
+ * part of a program produced by shc (the shell script compiler) without,
+ * restriction.,
+ *,
+ * Note that people who make modified versions of this software are not,
+ * obligated to grant this special exception for their modified versions;,
+ * it is their choice whether to do so. The GNU General Public License,
+ * gives permission to release a modified version without this exception;,
+ * this exception also makes it possible to release a modified version,
+ * which carries forward this exception.,
*/,
,
-static unsigned char stte[256], indx, jndx, kndx;,
+struct crypto_rc4_s,
+{,
+ unsigned char s[256];,
+ unsigned char i;,
+ unsigned char j;,
+} ctxo, *ctx=ctxo;,
+,
+#define SWAP(x, y) do{unsigned char tmp;tmp=(x);(x)=(y);(y)=tmp;}while (0),
,
-/*,
- * Reset arc4 stte. ,
- */,
void stte_0(void),
{,
- indx = jndx = kndx = 0;,
- do {,
- stte[indx] = indx;,
- } while (++indx);,
+ int i;,
+,
+ for (i=0; i256; i++),
+ ctx-s[i]=i;,
+ ctx-i=ctx-j=0;,
},
,
-/*,
- * Set key. Can be used more
Bug#335278: shc -- #335278 broken packaging -- non-DD NMU prepared
On Wednesday 05 July 2006 17:16, Francisco Rosales wrote:
Hello all,
Unfortunately I face a break with the new GPL'ed ARC4 implementation. The
patch for that implementation for shc 3.7 along with some rc4 tests is
found at:
Please, do not use the shc 3.7 rc4 implementation. It has a
problem. In rc4, the global jndx = 0; is reset to 0 for each chuck of data
encrypted. It must not be done so, jndx = 0; must be set only at
initialization (in state_0).
This bug was fixed in shc 3.8.
Well we start off with 3.7 because it is currently in Debian. The main problem
is the rc4 implementation which has no copyright attached. That's the reason
we started replacing it with a clean-room GPL'ed implementation and finally
make the program licensed free and consistent. Otherwise it will be removed
from the archive because of legal issues.
For the time being as for 3.7 version with the new GPL'ed rc4 implementation I
forced intentionaly relax/redistributable binary to be created to overpass
the above 'shell has changed'. I agree, it is far from being perfect.
You can find more information at:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=335278
As you have seen, I have implemented the initialization stage with
two functions, not one (stte_0 and key). The reason is that I want to be
able to apply more than one password, using key fuction several times.
That was what puzzled me a lot in the first place, but seems is the right way
to go.
/* 3.8.5 */
I failed to find 3.8.5 version at http://www.datsi.fi.upm.es/~frosal/sources/
and the rows listed below are not from the last version found 3.8.3.
851 stte_0();
852 key(pswd, pswd_z);
...
862 key(chk1, chk1_z);
...
867 if (indx key_with_file(kwsh)) {
...
875 key(chk2, chk2_z);
One stte_0 but four key calls. One is key_with_file which makes
the rest of the encryption to depend on some signature of a given file.
This is the reason of the message (and the method to detect)
shell has changed!.
(( You cannot make the change:
- key(control, sizeof(control));,
+ key(\control\, sizeof(control));,
because it changes totally the pretended behaviour ))
Oh, that is a forgotten temporal compiler shut-up which will be reverted. The
first arg of the key function should be changed to void *str, but I rather go
for const char *str as more safe one, which couse a little redesign though.
In shc-3.8.3.diff your implementation of key do not remember the
last index exchanged (kndx) and do not uses len to bound k[] indexing to
its real length.
Well this comes as a consequence of the above misunderstanding. I have to look
more closely to that one.
http://crustytoothpaste.ath.cx/~bmc/files/free/crypto.pax.bz2
I still need to resolve why strcmp(TEXT_chk2, chk2) is put there, which
succeeds causing the following break:
As I have already stated, key_with_file (and the ability to use
key _incrementally_ several times) permits to make the encryption
dependent on some details of a given file. So the decryption of chk2
will change if the signature of the given file changes, in other words
if the shell has changed!.
Hm, I'm a little bit confused by the message like shell has changed, should
it be more straightforward ... 'signature has changed' or 'decryption
failed' ?
Perhaps my implementation of arc4 is more add-hoc than yours, but,
please, I see no reason to break the described behaviour.
I agree with you. OTOH, in the light of having bits with clear license only we
should replace the unknown-license cypherpunks code with a license-clear
implementation. I'll try to have a look and try to achieve what you describe
above. The best solution im my opinion will be a new upstream version of shc
with license-clear arc4 implementation.
--
pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335278: shc -- #335278 broken packaging -- non-DD NMU prepared
On Saturday 01 July 2006 20:06, Alexander Schmehl wrote:
Hi!
* George Danchev [EMAIL PROTECTED] [060701 15:20]:
I hope that Alexander Schmehl is still willing to check it out and
upload. Should anything still to be corrented I'm willing to do so. The
new RC4 implementation is documented in debian/copyright, along with the
match script as well (that were the points Alexnder raised in his last
reviewing).
Currently I'm on the road without my gpg-key, so I can't upload anythign
right now. I'll be back on Tuesday evening / wednesday morning will
check it then (if I don't forget it, might be a got idea to send me an
reminder ;)
Unfortunately I face a break with the new GPL'ed ARC4 implementation. The
patch for that implementation for shc 3.7 along with some rc4 tests is found
at:
http://crustytoothpaste.ath.cx/~bmc/files/free/crypto.pax.bz2
I still need to resolve why strcmp(TEXT_chk2, chk2) is put there, which
succeeds causing the following break:
$ ./shc -f test.csh
$ ./test.csh.x
$ ./test.csh.x: No such file or directory: shell has changed!
I attached a similar patch for shc 3.8.3, but the following occurs with the
above test.csh test:
$./test.csh.x
$./test.csh.x: location has changed!
--
pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
diff -Naur shc-3.8.3/shc.c shc-3.8.3.dfsg/shc.c
--- shc-3.8.3/shc.c 2005-06-28 22:28:52.0 +0300
+++ shc-3.8.3.dfsg/shc.c 2006-07-04 12:35:06.0 +0300
@@ -1,10 +1,27 @@
/* shc.c */
-/**
- * This software contains the 'Alleged RC4' source code.
- * The original source code was published on the Net by a group of cypherpunks.
- * I picked up a modified version from the news.
- * The copyright notice does not apply to that code.
+/*-
+ * This software contains a clean-room implementation of Alleged RC4 (ARC4).
+ * The following copyright notice and license apply only to that code.
+ *
+ * Copyright (c) 2006 Brian M. Carlson
+ *
+ * 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; version 2 of the License, dated June
+ * 1991, with MD5 hash 8ca43cbc842c2336e835926c2166c28b.
+ *
+ * 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:
+ * Free Software Foundation, Inc.
+ * 51 Franklin St, Fifth Floor
+ * Boston, MA 02110-1301
+ * USA
*/
static const char my_name[] = shc;
static const char version[] = Version 3.8.3;
@@ -125,63 +142,85 @@
#include string.h,
#include time.h,
#include unistd.h,
-,
-/**,
- * 'Alleged RC4' Source Code picked up from the news.,
- * From: [EMAIL PROTECTED] (John L. Allen),
- * Newsgroups: comp.lang.c,
- * Subject: Shrink this C code for fame and fun,
- * Date: 21 May 1996 10:49:37 -0400,
+/*-,
+ * This software contains a clean-room implementation of Alleged RC4.,
+ * The following copyright notice and license apply only to that code.,
+ *,
+ * Copyright (c) 2006 Brian M. Carlson,
+ * ,
+ * 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; version 2 of the License, dated June,
+ * 1991, with MD5 hash 8ca43cbc842c2336e835926c2166c28b.,
+ * ,
+ * 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:,
+ * Free Software Foundation, Inc.,
+ * 51 Franklin St, Fifth Floor,
+ * Boston, MA 02110-1301,
+ * USA,
+ *,
+ * In addition, as a special exception, you may deal in this software as,
+ * part of a program produced by shc (the shell script compiler) without,
+ * restriction.,
+ *,
+ * Note that people who make modified versions of this software are not,
+ * obligated to grant this special exception for their modified versions;,
+ * it is their choice whether to do so. The GNU General Public License,
+ * gives permission to release a modified version without this exception;,
+ * this exception also makes it possible to release a modified version,
+ * which carries forward this exception.,
*/,
,
-static unsigned char stte[256], indx, jndx, kndx;,
+struct crypto_rc4_s,
+{,
+ unsigned char s[256];,
+ unsigned char i;,
+ unsigned char j;,
+} ctxo, *ctx=ctxo;,
+,
+#define SWAP(x, y) do{unsigned char tmp;tmp
Bug#335278: shc -- #335278 broken packaging -- non-DD NMU prepared
On Thursday 29 June 2006 01:10, [EMAIL PROTECTED] wrote: On Wed, Jun 28, 2006 at 12:58:59AM +0200, Alexander Schmehl wrote: [ Cc-ing the bug report, so we have it in the bts, too ] Hi! - Now the real problem: shc.c Lookit at it we have: /** * This software contains the 'Alleged RC4' source code. * The original source code was published on the Net by a group of cypherpunks. * I picked up a modified version from the news. * The copyright notice does not apply to that code. */ As far as I remember, the general belief is that 'Alleged RC4' was in fact leaked intentionnaly by RSA inc. itself (which designed RC4). So much for the group of cypherpunks. Right, ARC4 algorythm is also used in ssh. So the algorythm itself is not a problem. /** * 'Alleged RC4' Source Code picked up from the news. * From: [EMAIL PROTECTED] (John L. Allen) * Newsgroups: comp.lang.c * Subject: Shrink this C code for fame and fun * Date: 21 May 1996 10:49:37 -0400 */ I think it should be easy to replace that code by a DFSG-free implementation of RC4. Openssl include one. I'm afraid that I can not use OpenSSL licensed code into GPL program (shc) without a special OpenSSL exception given from the shc's upstream, which unfortunately did not respond to any mail sent yet. Also I'm a litle bit scared to reimplement that myself - I might introduce hell of bugs at least ;-) ... deviating from upstream for the matter of that is not a good idea also. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335278: shc -- #335278 broken packaging -- non-DD NMU prepared
On Wednesday 28 June 2006 01:58, Alexander Schmehl wrote: Let's start with something simple: - According to the header, the script match was [EMAIL PROTECTED] It has no explicit license, but is so easy and short, that I don't think one could claim copyright for that (the german word for that would be Schöpfungshöhe). I don't think the missing license of that script is a problem, but the author should be mentioned in the copyright file. Done. - Now the real problem: shc.c Lookit at it we have: /** * This software contains the 'Alleged RC4' source code. * The original source code was published on the Net by a group of cypherpunks. * I picked up a modified version from the news. * The copyright notice does not apply to that code. */ and: /** * 'Alleged RC4' Source Code picked up from the news. * From: [EMAIL PROTECTED] (John L. Allen) * Newsgroups: comp.lang.c * Subject: Shrink this C code for fame and fun * Date: 21 May 1996 10:49:37 -0400 */ This post can be found at [1]. Well... no license for this code, no implicit or explicit grant of any rights... not even an make whatever you want with this code. I don't think we can distribute this, and I don't think this bug is fixed yet ;) You mentioned you allready mailed upstream, but has anyone tried to contact the original poster of that code? Ask him, if he put his code to public domain when posting it to that newsgroup or if he could license it under GPL. That would the solve the problem and everything would be fine. Seems that Northrop Grumman's corporate mail server does not remember the guy in question: - Transcript of session follows - ... while talking to gateway.grumman.com.: DATA 550 5.0.0 [EMAIL PROTECTED]... We do not accept mail from spammers. 550 5.1.1 [EMAIL PROTECTED]... User unknown 503 5.0.0 Need RCPT (recipient) Now what ... wait for 20 (?) years in hope that nobody will claim a copyright for that piece of code so that we can have it in PD ? -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
Bug#362806: depends on adns not found in Sid
Hello, Also chiark-tcl/1.0.0 seems to build-depend (at least) on a newer version of libadns1-dev (adns-1.3.tar.gz) which is not available in Sid. The function adns_init_logfn is used in chiark-tcl-1.0.0/adns/adns.c which is found to be in adns.h of adns-1.3.tar.gz, but not in the packages currently in Sid. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#375404: cheops should not build-depend on a virtual package
Hello, cheops should not build-depend on a virtual package since that prevents succesful autobuilding. Better yet, just build-depend on libsnmp9-dev. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335274: patch does not apply cleanly
Hello Paul, your patch seems to be incomplete ? /matanza-0.13$ patch -p1 --dry-run /tmp/matanza_0.13-3.2.diff patching file debian/docs patching file debian/control Hunk #1 FAILED at 2. 1 out of 1 hunk FAILED -- saving rejects to file debian/control.rej patching file debian/rules Hunk #1 FAILED at 1. 1 out of 1 hunk FAILED -- saving rejects to file debian/rules.rej patching file debian/watch patching file debian/changelog Hunk #1 FAILED at 1. 1 out of 1 hunk FAILED -- saving rejects to file debian/changelog.rej patching file debian/matanza-ai.1 patching file debian/matanza.1 Hunk #1 FAILED at 1. 1 out of 1 hunk FAILED -- saving rejects to file debian/matanza.1.rej patching file debian/manpages patching file debian/compat patching file debian/copyright patching file debian/examples -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#375894: kiax DFSGness not taken seriously
On Wednesday 28 June 2006 21:25, Santiago Garcia Mantinan wrote: Package: kiax Version: 0.8.51.dfsg-1-1 Severity: serious Hi! Hello, We had a package that we knew was dfsg compliant, I had removed the lib stuff which had several license problems because of that and then renamed it to dfsg as we had agreed that it was dfsg compliant, now... I found of a bad taste that a new dfsg package was uploaded, as I had objected to the DFSGness of this new package, today I have looked at it more carefully and I found out what had been said before, please somebody correct me if I'm wrong, but... Unfortunaly there was a bug in the sed'ish code which was not ready to cope with dfsg-[0-9]-[0-9]. I've just fixed that in svn. That last 0.8.51.dfsg-1-1 changelog entry caused that repackaing faulire and failed tarball sanitization because we did realized (hi Mark ;-) we need a new dfsg tarball version (-1-1) after the upload has been rejected by debian installer because of the md5sum mismatch: http://lists.alioth.debian.org/pipermail/pkg-voip-maintainers/2006-June/005126.html That was not intended, that was a programming mistake. 1- the echo cancellation stuff doesn't have a license we can use to say it's free, this has been discussed before (see Emil Stoyanov [1] message to the list) and I didn't read anybody saying that it was no longer like that aec_nlms directory is now properly deleted from kiax_0.8.51.dfsg-2.orig.tar.gz 2- the iLBC stuff is stil non-free as it used to be that way and it hasn't changed its license. iLBC directory is now properly deleted from kiax_0.8.51.dfsg-2.orig.tar.gz The rest of kiax/lib/ is really LGPL'ed. Other than that, having a program include on its sources at least 4 of our already packaged libs and use those sources to compile them statically instead of using our tested libs seems a really bad way of packaging something. That's true, but kiax is not ready to use these our libs as of yet. We have 3 choices: * keep it as it is with iLBC and aec_nlms removed from upstream tarball. This is: 2a4d5266f5d312ac3f4ba6cea807f2e0 kiax_0.8.51.dfsg-2.orig.tar.gz in that case we have Echo Cancellation. * revert to the version in testing - no Echo Cancellation, but our libs are used. * remove kiax from the archive ;-) So... after having a package that could go into Debian because it was free, we have now come back to the sources that our ftp masters had rejected because they were non-free. This really seems nonsense to me, I don't know if I have to take this as a joke or what, who didn't read the list or didn't at least didn't look at the sources that he was packaging, or... I just can't explain this, please somebody explain this for me. I had to check twice that what I was looking at were the sources coming from cc39dab9cb55afbe9722a6f4ad2bb5f0 kiax_0.8.51.dfsg-1.orig.tar.gz and not from the old non-free version we used to have, and in fact all non-free stuff is in there. the correct one should have been: 2a4d5266f5d312ac3f4ba6cea807f2e0 kiax_0.8.51.dfsg-2.orig.tar.gz I hope I'm missing something with all this, otherwise I don't know what we are playing at, this seems completely nonsense and a Debian developer should be more cautious with what he uploads at least once he knows there are problems with licenses on some parts of a software. Really this was not intended. I hope that now it is really properly corrected. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#375894: kiax DFSGness not taken seriously
On Wednesday 28 June 2006 22:58, Mark Purcell wrote: -- Agreed we should remove this EC patch until it is DFSG licenced. Apart from the blatant sed'ish bug (which was not inteneded, and never met before this special case arose) our EC patch is not the same as the Tipic one. Everything in ours tarball in kiax/lib/ is LGPL'ed, please look for yourself in the files. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328200: Problems with ntp
On Wednesday 14 September 2005 10:03, Steve Langasek wrote: On Wed, Sep 14, 2005 at 01:07:30AM -0400, Nathanael Nerode wrote: I just discovered that the ntp source is a nest of licensing problems. The arlib subdir isn't distributable. Neither is the entire libparse subdir, or anything else by Frank Kardel. I'm not actually sure it will build without these bits. So I guess NTP should be removed from Debian. It's not very maintained anyhow, having multiple RC bugs open for quite a while. What are you going to replace it with? AFAIK, ntp is the only package we have in Debian which supports useful clock synchronization, which is essential for a number of other services (e.g., Kerberos). I've never tested openntpd, but it is the obvious replacement in case of legal problems with ntp and it has been released with sarge. Obviously we can't ship non-distributable code, but I'm not going to remove ntp from testing just because it appears at first blush to be inconsistently licensed. The maintainers should have a chance to clear up this question first. Agreed. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
