Activity for libLASi
-
Orion Poplawski created ticket #9
Fails to build in Fedora rawhide
-
Alan W. Irwin posted a comment on ticket #8
Sorry, but I am too used to other SF facilities (for several different projects) to change now. Also, I am a free software advocate who "eats his own dogfood" so I am happy to use open-source SourceForge for my projcts, and I just don't use github for my projects because of its closed-source nature. With regard to your other question, I think lasi is ready to release, but I still need to do final testing to make sure everything is working fine from my perspective. However, my (Debian Stable) platform...
-
Migrate to gotlab or github
-
Tomasz Kłoczko posted a comment on ticket #8
BTW: any plans to make new release? :)
-
Migrate to gotlab or github
-
Remove ancient (and unused) macro TRANSFORM_VERSION
-
Bump version to 1.1.4 as a preliminary to the release of 1.1.4
-
Update the cumulated release notes for the last several releases to be consistent with the current release notes
-
Bump minimum allowed version of CMake from 3.13.2 to 3.13.4
-
Drop the NON_TRANSITIVE option and implement the LASI_LINK_PUBLIC option which supersedes it
-
Improve script that tests a libLASi release tarball
-
Luigi Baldoni posted a comment on ticket #6
I can confirm this bug to be fixed in r233.
-
Linker error on 1.1.3
-
I am changing the status of this bug report to closed-fixed since all my extensive testing on Debian Buster indicates that is the case. And I have decided to move ahead with the forthcoming release of 1.1.4 in the next few days based on this bug fix (and several other less important bug fixes). However, if you do have time to test revision 233 in exactly the way I indicated for your other bug report in the next few days, that should provide helpful confirmation for the release that this linking bug...
-
tests fail on 1.1.3
-
I am changing the status of this bug report to closed-fixed since all my extensive testing on Debian Buster indicates that is the case. And I have decided to move ahead with the forthcoming release of 1.1.4 in the next few days based on this bug fix (and several other less important bug fixes). However, if you do have time to test revision 233 in exactly the way I indicated in the next few days, that should provide helpful confirmation for the release that this linking bug is now gone on all Linux...
-
Sorry for the delay in getting back to you. But now that I have had a chance to work on libLASi again could you please try revision 233? In particular, could you follow the new instructions in section (1) of README.Release_Manager_Cookbook for preliminary testing of libLASi? In your case don't bother with the PLplot part of the test (which happens automatically with this new test_tarball.sh script if you don't specify PLplot-related environment variables). I just now ran test_tarball.sh for our four...
-
Sorry for the delay in getting back to you. But now that I have had a chance to work on libLASi again could you please try revision 233? In particular, could you follow the new instructions in section (1) of README.Release_Manager_Cookbook for preliminary testing of libLASi? In your case don't bother with the PLplot part of the test (which happens automatically with this new test_tarball.sh script if you don't specify PLplot-related environment variables). I just now ran test_tarball.sh for our four...
-
Sorry for the delay in getting back to you. But now that I have had a chance to work on libLASi again could you please try revision 233? In particular, could you follow the new instructions in section (1) of README.Release_Manager_Cookbook for preliminary testing of libLASi? In your case don't bother with the PLplot part of the test (which happens automatically with this new test_tarball.sh script if you don't specify PLplot-related environment variables). I just now ran test_tarball.sh for our four...
-
Sorry for the delay in getting back to you. But now that I have had a chance to work on libLASi again could you please try revision 233? In particular, could you follow the new instructions in section (1) of README.Release_Manager_Cookbook for preliminary testing of libLASi? In your case don't bother with the PLplot part of the test (which happens automatically with this new test_tarball.sh script if you don't specify PLplot-related environment variables). I just now ran test_tarball.sh for our four...
-
Sorry for the delay in getting back to you. But now that I have had a chance to work on libLASi again could you please try revision 233? In particular, could you follow the new instructions in section (1) of README.Release_Manager_Cookbook for preliminary testing of libLASi? In your case don't bother with the PLplot part of the test (which happens automatically with this new test_tarball.sh script if you don't specify PLplot-related environment variables). I just now ran test_tarball.sh for our four...
-
Omnibus commit concerning linking-related issues
-
Improve libLASi's find capability for pkg-config
-
Drop the www subdirectory from the source release tarball
-
Since the original fix in r230 was not correct, and because it is taking several days to fix this issue properly, change status appropriately.
-
Linker error on 1.1.3
-
Since the orignal fix in r230 was not correct, and because it is taking several days to fix this issue properly, change status appropriately.
-
Done on r230 svn.
-
On 2019-06-07 23:17-0000 Luigi Baldoni wrote: Unfortunately I could not understand how to pass that XML tag to cmake. It is not an XML tag. And it was further clobbered by some markdown translation that was going on from my original e-mail content to what is rendered at SourceForge. The brackets notation simply means in this case it is a description of the option you should have there in the command line. So (trying backtick notation this time to attempt to stop markdown translation) <path to top-level...
-
On 2019-06-07 06:24-0000 Luigi Baldoni wrote: Tests fail on openSUSE (any version), I assume it needs LD_LIBRARY_PATH set at some point, but I don't know cmake enough to fix it myself. Hi Luigi: To get further with this I need more details. To supply those, please do the following In an initially empty build tree: cmake -DBUILD_SHARED_LIBS=ON <path to lasi source tree> >& cmake.out make VERBOSE=1 all >& all.out ctest --extra-verbose >& ctest.out Collect the file CMakeCache.txt (generated by cmake...
-
I ran the crashing program through gdb, not sure what to make of it, please see attached log.
-
Unfortunately I could not understand how to pass that XML tag to cmake. These are the commands I issued: > cmake -DBUILD_SHARED_LIBS=ON >& cmake.out > make VERBOSE=1 all >& all.out > ctest --extra-verbose >& ctest.out As you predicted, it worked perfectly in a local tree, however I still see the original problem in the chroot openSUSE OBS uses for building rpms. I'm including both sets of logs in the attached tarball.
-
Unfortunately I could not understand how to pass that XML tag to cmake. These are the commands I issued: > cmake -DBUILD_SHARED_LIBS=ON >& cmake.out > make VERBOSE=1 all >& all.out > ctest --extra-verbose >& ctest.out As you predicted, it worked perfectly in a local tree, however I still see problem in the chroot openSUSE OBS uses for building rpms. I'm including both sets of logs in the attached tarball.
-
On 2019-06-07 06:24-0000 Luigi Baldoni wrote: Tests fail on openSUSE (any version), I assume it needs LD_LIBRARY_PATH set at some point, but I don't know cmake enough to fix it myself. Hi Luigi: To get further with this I need more details. To supply those, please do the following In an initially empty build tree cmake -DBUILD_SHARED_LIBS=ON <path to="" tree="" source="" lasi=""> >& cmake.out</path> make VERBOSE=1 all >& all.out ctest --extra-verbose >& ctest.out Collect the file CMakeCache.txt (generated...
-
tests fail on 1.1.3
-
On 2019-06-06 08:58-0000 Luigi Baldoni wrote: I'm sorry, but r230 doesn't solve the problem with building libLASi itself. Hi Luigi: I now know why r230 was not the correct solution, and I think I know what the correct solution is. However, to confirm that I am trying to put together a test case (where system pkg-config on Debian Buster does not reference gobject-2.0 or glib-2.0 similar to the openSUSE result), but I haven't finalized that test case. But when I do, I expect to be able to replicate...
-
I'm sorry, but r230 doesn't solve the problem with building libLASi itself.
-
Linker error on 1.1.3
-
On 2019-06-05 11:33-0000 Luigi Baldoni wrote: I'm noticing linking errors on openSUSE Tumbleweed: [...] /home/abuild/rpmbuild/BUILD/libLASi-1.1.3/src/contextMgr.h:30: undefined reference to g_object_unref' [...] /home/abuild/rpmbuild/BUILD/libLASi-1.1.3/src/psDoc.cpp:502: undefined reference tog_list_free' /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: /home/abuild/rpmbuild/BUILD/libLASi-1.1.3/src/psDoc.cpp:502: undefined reference to `g_list_free' collect2: error: ld returned...
-
Fix underlinking issue discovered by Luigi Baldoni
-
Linker error on 1.1.3
-
Add a preview image of the logo that has margins and a drop shadow
-
Use an updated logo for the website
-
Add validation checking and unicode encoded logo icons to index.html
-
Consolidate menu items
-
Complete rewrite of the website index.html page
-
Put LASi website files under svn control
-
Update README.Release_Manager_Cookbook to reflect final changes in release procedure for 1.1.3
-
libLASi-1.1.3 has been released
-
libLASi-1.1.3 has been released
-
libLASi-1.1.3 has been released
-
Add and commit of the 1.1.3 release tag
-
libLASi released /lasi/1.1.3 Source/libLASi-1.1.3.tar.gz.asc
-
-
-
Update commit messages for 1.1.3 release cycle
-
Update to the lastest version of the instructions for the release manager
-
Finalize release notes for the forthcoming release of libLASi-1.1.3
-
Rename CONCATENATED_README.release => README.cumulated_release
-
Bump package version from 1.1.2 to 1.1.3 and library SOVERSION from 1 to 2 in anticipation of the 1.1.3 release
-
Reorganize how examples are built and run and replace old PNG snapshots with new ones
-
Insert copyright notice in CMakeLists.txt and src/CMakeLists.txt
-
Substantial update of the documentation of the examples
-
Make glyph names have a one-to-one relationship with glyphs
-
Work around libLASi issue that occurs when pango chooses pure bitmapped fonts
-
Modify the "Missing Glyph" example again
-
Update "Missing Glyphs" example to provide more stringent tests of the libLASi library
-
Replace deprecated lower-case variants of Freetype macro constants with preferred upper-case form
-
Add boundary boxes to the "Missing Glyph" and "Complex Text Layout" examples
-
Fix minor boundary box issue
-
Update doxygen configuration files from doxygen version 1.8.1.2 to 1.8.13
-
Bump (or shove hard in this case) the minimum version of CMake from 2.8.9 to 3.13.2
-
Build system: set target property POSITION_INDE...
-
Prepend the release notes for 1.1.2.
-
Update instructions to exactly what occurred fo...
-
libLASi-1.1.2 has been released
-
libLASi-1.1.2 has been released
-
-
-
-
-
-
-
Create tag of release 1.1.2
-
Update commit messages for 1.1.2 release cycle.
-
Another tweak.
-
Tweak wording.
-
Update instructions to be consistent with what ...
-
Describe tests of this release.
-
Include fix of file-repeatability bug in descri...
-
Changed from glyph_1, glyph2, etc., to using LA...
-
Changed to LASi_glyph_1, etc., just before the release to avoid any potential name...
-
At Ed Trager's suggestion simplified the fix by deriving a unique but sensible glyph...
-
Improve commentary concerning deriving unique g...
-
Change from using rand_r to generate unique gly...
-
Name and order of stored glyphs is sometimes not repeatable
-
Fixed as of revision 191 by changing from rand to rand_r. See the commit message...
-
Fix the repeatability of glyph identification s...
-
Name and order of stored glyphs is sometimes not repeatable
-
Yet another "final" commit of the ChangeLog.rel...
