Menu
▾
▴
kreatecd-devel
You can subscribe to this list here.
| 2000 |
Jan
(1) |
Feb
(4) |
Mar
(5) |
Apr
(2) |
May
(2) |
Jun
(4) |
Jul
|
Aug
(17) |
Sep
(2) |
Oct
|
Nov
(1) |
Dec
(60) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(15) |
Feb
(73) |
Mar
(49) |
Apr
(38) |
May
(8) |
Jun
(4) |
Jul
(45) |
Aug
(53) |
Sep
(9) |
Oct
(35) |
Nov
(20) |
Dec
(1) |
| 2002 |
Jan
(21) |
Feb
(5) |
Mar
(2) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
(2) |
|
From: Alexander F. <Ale...@gm...> - 2001-08-19 12:08:43
|
On Sunday, 19. August 2001 10:15, Niels Reedijk wrote: > Hi, > > I've fixed the doc and added a backdoor for KDE 2.1.1 and back. But I can't > seem to get the makefile right. Would someone please care to fix it? > What is the exact problem with the Makefile. On KDE 2.2 it compiles without problems. Do I have to install KDE 2.1.1 to fix it? Alexander |
|
From: Joseph W. <jo...@bi...> - 2001-08-19 12:06:05
|
Hi > > What I want to do at install time is: > a) remove the common subdir > b) install our common subdir > > the common subdirs lack some things we need. > Why do we need to change the common subdir ? Should images, ..... not stay in the applications documentation directory ? Kind regards Joseph Wenninger |
|
From: Niels R. <n.r...@pl...> - 2001-08-19 12:01:56
|
Op zondag 19 augustus 2001 13:55, schreef u: > If meinproc is found then doc/en/kreatecd/index.docbook is used, if > meinproc is not found, but kdb2html, than in tries to run it with > index.docbook, if there is not alreay a HTML directory containing files. -> > I believe it should be enough, if you put your html and other files into > doc/en/kreatecd/HTML/ and you don't need too change Makefile.am. > > It could be that I only told nonsense in the above lines, but it is a while > back I changed the am_edit (and friends) file and this file is not nice to > read and easy to understand I can't really reproduce this behaviour... What I want to do at install time is: a) remove the common subdir b) install our common subdir the common subdirs lack some things we need. Niels -- Ga eens wat vaker met de metro |
|
From: Joseph W. <jo...@bi...> - 2001-08-19 11:40:17
|
Hi On Sunday 19 August 2001 10:15, you wrote: > Hi, > > I've fixed the doc and added a backdoor for KDE 2.1.1 and back. But I can't > seem to get the makefile right. Would someone please care to fix it? > > Niels I'm not sure, and I can't test it, because I have only KDE CVS head on my system, but I think the patch I did some time ago to make kreatecd configure and compile on KDE >=2.2 Alpha1 has a backdoor for older version. The code which does this handling is in admin/am_edit. If meinproc is found then doc/en/kreatecd/index.docbook is used, if meinproc is not found, but kdb2html, than in tries to run it with index.docbook, if there is not alreay a HTML directory containing files. -> I believe it should be enough, if you put your html and other files into doc/en/kreatecd/HTML/ and you don't need too change Makefile.am. It could be that I only told nonsense in the above lines, but it is a while back I changed the am_edit (and friends) file and this file is not nice to read and easy to understand Kind regards Joseph Wenninger |
|
From: Niels R. <n.r...@pl...> - 2001-08-19 08:18:28
|
Hi, I've fixed the doc and added a backdoor for KDE 2.1.1 and back. But I can't seem to get the makefile right. Would someone please care to fix it? Niels -- Ga eens wat vaker met de metro |
|
From: Alexander F. <Ale...@gm...> - 2001-08-18 18:30:10
|
On Saturday, 18. August 2001 10:05, Niels Reedijk wrote: > Op zaterdag 18 augustus 2001 00:53, schreef u: > > OK, I've taken your constructive comments and merged it into the following: > > KreateCD 1.1a1 (internal KreateCD 1.0.7) > ======================================== > - a current snapshot > - this snapshot is marked unstable, to receive bug reports > TAGPOINT: the tag KREATECD_1_0_7_RELEASE is put upon the files > PROPOSED DATE: Tomorrow (19/08/2001), tagged at 20:00 Dutch time (don't > know, either 18:00 or 19:00 GMT, although I believe we're all in the same > timezone.) TODO: - last minute fixes for the document (on my stack...) > - anything you specify > That's ok. There is a litlle bit of work I want to do before this release but I think I can manage that. We don't have much time left to test this release - but we only have to avoid that it is totally broken Alexander |
|
From: Joseph W. <jo...@bi...> - 2001-08-18 13:57:20
|
Hi > This article really got me thinking. The > "This program is free software; you can redistribute it and/or modify > it under the terms of the GNU General Public License as published by > the Free Software Foundation; either version 2 of the License, or > (at your option) any later version." > > line is quite dangerous. what if the FSF (or whoever owns the license) > decides to release a new version with a commercial clausule (so the fSF may > sell commercial licenses...) we can't do anything about it. > I don't know about other countries, but as far as I know these lines aren't effective at least in Germany and Austria. (In America they workd). In Germany/Austria "or (at your option) any later version." is not backed by law -> you will have to explicitly specify, if you want the user to be able to use GPL 3, ..... At least in Germany/Austria, there are some otther things not backed by the law. eg the paragraph talking about no liabilty in general. The author can be held liable in Germany/Austra, althought he puts this lines into the licencse. (eg if he knows about a severe problem, which eg can cause data loss, but doesn't inform the user that this possibility exists, or if he WANTS to damage something/someone/... with her/his software) I'm no lawyer though, just heard something about it at LinuxTag in Stuttgart. Joseph Wenninger |
|
From: Niels R. <n.r...@pl...> - 2001-08-18 12:02:14
|
Op zaterdag 18 augustus 2001 00:53, schreef u:
OK, I've taken your constructive comments and merged it into the following:
KreateCD 1.1a1 (internal KreateCD 1.0.7)
========================================
- a current snapshot
- this snapshot is marked unstable, to receive bug reports
TAGPOINT: the tag KREATECD_1_0_7_RELEASE is put upon the files
PROPOSED DATE: Tomorrow (19/08/2001), tagged at 20:00 Dutch time (don't know,
either 18:00 or 19:00 GMT, although I believe we're all in the same timezone.)
TODO: - last minute fixes for the document (on my stack...)
- anything you specify
KreateCD 1.1 B1 (internal KreateCD 1.0.8)
=========================================
- All features wanted present:
* trackviewpart
* kill the wrong error messages when someone "cuts" a mp3 or
vorbis file on the fly. They don't stop the burning process - they are just
confusing.
* improve the audio options dialog
* a change CD dialog when using the same CD drive for reading and writing
- Intended for test use: tell this to the users
- No message freeze whatsoever, also, documentation not important
BRANCHPOINT: The KREATECD_1_1_BRANCH is created (intended for bug fixes
only) TAGPOINT: the tag KREATECD_1_0_8_RELEASE is put upon the files
PROPOSED DATE: Saturday 1st of September 2001
KreateCD 1.1 RC (internal KreateCD 1.0.9)
=========================================
- Feature freeze, as well as a message freeze.
- Basic documentation written
- Bugs fixed
* We should burn CD-Rs of the most common types (mp3,ogg,wav , 1:1 copies,
ISO9660, multisession) in on-the-fly and normal mode too before we release
1.0.9. I have a CD-RW here and will run the complete set - but it would be
great if a large part of the tests could be run on other hardware.
TAGPOINT: (in branch KREATECD_1_1_BRANCH) KREATECD_1_0_9_RELEASE
PROPOSED DATE: Saturday 22th of September 2001 (so three weeks for
bug-reports)
Alexander's birthday present ( aka KreateCD 1.1)
==================================
- Translations, Documentation, bugfixes...
TAGPOINT: (in branch KREATECD_1_1_BRANCH) KREATECD_1_1_RELEASE
PROPOSED DATE: Saturday 13th of October 2001 (so another three weeks)
> BTW, I get some complaints from meinproc at the moment.
Me too, under construction...
/* Roadmap: *
* November/December 2001: KreateCD 1.1.1 *
* April 2002: KreateCD 2.0 (based on KDE 3.0) */
> Aug 2001: Release of KDE 2.2
> Sep 2001: Release of KDE 2.2.1
> Okt 2001: Development release, KDE 2.89 aka Qrash3.
> Nov 2001: KDE 3.0beta1
> Dec 2001: KDE 3.0beta2
> Jan 2002: KDE 3.0 final
That above was said on kde-core-devel. I believe it will take a month or two
more, so I think april is a great guess :-)
Niels
--
Ga eens wat vaker met de metro
|
|
From: Alexander F. <Ale...@gm...> - 2001-08-17 22:59:49
|
On Friday, 17. August 2001 19:58, Niels Reedijk wrote: > Hi guys, > > In my eyes it is time to show the world what we have accomplished, so I > propose this release schedule. Please comment, flame, kill me for it. > I thought about these great features which we added since 1.0.0 too. Actually most of the features which we want to have in 1.1.0 are finished or nearly finished. If that would be not the case I would even think about releasing a "developer snapshot". Much days have passed since 1.0.0 - too much. > KreateCD 1.1 B1 (internal KreateCD 1.0.8) > ========================================= > - All features wanted present ( I want to finish trackview) - I have to kill the wrong error messages when someone "cuts" a mp3 or vorbis file on the fly. They don't stop the burning process - they are just confusing. - I want to improve the audio options dialog - a change CD dialog when using the same CD drive for reading and writing What top tasks have still to be done? > - Intended for test use: tell this to the users > - No message freeze whatsoever, also, documentation not important BTW, I get some complaints from meinproc at the moment. > BRANCHPOINT: The KREATECD_1_1_BRANCH is created (intended for bug fixes > only) TAGPOINT: the tag KREATECD_1_0_8_RELEASE is put upon the files > PROPOSED DATE: 28th of August (yes, this year :-) I hope we can get the rest of features ready in time. But I want to make a release now ASAP. > > KreateCD 1.1 RC (internal KreateCD 1.0.9) > - Feature freeze, as well as a message freeze. > - Basic documentation written > - Bugs fixed > TAGPOINT: (in branch KREATECD_1_1_BRANCH) KREATECD_1_0_9_RELEASE > PROPOSED DATE: third week of September (so three weeks for bug-reports) > We should burn CD-Rs of the most common types (mp3,ogg,wav , 1:1 copies, ISO9660, multisession) in on-the-fly and normal mode too before we release 1.0.9. I have a CD-RW here and will run the complete set - but it would be great if a large part of the tests could be run on other hardware. > KreateCD 1.1 final ( KreateCD 1.1) > - Translations, Documentation, bugfixes... > TAGPOINT: (in branch KREATECD_1_1_BRANCH) KREATECD_1_1_RELEASE > PROPOSED DATE: second week of October (so another three weeks) > That is one week before my birthday :) > Roadmap: > November/December 2001: KreateCD 1.1.1 > April 2002: KreateCD 2.0 (based on KDE 3.0) When is the best point to switch to KDE 3.0 CVS? after we branched for 1.1.0 the HEAD branch could be used for this. If we are not too busy with bug fixing we could switch before 1.1.0 - if KDE HEAD is stable enough. Are there any schedules for KDE 3.0 final yet? Alexander |
|
From: Alexander F. <Ale...@gm...> - 2001-08-17 22:18:07
|
On Friday, 17. August 2001 20:05, Niels Reedijk wrote: > My compiler was very clear about rootwrapper ... > rootwrapper.c:1: parse error before `/' Oops. I should convert C++ comments into C comments :) Alexander |
|
From: Niels R. <n.r...@pl...> - 2001-08-17 21:06:18
|
Hi, Read this: http://linuxtoday.com/news_story.php3?ltsn=2001-08-17-002-20-NW-CY This article really got me thinking. The "This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version." line is quite dangerous. what if the FSF (or whoever owns the license) decides to release a new version with a commercial clausule (so the fSF may sell commercial licenses...) we can't do anything about it. What I want to say is, that I'm really shocked by this. I'm not saying that we actually should change license :-) (Though I'm thinking about removing the "or (at your option) any later version" clause). what do you think? Niels Reedijk -- Ga eens wat vaker met de metro |
|
From: Joseph W. <jo...@bi...> - 2001-08-17 20:07:28
|
Hi > > In my eyes it is time to show the world what we have accomplished, so I > propose this release schedule. Please comment, flame, kill me for it. > > KreateCD 1.1 B1 (internal KreateCD 1.0.8) > ========================================= > PROPOSED DATE: 28th of August (yes, this year :-) > > KreateCD 1.1 RC (internal KreateCD 1.0.9) > PROPOSED DATE: third week of September (so three weeks for bug-reports) > > KreateCD 1.1 final ( KreateCD 1.1) > PROPOSED DATE: second week of October (so another three weeks) > > Roadmap: > November/December 2001: KreateCD 1.1.1 > April 2002: KreateCD 2.0 (based on KDE 3.0) Sounds good to me, I think I'll find some time to hack on kreatecd next to learning till 28th. The rest of the roadmap sound reasonable too. Alexander ? Kind regards Joseph Wenninger |
|
From: Niels R. <n.r...@pl...> - 2001-08-17 18:07:57
|
My compiler was very clear about rootwrapper ...
rootwrapper.c:1: parse error before `/'
In file included from rootwrapper.c:13:
/usr/include/unistd.h:310: parse error before `size_t'
/usr/include/unistd.h:313: parse error before `size_t'
/usr/include/unistd.h:423: parse error before `size_t'
In file included from rootwrapper.c:13:
/usr/include/unistd.h:513: parse error before `confstr'
/usr/include/unistd.h:513: parse error before `size_t'
/usr/include/unistd.h:513: ANSI C forbids data definition with no type or
storage class
/usr/include/unistd.h:664: parse error before `size_t'
/usr/include/unistd.h:689: parse error before `size_t'
In file included from rootwrapper.c:13:
/usr/include/unistd.h:739: parse error before `size_t'
/usr/include/unistd.h:749: parse error before `size_t'
/usr/include/unistd.h:750: parse error before `size_t'
/usr/include/unistd.h:767: parse error before `size_t'
In file included from rootwrapper.c:14:
/usr/include/string.h:38: parse error before `size_t'
/usr/include/string.h:41: parse error before `size_t'
/usr/include/string.h:49: parse error before `size_t'
/usr/include/string.h:55: parse error before `size_t'
/usr/include/string.h:58: parse error before `size_t'
/usr/include/string.h:62: parse error before `size_t'
/usr/include/string.h:81: parse error before `size_t'
/usr/include/string.h:88: parse error before `size_t'
/usr/include/string.h:94: parse error before `size_t'
/usr/include/string.h:101: parse error before `strxfrm'
/usr/include/string.h:102: parse error before `size_t'
/usr/include/string.h:102: ANSI C forbids data definition with no type or
storage class
/usr/include/string.h:167: parse error before `strcspn'
/usr/include/string.h:168: ANSI C forbids data definition with no type or
storage class
/usr/include/string.h:171: parse error before `strspn'
/usr/include/string.h:172: ANSI C forbids data definition with no type or
storage class
/usr/include/string.h:218: parse error before `strlen'
/usr/include/string.h:218: ANSI C forbids data definition with no type or
storage class
/usr/include/string.h:233: parse error before `size_t'
/usr/include/string.h:238: parse error before `size_t'
/usr/include/string.h:242: parse error before `size_t'
/usr/include/string.h:245: parse error before `size_t'
/usr/include/string.h:248: parse error before `size_t'
/usr/include/string.h:276: parse error before `size_t'
In file included from /usr/include/string.h:359,
from rootwrapper.c:14:
/usr/include/bits/string2.h:396: parse error before `size_t'
/usr/include/bits/string2.h:401: parse error before `size_t'
/usr/include/bits/string2.h:402: warning: no previous prototype for
`__strcpy_small'
/usr/include/bits/string2.h: In function `__strcpy_small':
/usr/include/bits/string2.h:407: `__dest' undeclared (first use in this
function)
/usr/include/bits/string2.h:407: (Each undeclared identifier is reported only
once
/usr/include/bits/string2.h:407: for each function it appears in.)
/usr/include/bits/string2.h:408: `__srclen' undeclared (first use in this
function)
/usr/include/bits/string2.h:414: `__src0_2' undeclared (first use in this
function)
/usr/include/bits/string2.h:422: `__src0_4' undeclared (first use in this
function)
/usr/include/bits/string2.h:432: `__src4_2' undeclared (first use in this
function)
/usr/include/bits/string2.h:444: `__src4_4' undeclared (first use in this
function)
/usr/include/bits/string2.h:411: warning: unreachable code at beginning of
switch statement
/usr/include/bits/string2.h:448: warning: control reaches end of non-void
function
/usr/include/bits/string2.h: At top level:
/usr/include/bits/string2.h:873: parse error before `__strcspn_c1'
/usr/include/bits/string2.h:873: ANSI C forbids data definition with no type
or storage class
/usr/include/bits/string2.h:875: parse error before `__strcspn_c1'
/usr/include/bits/string2.h: In function `__strcspn_c1':
/usr/include/bits/string2.h:877: warning: ANSI C forbids nested functions
/usr/include/bits/string2.h:877: syntax error before `__result'
/usr/include/bits/string2.h:878: `__result' undeclared (first use in this
function)
/usr/include/bits/string2.h:881: warning: control reaches end of non-void
function
/usr/include/bits/string2.h: At top level:
/usr/include/bits/string2.h:883: parse error before `__strcspn_c2'
/usr/include/bits/string2.h:884: ANSI C forbids data definition with no type
or storage class
/usr/include/bits/string2.h:886: parse error before `__strcspn_c2'
/usr/include/bits/string2.h: In function `__strcspn_c2':
/usr/include/bits/string2.h:888: warning: ANSI C forbids nested functions
/usr/include/bits/string2.h:888: syntax error before `__result'
/usr/include/bits/string2.h:889: `__result' undeclared (first use in this
function)
/usr/include/bits/string2.h:893: warning: control reaches end of non-void
function
/usr/include/bits/string2.h: At top level:
/usr/include/bits/string2.h:895: parse error before `__strcspn_c3'
/usr/include/bits/string2.h:896: ANSI C forbids data definition with no type
or storage class
/usr/include/bits/string2.h:898: parse error before `__strcspn_c3'
/usr/include/bits/string2.h: In function `__strcspn_c3':
/usr/include/bits/string2.h:901: warning: ANSI C forbids nested functions
/usr/include/bits/string2.h:901: syntax error before `__result'
/usr/include/bits/string2.h:902: `__result' undeclared (first use in this
function)
/usr/include/bits/string2.h:906: warning: control reaches end of non-void
function
/usr/include/bits/string2.h: At top level:
/usr/include/bits/string2.h:928: parse error before `__strspn_c1'
/usr/include/bits/string2.h:928: ANSI C forbids data definition with no type
or storage class
/usr/include/bits/string2.h:930: parse error before `__strspn_c1'
/usr/include/bits/string2.h: In function `__strspn_c1':
/usr/include/bits/string2.h:932: warning: ANSI C forbids nested functions
/usr/include/bits/string2.h:932: syntax error before `__result'
/usr/include/bits/string2.h:934: `__result' undeclared (first use in this
function)
/usr/include/bits/string2.h:937: warning: control reaches end of non-void
function
/usr/include/bits/string2.h: At top level:
/usr/include/bits/string2.h:939: parse error before `__strspn_c2'
/usr/include/bits/string2.h:940: ANSI C forbids data definition with no type
or storage class
/usr/include/bits/string2.h:942: parse error before `__strspn_c2'
/usr/include/bits/string2.h: In function `__strspn_c2':
/usr/include/bits/string2.h:944: warning: ANSI C forbids nested functions
/usr/include/bits/string2.h:944: syntax error before `__result'
/usr/include/bits/string2.h:946: `__result' undeclared (first use in this
function)
/usr/include/bits/string2.h:949: warning: control reaches end of non-void
function
/usr/include/bits/string2.h: At top level:
/usr/include/bits/string2.h:951: parse error before `__strspn_c3'
/usr/include/bits/string2.h:952: ANSI C forbids data definition with no type
or storage class
/usr/include/bits/string2.h:954: parse error before `__strspn_c3'
/usr/include/bits/string2.h: In function `__strspn_c3':
/usr/include/bits/string2.h:956: warning: ANSI C forbids nested functions
/usr/include/bits/string2.h:956: syntax error before `__result'
/usr/include/bits/string2.h:958: `__result' undeclared (first use in this
function)
/usr/include/bits/string2.h:962: warning: control reaches end of non-void
function
/usr/include/bits/string2.h: In function `__strpbrk_c2':
/usr/include/bits/string2.h:991: `size_t' undeclared (first use in this
function)
/usr/include/bits/string2.h:991: parse error before `__s'
/usr/include/bits/string2.h:992: warning: control reaches end of non-void
function
/usr/include/bits/string2.h: In function `__strpbrk_c3':
/usr/include/bits/string2.h:1004: `size_t' undeclared (first use in this
function)
/usr/include/bits/string2.h:1004: parse error before `__s'
/usr/include/bits/string2.h:1005: warning: control reaches end of non-void
function
/usr/include/bits/string2.h: In function `__strsep_g':
/usr/include/bits/string2.h:1172: `size_t' undeclared (first use in this
function)
/usr/include/bits/string2.h:1172: parse error before `const'
/usr/include/bits/string2.h:1172: parse error before `const'
/usr/include/bits/string2.h:1172: parse error before `)'
/usr/include/bits/string2.h:1172: warning: unused variable `__a2'
/usr/include/bits/string2.h:1172: warning: unused variable `__a1'
/usr/include/bits/string2.h:1172: warning: unused variable `__a0'
/usr/include/bits/string2.h:1172: void value not ignored as it ought to be
In file included from /usr/include/bits/string2.h:1188,
from /usr/include/string.h:359,
from rootwrapper.c:14:
/usr/include/stdlib.h: At top level:
/usr/include/stdlib.h:528: parse error before `__size'
/usr/include/stdlib.h:530: parse error before `__nmemb'
In file included from /usr/include/string.h:359,
from rootwrapper.c:14:
/usr/include/bits/string2.h:1212: parse error before `size_t'
rootwrapper.c:17: warning: no previous prototype for `start_app'
rootwrapper.c:25: warning: no previous prototype for `fork_off'
rootwrapper.c: In function `main':
rootwrapper.c:44: `size_t' undeclared (first use in this function)
rootwrapper.c:44: parse error before `__s1_len'
rootwrapper.c:44: `__s1_len' undeclared (first use in this function)
rootwrapper.c:44: `__s2_len' undeclared (first use in this function)
rootwrapper.c:44: parse error before `const'
rootwrapper.c:44: parse error before `const'
rootwrapper.c:44: warning: left-hand operand of comma expression has no effect
rootwrapper.c:44: warning: left-hand operand of comma expression has no effect
rootwrapper.c:44: parse error before `const'
rootwrapper.c:44: parse error before `const'
rootwrapper.c:44: parse error before `)'
rootwrapper.c:44: `__result' undeclared (first use in this function)
rootwrapper.c:44: parse error before `:'
rootwrapper.c:44: warning: empty body in an if-statement
rootwrapper.c:44: `__s2' undeclared (first use in this function)
rootwrapper.c:44: warning: control reaches end of non-void function
rootwrapper.c: At top level:
rootwrapper.c:44: parse error before `)'
rootwrapper.c:44: warning: type defaults to `int' in declaration of `__result'
rootwrapper.c:44: `__result' used prior to declaration
rootwrapper.c:44: ANSI C forbids data definition with no type or storage class
rootwrapper.c:44: parse error before `}'
rootwrapper.c:44: conflicting declarations of `__result'
rootwrapper.c:44: `__result' previously declared here
rootwrapper.c:44: `__s1' undeclared here (not in a function)
rootwrapper.c:44: `argv' undeclared here (not in a function)
rootwrapper.c:44: initializer element is not constant
rootwrapper.c:44: parse error before `if'
rootwrapper.c:44: warning: type defaults to `int' in declaration of `__result'
rootwrapper.c:44: conflicting declarations of `__result'
rootwrapper.c:44: `__result' previously defined here
rootwrapper.c:44: ANSI C forbids data definition with no type or storage class
rootwrapper.c:44: parse error before `}'
rootwrapper.c:52: parse error before string constant
rootwrapper.c:52: warning: type defaults to `int' in declaration of `__result'
rootwrapper.c:52: ANSI C forbids data definition with no type or storage class
rootwrapper.c:52: parse error before `}'
rootwrapper.c:52: redefinition of `__result'
rootwrapper.c:44: `__result' previously defined here
rootwrapper.c:52: `__s2' undeclared here (not in a function)
rootwrapper.c:52: initializer element is not constant
rootwrapper.c:52: parse error before `if'
rootwrapper.c:52: warning: type defaults to `int' in declaration of `__result'
rootwrapper.c:52: conflicting declarations of `__result'
rootwrapper.c:52: `__result' previously defined here
rootwrapper.c:52: ANSI C forbids data definition with no type or storage class
rootwrapper.c:52: parse error before `}'
rootwrapper.c:52: warning: type defaults to `int' in declaration of `__result'
rootwrapper.c:52: ANSI C forbids data definition with no type or storage class
rootwrapper.c:52: parse error before `}'
rootwrapper.c:52: redefinition of `__result'
rootwrapper.c:52: `__result' previously defined here
rootwrapper.c:52: `__s1' undeclared here (not in a function)
rootwrapper.c:52: `argv' undeclared here (not in a function)
rootwrapper.c:52: initializer element is not constant
rootwrapper.c:52: parse error before `if'
rootwrapper.c:52: warning: type defaults to `int' in declaration of `__result'
rootwrapper.c:52: conflicting declarations of `__result'
rootwrapper.c:52: `__result' previously defined here
rootwrapper.c:52: ANSI C forbids data definition with no type or storage class
rootwrapper.c:52: parse error before `}'
rootwrapper.c:68: parse error before string constant
rootwrapper.c:68: warning: type defaults to `int' in declaration of `__result'
rootwrapper.c:68: ANSI C forbids data definition with no type or storage class
rootwrapper.c:68: parse error before `}'
rootwrapper.c:68: redefinition of `__result'
rootwrapper.c:52: `__result' previously defined here
rootwrapper.c:68: `__s2' undeclared here (not in a function)
rootwrapper.c:68: initializer element is not constant
rootwrapper.c:68: parse error before `if'
rootwrapper.c:68: warning: type defaults to `int' in declaration of `__result'
rootwrapper.c:68: conflicting declarations of `__result'
rootwrapper.c:68: `__result' previously defined here
rootwrapper.c:68: ANSI C forbids data definition with no type or storage class
rootwrapper.c:68: parse error before `}'
rootwrapper.c:68: warning: type defaults to `int' in declaration of `__result'
rootwrapper.c:68: ANSI C forbids data definition with no type or storage class
rootwrapper.c:68: parse error before `}'
rootwrapper.c:68: redefinition of `__result'
rootwrapper.c:68: `__result' previously defined here
rootwrapper.c:68: `__s1' undeclared here (not in a function)
rootwrapper.c:68: `argv' undeclared here (not in a function)
rootwrapper.c:68: initializer element is not constant
rootwrapper.c:68: parse error before `if'
rootwrapper.c:68: warning: type defaults to `int' in declaration of `__result'
rootwrapper.c:68: conflicting declarations of `__result'
rootwrapper.c:68: `__result' previously defined here
rootwrapper.c:68: ANSI C forbids data definition with no type or storage class
rootwrapper.c:68: parse error before `}'
rootwrapper.c:76: parse error before string constant
rootwrapper.c:76: warning: type defaults to `int' in declaration of `__result'
rootwrapper.c:76: ANSI C forbids data definition with no type or storage class
rootwrapper.c:76: parse error before `}'
rootwrapper.c:76: redefinition of `__result'
rootwrapper.c:68: `__result' previously defined here
rootwrapper.c:76: `__s2' undeclared here (not in a function)
rootwrapper.c:76: initializer element is not constant
rootwrapper.c:76: parse error before `if'
rootwrapper.c:76: warning: type defaults to `int' in declaration of `__result'
rootwrapper.c:76: conflicting declarations of `__result'
rootwrapper.c:76: `__result' previously defined here
rootwrapper.c:76: ANSI C forbids data definition with no type or storage class
rootwrapper.c:76: parse error before `}'
rootwrapper.c:76: warning: type defaults to `int' in declaration of `__result'
rootwrapper.c:76: ANSI C forbids data definition with no type or storage class
rootwrapper.c:76: parse error before `}'
rootwrapper.c:76: redefinition of `__result'
rootwrapper.c:76: `__result' previously defined here
rootwrapper.c:76: `__s1' undeclared here (not in a function)
rootwrapper.c:76: `argv' undeclared here (not in a function)
rootwrapper.c:76: initializer element is not constant
rootwrapper.c:76: parse error before `if'
rootwrapper.c:76: warning: type defaults to `int' in declaration of `__result'
rootwrapper.c:76: conflicting declarations of `__result'
rootwrapper.c:76: `__result' previously defined here
rootwrapper.c:76: ANSI C forbids data definition with no type or storage class
rootwrapper.c:76: parse error before `}'
Niels
--
Ga eens wat vaker met de metro
|
|
From: Niels R. <n.r...@pl...> - 2001-08-17 18:00:56
|
Hi guys, In my eyes it is time to show the world what we have accomplished, so I propose this release schedule. Please comment, flame, kill me for it. KreateCD 1.1 B1 (internal KreateCD 1.0.8) ========================================= - All features wanted present ( I want to finish trackview) - Intended for test use: tell this to the users - No message freeze whatsoever, also, documentation not important BRANCHPOINT: The KREATECD_1_1_BRANCH is created (intended for bug fixes only) TAGPOINT: the tag KREATECD_1_0_8_RELEASE is put upon the files PROPOSED DATE: 28th of August (yes, this year :-) KreateCD 1.1 RC (internal KreateCD 1.0.9) - Feature freeze, as well as a message freeze. - Basic documentation written - Bugs fixed TAGPOINT: (in branch KREATECD_1_1_BRANCH) KREATECD_1_0_9_RELEASE PROPOSED DATE: third week of September (so three weeks for bug-reports) KreateCD 1.1 final ( KreateCD 1.1) - Translations, Documentation, bugfixes... TAGPOINT: (in branch KREATECD_1_1_BRANCH) KREATECD_1_1_RELEASE PROPOSED DATE: second week of October (so another three weeks) Roadmap: November/December 2001: KreateCD 1.1.1 April 2002: KreateCD 2.0 (based on KDE 3.0) -- Ga eens wat vaker met de metro |
|
From: Alexander F. <Ale...@gm...> - 2001-08-17 12:40:05
|
Hi! I just commited the new SUID code which uses a seperate wrapper for root privileges. I did some simple tests and I hope it breaks nothing. The advanced widget problems are gone with KDE 2.2 - it was a bug in beta 1 and we should verify which versions are affected Alexander |
|
From: Alexander F. <Ale...@gm...> - 2001-08-15 12:19:50
|
On Wednesday, 15. August 2001 12:16, Niels Reedijk wrote: > Hi Joseph and Alex, > > I'm back, and currently looking at what you've done lately. Looking good > :-) > I just try to increase the suid root secuity of kreatecd by using a special wrapper for calling privileged helper apps. This wrapper can carefully designed to avoid security risks more easily. The main kreatecd executable will have no potential root privileges after that. If you don't want the user to call cdrecord, mkisofs, cdda2wav etc. you will have to forbid calling the wrapper by creating a group for kreatecd, set kreatecd setgid and make the wrapper only executable by this group. The group should not have any special privileges. Calling cdrecord manually through the wrapper (if not doing setgid) shouldn't be a problem either as you probably can use kreatecd to create the command line you need anyway (as long there is no security problem in cdrecord - but cdrecord is designed with security concepts in mind too) Alexander |
|
From: Niels R. <n.r...@pl...> - 2001-08-15 10:18:46
|
Hi Joseph and Alex, I'm back, and currently looking at what you've done lately. Looking good :-) Niels |
|
From: Alexander F. <Ale...@gm...> - 2001-08-10 11:26:06
|
On Friday, 10. August 2001 11:54, Stefan Gehn wrote: > Hi, > > I've seen this for a long time now and I think it's worth a small mail :) > KreateCD-sources are missing a lot of #include <cppfilename.moc> which > saves a lot of time when compiling. > If one forgets to do that, the moc-files will get compiled by gcc which is > a _lot_ slower than just including them. > Hmm, I did never a benchmark what is faster but you're probably right. I started to code kreatecd at a time where I didn't know about the possibility to append the include in the .cpp file - it probably was not supported by am_edit too. (it was called automoc) > I've once fixed that myself but i've been too lazy to send a diff to this > list. So if nobody feels the need to add one line while editing one of the > files just let me know and I will try to do a working diff. > I can do that. Should be no problem. :) Alexander |
|
From: Stefan G. <sg...@gm...> - 2001-08-10 10:02:05
|
Hi, I've seen this for a long time now and I think it's worth a small mail :) KreateCD-sources are missing a lot of #include <cppfilename.moc> which sa= ves=20 a lot of time when compiling. If one forgets to do that, the moc-files will get compiled by gcc which i= s a=20 _lot_ slower than just including them. I've once fixed that myself but i've been too lazy to send a diff to this= =20 list. So if nobody feels the need to add one line while editing one of th= e=20 files just let me know and I will try to do a working diff. Bye, Stefan aka mETz --=20 sg...@gm... | ICQ#51123152 | Moege der Pinguin mit euch sein |
|
From: Joseph W. <jo...@bi...> - 2001-08-08 21:15:55
|
Hi The wave view looks great, but I think the lines for the start and the stop should be marked somehow better (other color or thicker lines) What is the top most slider for (Hadn't time to look at the code yet) Kind regards Joseph Wenninger |
|
From: Joseph W. <jo...@bi...> - 2001-08-08 20:59:14
|
Hi > > Do you get any error messages when you start kreatecd from konsole and use > your kword/kivio trick to crash the UI? I had a similar problem with audio > options when you cancel the decoding process of mp3/ogg. A forked process > did some X11 IO and messed up the X11 connection and there were some errors > on konsole. > Will check it, but I can't remember any output on the terminal. > What methods are needed to support other audio files (ogg) for drag & drop > in the project window? > At the moment I look at the file extensions (it's somewhere in the tracklistmanager. I check if the file extension is suitable for audio/x-wav and audio/x-mp3), but I think this should be changed to use the identification code, which is provided by the plugins) Kind regards Joseph Wenninger |
|
From: Alexander F. <Ale...@gm...> - 2001-08-08 12:26:46
|
Hi! Do you get any error messages when you start kreatecd from konsole and use your kword/kivio trick to crash the UI? I had a similar problem with audio options when you cancel the decoding process of mp3/ogg. A forked process did some X11 IO and messed up the X11 connection and there were some errors on konsole. What methods are needed to support other audio files (ogg) for drag & drop in the project window? Alexander |
|
From: Alexander F. <Ale...@gm...> - 2001-08-07 22:21:34
|
Hi! I just have integrated a "wave view" widget which I hacked together during the last weeks. It is heavily inspired by the QSOscillo class which is used by kdao. I didn't use this class because it didn't met exaclly my needs and I wanted to write an optimized class. With this "wave view" you can navigate through your audio file easily and you can set your start and end marks more exactly. There is still some improvement we can do for the audio options dialog : it would be nice to have some exact display / edit for the start and end marks (displaying in minutes/seconds/frames/samples) and some "scales" around the wave view Any comments? Alexander |
|
From: Joseph W. <jo...@bi...> - 2001-08-05 13:50:46
|
Hi I encountered an (interesting problem). I tried to write a CD on the fly, from a filesystem tree. Then I started Kword and embedded a KIVIO document. -> Kreatecd UI doesn't react anymore (no repains,. ...), although CD writing seems to finish without problems. I can only produce this problem with an embedded kivio part (at the moment). It is independently, if I use the old or the new file tree. It was my first thought the kpart I use in the adnvanced widget could be the problem, but it doesn't seem to be. ***** I'm testing CD recording, (with on the lfy turned on) from a file tree, but it seams, I can't get the segmentation fault, with recent KDE 2.2 CVS. I think in KDE2.2 the filetree part has completely been rewritten, and it seams this rewrite has been fixed now in CVS finally. Does someone use KDE 2.1.x or 2.0.x ? Any problems with the kpart filetree in the advanced widget (or does it use the built in tree ?) ? Kind regards Joseph Wenninger |
|
From: Alexander F. <Ale...@gm...> - 2001-08-03 10:51:37
|
On Friday, 3. August 2001 10:11, jo...@bi... wrote:
> I never noticed this problem :(
>
> I'll look if I can reproduce it when I'm at home
> today (very late). I run KDE 2.2 (nearly final)
>
I have this problems since I really tried to use it - about the same time
on-the-fly is merged into the head. I thought that was one of the reasons why
it is not usable.
I'm using 2.2.0 beta 1 here. Short after beta 1 was released, the crashing
method in KDE was touched. So it may run on 2.2.0 and current CVS but it
might not run on earlier versions.
> I do a check anyways, if the dirtree part is
> available and use instead the built in, if the
> external one does not exist. Perhaps I should
> add an additional version check, which overrides
> the usage of the part. Which function does crash
> (in the part) ?
>
#0 KonqTreeViewWidget::slotCompleted (this=0x4125daa0, _url=@0x81fedb0)
at /usr/lib/qt2/include/qdict.h:654
#1 0x0000bfff in ?? ()
It crashes with a segfault - but not every run exactly on the same time.
First I suspected some bug in kreatecd itself but I think it is a problem of
the part - if I force to use the built in, everything works ok btw.
When was the part introduced (KDE version). Maybe we will have to check older
KDE versions.
Alexander
|
1 message has been excluded from this view by a project administrator.
