dev-ada/cbind-6.0:20081212-220251.log: * QA Notice: Pre-stripped files found: dev-ada/cbind-6.0:20081212-220251.log: * /var/tmp/portage/dev-ada/cbind-6.0/image/usr/bin/cbfe dev-ada/cbind-6.0:20081212-220251.log: * /var/tmp/portage/dev-ada/cbind-6.0/image/usr/bin/cbpp dev-ada/cbind-6.0:20081212-220251.log: * /var/tmp/portage/dev-ada/cbind-6.0/image/usr/bin/cdep dev-ada/cbind-6.0:20081212-220251.log: * /var/tmp/portage/dev-ada/cbind-6.0/image/usr/bin/cbind Portage warns about pre-stripped files being installed into the image directory; this is a bad thing since it makes Portage's splitdebug feature useless, and it stops the users and the developers from looking into backtraces with full debug information available. For the developers going to look into it, what you have to look out for, to find what is stripping the files, is one of these conditions: - explicit "strip" command run on the produced files; - "install -s" command to install the binary files; - "-Wl,-s" flag passed during linking Remove the "strip" commands, remove the "-s" option at install, and remove "-Wl,-s" and the problem should be gone. Thanks, Diego
Probably this QA reasons are not enough to treeclean this (if it would have another opened bug...). I personally wouldn't have any problems with dropping it... but I have seen lots of discussions in the past when treecleaning with ONLY QA issues like this (that are different than package not installing/building/running or major problems) On the other hand, if ADA team is ok with treecleaning this, feel free to CC us again
In reply to comment #1) > On the other hand, if ADA team is ok with treecleaning this, feel free to CC > us again The Ada (its a name btw (of the first programmer, no less ;)), not acronym) team is definitely against treecleaning. As it is common when Ada is concerned, this is a small and old utility written for a specific purpose and way before many people worried about QA issues. However, stuff tends to work forever in Ada world and, frankly, there usually aren't any alternatives to replace the tool. I'll take a look at the build of the package and see if it is under my control or if it can be easily repackaged.
Ok, fixed it. Apparently there is no chance of reasonable upgrade, as it is hardly possible to trace "upstream" nowadays. However, this is still a useful, if minor, utility. Stuff is very basic and does just what it was made to do over 10 years ago - that is, spits proper headers for C structs in Ada (quite invaluable, when trying to interface 1000+ record structures of data). Therefore, it is unlikely to really break any time soon (even though current, stricter gcc spits out tons of warning about programming malpractices). So, it should stay in.
Created attachment 332016 [details] c2ada ebuild for latest svn You appear to have updated the ebuild without uploading the tarball. I figured I'd ping the bug which triggered the update, since it broke my emerge update for a while now. Since there is no SRC_URI, I have no idea where to get it. Also, there does appear to be a fork: http://c2ada.sourceforge.net/c2ada.html. At least it's in a place where it will not likely disappear after various corporate acquisitions. While this is an inappropriate place to do so, I have attached an initial ebuild for it. Keep in mind that I have no idea how to do python properly (and in fact left AdaMain.py dangling), and I haven't used gnat/ada in years (but still keep it on my system for some reason). Sorry, but don't ask me to do it the right way (i.e. opening a new ebuild request): I don't really care enough. I'm not even sure what possessed me to do this much.
Created attachment 332018 [details, diff] Patch to go with c2ada ebuild Yes, I know I should report this patch upstream. Again, too lazy/apathetic. Sorry. Patch has interspersed comments on why each chunk was necessary.
(In reply to comment #4) > You appear to have updated the ebuild without uploading the tarball. I > figured I'd ping the bug which triggered the update, since it broke my > emerge update for a while now. Since there is no SRC_URI, I have no idea > where to get it. Sorry about it, fixed. Actually, the tarball was uploaded. It was the SRC_URI that I forgot to update: "recently" gentoo changed its policy on keeping relevant sources in gentoo space vs direct upload to mirrors. Naturally, this ebuild had old-style SRC_URI. Fixed now.
(In reply to comment #4) > Also, there does appear to be a fork: > http://c2ada.sourceforge.net/c2ada.html. At least it's in a place where it > will not likely disappear after various corporate acquisitions. Right, when I was looking at these some years ago, c2ada had multiple "sources" returned by google with unclear status. cbind seemed simpler and "more definite" and was sufficient for my needs, so I went with it. If c2ada "stabilized" since then, I guess I'll try to look into adding it; when I have time and if it still seems reasonable. Frankly, I think most people just use gnatgcc to generate bindings nowadays. However, these two are "full translators", so they may still have some use over gnat. Thanks for the pointer!
Actually, I should reopen the bug and rename it.
and remove blockers
removed
