Summary: | app-misc/oneko fork | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Simon <sur3> |
Component: | New packages | Assignee: | Default Assignee for New Packages <maintainer-wanted> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | desktop-misc, redblade7 |
Priority: | Normal | Keywords: | EBUILD |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://homepages.uni-paderborn.de/neuron/oneko/ | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
app-misc/oneko-1.3.ebuild
files/oneko-1.3-include.patch app-misc/oneko-1.3.ebuild app-misc/oneko-1.3.ebuild app-misc/oneko-1.3.ebuild app-misc/oneko-1.3.ebuild app-misc/oneko-1.3.ebuild oneko-1.3.ebuild oneko-1.3.ebuild (renamed dependency xext-proto -> xorg-proto) oneko-1.3-sakura-nobsd.patch |
Description
Simon
2017-04-02 06:21:35 UTC
Created attachment 468944 [details]
app-misc/oneko-1.3.ebuild
Created attachment 468946 [details, diff]
files/oneko-1.3-include.patch
Created attachment 468988 [details]
app-misc/oneko-1.3.ebuild
I updated the oneko-1.3.txz a bit more the unistd-patch is now included.
Created attachment 469016 [details]
app-misc/oneko-1.3.ebuild
Added an icon for the desktop-entry for killing oneko.
Created attachment 469018 [details]
app-misc/oneko-1.3.ebuild
changed the Homepage
Created attachment 469020 [details]
app-misc/oneko-1.3.ebuild
More and improved menu icons with transparency.
I just changed some statements about Licensing in the oneko-1.3.txz as i found out the BSD daemon icons are under BSD Daemon License, that was probably also the reason for the bsd-patch to remove them, though i think it is in the hand of the user itselve to only use the -bsd_daemon command line option if he uses bsd/gentoo, therefore i would just left it in for the user to decide how much bsd he is to be conform with that license?! Created attachment 469310 [details]
app-misc/oneko-1.3.ebuild
I updated the license and changed the local USE-Flag to the name bsd-daemon, and if enabled a warning is messaged:
"* You activated the bsd-daemon USE-Flag, be sure to use the bsd-daemon logo only according to BSD Daemon Copyright."
I think that should solve that problem with the daemon. ^^
I also changed epatch to eapply according to EAPI=6.
Also i did a little change on the oneko-man pages from a debian patch to allow whatis/apropos now.
Created attachment 469368 [details]
oneko-1.3.ebuild
I included the Japanese and German man page.
I also changed the License to Artistic-1.0 for compatibility with DFSG.
Comment on attachment 469368 [details]
oneko-1.3.ebuild
It's not really a version bump with a HOMEPAGE/SRC_URI change, is it? Is the original oneko-sakura author unresponsive?
Yes the Maintainer of the Website didn't answer yet, and the Maintainer of oneko itself is unavailable: --- This is the mail system at host mpsrv0.mp.es.osaka-u.ac.jp. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system <mukose@hbar.mp.es.osaka-u.ac.jp>: delivery temporarily suspended: connect to hbar.mp.es.osaka-u.ac.jp[-.-.-.-]:25: No route to host --- Therefore I took over Maintenance. Is anyone planning on adding this ebuild? It's been 2 years. The requirement x11-proto/xextproto doesnt exist anymore. No matter what I try, I cannot get this new ebuild to work. >>> Unpacking source... >>> Unpacking oneko-1.3.txz to /var/tmp/portage/app-misc/oneko-1.3/work >>> Unpacking oneko-cat.png to /var/tmp/portage/app-misc/oneko-1.3/work unpack oneko-cat.png: file format not recognized. Ignoring. >>> Unpacking oneko-dog.png to /var/tmp/portage/app-misc/oneko-1.3/work unpack oneko-dog.png: file format not recognized. Ignoring. >>> Unpacking oneko-tora.png to /var/tmp/portage/app-misc/oneko-1.3/work unpack oneko-tora.png: file format not recognized. Ignoring. >>> Unpacking oneko-sakura.png to /var/tmp/portage/app-misc/oneko-1.3/work unpack oneko-sakura.png: file format not recognized. Ignoring. >>> Unpacking oneko-kill-cat.png to /var/tmp/portage/app-misc/oneko-1.3/work unpack oneko-kill-cat.png: file format not recognized. Ignoring. >>> Unpacking oneko-1.2-sakura-nobsd.patch.bz2 to /var/tmp/portage/app-misc/oneko-1.3/work >>> Source unpacked in /var/tmp/portage/app-misc/oneko-1.3/work >>> Preparing source in /var/tmp/portage/app-misc/oneko-1.3/work/oneko-1.3 ... * Applying oneko-1.2-sakura-nobsd.patch ... 1 out of 2 hunks FAILED -- saving rejects to file oneko.man.rej [ !! ] * ERROR: app-misc/oneko-1.3::localrepo failed (prepare phase): * patch -p1 failed with /var/tmp/portage/app-misc/oneko-1.3/work/oneko-1.2-sakura-nobsd.patch * * Call stack: * ebuild.sh, line 125: Called src_prepare * environment, line 1998: Called eapply '/var/tmp/portage/app-misc/oneko-1.3/work/oneko-1.2-sakura-nobsd.patch' * environment, line 475: Called _eapply_patch '/var/tmp/portage/app-misc/oneko-1.3/work/oneko-1.2-sakura-nobsd.patch' * environment, line 413: Called __helpers_die 'patch -p1 failed with /var/tmp/portage/app-misc/oneko-1.3/work/oneko-1.2-sakura-nobsd.patch' * isolated-functions.sh, line 119: Called die * The specific snippet of code: * die "$@" * * If you need support, post the output of `emerge --info '=app-misc/oneko-1.3::localrepo'`, * the complete build log and the output of `emerge -pqv '=app-misc/oneko-1.3::localrepo'`. * The complete build log is located at '/var/tmp/portage/app-misc/oneko-1.3/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/app-misc/oneko-1.3/temp/environment'. * Working directory: '/var/tmp/portage/app-misc/oneko-1.3/work/oneko-1.3' * S: '/var/tmp/portage/app-misc/oneko-1.3/work/oneko-1.3' How do I attach my own log file to someone else's bug so I dont get the mess above? Thanks for the error reports, it seems xext-proto was renamed to xorg-proto and the no-bsd-patch was removed from the current version of oneko in portage. I will look into this and fix it. PS: You can send log-files using the "Add an attachment"-link above. Well this is weird, the nobsd patch was removed from the files but I cant find a commit removing it and it is still referenced in the current oneko ebuilds in portage, this is a bug in the current oneko ebuilds in portage it seems.. Created attachment 587738 [details]
oneko-1.3.ebuild (renamed dependency xext-proto -> xorg-proto)
Created attachment 587740 [details, diff]
oneko-1.3-sakura-nobsd.patch
I updated the ebuild and also added the missing nobsd patch. BTW this is marked as maintainer-wanted, so what would it need to take over maintenance for me? (In reply to Simon from comment #20) > I updated the ebuild and also added the missing nobsd patch. > BTW this is marked as maintainer-wanted, so what would it need to take over > maintenance for me? Sorry I wasn't more clear about this. You created a fork of the original oneko project and then requested through this bug report that the maintainers of app-misc/oneko would switch to your fork, instead of asking for a new app-misc/oneko-<fork> package to be created. I addressed that problem a few days ago by setting the [Component] field of this bug report to "New package": so far it is should not be regarded as an update to an existing package (app-misc/oneko). I also added a new app-misc/oneko ebuild that uses Debian sources (patch level 6) and Debian's patchset (level 14): =app-misc/oneko-1.2_p6_p14. >I also added a new app-misc/oneko ebuild that uses Debian sources (patch level 6) and Debian's patchset (level 14): =app-misc/oneko-1.2_p6_p14.
Those patches are included in oneko-1.3 already except the bsd-removal patch.. (see last sentence below).
Maybe you're right and it is a fork, but I thought a continuous numbering would make sense, hence version 1.3. Though I dont rly think it is a fork, I rather see it as an iteration because previous upstream seems to be dead (hopefully not literal) as I tried to contact but no one would be reachable or responding, I mean fork literally means there would be an other alternative iteration, otherwise its not a fork but a straight development. Even more there seems to not have been a continuous previous upstream at all but a multitude of authors and patches. What could be the fork though is that I put an actual licensing on it as there seem to have been a lot of confusion about the actual licensing of the program and its content. Regarding the content I also would vote for a use flag rather than a removal of the BSD-daemon as Gentoo is heavily related to BSD compared to other linux distros, isn't it?
|