All,
As I've blasted across the universe, I'm trying to package a set of
computer forensic apps.
I'm tracking my progress here.
http://en.opensuse.org/Portal:Digital_Forensics_/_Incident_Response
The next one on my list is pyflag. I have a package in OBS:
home:gregfreemyer:Tools-for-forensic-boot-cd > pyflag
But the build is failing in the INSTALL section with:
==
gcc -shared -I/usr/include/python2.7 -I../../src/include -L
-lpython2.7 -o pypacket.so pypacket.c .libs/pypacket.a -lpthread -ldl
-lutil
In file included from /usr/include/python2.7/Python.h:8:0,
from ../../src/include/pypacket.h:4,
from pypacket.c:8:
/usr/include/python2.7/pyconfig.h:1161:0: warning: "_POSIX_C_SOURCE"
redefined [enabled by default]
/usr/include/features.h:215:0: note: this is the location of the
previous definition
pypacket.c:323:5: warning: initialization from incompatible pointer
type [enabled by default]
pypacket.c:323:5: warning: (near initialization for
'PyPacketType.tp_getattr') [enabled by default]
/usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../x86_64-suse-linux/bin/ld:
/tmp/ccHOtZu6.o: relocation R_X86_64_32 against `.rodata' can not be
used when making a shared object; recompile with -fPIC
/tmp/ccHOtZu6.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
==
I have unpacked the tarball and manually done "./configure; make; make
install" and I get the same error.
If I cd into "pyflag-0.87-pre1/src/lib" and then do a make pypacket.so
(which seems to be the goal of the above gcc command), I get the exact
same error.
So I'm in the right place, but I don't know how to debug this any further.
I've attached the Makefile from pyflag-0.87-pre1/src/lib folder.
Can anyone help me with that?
Thanks
Greg
Hi all,
I'm trying to stop the daily virtualbox updates from the
Virtualization repo (on every rebuild).
One culprit is a "__DATE__, __TIME__" in VBoxSVC which I
can patch out quite easily.
Another one is:
compare /.build.oldpackages/virtualbox-host-kmp-desktop-4.1.8_k3.1.9_1.4-28.15.x86_64.rpm /home/abuild/rpmbuild/RPMS/x86_64/virtualbox-host-kmp-desktop-4.1.8_k3.1.9_1.4-28.16.x86_64.rpm
--- /tmp/tmp.8NI4XILsY7 2012-02-19 18:57:32.776000001 +0000
+++ /tmp/tmp.KDp84V0Y4m 2012-02-19 18:57:32.804000001 +0000
@@ -9,16 +9,16 @@
(none) 4.9.1.2 x86_64-suse-linux
cpio lzma 5
-/bin/sh nvr=virtualbox-host-kmp-desktop-4.1.8_k3.1.9_1.4-28.15
+/bin/sh nvr=virtualbox-host-kmp-desktop-4.1.8_k3.1.9_1.4-28.16
wm2=/usr/lib/module-init-tools/weak-modules2
if [ -x $wm2 ]; then
/bin/bash -${-/e/} $wm2 --add-kmp $nvr
fi
This seems to come from one of those whacko KMP macros.
Can we just ignore these in build-compare? If the only difference is
the build counter, then ignore it?
Pretty please?
--
Stefan Seyfried
"Dispatch war rocket Ajax to bring back his body!"
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi, all
Yesterday I promise Ralf Lang <lang(a)b1-systems.de> that I would take
care of long unmaintained package xinc.
And I find there's still a long way to go on PHP.
1. we lack a wiki package. Portal:Packaging Packaging:PHP doesn't
exist, and I have to refer to Fedora.
to me, knowing nothing about PHP, I have to follow other packages'
specfiles to find my way. a wiki page will help a lot.
2. we even lack a RPM Group named Development/Languages/PHP and many
macros like %{__pear}, related rpmlint checks
You can see /usr/lib/rpm/macro.php is nearly empty. macros.suse
have no line of PHP. and rpmlint errors & warning seems ignore that
series too.
Hope this situation could change in the near future and some one
developing it can see and fulfill our needs.
Marguerite.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
All,
I'm trying to package guymager and libguytools. They work together
and guymager buildrequires the library.
libguytools is really just some /usr/include/libguytools/*.h files and
a static library. That seems wrong to me, but its the way they have
it broke up at sourceforge.
I've got a package for libguytools in my home project.
(home:gregfreemyer:Tools-for-forensic-boot-cd > libguytools )
Right now, the main libguytools package is empty and I've got 2 sub-packages:
%files -n %{name}-devel
%defattr(-,root,root,-)
%{_includedir}/libguytools2/
%files -n %{name}-devel-static
%defattr(-,root,root,-)
%{_libdir}/libguytools.a
Is this approach acceptable?
I seriously doubt there is another user of the libguytools library
floating around anywhere. Should I just combine this package with the
guymager package somehow?
I don't yet have a good guymager package at all. I'm starting with the library.
Greg
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Am 27.02.2012 17:38, schrieb Marguerite Su:
> dont be so hurry. let me branch it tomorrow. its bed time in Asia. its
> too sad to drop any built package. i will take care of that baby. good
> night.
>
> marguerite
>
Thank you very much :)
--
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: lang(a)b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi folks,
Is somebody interested in taking care of the xinc php CI server?
The current package in server:php:applications has a confusion mix of
contradicting license tags (BSD vs LGPL, probably LGPL-2.1+), is rather
old (2 years - it's not even offered on the current project pear server)
and would probably not be accepted into factory as of now.
It also has some patches which I cannot quickly evaluate and the
.changes file is missing.
Does anything depend on it?
I don't think we should keep having it in the repo in its current form.
--
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: lang(a)b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Roman / All,
I just noticed that logsurfer+ v1.7 in security was renamed by
upstream to logsurfer v1.8.
http://www.crypt.gen.nz/logsurfer/
Should logsurfer+ be updated to version 1.8, then a copypac done
inside security, then logsurfer+ deleted.
Would that preserve all the revision history?
fyi: I'm not necessarily volunteering to do that. I'm more curious
about the process of rename. Roman has recently done some work on
logsurfer, so I hope/assume he will update it, especially since it
doesn't currently build for factory.
Greg
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
All,
I have a package that says it will leverage python-tkinter if its available.
Per http://wiki.python.org/moin/TkInter it is a defacto standard for
python GUI work.
So I'm surprised it isn't already in OBS somewhere.
fyi: when I test my little package, it is not kicking off a GUI. Just
pure cli, so it's not finding it in the base python package.
Thanks
Greg
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
Logrotate 3.8 introduced stricter demands on the ownership of log
directories. It refuses to rotate log files in directories that are
writable by anyone other than root to avoid e.g. symlink tricks of a
compromised account.
The correct fix is to change the ownership of log _directories_ to root
and also don't allow any group != 0 to write there. It's still ok for
log _files_ to be owned and writable by some unprivileged user
or group.
Bad:
drwxrwxr-x 2 foo bar /var/log/foo/
-rw-rw-r-- 2 foo bar /var/log/foo/foo.log
Good:
drwxr-xr-x 2 root root /var/log/foo/
-rw-rw-r-- 2 foo bar /var/log/foo/foo.log
Alternatively if the package in question for whatever reason requires
the log directory to be writable by unprivileged users logrotate now
also supports a 'su' option.
So I've introduced a new rpmlint check in Factory that checks for
user owned log directories resp lack of the 'su' option. rpmlint now
also complains if the log directory is not packaged as it obviously
can't check the permissions then.
So please fix your package if you see the
'logrotate-user-writable-log-dir' error in the build log as logrotate
won't rotate logs for this package in the future.
cu
Ludwig
--
(o_ Ludwig Nussel
//\
V_/_ http://www.suse.de/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org