3:04 p.m.
http://bugzilla.rpmfusion.org/show_bug.cgi?id=151
Summary: Review Request: systemc - Design and verification
language for Hardware
Product: Package Reviews
Version: Current
Platform: All
OS/Version: GNU/Linux
Status: NEW
Severity: normal
Priority: P5
Component: Review Request
AssignedTo: rpmfusion-package-review(a)rpmfusion.org
ReportedBy: cgoorah(a)yahoo.com.au
CC: rpmfusion-package-review(a)rpmfusion.org
Blocks: 2
Estimated Hours: 0.0
Spec URL: http://chitlesh.fedorapeople.org/systemC/systemc.spec
SRPM URL: http://chitlesh.fedorapeople.org/systemC/systemc-2.2.0-1.fc9.src.rpm
Description:
SystemC™ is a language built in standard C++ by extending the language
with the use of class libraries. SystemC addresses the need for a system
design and verification language that spans hardware and software.
SystemC is listed among Fedora Electronic Lab (FEL) packages.
--------------
SystemC couldn't be part of the Fedora collection. TomCallaway and Red Hat
lawyers talked to upstream. But upstream don't want to change any clause of
their license.
SystemC Fedora's bugzilla blocked as CANTFIX
https://bugzilla.redhat.com/show_bug.cgi?id=453335
rpmlint's warnings:
systemc.i386: W: invalid-license SystemC Open Source License 2.3
systemc.i386: W: devel-file-in-non-devel-package
can be ignored.
devel-file-in-non-devel-package:
Systemc is a collection of c++ class libraries for hardware design.
--
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
3:10 p.m.
New subject: [Bug 151] Review Request: systemc - Design and verification language for Hardware
http://bugzilla.rpmfusion.org/show_bug.cgi?id=151
--- Comment #1 from Chitlesh GOORAH <cgoorah(a)yahoo.com.au> 2008-11-14 16:10:04 ---
One of my blog post about systemC:
http://clunixchit.blogspot.com/2008/07/fel-systemc-was-put-aside-legal.html
License:
http://chitlesh.fedorapeople.org/systemC/License.pdf
--
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
8:43 p.m.
New subject: [Bug 151] Review Request: systemc - Design and verification language for Hardware
http://bugzilla.rpmfusion.org/show_bug.cgi?id=151
Orcan Ogetbil <orcanbahri(a)yahoo.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |orcanbahri(a)yahoo.com
Blocks|2 |3
Status|NEW |ASSIGNED
--- Comment #2 from Orcan Ogetbil <orcanbahri(a)yahoo.com> 2008-11-27 21:43:05 ---
I can confirm that the source SHA1SUM matches upstream and is the latest
version. I will have to go through the license text (I hate long license
texts). Can you point me to the discussion in the mailing list about this
license issue?
A few quick things I noticed:
* Those seds need to go to the %prep section
* I think you should keep AUTHORS and README files in the %doc section.
* Fedora specific compiler flag -O2 gets overridden by -O3. You will need to
fix that.
I will do a comprehensive review sometime soon.
--
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
9:53 p.m.
New subject: [Bug 151] Review Request: systemc - Design and verification language for Hardware
http://bugzilla.rpmfusion.org/show_bug.cgi?id=151
--- Comment #3 from Chitlesh GOORAH <cgoorah(a)yahoo.com.au> 2008-11-27 22:53:12 ---
Updated:
Spec URL: http://chitlesh.fedorapeople.org/systemC/systemc.spec
SRPM URL: http://chitlesh.fedorapeople.org/systemC/systemc-2.2.0-2.fc9.src.rpm
Email from TomCallaway: http://chitlesh.fedorapeople.org/systemC/tom.txt
--
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
4:01 p.m.
New subject: [Bug 151] Review Request: systemc - Design and verification language for Hardware
http://bugzilla.rpmfusion.org/show_bug.cgi?id=151
--- Comment #4 from Orcan Ogetbil <orcanbahri(a)yahoo.com> 2008-11-28 17:01:02 ---
This package needs some work. rpmlint gives some ~300 warnings/errors. The main
reasons seems to be your unusual prefix for configure.
-Why don't you use %{_usr} for prefix? Or just use %configure and it will take
care of it for you.
-I see you defining the $DESTDIR. But there is no reference to the $DESTDIR
anywhere in the Makefiles or the code.
-The contents of the include directory must go to a devel subpackage.
-The library is built static. Is there no way of making it dynamic?
-There are a lot of "wrong EOL encoding" warnings. You can use
sed 's/\r//' filename
to fix those. But make sure you preserve timestamps for the relevant files.
-There are bunch of binary files in the source tarball. For instance, the
.DS_Store files. You should remove all of them during %prep
-We don't mention the %buildroot during %prep. That comes in the %build and
%install sections.
--
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
8:30 p.m.
New subject: [Bug 151] Review Request: systemc - Design and verification language for Hardware
http://bugzilla.rpmfusion.org/show_bug.cgi?id=151
--- Comment #5 from Chitlesh GOORAH <cgoorah(a)yahoo.com.au> 2008-11-29 21:30:28 ---
(In reply to comment #4)
This package needs some work. rpmlint gives some ~300
warnings/errors. The main
reasons seems to be your unusual prefix for configure.
No the main reason is the devel-file-in-non-devel-package. Thus the above
mentioned 300 reflects the number of files and not the amount of work the
package requires.
-Why don't you use %{_usr} for prefix? Or just use %configure and
it will take
care of it for you.
In this context, please do not confuse prefix with exec_prefix
Here prefix is used as an install base location
It is not wise to opt another install base location as:
- it will conflict with the whole set of fedora/rpmfusion packages
-I see you defining the $DESTDIR. But there is no reference to the
$DESTDIR
anywhere in the Makefiles or the code.
Removed
-The contents of the include directory must go to a devel subpackage.
systemc is meant to be used at low-level. systemc is used to design hardware,
and just requires the includes/
-The library is built static. Is there no way of making it dynamic?
No, it was not designed to.
-There are a lot of "wrong EOL encoding" warnings. You can
use
sed 's/\r//' filename
to fix those. But make sure you preserve timestamps for the relevant files.
done
-There are bunch of binary files in the source tarball. For instance,
the
.DS_Store files. You should remove all of them during %prep
done
-We don't mention the %buildroot during %prep. That comes in the
%build and
%install sections.
unfortunately in this case, yes.
Updated
Spec URL: http://chitlesh.fedorapeople.org/systemC/systemc.spec
SRPM URL: http://chitlesh.fedorapeople.org/systemC/systemc-2.2.0-3.fc10.src.rpm
--
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
12:54 a.m.
New subject: [Bug 151] Review Request: systemc - Design and verification language for Hardware
http://bugzilla.rpmfusion.org/show_bug.cgi?id=151
--- Comment #6 from Orcan Ogetbil <orcanbahri(a)yahoo.com> 2008-11-30 01:54:41 ---
OK, I did a full review on this package (except, I still have to read the
license file)
(In reply to comment #5)
(In reply to comment #4)
> -Why don't you use %{_usr} for prefix? Or just use %configure and it will take
> care of it for you.
In this context, please do not confuse prefix with exec_prefix
Here prefix is used as an install base location
It is not wise to opt another install base location as:
- it will conflict with the whole set of fedora/rpmfusion packages
> -I see you defining the $DESTDIR. But there is no reference to the $DESTDIR
> anywhere in the Makefiles or the code.
Removed
* Then I think we should follow the gcc scheme rather than creating a systemc
directory directly inside /usr . gcc is installed in the path:
/usr/lib/gcc/x86_64-redhat-linux/4.3.2/
I don't like putting %{buildroot} into the prefix. You can use a
sed 's|\$(prefix)|\$(DESTDIR)/\$(prefix)|g'
on the Makefile* and then use the DESTDIR trick you just removed. e.g.
%configure --prefix=%{_libdir}/%{name}/%{version}
(or something similar) and then
%{__make} INSTALL="install -p" DESTDIR=%{buildroot} install
* I also wonder why you don't use
gmake install
> -There are bunch of binary files in the source tarball. For instance, the
> .DS_Store files. You should remove all of them during %prep
done
* There are more precompiled binary files. e.g. .ncb files
Please run something like
for i in $(rpm -qpl systemc*.rpm); do file $i; done
to check for filetypes in an rpm.
And this is the rest of my review:
* Do we need to package the .vcproj files? They are for use of MS' visualC.
* The files README and doc/README are different. You are overwriting one the
way you package the doc files. (Maybe you should use docs instead of docs/* in
%doc or just rename one of these README files)
* This one is for making the SPEC file plainer: Check
rpm --eval %{optflags}
to see what flags need to be there for compilation. You are removing some of
these flags from the configure script. Removing them is unnecessary.
? The debuginfo package is empty?
* I am worried about the Requires. You are building this with g++34. Don't you
think we need to require g++34 for this package? If someone writes a code with
this library he needs to compile the code with g++34, right? And what about
other (possible) dependencies?
--
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
2:49 p.m.
New subject: [Bug 151] Review Request: systemc - Design and verification language for Hardware
http://bugzilla.rpmfusion.org/show_bug.cgi?id=151
--- Comment #7 from Chitlesh GOORAH <cgoorah(a)yahoo.com.au> 2008-11-30 15:49:51 ---
(In reply to comment #6)
* Then I think we should follow the gcc scheme rather than creating a
systemc
directory directly inside /usr . gcc is installed in the path:
/usr/lib/gcc/x86_64-redhat-linux/4.3.2/
Now: /usr/lib/systemc/2.2.0/
I don't like putting %{buildroot} into the prefix. You can use a
sed 's|\$(prefix)|\$(DESTDIR)/\$(prefix)|g'
on the Makefile* and then use the DESTDIR trick you just removed. e.g.
%configure --prefix=%{_libdir}/%{name}/%{version}
(or something similar) and then
%{__make} INSTALL="install -p" DESTDIR=%{buildroot} install
done
* I also wonder why you don't use
gmake install
done
* There are more precompiled binary files. e.g. .ncb files
* Do we need to package the .vcproj files? They are for use of MS' visualC.
*.ncb and *.vcproj removed
* The files README and doc/README are different. You are overwriting
one the
way you package the doc files. (Maybe you should use docs instead of docs/* in
%doc or just rename one of these README files)
done
* This one is for making the SPEC file plainer: Check
rpm --eval %{optflags}
to see what flags need to be there for compilation. You are removing some of
these flags from the configure script. Removing them is unnecessary.
Because the build fails with the following :
cc1plus: error: unrecognized command line option "-fstack-protector"
cc1plus: error: invalid parameter `ssp-buffer-size'
cc1plus: error: invalid parameter `ssp-buffer-size'
warning: #warning _FORTIFY_SOURCE supported only with GCC 4.1 and later
? The debuginfo package is empty?
I have no clue how to fix this.
* I am worried about the Requires. You are building this with g++34.
Don't you
think we need to require g++34 for this package? If someone writes a code with
this library he needs to compile the code with g++34, right? And what about
other (possible) dependencies?
true, Requires: compat-gcc-34-c++ was missing. But no other requires are
needed.
Updated
Spec URL: http://chitlesh.fedorapeople.org/systemC/systemc.spec
SRPM URL: http://chitlesh.fedorapeople.org/systemC/systemc-2.2.0-4.fc10.src.rpm
--
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
3:10 p.m.
New subject: [Bug 151] Review Request: systemc - Design and verification language for Hardware
http://bugzilla.rpmfusion.org/show_bug.cgi?id=151
Hans de Goede <j.w.r.degoede(a)hhs.nl> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |j.w.r.degoede(a)hhs.nl
--- Comment #8 from Hans de Goede <j.w.r.degoede(a)hhs.nl> 2008-11-30 16:10:35 ---
(In reply to comment #7)
> * I am worried about the Requires. You are building this with
g++34. Don't you
> think we need to require g++34 for this package? If someone writes a code with
> this library he needs to compile the code with g++34, right? And what about
> other (possible) dependencies?
>
true, Requires: compat-gcc-34-c++ was missing. But no other requires are
needed.
Ugh, ok so you are going to hate me (or atleast dislike), but compiling with
compat-gcc34 is not an acceptable solution to compile issues with a newer gcc.
This not only means that apps using systemc libs need to be compiled with
gcc34, it also means they cannot use any other c++ libraries compiled with
gcc4x, the proper solution is to fix the code to compile with 4x, even though
that may be painful.
compat-gcc34 only exist so that some libraries can be compiled with it, so that
old (binary only / blob) applications compiled with gcc34 can stay functioning,
iow compat-gcc34 is only there to compile compat-foo packages, not to compile
new packages.
Note I'm willing to help with getting things to compile with 4x, although I
don't have time to do the main effort here, I can assist where you encounter
errors you cannot solve yourself.
--
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
7:49 p.m.
New subject: [Bug 151] Review Request: systemc - Design and verification language for Hardware
http://bugzilla.rpmfusion.org/show_bug.cgi?id=151
--- Comment #9 from Chitlesh GOORAH <cgoorah(a)yahoo.com.au> 2008-11-30 20:49:04 ---
Note I'm willing to help with getting things to compile with 4x,
although I
don't have time to do the main effort here, I can assist where you encounter
errors you cannot solve yourself.
Hello Hans,
I have updated it for gcc4. I would appreciate if you take some time to fix the
warnings as they now spits a lot of warnings, with the examples.
The debug-info has not yet been solved.
Updated:
Spec URL: http://chitlesh.fedorapeople.org/systemC/systemc.spec
SRPM URL: http://chitlesh.fedorapeople.org/systemC/systemc-2.2.0-5.fc10.src.rpm
--
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
8:05 p.m.
New subject: [Bug 151] Review Request: systemc - Design and verification language for Hardware
http://bugzilla.rpmfusion.org/show_bug.cgi?id=151
--- Comment #10 from Orcan Ogetbil <orcanbahri(a)yahoo.com> 2008-11-30 21:05:18 ---
Good, let's find a way to solve this debuginfo issue. I am working on it too.
Everything seems good, except I have to warn you at one point. Never use the
output of "ls" for parsing. "ls" gives a human-friendly output, but
that's all.
It is not intended to be used in bash scripts. You will get into trouble in
many places if you do. For instance you'll get screwed up if there are files
that have whitespaces (space,tab,newline etc) in their names.
--
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
8:10 a.m.
New subject: [Bug 151] Review Request: systemc - Design and verification language for Hardware
http://bugzilla.rpmfusion.org/show_bug.cgi?id=151
--- Comment #11 from Hans de Goede <j.w.r.degoede(a)hhs.nl> 2008-12-02 09:10:24 ---
(In reply to comment #9)
> Note I'm willing to help with getting things to compile with
4x, although I
> don't have time to do the main effort here, I can assist where you encounter
> errors you cannot solve yourself.
Hello Hans,
I have updated it for gcc4. I would appreciate if you take some time to fix the
warnings as they now spits a lot of warnings, with the examples.
Can you attach a log file with the warnings? Then I can take a look what kind
of warnings they are and how hard to fix they will be.
The debug-info has not yet been solved.
Are the installed .so.x files executable? If not you won't get debuginfo. Are
the rpmoptflags used everywhere? Maybe during linking or install the binaries
are stripped (-s argument to ld / gcc / install, or a plain call of strip) ?
--
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
5:39 p.m.
New subject: [Bug 151] Review Request: systemc - Design and verification language for Hardware
http://bugzilla.rpmfusion.org/show_bug.cgi?id=151
--- Comment #12 from Orcan Ogetbil <orcanbahri(a)yahoo.com> 2008-12-02 18:39:11 ---
The thing is there is no dynamic library in this package. The static library
has 644 permission, which I think is normal. That is probably the cause of no
debuginfo package is getting built.
I was wondering, though, if it is possible at all to make this library dynamic.
I know it is contrary to what upstream intends...
--
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
3:07 a.m.
New subject: [Bug 151] Review Request: systemc - Design and verification language for Hardware
http://bugzilla.rpmfusion.org/show_bug.cgi?id=151
--- Comment #13 from Kevin Kofler <kevin.kofler(a)chello.at> 2008-12-08 04:07:42 ---
g++ 3.4 is actually binary-compatible with g++ 4.x.
--
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
5:40 p.m.
New subject: [Bug 151] Review Request: systemc - Design and verification language for Hardware
http://bugzilla.rpmfusion.org/show_bug.cgi?id=151
--- Comment #14 from Chitlesh GOORAH <cgoorah(a)yahoo.com.au> 2008-12-08 18:40:55
---
I have the static lib converted to dynamic and did some cleanups. However now
the examples are failing! I'll have a look at them soon and will update today
or tomorrow.
--
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
12:10 a.m.
New subject: [Bug 151] Review Request: systemc - Design and verification language for Hardware
http://bugzilla.rpmfusion.org/show_bug.cgi?id=151
--- Comment #15 from Chitlesh GOORAH <cgoorah(a)yahoo.com.au> 2008-12-14 01:10:47
---
Updated:
Spec URL: http://chitlesh.fedorapeople.org/systemC/systemc.spec
SRPM URL: http://chitlesh.fedorapeople.org/systemC/systemc-2.2.0-6.fc10.src.rpm
--
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
12:48 a.m.
New subject: [Bug 151] Review Request: systemc - Design and verification language for Hardware
http://bugzilla.rpmfusion.org/show_bug.cgi?id=151
--- Comment #16 from Orcan Ogetbil <orcanbahri(a)yahoo.com> 2008-12-15 01:48:50 ---
* Patch 0 and Patch1 contain unnecessary bits. Please clean them up and make
the patches as plain as possible.
* Patch 3 is an empty patch file and it is applied twice. Did you forget
something?
* affected=`find src/ -type f -name "Makefile*" -exec ls {} ';'`
can be just
affected=`find src/ -type f -name "Makefile*"`
As I noted before "ls" is not intended to be used in shell scripts.
* Please remove the comments such as
#%{__sed} -i -e 's|prefix = @prefix@|prefix = %{SYSTEMC_HOME}|g' \
# examples/*/Makefile* \
# examples/*/*/Makefile* \
# examples/*/*/*/Makefile*
from the final version of the SPEC file. I'd also like to remind you that
whenever you want to use macros inside comments, you need to use %% instead of
single %.
* Don't use the %{version} macro for patch names. If you do, you will need to
re-upload them at each version. Either put explicit version number or no
version number at all.
* More important than anything else: This SRPM does not build!
--
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
12:53 a.m.
New subject: [Bug 151] Review Request: systemc - Design and verification language for Hardware
http://bugzilla.rpmfusion.org/show_bug.cgi?id=151
--- Comment #17 from Orcan Ogetbil <orcanbahri(a)yahoo.com> 2008-12-15 01:53:27 ---
Here is the error message:
...
~/rpmbuild/BUILD/systemc-2.2.0
+ /bin/rm -f examples/Makefile examples/Makefile.am examples/Makefile.in
+ ar -x src/libsystemc.a
+ gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic -Wa,--noexecstack -shared qt.o
qtmdc.o qtmds.o sc_attribute.o sc_bit.o sc_bv_base.o sc_clock.o sc_concatref.o
sc_cor_fiber.o sc_cor_pthread.o sc_cor_qt.o sc_cthread_process.o sc_event.o
sc_event_finder.o sc_event_queue.o sc_export.o sc_fxcast_switch.o sc_fxdefs.o
sc_fxnum.o sc_fxnum_observer.o sc_fxtype_params.o sc_fxval.o
sc_fxval_observer.o sc_hash.o sc_int32_mask.o sc_int64_io.o sc_int64_mask.o
sc_int_base.o sc_interface.o sc_join.o sc_length_param.o sc_list.o sc_logic.o
sc_lv_base.o sc_main.o sc_main_main.o sc_mempool.o sc_method_process.o
sc_module.o sc_module_name.o sc_module_registry.o sc_mutex.o sc_name_gen.o
sc_nbdefs.o sc_nbexterns.o sc_nbutils.o sc_object.o sc_object_manager.o
sc_port.o sc_pq.o sc_prim_channel.o sc_process.o sc_report.o
sc_report_handler.o sc_reset.o sc_semaphore.o sc_sensitive.o sc_signal.o
sc_signal_ports.o sc_signal_resolved.o sc_signal_resolved_ports.o sc_signed.o
sc_simcontext.o sc_stop_here.o sc_string.o sc_thread_process.o sc_time.o
sc_trace.o sc_uint_base.o sc_unsigned.o sc_utils_ids.o sc_value_base.o
sc_vcd_trace.o sc_ver.o sc_wait.o sc_wait_cthread.o sc_wif_trace.o scfx_mant.o
scfx_pow10.o scfx_rep.o scfx_utils.o -o libsystemc.so
/usr/bin/ld: qt.o: relocation R_X86_64_32 against `__gxx_personality_v0' can
not be used when making a shared object; recompile with -fPIC
qt.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
error: Bad exit status from /var/tmp/rpm-tmp.egTUgQ (%install)
--
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
7:03 a.m.
New subject: [Bug 151] Review Request: systemc - Design and verification language for Hardware
http://bugzilla.rpmfusion.org/show_bug.cgi?id=151
rc040203(a)freenet.de changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rc040203(a)freenet.de
--- Comment #18 from rc040203(a)freenet.de 2008-12-15 08:03:32 ---
(In reply to comment #16)
As I noted before "ls" is not intended to be used in shell
scripts.
No idea, what makes you think this.
It's perfectly legitimate to use "ls" in shell scripts.
--
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
10:51 p.m.
New subject: [Bug 151] Review Request: systemc - Design and verification language for Hardware
http://bugzilla.rpmfusion.org/show_bug.cgi?id=151
--- Comment #19 from Orcan Ogetbil <orcanbahri(a)yahoo.com> 2008-12-15 23:51:51 ---
(In reply to comment #18)
(In reply to comment #16)
> As I noted before "ls" is not intended to be used in shell scripts.
No idea, what makes you think this.
It's perfectly legitimate to use "ls" in shell scripts.
Just google "bash guide" or something similar and click on any of the results.
I'm sure you will see that they will try to discourage you from parsing ls
outputs. It's considered "bad" programming.
For instance see (scroll down to "NOTE:"):
http://wooledge.org:8000/BashGuide#BashGuide.2BAC8-TheBasics.2BAC8-Comman...
--
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
6:03 a.m.
New subject: [Bug 151] Review Request: systemc - Design and verification language for Hardware
On Mon, 2008-12-15 at 23:51 +0100, RPM Fusion Bugzilla wrote:
--- Comment #19 from Orcan Ogetbil <orcanbahri(a)yahoo.com>
2008-12-15 23:51:51 ---
(In reply to comment #18)
> (In reply to comment #16)
> > As I noted before "ls" is not intended to be used in shell scripts.
> No idea, what makes you think this.
>
> It's perfectly legitimate to use "ls" in shell scripts.
>
Just google "bash guide" or something similar and click on any of the results.
I'm sure you will see that they will try to discourage you from parsing ls
outputs. It's considered "bad" programming.
For instance see (scroll down to "NOTE:"):
http://wooledge.org:8000/BashGuide#BashGuide.2BAC8-TheBasics.2BAC8-Comman...
What this author says is entire BS.
1. "ls" is standardized by POSIX etc.
2. It is not "intended to be used only for producing human-readable
results".
Furthermore, we are talking about building RPMs on Linux (i.e. in well
defined environment), not on general portability of ls (which, unlike
you and the author of the article above claim, exists).
Ralf
12:07 a.m.
New subject: [Bug 151] Review Request: systemc - Design and verification language for Hardware
http://bugzilla.rpmfusion.org/show_bug.cgi?id=151
--- Comment #20 from Chitlesh GOORAH <cgoorah(a)yahoo.com.au> 2008-12-16 01:07:05
---
Updated:
Spec URL: http://chitlesh.fedorapeople.org/systemC/systemc.spec
SRPM URL: http://chitlesh.fedorapeople.org/systemC/systemc-2.2.0-7.fc10.src.rpm
--
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
2:07 a.m.
New subject: [Bug 151] Review Request: systemc - Design and verification language for Hardware
http://bugzilla.rpmfusion.org/show_bug.cgi?id=151
--- Comment #21 from Orcan Ogetbil <orcanbahri(a)yahoo.com> 2008-12-16 03:07:48 ---
* You can drop BR: gcc-c++ as it is among the minimal build environment
packages (R: gcc-c++ should stay).
* The package still does not build with mock. But I found the main source of
the problem. From the build.log:
g++ -I. -I../../../src -Wall -DSC_INCLUDE_FX -g -c sc_stop_here.cpp
As you see neither %optflags nor -fPIC is passed to the compiler during the
compilation of this file. If you look at the
src/sysc/utils/Makefile.am
file you will see that
sc_stop_here.o: sc_stop_here.cpp
$(CXXCOMPILE_DEBUG) -c $<
so the $(CXXCOMPILE_DEBUG) variable must contain both %optflags and -fPIC. But
it is defined as (same file)
CXXCOMPILE_DEBUG = $(CXX) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS)
$(AM_CXXFLAGS) $(EXTRA_CXXFLAGS) $(DEBUG_CXXFLAGS)
Here, the OPT_CXXFLAGS is not passed to the CXXCOMPILE_DEBUG, hence the
compilation fails for x86_64.
There are various ways to fix this. I leave it up to you, but make sure that
both %optflags and -fPIC is passed to the compiler for the compilation of
sc_stop_here.cpp.
--
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
2:21 a.m.
New subject: [Bug 151] Review Request: systemc - Design and verification language for Hardware
http://bugzilla.rpmfusion.org/show_bug.cgi?id=151
--- Comment #22 from Orcan Ogetbil <orcanbahri(a)yahoo.com> 2008-12-16 03:21:30 ---
When I fixed this myself I found out that you must also BR: prelink (for
execstack)
--
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
7:15 p.m.
New subject: [Bug 151] Review Request: systemc - Design and verification language for Hardware
http://bugzilla.rpmfusion.org/show_bug.cgi?id=151
--- Comment #23 from Chitlesh GOORAH <cgoorah(a)yahoo.com.au> 2008-12-17 20:15:04
---
Updated
Spec URL: http://chitlesh.fedorapeople.org/systemC/systemc.spec
SRPM URL: http://chitlesh.fedorapeople.org/systemC/systemc-2.2.0-3.fc10.src.rpm
Mock i386: http://chitlesh.fedorapeople.org/systemC/build.log
--
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
12:52 a.m.
New subject: [Bug 151] Review Request: systemc - Design and verification language for Hardware
http://bugzilla.rpmfusion.org/show_bug.cgi?id=151
--- Comment #24 from Orcan Ogetbil <orcanbahri(a)yahoo.com> 2008-12-18 01:52:45 ---
OK, I finally got everything together.
BR: gcc-c++ is not required (you must remove it)
R: gcc-c++ is not required either (which you already removed)
We came to the point where we have to discuss about the license.
Section 5 describes the responsibilities of the distributor. And the last
sentence scares me. Let's talk this in the mailing list.
--
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
1:39 p.m.
New subject: [Bug 151] Review Request: systemc - Design and verification language for Hardware
http://bugzilla.rpmfusion.org/show_bug.cgi?id=151
--- Comment #25 from Chitlesh GOORAH <cgoorah(a)yahoo.com.au> 2008-12-20 14:39:35
---
Upstream is contacted again:
Since one have to login in order to view the archives, I have CC: FEL mailing
list:
https://www.redhat.com/archives/fedora-electronic-lab-list/2008-December/...
Let's keep this bug pending, until we have news from upstream.
I have also pointed out in a separate my to systemc-forum that SCLive is
violating the GPL License as it includes opera and Systemc.
On http://sourceforge.net/projects/sclive/, and click on details: you will see:
License : GNU General Public License (GPL)
However FSF says the OSCI is non-free and not compatible with GPL.
Thereby the SCLive license should not be GPL'ed. I am not a lawyer, I
can only deduced this.
--
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
10:49 p.m.
New subject: [Bug 151] Review Request: systemc - Design and verification language for Hardware
http://bugzilla.rpmfusion.org/show_bug.cgi?id=151
Orcan Ogetbil <oget.fedora(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks|3 |4
--- Comment #26 from Orcan Ogetbil <oget.fedora(a)gmail.com> 2009-01-15 23:49:12 ---
I got a hold of spot to discuss about this license issue. He told me that it is
OK to distribute systemc on rpmfusion provided that we abide by the terms in
section 4.4 of the license.
He says: "Basically, be sure in the patch there is some comment claiming who
made the change."
If you can add comments into all of the patch files that identifies you as the
person who made the change, this package can be distributed in rpmfusion.
* Please do that before you commit
* Also, please remove BR: gcc-c++. It is not needed.
Both are easy to do, therefore I'm approving this package now.
----------------------------------------------------------------
This package (systemc) is APPROVED by oget for rpmfusion-nonfree
----------------------------------------------------------------
--
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
12:29 a.m.
New subject: [Bug 151] Review Request: systemc - Design and verification language for Hardware
http://bugzilla.rpmfusion.org/show_bug.cgi?id=151
--- Comment #27 from Orcan Ogetbil <oget.fedora(a)gmail.com> 2009-02-22 01:29:23 ---
ping?
what happened?
--
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
10:25 a.m.
New subject: [Bug 151] Review Request: systemc - Design and verification language for Hardware
http://bugzilla.rpmfusion.org/show_bug.cgi?id=151
Chitlesh GOORAH <cgoorah(a)yahoo.com.au> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |WONTFIX
--- Comment #28 from Chitlesh GOORAH <cgoorah(a)yahoo.com.au> 2009-03-02 11:25:20
---
(In reply to comment #27)
ping?
what happened?
Well, despite our requests and support, it is a dead end.
I'm closing this bug.
thanks oget
--
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
5531
days inactive
5639
days old
rpmfusion-developers@lists.rpmfusion.org
29 comments
2 participants
participants (2)
-
Ralf Corsepius -
RPM Fusion Bugzilla