I created an ebuild for hibiscus and will try to push it into sunrise soon. Reproducible: Always
Created attachment 259052 [details] Initial ebuild Attaching the initial ebuild (not reviewed yet and still installs binary-package of Eclipse BIRT)
I wanted to comment on common problems I saw in the dependency ebuilds, so I chose the root bug to avoid duplication The ones using ejavac for compilation can make use of java-pkg-simple eclass which simplifies compiling a tree of java code. I also see explicit unzip calls in src_prepare phases, apart from being in wrong phase (as opposed to src_unpack) is there a need for explicit definition of unpack code? Regards, Serkan
Created attachment 259071 [details, diff] Patch to fix compilation against hbci4java-2.5.12 This patch is needed so hibiscus compiles. Strangly, hibiscus seams not to use official hbci4java release 2.5.12 API. I will contact upstream about this issue.
Created attachment 259072 [details, diff] Patch location of hbci4java chipcard driver This patch allows hibiscus to find the chipcard-driver installed by the hbci4java ebuild under /usr/lib
(In reply to comment #2) > I wanted to comment on common problems I saw in the dependency ebuilds, so I > chose the root bug to avoid duplication > > The ones using ejavac for compilation can make use of java-pkg-simple eclass > which simplifies compiling a tree of java code. I also see explicit unzip calls > in src_prepare phases, apart from being in wrong phase (as opposed to > src_unpack) is there a need for explicit definition of unpack code? Thanks for your comments, I will take a look on it later.
Hibiscus 2.0 has been released. Any updates on this ebuild?
(In reply to comment #6) > Hibiscus 2.0 has been released. > Any updates on this ebuild? Hi, I started working on it. Expect an working ebuild in 1-3 days (depending on when I find some time for it).
Sorry, currently I do not have much time. I hope next week.
(In reply to comment #6) > Hibiscus 2.0 has been released. > Any updates on this ebuild? I now managed to work again on the ebuilds and I have an initial ebuild for 2.4.2 in place. You can find it in my overlay at https://gitorious.org/hibiscus-gentoo-overlay/hibiscus-gentoo-overlay I will now start pushing ebuilds to sunrise.
Thanks for your ebuild! I've the following problem emerging hibiscus: -- cut compile: [mkdir] Created dir: /var/tmp/portage/dev-java/jameica-2.4.0/work/jameica/releases/2.4.0-0/tmp/bin [javac] Compiling 301 source files to /var/tmp/portage/dev-java/jameica-2.4.0/work/jameica/releases/2.4.0-0/tmp/bin [javac] /var/tmp/portage/dev-java/jameica-2.4.0/work/jameica/src/de/willuhn/jameica/gui/calendar/DayRendererImpl.java:232: cannot find symbol [javac] symbol : method setMargins(int,int,int,int) [javac] location: class org.eclipse.swt.custom.CLabel [javac] label.setMargins(0,0,0,0); [javac] ^ [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. [javac] 1 error -- cut and here further infos GENTOO_VM=sun-jdk-1.6 CLASSPATH="" JAVA_HOME="/opt/sun-jdk-1.6.0.43" JAVACFLAGS="-source 1.5 -target 1.5" COMPILER="javac" # emerge --info =jameica-2.4.0 Portage 2.2.0_alpha176 (default/linux/amd64/13.0/desktop/kde, gcc-4.6.3, glibc-2.15-r3, 3.7.10-gentoo x86_64) ================================================================= System Settings ================================================================= System uname: Linux-3.7.10-gentoo-x86_64-AMD_Athlon-tm-_64_X2_Dual_Core_Processor_6000+-with-gentoo-2.1 KiB Mem: 8183284 total, 1001172 free KiB Swap: 10490408 total, 10490344 free Timestamp of tree: Mon, 27 May 2013 09:45:01 +0000 ld GNU ld (GNU Binutils) 2.22 app-shells/bash: 4.2_p37 dev-java/java-config: 2.1.12-r1 dev-lang/python: 2.7.3-r3, 3.2.3-r2 dev-util/cmake: 2.8.9 dev-util/pkgconfig: 0.28 sys-apps/baselayout: 2.1-r1 sys-apps/openrc: 0.11.8 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.9.6-r3, 1.10.3, 1.11.6, 1.12.6 sys-devel/binutils: 2.22-r1 sys-devel/gcc: 4.6.3 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.7 (virtual/os-headers) sys-libs/glibc: 2.15-r3 Repositories: gentoo kde-sunset java personal hibiscus-gentoo-overlay dev-jokey sunrise ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/maven-bin-3.0/conf /usr/share/openvpn/easy-rsa /usr/share/polkit-1/actions /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.4/ext-active/ /etc/php/cgi-php5.4/ext-active/ /etc/php/cli-php5.4/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage/distfiles" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms splitdebug strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="ftp://ftp6.uni-muenster.de/pub/linux/distributions/gentoo http://distfiles.gentoo.org" LANG="de_DE.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/kde-sunset /var/lib/layman/java /opt/personal-portage /opt/hibiscus-gentoo-overlay /var/lib/layman/jokey /var/lib/layman/sunrise" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="7zip X a52 aac acl acpi alsa amd64 berkdb bluetooth branding bzip2 cairo cdda cdr cli consolekit cracklib crypt cups cxx dbus declarative dri dts dvd dvdr emboss encode exif fam firefox flac fortran gdbm gif gpm gtk iconv ipv6 java jpeg jpeg2k kde kipi lcms ldap libnotify mad mmx mmxext mng modules mp3 mp4 mpeg mtp mudflap multilib mysql ncurses nls nptl nsplugin ogg oggvorbis opengl openmp pam pango pcre pdf phonon plasma png policykit ppds qt3support qt4 readline samba sdl semantic-desktop session spell sse sse2 ssl startup-notification svg tcpd tiff truetype udev udisks unicode upower usb vorbis wxwidgets x264 xcb xcomposite xinerama xml xscreensaver xv xvid zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="canon ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="de en" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-3" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2" RUBY_TARGETS="ruby18 ruby19" USERLAND="GNU" VIDEO_CARDS="nvidia vesa fbdev nv" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
(In reply to Martin Fernau from comment #10) > Thanks for your ebuild! > > I've the following problem emerging hibiscus: > > -- cut > compile: > [mkdir] Created dir: > /var/tmp/portage/dev-java/jameica-2.4.0/work/jameica/releases/2.4.0-0/tmp/bin > [javac] Compiling 301 source files to > /var/tmp/portage/dev-java/jameica-2.4.0/work/jameica/releases/2.4.0-0/tmp/bin > [javac] > /var/tmp/portage/dev-java/jameica-2.4.0/work/jameica/src/de/willuhn/jameica/ > gui/calendar/DayRendererImpl.java:232: cannot find symbol > [javac] symbol : method setMargins(int,int,int,int) > [javac] location: class org.eclipse.swt.custom.CLabel > [javac] label.setMargins(0,0,0,0); > [javac] ^ > [javac] Note: Some input files use unchecked or unsafe operations. > [javac] Note: Recompile with -Xlint:unchecked for details. > [javac] 1 error > -- cut I remember that there were some incompatibilities regarding different SWT versions. Which version of dev-java/swt is installed on your system? Did you enable java-overlay?
http://gpo.zugaina.org/Search?search=hibiscus there seems to be no ebuild on sunrise anymore. Was there a general problem with the ebuild? Where can one find the latest experimental ebuild for hibiscus?
(In reply to Jonas Stein from comment #12) > http://gpo.zugaina.org/Search?search=hibiscus there seems to be no ebuild on > sunrise anymore. Was there a general problem with the ebuild? Where can one > find the latest experimental ebuild for hibiscus? Hi. You can find my current ebuilds for Jameica and Hibiscus 2.6.0 on in my overlay at https://gitorious.org/hibiscus-gentoo-overlay/hibiscus-gentoo-overlay/ The general problem with Jameica is its dependency on Eclipse libraries, which are complex to build and afaik there is no ebuild for it available on Gentoo. In my ebuilds I build everything from source except those Eclipse libraries. My plan is to push all other dependencies to Sunrise, though. But I did not have the time to polish them up, yet.
The dependency on bug #325271 (eclipse) should rather be on bug #350662 (jameica), because it is not a direct dependency of Hibiscus.
Furthermore, I would like to see an ebuild for the Eclipse Runtime only (without the SDK), cause it would be overkill to install the whole SDK just because Jameica needs some of its core components.
Yes, the dependency is just so that this bug is taken into account when deciding how Eclipse is brought to the Portage tree.
(In reply to Tom Wijsman (TomWij) from comment #16) > Yes, the dependency is just so that this bug is taken into account when > deciding how Eclipse is brought to the Portage tree. Ah, I see.
This bug has many completely stalled dependencies. I added myself to each of them. Let’s close this bug, and finally have proper FinTS banking on Gentoo! :)
(In reply to Navid Zamani from comment #18) > This bug has many completely stalled dependencies. I added myself to each of > them. Let’s close this bug, and finally have proper FinTS banking on Gentoo! > :) There are mainly two problems why there is not much progress on this bug and its dependencies: 1.) I created most of the required ebuilds and I would definitely love to work more on this, but I do not have much time currently. I am not a official Gentoo developer yet so I would need a mentor and plenty of time to bring this into the main tree. I am not expecting this to happen soon. 2.) Hibiscus resp. Jameica heaviy depends on Eclipse Runtime libraries and there has not been much progress in packaging recent versions of this in Gentoo (bug #325271). From what I hear it is difficult to package and without it Hibiscus won't land in main tree. But regardless of 2.) you could definitely help on 1.) and improve the ebuilds I created and try to get more of the dependencies into sunrise or even the main tree. If you have a good knowledge in Java packaging and the eclipse eco system you can probably also help with 1.).
I just found out that the pre-compiled Jameica from the original site runs flawlessly on Gentoo. So I think a jameica-bin ebuild would be a nice workaround for now. (Nobody likes Eclipse/eclipse-sdk anyway, boo! ;) (Or how about putting eclipse-sdk in /opt/ and letting it in whatever sorry unpackagable state I’m sure it is. ^^) But then I found out, that my card (RSA/Starcos) is not supported by Hibiscus anyway. (And even though it’s supported in aqbanking, the creation dialog doesn’t support it either. Finally, even though aqhbci-tool4 supposedly can use those cards, the correct command fails with a useless error with no known solutions online. And that’s where I draw the line.) So until it is, I frankly am not interested in Hibiscus anymore. Sorry to have jumped the gun. It’s my stupid bank’s stupid card’s fault. I’ll be back, when Hibiscus gets RSA support or I’ve moved to a better bank (or away from all banks forever, preferably).
I am planning to work on this again. I moved my overlay to an user overlay on Gentoo's infrastructure: https://gitweb.gentoo.org/user/hibiscus.git/ If you have layman, you can just add it with layman -a hibiscus But notice that emerging hibiscus will probably fail until I fix some issues. I will let you know if you can give it a try.
As far as I can tell, the community interest in getting Hibiscus into Portage seems to have let up. Quite frankly, I'm afraid this will never hit the tree. I think the same applies for the dependent bugs. However, you can still host those ebuilds in your overlay. What do you think?
(In reply to Patrice Clement from comment #22) > As far as I can tell, the community interest in getting Hibiscus into > Portage seems to have let up. Quite frankly, I'm afraid this will never hit > the tree. I think the same applies for the dependent bugs. However, you can > still host those ebuilds in your overlay. What do you think? The interest of the Gentoo community for Hibiscus was in my view always quite low. The main motivation for working on this is rather my own personal use of Hibiscus on Gentoo. Getting this into the Portage main tree was my original goal, but currently I prefer to have just working ebuilds in the overlay which are easy to find for the few other people of Hibiscus on Gentoo (who also want to build from source). I will see in the next days if it is possible for any of those bugs to every be fixed and close them otherwise.
(In reply to Fabian Köster from comment #23) > The interest of the Gentoo community for Hibiscus was in my view always > quite low. Obviously, with HBCI being a German-only thing, as far as I can tell. Also, the one advantage of Hibiscus that I knew, which was that it could actually do real online banking, as opposed to what Gnucash/KMyMoney did, went away, due to those programs being able to do it now, even with more complicated setups. > I will see in the next days if it is possible for any of those bugs to every > be fixed and close them otherwise. It would be nice, if I could keep track of the state of the ebuilds in your overlay via these existing bugs here. Maybe in that way it’s useful for you too. And if you decide you won’t fit them, can you please do it in a way that allows anyone (like me) to come back later, and fix the bugs? I’d be thankful. :) <details> I never encountered any sense in the concept of calling bugs “closed”, when the problem still exists. All I saw, was that people wanted to say “I don’t *want* to do this / don’t care”, but there was no option for that, they didn’t have the character to be that direct, or they themselves weren’t even ware of it. As if it wasn’t OK to say NO, even though this isn’t paid/slave labor… (Or is the “WONTFIX” choice meant for that purpose? I always understood it to mean something different…) </details> P.S.: You’re not related to Gerd Köster, are you? :)
> > I will see in the next days if it is possible for any of those bugs to every > > be fixed and close them otherwise. > > It would be nice, if I could keep track of the state of the ebuilds in your > overlay via these existing bugs here. Maybe in that way it’s useful for you > too. > > And if you decide you won’t fit them, can you please do it in a way that > allows anyone (like me) to come back later, and fix the bugs? I’d be > thankful. :) We can agree on that, I will keep the bugs open and report any progress or major problems here. > <details> > I never encountered any sense in the concept of calling bugs “closed”, when > the problem still exists. All I saw, was that people wanted to say “I don’t > *want* to do this / don’t care”, but there was no option for that, they > didn’t have the character to be that direct, or they themselves weren’t even > ware of it. As if it wasn’t OK to say NO, even though this isn’t paid/slave > labor… > (Or is the “WONTFIX” choice meant for that purpose? I always understood it > to mean something different…) > </details> Yes, I think the "WONTFIX" state is intended for the cases where a bug is existent but it was decided to be not important enough to get fixed. Many projects want to keep the number of "open" bugs low and only count the "real" bugs into the statistics. I think the Gentoo policy is different here, there are many "OPEN" bugs and the developers use different criteria for finding the "relevant" bugs. So it is probably ok to leave it open as long as it could be fixed by someone. > P.S.: You’re not related to Gerd Köster, are you? :) No, I am not related to him or his cousin Gaby :-)
Sorry for spoiling your party folks but we're trying to reduce the number of bugs assigned to Java as much as possible. :) It's one of the reasons why I pinged you about it. There's really no point in keeping this bug (and its dependencies) open forever. We already have dozens of bugs who are way older than this one and often, developers are gone, the industry has moved on or the project is dead. If it hasn't made it yet into Portage, IMHO it never will. Better to close the bug and move on. (In reply to Fabian Köster from comment #23) > The interest of the Gentoo community for Hibiscus was in my view always > quite low. The main motivation for working on this is rather my own personal > use of Hibiscus on Gentoo. > As I said, the momentum for getting this software into Portage seemed to have somewhat petered out and it would be best to keep your work and your ebuilds in a separate overlay. Since you're the only person interested in hbci and unless a bunch of people are pushing together and do want hbci in Portage, we are going to close these bugs as WONTFIX. If you're looking for issue tracking, email notifications and that sort of fancy thing, you should create a Github account and host the overlay there.
Marking as WONTFIX as per previous comment. You can still access those ebuilds using layman and adding the hibiscus overlay: https://gitweb.gentoo.org/user/hibiscus.git/
