Bug 92854 - New Package: k9copy-0.2
|
Bug#:
92854
|
Product: Gentoo Linux
|
Version: 2005.0
|
Platform: All
|
|
OS/Version: Other
|
Status: RESOLVED
|
Severity: enhancement
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: media-optical@gentoo.org
|
Reported By: spammail01@gmx.net
|
|
Component: Ebuilds
|
|
|
URL:
http://k9copy.free.fr
|
|
Summary: New Package: k9copy-0.2
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2005-05-16 19:25 0000
|
a ebuild for k9copy + the ebuild for a modified version of vamps which i
entitled vamps-k9copy. another issue is that the homepage doesn't allow direct
downloads and i don't know if emerge supports referer settings. that's why i
mirrored it on my homepage. that won't matter if the package gets accepted and
it's distributed by the mirrors.
Florian, please NEVER attach tarballs to portage, only plain text files. No
digests or Manifests or ChangeLogs either -- ONLY ebuilds and patches. Reopen
when fixed.
in k9copy.ebuild is a mistake:
DEPEND="media-video/dvdauthor
media-video/vamps-k9copy
media-video/vamps-k9copy is not a depend of k9copy. I have the original vamps
installed. The better way is an Use-Flag.
work ok for me , compiled perfectly
gentoo 2005.1, x86
Please provide an updated ebuild for this application.
Created an attachment (id=61126) [details]
updated version 0.3b (2005-06-11)
works with standard vamps-0.97
the ebuild works but i get the following errors and i don't know how to fix
this:
>>> Unpacking k9copy-0.3b.tar.gz to /var/tmp/portage/k9copy-0.3b/work
/usr/portage/eclass/base.eclass: line 37: cd:
/var/tmp/portage/k9copy-0.3b/work/k9copy-0.3b: No such file or directory
/usr/portage/eclass/kde.eclass: line 54: cd:
/var/tmp/portage/k9copy-0.3b/work/k9copy-0.3b: No such file or directory
find: /var/tmp/portage/k9copy-0.3b/work/k9copy-0.3b: No such file or directory
sed: can't read -: No such file or directory
>>> Source unpacked.
it's because if you unpack the v0.3b tar.gz file it creates a directory called
k9copy-0.3 instead of k9copy-0.3b...
If this bug is being fixed, would it be a good idea to bring this ebuild into
portage?
It's easier for the users then to test k9copy ebuild and program, so there
should be more feedback.
Created an attachment (id=61239) [details]
updated version 0.3b (2005-06-11) [updated]
after looking at the enemy-territory-truecombat ebuild i saw a way to fix the
previous error messages by using the src_unpack() function. here's an updated
ebuild for version 0.3b
FYI: I just have emerged k9copy 1.0.0 with ~amd64 and copied a DVD9 to a DVD5
ISO. I did burn the stuff with k3b, and now I have a perfect copy on a RW-DVD5.
I tried to install k9copy with the last ebuild, but i had a problem:
I don't use kde, so in my USE flags there is "-arts", but configure stopped,
telling me to use --without-arts
I solved the problem using:
kde_src_compile
insted of:
econf || die "econf failed"
emake || die "emake failed"
*** Bug 110037 has been marked as a duplicate of this bug. ***
at least one think i learned from the duplicate ebuild: the direct download url
from k9copy.free.fr seams to work again :) so the SRC_URI in my ebuild should be
changed to the one from Leo:
SRC_URI="http://k9copy.free.fr/${P}.tar.gz"
so can we have this ebuild into portage?
Shouldn't the last ebuild depend of vamps ? I will commit this soon
fejf@fejfs:[~] > equery files k9copy
* Contents of media-video/k9copy-1.0.0:
[...]
/usr/bin/k9copy
/usr/bin/k9playcell
/usr/bin/k9vamps
seams as the author put it's own version of vamps inside k9copy-1.0.0.tar.gz :)
but at the moment i'm not sure why i initially added media-video/mjpegtools and
media-sound/toolame and Carsten Lohrke didn't ;)
(In reply to comment #21)
> seams as the author put it's own version of vamps inside k9copy-1.0.0.tar.gz :)
And that sucks badly from the maintenance point of view. Would be nice if
someone would tell the author that this means more work for distributions in
case of security issues - not to mention that such included dependencies are
easily overlooked.
Hi all... I think that the new ebuild has a little "bug"... it is almost empty
compared to the "updated ebuild for version 1.0.0"
Maybe it is missing some parts ;-)
Leo
the emptiness is not a problem :) because it uses kde eclass. I just need the
dependencies tested and this package tested before commit into portage.
When you say you need them tested, what do you mean?
If I already tested it you will add it to portage?
Or you need some certified Gentoo developer to test it?
Cheers!
(In reply to comment #25)
> When you say you need them tested, what do you mean?
> If I already tested it you will add it to portage?
> Or you need some certified Gentoo developer to test it?
>
> Cheers!
You sound a little harsh to me. Gentoo is about QA too and i will not commit a
new package without test it extensively. This means you'll have to wait a little
bit. Everyone feel free to test it and commment here.
The ebuild works, and the app is stable enough for me. amd64, kde 3.5.0-beta2.
But I think the "k9vamps" approach is unacceptable for gentoo, we don't need two
copies of the same application coming from different ebuilds. If this comes from
upstream, there should be a way to make it use the standard vamps (configure flags?)
I'm sorry Luis Medinas, I was not tring to be harsh, I just wanted to know what
do you mean when you say it needs to be tested. I use gentoo, but I'm not
involved in the development or testing, at least not officially or intensively.
I don't really know what the rules are. So my question, do the testers have to
be part of the developing team? I tested it and it works just fine and the
dependencies work fine too.
Cheers!
about the k9vamps: as far as i can see the author of k9copy changed the .c to
.cpp and modified about 30-50 lines of the vamps-0.97 source. so i think it
isn't possible to do sth. like "emerge vamps && ln -s vamps k9vamps" instead...
(In reply to comment #29)
> about the k9vamps: as far as i can see the author of k9copy changed the .c to
> .cpp and modified about 30-50 lines of the vamps-0.97 source. so i think it
> isn't possible to do sth. like "emerge vamps && ln -s vamps k9vamps" instead...
I did not imply you could simply use vamps instead k9vamps (I didn't looked at
the code). It would be much better if the author of k9copy would have sent the
author of vamps some patches, if needed, instead integrating it.
(In reply to comment #30)
> I did not imply you could simply use vamps instead k9vamps (I didn't looked at
> the code). It would be much better if the author of k9copy would have sent the
> author of vamps some patches, if needed, instead integrating it.
>
The original author of vamps made it on C and the k9copy author ported vamps to
C++ and made some changes. I think vamps was made in C because it has other
purpose than to be used by k9copy, which is in C++. That's why vamps was ported
to C++. I personally think the approach is ok. What the k9copy author needed was
a C++ port not a patched vamps.
Version 1.0.1 is available.
Changelog:
v 1.0.1
- makes use of libK3bDevice for devices detection
- fix some compile problems
(In reply to comment #32)
> Version 1.0.1 is available.
>
> Changelog:
> v 1.0.1
> - makes use of libK3bDevice for devices detection
> - fix some compile problems
I was able to emerge version 1.0.1 without problems. But i can't run it. I only
see a window for 10ms and then i get a Segmentation fault.
emerge info:
Portage 2.0.51.22-r3 (default-linux/x86/2005.0, gcc-3.3.5-20050130,
glibc-2.3.5-r0, 2.6.12-gentoo-r4 i686)
=================================================================
System uname: 2.6.12-gentoo-r4 i686 Intel(R) Pentium(R) 4 CPU 3.40GHz
Gentoo Base System version 1.6.13
dev-lang/python: 2.3.5
sys-apps/sandbox: 1.2.10
sys-devel/autoconf: 2.13, 2.59-r6
sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils: 2.15.92.0.2-r10
sys-devel/libtool: 1.5.20
virtual/os-headers: 2.6.11-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O3 -march=pentium4 -fomit-frame-pointer -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env
/usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config
/usr/lib/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/
/usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/
/usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/env.d"
CXXFLAGS="-O3 -march=pentium4 -fomit-frame-pointer -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://distfiles.gentoo.org
http://distro.ibiblio.org/pub/Linux/distributions/gentoo"
LINGUAS="de"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.de.gentoo.org/gentoo-portage"
USE="x86 X a52 aac alsa apache2 apm audiofile avi berkdb bitmap-fonts bzip2 cdr
crypt cups curl directfb divx divx4linux dts dvd dvdread eds emboss encode esd
exif expat fam fame ffmpeg firefox foomaticdb fortran gd gif glut gphoto2 gpm
gstreamer gtk gtk2 idn imagemagick imlib ipv6 java jpeg junit kde lcms libg++
libwww mad mhash mikmod mjpeg mmx mmx2 mng motif mp3 mpeg mysql ncurses nls nptl
nvidia ogg oggvorbis opengl oss pam pcre pdflib perl php png python qt quicktime
readline samba sdl spell sse sse2 ssl tcpd tetex tex theora tiff truetype
truetype-fonts type1-fonts udev usb userlocales vorbis win32codecs xine xml2
xmms xv xvid zlib linguas_de userland_GNU kernel_linux elibc_glibc"
Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS
stack trace:
(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 27590)]
0xb6c3cc5e in waitpid () from /lib/libpthread.so.0
#0 0xb6c3cc5e in waitpid () from /lib/libpthread.so.0
#1 0xb792b8ac in ?? () from /usr/kde/3.4/lib/libkdecore.so.4
#2 0xb784e59f in KCrash::defaultCrashHandler ()
from /usr/kde/3.4/lib/libkdecore.so.4
#3 0x00000000 in ?? ()
#4 0x00000003 in ?? ()
#5 0xffffffb6 in ?? ()
#6 0xbfbb73e0 in ?? ()
#7 0x00000000 in ?? ()
#8 0x00000001 in ?? ()
#9 0x00000002 in ?? ()
#10 0x082bcde0 in ?? ()
#11 0x00000004 in ?? ()
#12 0x00006bc9 in ?? ()
#13 0x00000400 in ?? ()
#14 0x00000400 in ?? ()
#15 0xbfbb74b0 in ?? ()
#16 0xbfbb72c0 in ?? ()
#17 0xbfbb7358 in ?? ()
#18 0xb7258c55 in QTextLayout::endLine () from /usr/qt/3/lib/libqt-mt.so.3
#19 0x00000006 in ?? ()
#20 0xb748927b in QString::QString () from /usr/qt/3/lib/libqt-mt.so.3
version 1.0.1b available, i (and many other people) will be happy if it will be
in portage...
provide a new ebuild and test it please
Created an attachment (id=74186) [details]
k9copy-1.0.1b.ebuild
Ebuild for 1.0.1b is here. Just 2 notes:
1) needed to use direct URL since using file.php got issues with some
mirrors/wrong filename of saved package. (file.php?....)
2) the filename of the package is 1.0.1 since programmers just overwrited
1.0.1 package, however this is 1.0.1b version.
Works great for me. Could this be added to Portage in ~x86? There are no
similar
applications in the tree AFAIK.
well for me it works like a charm... a ***must*** have in portage :D
alright the package is in cvs
Next time please provide a ebuild with fixed headers and whitespaces :P
The maintainers will be from media-optical herd.
