Re: [Liborigin-devel] project repository

[Stefan G. <ste...@un...>]

I just released 3.0.1. Thanks for helping out with the coordination.

best
Stefan

On 11/05/2021 19:27, Alexander Ploumistos wrote:
> Hello Stefan,
> 
> I hadn't deleted the previous srpms and as a result I spent an hour
> building and rebuilding the wrong one, wondering why I'm not getting
> the documentation built…
> Everything seems fine, I think you can increment that last zero to one
> if you want.
> Thank you for all your work!
> 
> Best regards,
> A.
> 
> 
> On Tue, May 11, 2021 at 4:47 PM Stefan Gerlach
> <ste...@un...> wrote:
>>
>> Hi Alexander,
>>
>> thanks. I fixed the GNUInstallDirs, made the doxygen doc build per default and build opj2dat with the dynamic lib if static is disabled in the
>> latest commit. I hope that fixes all issues :-)
>>
>> best
>> Stefan
>>
>>
>> On 11/05/2021 16:09, Alexander Ploumistos wrote:
>>> Hi Stefan,
>>>
>>> I had to add "include(GNUInstallDirs)" before "install" in the shared
>>> library section, e.g.
>>>
>>> --- a/CMakeLists.txt    2021-05-11 14:20:57.000000000 +0200
>>> +++ b/CMakeLists.txt    2021-05-11 15:52:50.279765255 +0200
>>> @@ -86,6 +86,7 @@
>>>            VERSION ${PROJECT_VERSION}
>>>            SOVERSION ${PROJECT_VERSION_MAJOR}
>>>        )
>>> +    include(GNUInstallDirs)
>>>        install( TARGETS origin_shared
>>>            LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
>>>        )
>>>
>>> otherwise the shared object files end up under /usr/lib even on 64-bit
>>> arches. I suppose the static library is also affected by this. Can the
>>> include statement go to the beginning of the file?
>>>
>>>
>>> The HTML documentation is no longer created, is there an extra
>>> configuration/build option I need to specify or did it get eaten up
>>> with the latest changes?
>>>
>>>
>>> I don't know anyone using opj2dat by itself, if anyone files a bug
>>> report, I'll need to find a way to build it along with the shared
>>> libraries, but for now it doesn't matter.
>>>
>>>
>>> Best regards,
>>> A.
>>>
>>>
>>> On Tue, May 11, 2021 at 2:34 PM Stefan Gerlach
>>> <ste...@un...> wrote:
>>>>
>>>> Hello Alexander,
>>>>
>>>> i tried to fix the issues with liborigin in the upstream code. Let me know if there are still issues.
>>>> If i get the discussion correctly SciDAVis will also use the upstream version now or at least sync with upstream. Thanks for resolving these issues.
>>>>
>>>> Best regards,
>>>> Stefan
>>>>
>>>> On 11/05/2021 12:40, Alexander Ploumistos wrote:
>>>>> Hello Stefan,
>>>>>
>>>>> Thank you for taking care of this. It would be great to get a 3.0.1
>>>>> release, but not just yet; when I packaged the latest snapshot with
>>>>> the commits from SciDAVis, I came across a couple of issues:
>>>>> https://github.com/highperformancecoder/scidavis/issues/218
>>>>> They are not that important, but I think it would be better to get rid
>>>>> of them before the next release. Also, it might be a good idea to
>>>>> chime in on the issue or otherwise get in touch with the SciDAVis
>>>>> people, so as to avoid doing the work twice. If you get the chance to
>>>>> look at these, commit the changes and they can pick them up
>>>>> downstream. If they manage to get to them first, they should push them
>>>>> upstream.
>>>>> The later half of this discussion might also be of interest to you as well:
>>>>> https://github.com/highperformancecoder/scidavis/discussions/212
>>>>>
>>>>> Best regards,
>>>>> A.
>>>>>
>>>>> On Tue, May 11, 2021 at 12:25 PM Stefan Gerlach
>>>>> <ste...@un...> wrote:
>>>>>>
>>>>>> Hello Alexander,
>>>>>>
>>>>>> i updated upstream liborigin with the latest patches from SciDAVis. I could release a new version 3.0.1 if that's a good idea.
>>>>>> LabPlot now uses the system installed liborigin 3 if available.
>>>>>>
>>>>>> best wishes
>>>>>> Stefan
>>>>>>
>>>>>>> You can see the changes committed to SciDAVis's liborigin submodule here:
>>>>>>> https://github.com/SciDAVis/liborigin/commits/
>>>>>>> There are some fixes and cleanups and I don't think there's anything
>>>>>>> too SciDAVis-centric among them. Some of them will make my life more
>>>>>>> difficult as I'll probably need to refactor a few Fedora-specific
>>>>>>> workarounds with regard to cmake…
>>>>>>>
>>>>>>>     From the point of view of a distribution package maintainer it would
>>>>>>> be great if all the work happened first in liborigin upstream or if
>>>>>>> any changes made downstream were pushed upstream (within a reasonable
>>>>>>> timeframe), so as to avoid forking and fragmentation. While git
>>>>>>> submodules are appealing, at least to consumers of projects, I think
>>>>>>> they tend to complicate things.
>>>>>>>
>>>>>>> Once you get a chance to look at the code, let me know what you think.
>>>>>>>
>>>>>>>
>>>>>>> Thank you and have a nice weekend,
>>>>>>> A.
>>>>>>>
>>>>>>>
>>>>>>> On Sat, May 8, 2021 at 11:09 AM Stefan Gerlach
>>>>>>> <ste...@un...> wrote:
>>>>>>>>
>>>>>>>> Hello Alexander,
>>>>>>>>
>>>>>>>> i'm not working on SciDAVis but i also would like to see the changes incorporated in liborigin.
>>>>>>>> Missing updates of liborigin were the reason why we use a bundled version of liborigin in LabPlot. If nobody cares, i can take a look at
>>>>>>>> SCiDAVis liborigin and try to update liborigin. If that works, we can use the official liborigin in LabPlot.
>>>>>>>>
>>>>>>>> best wishes
>>>>>>>> Stefan
>>>>>>>>
>>>>>>>> On 07/05/2021 23:04, Alexander Ploumistos wrote:
>>>>>>>>> Hello Stefan, Miquel,
>>>>>>>>>
>>>>>>>>> I was about to update the Fedora packages of SciDAVis and its
>>>>>>>>> dependencies for which I am the maintainer and I realized that the
>>>>>>>>> changes committed to the SciDAVis branch of liborigin have not been
>>>>>>>>> incorporated yet into the "official" repository.
>>>>>>>>>
>>>>>>>>> In theory, the LabPlot should also depend on liborigin, but looking at
>>>>>>>>> the spec file, it seems that at some point one of the maintainers
>>>>>>>>> switched to the bundled version. Nevertheless, I'd like to abide by
>>>>>>>>> Fedora's rules and maintain a separate package - if possible - which I
>>>>>>>>> think it should be.
>>>>>>>>>
>>>>>>>>> Since the two of you are contributing to all of the above projects, I
>>>>>>>>> was wondering if you intend to merge the changes from SciDAVis to
>>>>>>>>> liborigin, so that there is one upstream source for everything.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> A.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Liborigin-devel mailing list
>>>>>>>>> Lib...@li...
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/liborigin-devel
>>>>>>