Fedora submission #118
Comments
|
Hi, it's really nice to hear... read that :) Here are the all dependencies needed just in case |
|
Making progress. |
|
Yes, this idea was modelled on my own experience when I was writing my thesis. The application linked to other full programs as to additional functionalities in menu. But the fact is, it was written in Haskell, which focuses very much on modularity, so attaching other programs resembled combining lego bricks. If antimicrox was to be part of something bigger someday, it could be used as a library. But if it doesn't make sense in the end, then I will withdraw it. |
|
Thanks, it's okay, I just needed to know this for packaging. 🙂 Here's the submission: https://bugzilla.redhat.com/show_bug.cgi?id=1844850 |
|
It fails to build on Build: https://koji.fedoraproject.org/koji/taskinfo?taskID=45515901 Here's a working It fails while linking Can this be fixed, or should I file for an The actual error part: |
|
Similar to #111 . Working on it, but he skipped this kind of problem installing newer version of gcc |
|
It looks like common problem with the architecture: Link, the problem here is with template class, just like in my case. Libantilib itself probably has nothing to do with it. So try to do something with ExcludeArch |
|
Thanks for the link. I can't help because I have no clue about C++ programming and I don't have an In the conversation you have linked, |
|
Ok, I will try it |
|
Nice, I'll make a Fedora scratch build today later. |
|
I did a build on But there's also I did a scratch build anyway, and it still fails on So I'll exclude that arch for now. |
|
yes, for resource files to be detected but can be in doc too |
|
I've tagged the program |
|
Awesome! Hopefully it'll be reviewed soon or I'll go for a review swap. |
|
Hi, I finally received some review feedback, and these issues could be fixed upstream. Please provide some feedback about these.
(So that I don't have to in the specfile 🙂, it's just good packaging/repository hygiene.) |
|
As far as I know, appropriate operations of this type can be performed in spec, PKGBUILD and similar files. The distributions are different and one of the ways is just to put the appropriate rules in the compilation file, which put the required libraries in the required places. |
|
@sirlucjan Yes and no. Of course I can easily remove an executable permission. 🙂 But unversioned In this case, Fedora packagers are supposed to inform upstream and work with them to resolve the situation:
Unfortunately, I don't know much about building packages, so that's why I asked for either a patch to add versioning, or some build flag to use, because such thing not detailed in Here's an example when I asked upstream of adding versioning to a library with cmake. It's not a big change and it's better to get this into upstream than creating a downstream patch in a specfile. @juliagoda what do you think? |
|
Thank you. I should have told you I was doing the same thing, but I had an "interesting" day yesterday, so I didn't find the time. Now I'm working on choosing the path for the antilib, it works, but it doesn't link correctly yet and the application can't see it. I will check your change and take it |
|
Super! Note that my PR keeps |
Example: cmake -DANTILIB_PATH=/usr/share/antimicroX/antilib ..
|
To use this you must write something like this (where .. is from subdirectory like build for example):
|
|
Package reviewed, built in Rawhide and submitted as an update to F32 and F31. I also set up Release-Monitoring for automatic update notifications: Shout out to me if you need anything. Will submit a PR to the README once this gets into the repos (after 7 days at most). Thanks for going through this with me! |
Hi, I'm very happy to see this fork of Antimicro being maintained.
Antimicro has been orphaned in Fedora, but I'll resubmit this as
antimicrox, it shouldn't be too hard to reconstruct from the original specfile.Also, I'll submit to
alternativeto.net. 🙂Keep up the good work!
The text was updated successfully, but these errors were encountered: