With a lot of help from debrouxl, I've created Fedora RPMs for tilp and libti*.

I intend to submit these packages to Fedora. However, I cannot do so at the moment because of various issues in libtifiles2, libticalcs2, tilp2, and gfm. So rather than submit half of the stack, I decided to wait until tilp 1.17.

So, until then, to make life easier for everyone else, I set up an unofficial yum repository on my local system. To install that repo (and then tilp2 and gfm), run the following commands:


Code:


Because the next time tilp is updated, these packages will be submitted directly to Fedora, they won't be updated again in this repository. So if you like, once you've installed tilp2 and gfm you can disable the repo by editing /etc/yum.repos.d/ticalc.repo as root and changing "enabled = 1" to read "enabled = 0"- or by simply deleting that file.

You don't have to do this, but it will make your yum updates go by faster and also save on my bandwith a bit.

The fact that we're talking about packages in the TilEm 2 topic ( http://www.cemetech.net/forum/viewtopic.php?t=7869 ) reminds me about this topic
TILP II 1.16 was released in December 2011, and TILP II 1.17 will hopefully be released in the next few months

openSUSE has packages for libti*/gfm/tilp, though they might be in the community repository rather than in the main repository, I'm not sure.

Yeah, I sort of forgot about this, my bad. I'll build updated packages and then... well.

I originally wanted to get them into a Fedora repository. However, after I looked through the packaging guidelines.. it seems highly unlikely that this would ever be possible. The main offenses here are statically linked libraries and libtool archives everywhere- and unless I'm missing something there is no way to work around that. (And that's not even getting into embedded forks of things like minizip and so on).

So then my idea was to set them up in an unofficial yum repository of some sort. I ideally want to use fedorapeople.org (these are unofficial repositories maintained by Fedora packagers), but to do that I actually need to be a Fedora packager. I found some other software I'd like to package and submitted a ticket for it a few weeks ago, hoping to become a sponsored package maintainer, but as of yet no one has reviewed the package and/or sponsored me. (Incidentally.. if anyone reading this happens to be a sponsored Fedora packager and wouldn't mind helping me out here, please let me know )

I could set up a yum repository on my own personal server and provide these packages there, provided the repo could be linked from the tilp website or something?

libti* are meant to be used as dynamic libraries anyway
Do libtool archives still clutter the way when --disable-static (which is supposed to be the default) is explicitly passed to configure ?

The embedded fork of minizip is indeed a sore spot. I had started to replace it by libzip, only to find, near the end of the (easy) replacement work, that libzip doesn't support setting the compression level... so we can't use it as a replacement for minizip.
I then set my sights on libarchive, but stopped working on that area.

I think that we should at least try to do what it takes for inclusion to the main repositories, so as to 1) avoid the extra work for you to set up a repository, and 2) potentially make other distros benefit as well

Thanks a lot, TC01. That was a *lot* less painful that compiling from source.

Unfortunately, they do. libticonv (which is currently the one I'm working on) still produces a "libticonv.la" regardless of a --disable-static flag or not. This seems to agree with the Fedora wiki:



I can manually delete libticonv.la during the RPM's build/install process.. alternatively, maybe we could get rid of it in the makefile?



Hmm, okay.

I'm pretty sure I suggested this before, but what about submitting whatever patches we've made to it upstream and then dynamically linking minizip?



Okay then.

Few other things then- does libticables now ship the udev rules? I remember before I had pulled them from the Arch pkgbuild or something.. if it doesn't, is there a reason why it can't?

And also, does tilp2 now ship with a desktop file? Again, I think the Arch pkgbuild had one, but it'd be easier to include it if it was in the main download.



Glad to know they were useful.

Then I'd say that you can delete them during the RPM's build/install process, indeed


IIRC (but I would need to check again the diff), that's unlikely to fly, unfortunately...
Some distros don't ship minizip in a ready-made form, so we'd still need to include the minizip sources somehow in upstream, even if you need to remove them for RPM packaging.


Not as a separate file, if that's what you mean
libticables' CONFIG describes the contents of /lib/udev/rules.d/69-libticables.rules - udev has changed a lot over time, causing lots of churn in rules...
Recent Fedora versions have udev (or systemd) >= 165, so you'll want to use

Code:



Compatibility-breaking churn in udev. For instance, AFAICT, the file, in its above form, shouldn't work on Debian stable (squeeze), which has udev < 165.


Both TILP and GFM have a desktop files and MIME type definitions, contributed by Jonimus. I'm not _sure_ they're installed in the right places when building - if they aren't, it's my fault, and it needs fixing in short order

Note, the mime type definition may contain errors and should most likely be shipped with libtifiles now that I think about it, but it shouldn't be to broken not to ship.

Putting some MIME type definitions in libtifiles would enable some sharing across tilp, gfm and tilem.

is there any reason why it can't just use the definitions tilem is using? (application/x-ti83plus-program, application/x-ti83plus-variables, etc)
/me was rather happy when installing it cleared up all of those for me so i didn't have to add things manually.

If we put the MIME definitions in libtifiles (whether it's the set originating from tilem, the set originating from tilp, or a mix of both), hopefully, all clients of libtifiles will be able to use the definitions

So, an update:

I have working, valid, guideline-compatible specs for libticonv and libtifiles. Until we figure out a workaround for bundled minizip, I won't be able to submit libtifiles (or the rest of the stack..). I can submit libticonv though, and then either put everything else in an unofficial repo or figure out a way around minizip.

I need to figure out how udev rules are supposed to be packaged to get a libticables spec working. After that, I don't think there's anything special about libticalcs or tilp2 that would render them unpackageable. If I remember correctly, though, tiemu has bundled libraries as well?

I did actually have a spec written for gcc4ti, but there's no way that would ever make it through the package review process.

Is there a small description of what each of the libraries actually does anywhere? I can sort of guess what *conv and *cables do but it would be nice to have an official description I could use in the specs.



In that case, if we can't replace minizip with anything, what about making it a more official fork? We could add a "libtizip" to the stack that would just be the fork of minizip in dynamically-linked, distro-packaging-friendly form.

Thanks for the status update


Alone, libticonv isn't much. I think that it can safely wait for the resolution of the libtifiles problem.


OK.


There's currently a problem with the ROM dumpers embedded in libticalcs, which sprang up for the Debian packaging efforts. Benjamin Moody and alberthro (mainly) are working on it.


Yeah, don't even bother with TIEmu. Its dysfunctional GDB integration is a horrible, tangled, fragile mess of forks of outdated versions of multiple third-party software...


GCC4TI would be more likely to pass a package review process than TIEmu is
Several changes have been performed (over the TIGCC legacy) to make GCC4TI easier ("less hard" would be more accurate) to package.


Possibly the README or documentation ?


I'm not sure this would fly with distro packaging reviews...
I'd be surprised if libarchive ( http://libarchive.github.com/ ), which supports all of the OS that libtifiles targets, couldn't fit our purposes. libarchive seems to be a prime choice, given that libzip (which would be a relatively straightforward replacement for minizip, API-wise) isn't fit for our purposes.

The libticables spec should now be good, and I can start working on libticalcs now.



Oh? What exactly is the issue? Something that would impact Fedora as well?



Oh dear, that's saying a lot about TIEmu then. But alright. I can host them in an unofficial repo, perhaps.



Hmm, not that I can see. The readmes for the libraries don't seem to explain very much. And I'm not even sure what other documentation I could check.. this isn't really that important, but I'd like the descriptions for the packages to be correct (and not just garbage made up by me. )


That sounds good, then. Any idea when this will be fixed by? I'll happily help if I can, but I'm afraid my C(++) isn't that good.

EDIT: Finished the spec for libticalcs2 and then moved onto tilp.

Running desktop-file-validate on the tilp.desktop file produces the following errors:


Code:

The issue is that multiple TI-Z80 ROM dumpers, in the form which has been in the libticalcs sources for many years, are not rebuildable from their sources using free software. Namely, they're made for the proprietary, Windows TASM tool, and AFAWCT, no free software is sufficiently compatible with sources made for TASM to compile them out of the box.
The issue is completely invisible to users, since said ROM dumpers are converted to hex arrays, which are then compiled into libticalcs. They seldom change, and don't need to be rebuilt.
But by now, the issue should be largely fixed by Benjamin and alberthro
We need to perform more tests, and I'll commit.


Do you have an idea of the appropriate number of words/characters for the description ? If it's five words, the summaries from the Debian packages may do the job; if it's longer, we'll have to come up with something. +1 item to the TODO list.



Nope. This is one of the items of a fairly large TODO list for TILP II 1.17...
I'm starting to think that the release will be dragged for too long if I don't split it. Put another way, it's becoming large enough for letting only the most important items (GTK+Builder conversion, ROM dumpers upgrade, prospected libarchive integration, plus several other entries, especially if they have patches) stand for this release.


Thanks for the information about the output of desktop-file-validate. +1 item to add to the TODO list...

Ah, I see. Glad to know it's been taken care of.



There are two, a summary and a description- the summary is around five words or so, yeah, so the Debian ones should be good for that.

The description can be as long as you want and just explains what the library does. However.. after making my last post, I went looking for extra documentation and found that the docs/html/info.html file for each library contains a nice description of what the library does.

That causes me to ask something else, though: how exactly is this documentation built? Using tfdocgen, I gather? I didn't even know it was there until I went looking... and this means I've not been building/packaging it. Perhaps it belongs in a *-doc subpackage? I guess this would mean packaging tfdocgen and have all the other packages rely on it, so the docs can be built for them.



Alright.. I think once I've gotten everything else ready, I'll put libticonv and libticables up for review, while for the mean time host the whole stack in a repo running on my server. If/when the ones up for review are approved I'll remove them from the unofficial repo.



Heh, okay. At least this one shouldn't be too difficult take care of.

For what it's worth, gfm.desktop also has issues- again, should be a pretty simple fix:


Code:

docs/html/info.html files are not auto-generated. AFAICT, tfdocgen is some sort of custom, hand-rolled Doxygen, aimed at developers.
I think that the documentation can be distributed alongside the packages, no need to make separate packages.


Well, I don't think it makes much sense to submit libticonv and libticables for review and integration into the main Fedora repositories for now.
libticonv and libticables aren't very interesting without libtifiles and libticalcs, which need an unofficial repository for now anyway (and would need one even if libticonv and libticables ended up being integrated in the main Fedora repositories).
We "just" have to fast-track the new ROM dumpers (partially done) and the libarchive integration (not started), for fixing the known problems that prevent packaging into one or more distros...

But it's clear that for faster progress, it would be good if someone else did the libarchive integration, so that I can concentrate on finishing the integration of the GTK+Builder / intltool conversion & update (the latter being best done by a native French speaker ).


EDIT: my version of desktop-file-validate, on Debian sid amd64, doesn't yield the same output as yours

Code:


Does your error go away if you remove the ";" at the end of the offending line ?
On my side, I killed the Encoding line, and replaced DesktopUtility by GTK.

EDIT2:

Code:

appears here if I remove the final semicolon, but for me, it's there, in SVN / Git

EDIT3: the "DesktopUtility" category was added at SVN r4431, when committing a patch originating from downstream openSUSE. I cannot find any occurrence of "X-DesktopUtility" on the Internet, I guess he meant "X-SuSE-DesktopUtility"; but regardless, I think I'll stick to using GTK instead of that.

Oh.. then why is there a makefile and a reference to tfdocgen under docs/ ?

I'm assuming I can just ignore that, then, and include the contents of docs/html as documentation files?



I think the differences stem from me packaging the released versions (1.16, that is), whereas you're working with the svn/git trunk. So as you point out the desktop files have changed in recent revisions.

But yes, adding a semicolon to that line and removing Encoding fixed all the desktop-file-validate errors for me.

Because the developer-oriented documentation is built alongside the rest of the documentation
Either tfdocgen needs to be packaged as well, or the Makefile.am needs to be patched to remove references to it.


The "install" target of the Makefile.am should be fine, unless it forgets to install something, or does something wrong.

I've committed three one-character patches originating from Debian (FTBFS fixes) at SVN r4443, and the fixed .desktop files at SVN r4444.

I've created a tfdocgen package now, and modified libticonv to depend on it make install the documentation during the install process. I'll soon do this for all the others as well.

Is it worth the trouble to try to isolate developer-oriented documentation files and bundle them into the *-devel subpackage instead? I doubt it is but I thought I'd check.

EDIT: Also, is there any extra documentation for either tilp or gfm that should be packaged? Or even for tfdocgen, I suppose? If not, I think everything is now done from a packaging standpoint.

EDIT 2: For the mean time I've disabled the call to desktop-file-validate in the tilp2 and gfm packages.

I've built x86_64 and i386 versions of the packages and put them in a temporary yum repository running on my local server. The repo file for that is available here, and I've edited the first post to have more information about this.