quasar is an accounting package, a very good one at that. I will attach the ebuild and patches required to build and install quasar in short order, if we can please get it into portage so that this great tool can be exploited by the masses. Reproducible: Always Steps to Reproduce:
Created attachment 52381 [details, diff] Patch to make quasar compile with gcc-3.4.x
Created attachment 52382 [details, diff] Patch to make quasar compile correctly on amd64 This patch resolves some casting issues and linking problems (-fPIC)
Created attachment 52383 [details] ebuild for quasar-1.4.1 This is an ebuild to build quasar-1.4.1, I suggest app-office/quasar, the two patches needs to be in the files dir. This ebuild works for me on both amd64 and x86. Things that is missing at this point: - startup scripts (/etc/init.d/quasar) - environment path settings (usr /opt/quasar/bin/quasar to run quasar)
hanno: you seem to maintain a number of banking/finance apps, would like this too?
Sorry, not interested, I'm only maintaining the hbci-stuff for german online-banking.
Created attachment 54364 [details] updated quasar-1.4.1 ebuild Updated ebuild. This version gets a lot more of the permissions right. The correct way would probably be to disect the install script and duplicate it but that imho is way more error prone. The permissions and ownership should be ok. One should also add /opt/quasar/config to the CONFIG_PROTECT variable in /etc/make.conf I also added a message about instability issues on amd64, not sure whether this is due to the fact that I tried against a 32-bit server though, will check again and get back with more details.
Created attachment 54367 [details] environment file to put quasar in the PATH
Created attachment 54368 [details, diff] Patch to make passwords of arbirary lengths possible
I tried out quasar 1.4.3. They modified the code to compile on gcc3.4, and it just successfully compiled on amd64 without the amd64 patch. It does have a (new?) dependency on dev-libs/icu. I just coppied the 1.4.1 ebuild to 1.4.3, but the patches weren't applying properly. Since I didn't need the gcc and amd64 patches, I just commented them out of the ebuild - I can live with an 8-character password for now. Thanks for taking on this effort - I really like quasar so far.
Correction from my previous post... the amd64 patch is still required. I forgot that I was compiling in my chroot environment.
I couldn't get to their site the past week or so, which is why I built the updated ebuild on 1.4.1 so I'll go get 1.4.3 asap. One thing though - are you successfully running quasar on amd64? Mine kept segfaulting, but I was using my 32-bit system as server. My amd64 patch was required to just get it to compile, so it should not have made a difference whether you were chrooted or not. That 8-char password is a bastard since it doesn't (didn't) enforce it when you change it, so what happened is I actually set a password of 11 chars and then couldn't get back into my company!
My status so far: When the quasar server is run on amd64, the client application can't log in. (It reports authentication error). This happens from both a 32-bit client and a 64-bit client. When the server is run on a standard 32-bit x86, a 32-bit client connects without issues. The 64-bit client connects successfully the first time, and segfaults after that. I've found that if you delete the <user-dir>/.quasar/cache/<server>/screens/default.xml file, then you can again reconnect. The location of the database does not seem to make any difference. Also, I was unable to get the server to use firebird on amd64 - it worked properly on the 32-bit machine, however. I was able to get everything working on an amd64 box by using a 32-bit chroot environment. I will be posting these issues to the support email at
Seems like 64-bit is going to cause some problems in the near future. Right, there is a USE flag for firebird and for postgres, I'll also update the ebuild to force selection of at least one of these two as soon as I get round to it (just need to do some kernel upgrades here quickly - or not so quickly since my notebook requires some custom hacking ...).
Created attachment 55139 [details] ebuild for quasar-1.4.3 Only patch that is still required is the amd64 one. Everything else seems good (look like they fixed the password length problem in 1.4.3). Still compiling on x86 but it looks like this should do the trick. Also added some use flags (btw, firebird is marked disabled on my amd64 so I assume we will have to use postgres if we can make this work on amd64), namely firebird, postgres and doc. If you know how to get debugging going, please inform me, cause I'm unable to get any kind of stack traces or any kind of information as to where exactly it crashes. Albeit I'm highly suspicious of the Variant.{h,cpp} files. As an alternative we *might* get away with compiling it 32-bit. I'd love to get it working on my amd64 though. The icu requirement is currently still masked - we need at least 3.2, icu-2.8 causes the quasar build to fail.
The 32-bit compile works on my amd64 box, unfortunately I need to run it in a 32-bit chroot environment, or else it complains about missing shared libraries. I have an init script that starts the application in the chrooted environment. It uses another script I created a while back that automates going into and out of the 32-bit chroot. I'm attaching those - not sure if they really belong here, though.
Created attachment 55205 [details] A script to manage switching into a 32-bit chroot This is relatively generic... make sure to modify the MOUNT_ROOT variable to point to your mount point.
Created attachment 55207 [details] Init script for quasar
I just found this list and am glad to help in any way to get Quasar compiling better on Gentoo. I've been reviewing the patches here and the amd64 one, while fixing compiling on 64bit systems, breaks compiling on 32bit systems since its using size_t to act as an unsigned 64bit int which it is on 64bit systems but on 32bit systems its basically an unsigned long which means the Variant(size_t) constructor conflicts with the Variant(unsigned long) constructor. A better fix it to add a typedef for unsigned 64bit ints to fixed.h called uint64 and then use that in variant.h/cpp. I think that will fix the 64bit compiling and will work properly on 32bit systems as well though I can only test on 32bit since I don't have a 64bit system to test with. I believe though that Firebird compiling on 64bit systems is broken so I'm not sure you will be able to get that working but PostgreSQL should work. I'm looking into the need for -fPIC now since qmake is supposed to handle those details for us and I'm working on making the install script setup permissions better and am planning to make it so you can install Quasar easily either in /opt like it does now or else in a more file system standard way using /etc for config files, /usr/bin for programs, and so on. Let me know if there is anything else I can do to make it easier for Quasar to work on Gentoo since I'd love to get it included with Gentoo!
I just dropped a line to the quasar-devel mailing list: http://www.linuxcanada.com/pipermail/quasar-devel/2005-April/000146.html
Created attachment 55314 [details] init script - place in ${FILESDIR}
Created attachment 55315 [details] A more thorough guasar-1.4.3.ebuild The previous two attachments form an updated ebuild. My init script I consider a tad more thorough (only real difference is that it makes use of pidfile instead of a killall quasar type thing - which btw I've seen break when restarting upgrades since the executable is no longer really the same executable). Also, forgot to create the companies dir. Should we make quasard_setup suid quasar? It's either that or have the files in data/companies root:root 600 - which cannot be read when quasard is invoked as quasar. The right permissions imho would be root:quasar 640. Oh yes, the companies directory is now created.
Created attachment 55588 [details] amd64 patch This patch is a generalised patch, and is similar to a patch that is going into 1.4.4 (that patch just has extra code to also take the Windows compiler into consideration and is not yet complete).
Created attachment 55589 [details] Fix SHA1 code Another patch that is required to make quasar run on 64-bit systems. This one fixes a type bug in the SHA1 code that caused authentication failures due to incorrect rotation operations due to incorrect sizes of some types. The patch has been submitted upstream for inclusion in 1.4.4
Created attachment 55591 [details] quasar-1.4.3 ebuild This ebuild is finally stable on amd64 as well as on x86. I don't have the hardware to test on other platforms. It also correctly creates the /var/log/quasar directory for use by quasar to log to. The only problem that I have left is that quasar_setup creates the company files mode 600, owned root:quasar, which if quasar is run as quasar:quasar cannot be read, the fix is to chmod 640 these files after updating them using quasar_setup. Comments and feedback welcome.
Jaco, is it possible to relocate the stuff in /opt to somewhere else? /opt is reserved for binary-only packages in gentoo.
Probably but it'll be hard. I want to get an ebuild out for 1.4.4 (which I'll do in a bit), just to make it available, then I'll get into contact with Brad and check how difficult it would be. I agree, it would be better to have the files in "the right locations".
Created attachment 55979 [details] quasar-1.4.4 ebuild
Created attachment 55980 [details] amd64 patch
I've just attached an ebuild for quasar-1.4.4, please test on x86, amd64 works for me. Also, so the doc pdf files is not yet available (so I've commented them for the moment - they can just be uncommented when docs is available). Gentoo is (to the best of my knowledge) the first distro for which quasar 1.4.4 is available :). I don't think the official announcement has yet been made. The sha1 patch is still required (I submitted it as the 1.4.4 snapshot was being made and as such it has not been included). The patch as used by upstream for fixing the type problems for amd64 is also incorrect - I've submitted the included patch upstream as well.
Created attachment 55992 [details] quasar.amd64.patch Argh, I hate that stupid -fPIC
Created attachment 56031 [details] quasar-1.4.4.ebuild By now I can write a book as to the configuration quirks of quasar. So if anybody gets stuck, first try the following: chown -R quasar:quasar /usr/share/quasar/data/companies/* Also, please follow the instructions in the install guide to the letter with regards to setting up postgresql (although - it can probably be done much better, I'm a n00b with postgres). This ebuild installs binaries in /usr/bin and /usr/sbin, libraries in /usr/lib/quasar, config files in /etc/quasar and most of the other files in /usr/share/quasar. Is this acceptable? If not, I can tinker a bit more, only restrictions is that we will have to use /etc/quasar for config files (not a problem I should reckon) and that each of the direct subdirectories below /usr/share/quasar needs to stay together. To the best of my knowledge the file permissions should be as secure as it's going to get (for now). I'm working with Brad on making the companies xml files root:quasar 640 but for now they are going to be quasar:quasar 600. The same applies to one or two of the config files iff you use the quasar_setup tool.
Created attachment 56703 [details] quasar-1.4.5.ebuild
Created attachment 56704 [details] quasar.fixed.amd64.patch
Created attachment 56705 [details] quasar.fpic.patch
The excellent ebuild mentions that the directory structure is not FSB compliant and welcomes any suggestions for directory placement. I've added a patch for the ebuild that uses directories that are more inline with gentoo-FSB.
Created attachment 56960 [details, diff] patch to quasar-1.4.5.ebuild for better gentoo-FSB compliance Answering the following call from the ebuild # These defines just defines where we would like things to be installed. # This makes for easier changing if/when people tell me that the Gentoo install # of quasar is not fhs compliant (which it probably isn't) Gentoo tends more to FSB aware than FSB compliant but this patch should make the quasar ebuild more FSB aware.
Created attachment 58668 [details] quasar portage overlay quasar portage overlay with all the fixin's, for those impatient few (like me) who can't wait for it to show up in portage. :-)
Now to just actually get it _in_ portage.
Created attachment 58678 [details] quasar portage overlay added changelog, removed ebuild patch file, redigest
Hi! <quote>quasar portage overlay added changelog, removed ebuild patch file, redigest </quote> I'm new with Quasar trying to emerge it on my amd64 box. It looks like 'quasar' script for /etc/init.d is missing from the package :-) I have tried Quasar with postgresql-8.0.02 and everythingwas fine except that client could not see created company. When doing telnet to the server I got: gour@gaura-nitai ~/$ telnet localhost 3599 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. resources companies error: {File type is invalid: companies} I browsed Quasar's archives, but /etc/quasar/* files are OK, but, according to archives, it a perms problem. Any hint? Sincerely, Gour
Hi! I was (finally) able to resolve my issue. The problem was/is that I picked a 'quasar' init.d script which is/was tailored for some older version of Quasar 'cause it starts the daemon with: 'start-stop-daemon --start --quiet --chuid quasar' So, removing '--chuid quasar' solved the problem :-) Maybe some small update to the whole package, ie. quasar overlay can help newcomers avoid the problem ;) Sincerely, Gour
Created attachment 61247 [details] quasar-1.4.6.ebuild Quasar-1.4.6 is mainly a bug release, see Brad's release email for more details (http://www.linuxcanada.com/pipermail/quasar-devel/2005-June/000230.html). I'm also including a printing patch I wrote which makes the printing subsystem act a tad more sane (imho), and also allows for file:// type printing to postscript files using the quasar_report tool. This patch isn't used by default though. To use it, uncomment line 55 of the ebuild ("epatch ${FILESDIR}/quasar.printing.patch") and regenerate the digest by issueing "ebuild quasar-1.4.6.ebuild digest" (This will require you to have downloaded all the files mentioned in SRC_URI even if you have -doc in your USE flags. Regarding the missing init.d script, I haven't changed anything there but etcat report that /etc/init.d/quasar belongs to the quasar package so afaik everything should be good, additionally, we do want --chuid quasar, this makes quasar run as the quasar user instead of as root. The fact that removing --chuid quasar makes it works indicates that there was most likely a permissions issue somewhere. Hopefully the new ebuild fixes all that (I'll need to remerge from clean to confirm - I'll do that a little later). To move your old companies to the new layout as proposed earlier, you will need to manually move the old company files from /usr/share/quasar/data/companies to /var/lib/quasar/data/companies. You should then be able to remove /usr/share/quasar/data from your system without causing harm.
Created attachment 61248 [details] quasar.printing.patch The printing patch as described in the previous comment. It basically makes a few printer settings "sticky" and allows for better printer selection from the command line quasar_report tool. I consider it experimental even though I'm using it myself.
Created attachment 61249 [details] quasar-1.4.6 overlay archive. An archive containing everything you need to merge quasar-1.4.6
Hi! <quote> Regarding the missing init.d script, I haven't changed anything there but etcat report that /etc/init.d/quasar belongs to the quasar package so afaik everything should be good, additionally, we do want --chuid quasar, this makes quasar run as the quasar user instead of as root. The fact that removing --chuid quasar makes it works indicates that there was most likely a permissions issue somewhere. Hopefully the new ebuild fixes all that (I'll need to remerge from clean to confirm - I'll do that a little later). </quote> I emerged 1.4.6 and I get the same error as before, i.e.: gour@gaura-nitai ~ $ quasar Error: Failed to open "./client.cfg" for reading Error: Failed to open "./client.cfg" for reading Failed to find translation for locale hr_HR Error: File type is invalid: companies Failed getting list of companies If I remove '--chuid quasar' it works as before. Sincerely, Gour
Ok, this is probably resident from a previous install, some permission on some directory, sounds like /etc/quasar. So here is some things to check: jkroon@pug jkroon $ ll /etc/quasar -d drwxr-xr-x 2 root quasar 144 Jun 15 08:07 /etc/quasar jkroon@pug jkroon $ ll /etc/quasar total 12 -rw-r--r-- 1 root quasar 180 Jun 15 08:07 client.cfg -rw-r----- 1 root quasar 373 Jun 15 08:07 postgresql.cfg -rw-r----- 1 root quasar 344 Jun 15 08:07 server.cfg jkroon@pug jkroon $ If that doesn't help, perhaps it's best if you mail me offline with the output from "ls -ld $(etcat -f quasar | grep '^/')" (You'll need to do this as root) which will allow me to compare your permissions with mine. It is likely that there is just something small wrong which can break things badly. We can then post back a summary of what was wrong. This is probably the reason why running quasard as root works and as quasar fails. I can't think of anything else and have to admit that I had my hands full trying to get that to work. In the end strace was my friend.
(In reply to comment #46) > Ok, this is probably resident from a previous install, some permission on some > directory, sounds like /etc/quasar. So here is some things to check: > > jkroon@pug jkroon $ ll /etc/quasar -d > drwxr-xr-x 2 root quasar 144 Jun 15 08:07 /etc/quasar My /etc/quasar is 750. However, I tried with 755, but it's the same. > If that doesn't help, perhaps it's best if you mail me offline with the output > from "ls -ld $(etcat -f quasar | grep '^/')" (You'll need to do this as root) > which will allow me to compare your permissions with mine. It is likely that > there is just something small wrong which can break things badly. We can then > post back a summary of what was wrong. OK. I sent you quasar-perms file in the attachment. Hopefully, we can resolve this issue. Sincerely, Gour
Turns out the command needed to fix the problem was: # chmod 755 /var/lib/quasar This was due to the way the previous FSB awareness patch modified things and this directory got created with root:root 750, which obviously (for me at least) should be 755. So fixing that solved the problem.
Created attachment 61513 [details, diff] space_fix.patch Bug fix patch already applied in CVS upstream, see http://www.linuxcanada.com/pipermail/quasar-devel/2005-June/000234.html for more information.
Created attachment 61514 [details] quasar-1.4.6.ebuild Updated ebuild to automatically apply previously attached space_fix.patch.
Created attachment 61515 [details] overlay tar archive for quasar-1.4.6 and of course, the archive ...
Created attachment 63293 [details, diff] tax_alloc.patch
Created attachment 63294 [details] quasar-1.4.7.ebuild ebuild for the new 1.4.7 release of quasar.
Created attachment 63295 [details] tar archive with overlay for quasar-1.4.7 Quasar 1.4.7 has been released, and I missed the release (it was never announced on the mailing lists *growl*). So here it is, rather late than never I always say.
Hey Thanks for working on the ebuild as I have been anxious to try this application. I downloaded the ebuild for 1.4.7 and it fails to merge on my machine. It looks like the code is built without a problem, but I get the following error: >>> Install quasar-1.4.7 into /var/tmp/portage/quasar-1.4.7/image/ category app-office install: invalid user `quasar' touch: cannot touch `/var/tmp/portage/quasar-1.4.7/image///var/log/quasar/.keep': No such file or directory !!! ERROR: app-office/quasar-1.4.7 failed. !!! Function keepdir, Line 335, Exitcode 1 !!! Failed to create .keep in /var/tmp/portage/quasar-1.4.7/image///var/log/quasar it looks like the ebuild is trying to write to a file that has not been created yet...
Weird. If I need to quess I'd say it's the "keepdir /var/log/quasar" that fails, but that just seems wrong, since keepdir attempts to create a .keep inside a newly created /var/log/quasar directory, from the ebuild(5) manpage: dodir <path> Creates a directory inside of ${D}. 'dodir /usr/lib/apache' creates ${D}/usr/lib/apache. Note that the do* functions will run dodir for you. keepdir <path> Tells portage to leave a directory behind even if it is empty. Functions the same as dodir. So now I'm confused. Alternatively, the directory is created as quasar:root with 700. So only the quasar user and root will be able to write there, so it might be that these restrictions apply when emerging as well. But then emerge won't be able to chown the directory so there goes that idea. Right, I'm baffled now.
Oh wait: app-office install: invalid user `quasar' First time you merge quasar. Ok, so it's unable to chown the directory. I never got this since I've already had the quasar user on my system. Don't have time right now but I'll see what I can do about fixing that over the weekend. In the meantime, just comment out the keepdir line and then manually create the /var/log/quasar directory when you're done merging quasar, chown quasar:root and chmod 700 it.
Created attachment 63464 [details] quasar-1.4.7-r1.ebuild Please try this version, you will need to make sure that the quasar user does not exist on your system.
LOL - So much for wating for the weekend... Good thing I looked here, because this morning I thought more about the invalid user and was just about ready to add them manually. Nice job! The new ebuild works like a champ. FYI for anyone wanting to use the latest ebuild, 1. download the tar archive with overlay for quasar-1.4.7 from comment #54. 2. download the new ebuild in comment #58 and save it as quasar-1.4.7-r1.ebuild 3. rebuild the digest for the new ebuild otherwise you'll get verification errors 4. then emerge! Again, great job and thanks for working on this, now I just need to start using this thing so my accountant will be happy ;)
LOL! Yea, having it and using it is two different things. I find taking one night in the week and just doing it makes it easier. Also, if you don't want to download all the documentation (I don't think I've ever read the latest docs from 1.4.2 onwards), in which case just md5sum the new ebuild and replace the checksum in the Manifest file with that. And what can I say - it's a boring job sifting through hundreds of user accounts to make sure there aren't any stale ones, had to do something slightly more challenging for a bit. And on Monday I'll tackle the hard job of migrating the left-over users to ldap and modifying home directories, modifying uid numbers to match up with the rest of the systems and archiving old data ... (not looking forward to it).
It is GREAT to see an ebuild finally - esp. for amd64. The ebuild installed properly once, then quit working (after I installed several qt/kde apps). After that it would not install any database drivers, even though I had postgres enabled in my use flags. I found the problem was that Postgres was not found during the configuration. The fix was to add EXTRA_ECONF="--with-postgresql-inc=/usr", so that quasar found postgres. Thanks a bunch to everyone who got this working on amd64.
That is particularly odd. Can anybody else confirm that? I've lost count of the number of times that I've remerged quasar (ccache is awesome) in order to debug these ebuilds, and quasar itself, and I haven't encountered that problem once. And it's a pleasure :). But most (if not all) credit should go to the developers at linuxcanada.
OK, so I'm thinking a bit about the ebuilds for the quasar accounting package as I'm watching the third build I have done. Thanks again for the work on this Jaco! So, the first two were stand alone workstations for test, now I'm getting to deploy Quasar in a production environment - Server with a mix of 6 workstations connecting, 4 Windows and 2 Linux - and I see a problem in the way the ebuilds work (and perhaps Quasar). Bear with me I'm writing this as I'm reading the documentation again for Quasar, but this is what I see needs to exist for this to be used seriously in production. There need to be two (2) ebuilds: app-office/quasar-server app-office/quasar-client The problem is that I want to build it on my server (with postgres) and do *not* want any of the QT or X11 stuff built. These are not necessry for my server, in fact I don't put any of the X windows stuff on my server - no need. Yet required for the ebuild to work. Secondly, I am going to need to install Quasar on two workstations that do not need to have a database or any other backend capabilities, just the GUI to connect. So, I'm looking and proposing that we take a look at possibly breaking this into seperate ebuilds.
Perhaps two USE flags rather, something like 'serveronly' and 'clientonly'? I suspect you need Qt in any case to build the server - not 100% sure of that one though. But yea, I thought of that problem too, and many other packages suffer the same type of problem (Like openldap and mysql for example), but since most of these packages are command-line only in any case it doesn't matter that much. Suggestions from the Gentoo devs?
I think I am in favor of two separate ebuilds, similiar to the RPM downloads and installs on the Quasar site and noted in the installation documentation. This way the server could have the database dependencies and would make the ebuilds cleaner. I'm not in favor of adding USE flags that are non-standard/undocumented for given packages, there are already way too many packages with "unique" USE flags in portage... A user wanting a stand-alone system would simply need to build both packages, as is done per the installation documentation for RPMs. Now, if someone really wanted to break apart openldap, mysql, samba, et al. that have client and server components, perhaps a standard use flag could be established to install a stand alone system when building the client like perhaps "full" - but that is a different issue. Thanks again
Created attachment 78845 [details, diff] quasar.quasar_report.locales.patch Patch to fix a locale bug in quasar_report. The patch has also been sent upstream.
Created attachment 78846 [details] quasar-1.4.7-r2.ebuild A new ebuild incorporating the locales patch, this means the quasar_report tool is now hopefully actually usable, and will print reports exactly as the report tool from within quasar would've printed it. Also, along with the printing patch it's possible to print directly to a file with the quasar_report tool. As for the split-ebuilds, I can't find an easy to way to compile only part of the whole system. This means that one will need to compile quasar in it's entirety three times. This is due to the way the installer is configured, it's divided into three sections: common server client common would always need to be installed, and then at least server or client to be usefull. common can't be incorporated into both the client and server ebuilds as this would cause file clashes in the installs, nor do we want it in seperate directories due to file duplication. So if you can tell me how to build only the common part, install that and then compile the client and server parts individually, against the already installed common part then I can create the split builds for you. However, as it is you need to compile the entire quasar in any case, in which case you can just as well install the entire thing as well. Which isn't ideal but the best I can do at the moment. Next mission: submitting invoices from an external source - there has been discussion of a perl tool on the quasar-devel list that can possibly achieve this (but accesses the DB directly).
Created attachment 112487 [details, diff] files/quasar.profit_loss.yearend.patch
Created attachment 112491 [details] quasar-1.4.7-r3.ebuild Updated ebuild. Adds a patch for fixing an annoying bug in the profit/loss statement around year-end. Reworks some of the stuff to get work _out_of_ pkg_postinst() and into src_install() - this means that users now gets created in pkg_setup. Also, config files for /etc/quasar is now generated during src_compile and installed during src_install(). Unpacking+patching is now in src_unpack ... the way it should have been in the first place. There are probably other issues I'm missing, please shout. What does it take to volunteer for being a maintainer of a package? Cause atm I'm looking at pushing this and a few other packages into an overlay somewhere. Probably just hosted on www.kroon.co.za in a tbz2 file, or possibly via rsync.
Created attachment 112533 [details, diff] quasar_bank_recon.resize.patch
Created attachment 112534 [details, diff] quasar_cheque_customer.resize.patch
Created attachment 112536 [details, diff] quasar_cheque_customer.single_row_totals.patch
Created attachment 112537 [details, diff] quasar_cheque_vendor.resize.patch
Created attachment 112538 [details, diff] quasar_report_list.resize.patch
Created attachment 112540 [details, diff] quasar_report_list.resize.patch
Created attachment 112542 [details, diff] quasar_setup.resize.patch
Created attachment 112543 [details] quasar-1.4.7.ebuild ebuild containing some GUI fixes. These patches has been submitted upstream but I'm not sure how likely a new version release is going to be at this point in time as the core quasar developers is pushing very hard to get quasar 1.5 out the door. overlay tgz to follow shortly.
Created attachment 112547 [details] quasar_overlay.tgz
Works splendidly, with a couple of dependencies. I followed http://gentoo-wiki.com/HOWTO_Installing_3rd_Party_Ebuilds with latest (2007-03-08) ebuild. * PORTAGE_OVERLAY=/usr/local/portage in /etc/make.conf * Unpacked overlay.tgz into /usr/local/portage/ - creating app-office/quasar/* * set up postgresql as per http://www.gentoo.org/doc/en/postgres-howto.xml * emerge icu * emerge tcl * emerge tk * ebuild /usr/local/portage/app-office/quasar/quasar-1.4.7.ebuild digest ... unpack ... compile ... install ... qmerge psql -U postgres template1 ==# create user quasar createdb; ==# create user quasar_dba createdb; I was then able to use quasar_setup to import a backup (foo.bak) from another Quasar system, all seems good. The docs (PDFs) don't seem to get installed anywhere, though they are in /usr/portage/distfiles and in the image/ dir. I cannot see xpm files either, though IIRC I got them with an earlier handbuilt Quasar.KDE .desktop files, integration into the "K"|"Office" menu would all be niceties :-) I'm attaching the xpms and KDE .desktop files that I've used, in case they save someone some time. Apart from the cosmetic tweaks above, all seems fine, I'd love to see this in portage. Tested on x86, up-to-date gentoo. Thanks Jaco!
Created attachment 114498 [details] XPMs and .desktop files for prettier integration
Hi there, Once you placed the ebuilds correctly in /usr/local/portage and added the PORTDIR_OVERLAY entry you should simply be able to emerge quasar and all the dependencies should be merged automatically. If you set the doc useflag then the pdfs will be merged into /usr/share/doc/quasar-1.4.7. I never did the KDE/Gnome integration since I don't use either. I reckon these additions should probably be added within "if use kde/gnome; then ... fi" sections, and yes, the xpm and desktop files are inside the source archive. If you can tell me where I should place them inside a standard gentoo install then I'll make adjustments to the ebuild.
(In reply to comment #81) > Hi there, > > Once you placed the ebuilds correctly in /usr/local/portage and added the > PORTDIR_OVERLAY entry you should simply be able to emerge quasar and all the > dependencies should be merged automatically. When I tried just "emerge quasar" I got a compilation error because ICU headers were not available; similarly for Tk and Tcl. > > If you set the doc useflag then the pdfs will be merged into > /usr/share/doc/quasar-1.4.7. Great! Missed that in the docs. > > I never did the KDE/Gnome integration since I don't use either. I reckon these > additions should probably be added within "if use kde/gnome; then ... fi" > sections, and yes, the xpm and desktop files are inside the source archive. Missed those too :-) > If you can tell me where I should place them inside a standard gentoo install then > I'll make adjustments to the ebuild. 'Fraid I don't know either... Looking forward to 1.5 when it appears! Thanks again, Thomas.
(In reply to comment #82) > (In reply to comment #81) > > Once you placed the ebuilds correctly in /usr/local/portage and added the > > PORTDIR_OVERLAY entry you should simply be able to emerge quasar and all the > > dependencies should be merged automatically. > > When I tried just "emerge quasar" I got a compilation error because ICU headers > were not available; similarly for Tk and Tcl. Strange: DEPEND=">=dev-lang/tcl-8.3 >=dev-lang/tk-8.3 <x11-libs/qt-4.0 >=dev-libs/icu-3.2" RDEPEND="${DEPEND} postgres? ( >=dev-db/postgresql-7.4 ) firebird? ( dev-db/firebird )" The depends are all there ... > > I never did the KDE/Gnome integration since I don't use either. I reckon these > > additions should probably be added within "if use kde/gnome; then ... fi" > > sections, and yes, the xpm and desktop files are inside the source archive. > > Missed those too :-) Looks like the .desktop files need to go into /usr/share/applications, I'm unable to locate the .xpm files though. > Looking forward to 1.5 when it appears! I had the priviledge of seeing some of the screenshots ... let's just say Softline Pastel may well find that they're going to have a run for their money if quasar 1.5 is even close to what it promises. Next opportunity: Write a tool to convert existing Pastel accounting data to Quasar...
(this is an automated message based on filtering criteria that matched this bug) 'EBUILD' is in the KEYWORDS which should mean that there is a ebuild attached to this bug. This bug is assigned to maintainer-wanted which means that it is not in the main tree. Hello, The Gentoo Team would like to firstly thank you for your ebuild submission. We also apologize for not being able to accommodate you in a timely manner. There are simply too many new packages. Allow me to use this opportunity to introduce you to Gentoo Sunrise. The sunrise overlay[1] is a overlay for Gentoo which we allow trusted users to commit to and all users can have ebuilds reviewed by Gentoo devs for entry into the overlay. So, the sunrise team is suggesting that you look into this and submit your ebuild to the overlay where even *you* can commit to. =) Because this is a mass message, we are also asking you to be patient with us. We anticipate a large number of requests in a short time. Thanks, On behalf of the Gentoo Sunrise Team, Jeremy. [1]: http://www.gentoo.org/proj/en/sunrise/ [2]: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq
Software no longer available under GPL, proprietary only as of version 2.0.x and 1.4.7 (last GPL version) is badly outdated.
