>>> Install firebird-2.0.1.12855.0-r2 into /var/tmp/portage/dev-db/firebird-2.0.1.12855.0-r2/image/ category dev-db install: invalid user `tomcat' install: invalid user `tomcat' install: invalid user `tomcat' touch: cannot touch `/var/tmp/portage/dev-db/firebird-2.0.1.12855.0-r2/image///var/log/firebird/.keep_dev-db_firebird-0': No such file or directory !!! ERROR: dev-db/firebird-2.0.1.12855.0-r2 failed. Thinko, I'd say. And please include the current patches from Debian http://ftp.debian.org/debian/pool/main/f/firebird2.0/firebird2.0_2.0.1.12855.ds1-4.diff.gz
Uh, btw. you violated the ebuild policy by doing a commit without Changelog entry.
Did not mean to make a commit less ChangeLog entry. Something must have happened there, since it's very rare for me to miss a ChangeLog entry. Much less I still see it in my .bash_history. The user/group of Tomcat is a habit from me being the Tomcat maintainer. No I did not copy and paste, just typed tomcat instead of firebird, twice :) Resolved in -r3. (In reply to comment #0) > > touch: cannot touch > `/var/tmp/portage/dev-db/firebird-2.0.1.12855.0-r2/image///var/log/firebird/.keep_dev-db_firebird-0': > No such file or directory Those are likely related and I question the path /var/tmp/portage/dev-db/firebird-2.0.1.12855.0-r2/image///var/ Is that even valid and where is the extra / coming from? > And please include the current patches from Debian > http://ftp.debian.org/debian/pool/main/f/firebird2.0/firebird2.0_2.0.1.12855.ds1-4.diff.gz Why? It builds just fine now on amd64 and x86. Top of the patches seems to be debian specific stuff. Much less weeding through it for any parts that we could use on Gentoo that aren't Debian specific.
> Is that even valid and where is the extra / coming from? It's valid. Try e.g. `ls ////`, locally. Stems from ${D}/${FOO} resolving to multiple slashes. That's not a problem. > Top of the patches seems to be debian specific stuff. Did you even look at the patches!? The typical cruft in these dpatch files aside, the least of the patches are Debian specifc. cvs-client-crash-on-remote-shutdown.patch cvs-common_classes_alloc.cpp-unaligned.patch cvs-jrd.cpp-crash-on-srervices-and-conventional-api-usage.patch mcpu-to-mtune.patch no-rpath.patch dsql.tab.h-bison2.3.patch proto_h-ALLSPACE-ulong.patch should be applied separate-file-and-sem-perms.patch is even a DoS issue as you can read here¹. No idea, if was ever reported upstream. create-run-dir.patch lock-file-location.patch These two make sense to me, but arguable. The other ones are either arch specific or I don't have an opinion about them. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=362001
(In reply to comment #3) > > Is that even valid and where is the extra / coming from? > > It's valid. Try e.g. `ls ////`, locally. Stems from ${D}/${FOO} resolving to > multiple slashes. That's not a problem. Just trying to figure out why that dir does not exist with both touch, and the keep file entry failing. > > Top of the patches seems to be debian specific stuff. > > Did you even look at the patches!? I tried but it's quite hard when they are all merged into on big one like this with most of the top, ~1k lines or so deals with license/file headers, init script, and other stuff. Hard to get to just the needed patches and to determine if we really do need them or not. The typical cruft in these dpatch files > aside, the least of the patches are Debian specifc. The init stuff I am seeing. Much less the overall format of the file? I am not familiar with stuff in this format. Quite hard to read through or parse. > cvs-client-crash-on-remote-shutdown.patch > cvs-common_classes_alloc.cpp-unaligned.patch > cvs-jrd.cpp-crash-on-srervices-and-conventional-api-usage.patch > mcpu-to-mtune.patch > no-rpath.patch > dsql.tab.h-bison2.3.patch > proto_h-ALLSPACE-ulong.patch > > should be applied I would like to review them before I just haul off and patch that stuff. > separate-file-and-sem-perms.patch > > is even a DoS issue as you can read here¹. No idea, if was ever reported > upstream. Reading their bug that effects only the Classic server. Sounds like when it's used via embeded library as opposed to xinetd. But the patch or etc in that bug I can't find to review. But seems changing perms of a file resolved that DoS issue, and might be Debian specific. Thus the patch for their version, not sure. > create-run-dir.patch > lock-file-location.patch > > These two make sense to me, but arguable. > > > The other ones are either arch specific or I don't have an opinion about them. The bottom ones seem to be ia64 additions. But the in between is very hard to parse. I would likely need to see about the patches on a one on one basis. I would also likely apply one at a time, instead of putting all into one big patch like this. And there is no way I can use this one as is, since it has ALLOT of debian specific stuff. Including paths where they are installing stuff which is a bit different from where we are.
(In reply to comment #4) > Just trying to figure out why that dir does not exist with both touch, and the > keep file entry failing. No idea about that either. dodir should really do it. > The init stuff I am seeing. Much less the overall format of the file? I am not > familiar with stuff in this format. Quite hard to read through or parse. Uh, that's simple. cd foo ; wget debian-patch.diff.gz ; gunzip debian-patch.diff.gz ; patch -p0 <debian-patch.diff and you have the directory structure with the individual patches. > Reading their bug that effects only the Classic server. Sounds like when it's > used via embeded library as opposed to xinetd. Hm, missed that, when reading the bug. It defintitely won't harm to include it, in case some day someone requests an embedded lib build (rather unlikely, I damit).
(In reply to comment #5) > > No idea about that either. dodir should really do it. Let me know if you have any ideas there :) I am fresh out. > cd foo ; wget debian-patch.diff.gz ; gunzip debian-patch.diff.gz ; patch -p0 > <debian-patch.diff > > and you have the directory structure with the individual patches. Thank you sooooo much for that. Makes it much easier to digest and work with. Sorry for being a newb about that stuff. > Hm, missed that, when reading the bug. It defintitely won't harm to include it, > in case some day someone requests an embedded lib build (rather unlikely, I > damit). Well I would not ignore just out of lack of use. If anything would just prioritize it based on other issues and time. Just don't want it to cause any other side effects :)
Another issue: * checking 100 files for package collisions existing file /opt/firebird/firebird.log is not owned by this package * This package is blocked because it wants to overwrite * files belonging to other packages (see messages above). * If you have no clue what this is all about report it * as a bug for this package on http://bugs.gentoo.org package dev-db/firebird-2.0.1.12855.0-r3 NOT merged This is because 1.5.x does the symlink within pkg_config(). Workaround would be using addwrite() to remove the symlink. Leveraging the sandbox to access the log directory is quite ugly, though.
I will likely modify 1.5.4 to do the symlink as part of the install process like 2.0 does. FYI, 2.0.1 has the same pkg_config() stuff, but I will likely be trying to move away from that. Seems it was mostly a bridge between past versions, Firebird < 1.5 and 1.5. IMHO Firebird should start out of the box without having to run pkg_config(). So that's the direction I will most likely be heading.
(In reply to comment #6) > (In reply to comment #5) > > > > No idea about that either. dodir should really do it. > > Let me know if you have any ideas there :) I am fresh out. Actually dodir failed because of the owner/group of tomcat :) Thus the dir not getting created, and the two other problems. So just down to what ever patches we need, and the log resolution.
(In reply to comment #8) > IMHO Firebird should start out of the box without having to run pkg_config(). > So that's the direction I will most likely be heading. Won't change anything. Any ebuild changed will try to overwrite an "unknown" file and Portage will bail out with FEATURES+=collision-protect. Another issue. Please restore the include symlinks. Testing with Qt 3 revealed that it bails out, becuae of not finding the headers. /usr/include/gds.h /usr/include/iberror.h /usr/include/ibase.h /usr/include/ib_util.h It also seems sensible to hard mask Firebird 2.x, unless these issues are ironed out.
(In reply to comment #10) > (In reply to comment #8) > > IMHO Firebird should start out of the box without having to run pkg_config(). > > So that's the direction I will most likely be heading. > > Won't change anything. Any ebuild changed will try to overwrite an "unknown" > file and Portage will bail out with FEATURES+=collision-protect. Then please advise how to resolve. Not sure why others were allowed to make an ebuild that would cause collisions like this in the future. IMHO having to run pkg_config after emerging a package is far from ideal. What ever hack is needed to overcome this for now is most likely what I will go with for now. > Another issue. Please restore the include symlinks. Testing with Qt 3 revealed > that it bails out, becuae of not finding the headers. > > /usr/include/gds.h > /usr/include/iberror.h > /usr/include/ibase.h > /usr/include/ib_util.h I checked all past ebuilds. Those files have never had symlinks. So I have no idea what you are referring to. There is nothing to restore. But if they are needed I can make them. But it will be for the first time. > > It also seems sensible to hard mask Firebird 2.x, unless these issues are > ironed out. Well Firebird is what a database server/RDBMS. I have it running on my development server and have been working with it for serveral days now. Not only with my applications in use and development. But also with client side tools like Flamerobin. Which so far all are working fine with Firebird 2.0. I consciously removed the hard mask after testing and working out some issues that effected Flamerobin. So remaining packages with problems, or fb problems should be minor. Ones that can be worked out in ~arch.
(In reply to comment #11) > Then please advise how to resolve. Not sure why others were allowed to make an > ebuild that would cause collisions like this in the future. IMHO having to run > pkg_config after emerging a package is far from ideal. As I said, I don't see another way but disabling the sandbox for the symlink. > Well Firebird is what a database server/RDBMS. I have it running on my > development server and have been working with it for serveral days now. Not > only with my applications in use and development. But also with client side > tools like Flamerobin. Which so far all are working fine with Firebird 2.0. This isn't what matters (alone). When an ebuilds enters testing, it shouldn't break other ebuilds either (typical stable/testing compatibility clashes becuae of API changes etc. aside).
(In reply to comment #12) > > As I said, I don't see another way but disabling the sandbox for the symlink. Actually I am leaning toward the Debian route. I might make a patch so it logs to /var/log/firebird/firebird.log by default. Then the symlink will not be necessary, and if the file exists or not in /opt/firebird, will be moot :) > This isn't what matters (alone). When an ebuilds enters testing, it shouldn't > break other ebuilds either (typical stable/testing compatibility clashes becuae > of API changes etc. aside). Yes I understand that when something enters ~arch it should not break other deps. See bug 164523. Which is 5+ month breakage of ~arch due to refusal to slot and provide both. Should be interesting as it's a major Gnome 2.18 feature. Firebird is no where near as wide used as Gnome or gnupg. :) But none the less I do care about any breakage. To my knowledge Firebird 2.0 is 100% backwards API compatible. The problem you are pointing out with header files, must have existed before Firebird 2.0.x. Since again I can't find any symlinks in any version of 1.5.x with regard to header files. So how did that ever work? Possibly a problem with the other packages? Anyway this bug is about Firebird 2.0 failing to merge or etc. We are wrapping way to many bugs under the one. Seem the file collision should be another bug. Beyond that maybe a bug about the other patches, which ones are needed or not. But at this point, there shouldn't be anything preventing merge of Firebird 2.0. I have done it on several machines that had 1.5.x on them. Then again I have not run pkg_config on any of them. Who ever came up with that, it was a horrible idea. Either way we need to change the summary of bug, and/or close and open others.
Closing this for now, since firebird 2.0.1 does merge now. We can open another bug for firebird 2.0.1 patches, and/or any other issues with firebird 2.0.1. As to not carry on an eternal bug :) I will still look into patches either way, bugs or not. Just as time permits.
Finally looked into the debian patch set. I did not like most all of it, and used none of it. I made my own patch to move Firebird out of /opt. Just commenting here as follow up, since I said I would look into the debian patches. To much modification outside of upstream, and I would rather keep source more pure per upstream. Till we have justified bugs or issues that require patching outside of upstream. Like for the paths issues, since it's not in /opt :)
