build fails on opensuse tumbleweed
carrotIndustries opened this issue · 9 comments
@fk0815 Looks like opensuse tumbleweed updated libpodofo from 0.9.8 to 0.10 and didn't keep the 0.9 version around.
podofo 0.10 is API-incompatible with the 0.9 series, so all other distros kept 0.9 around in one way or another. What's the best way to reach the opensuse maintainers to keep podofo 0.9 packaged?
the best, I assume, would be to raise that topic on the opensuse factory mailinglist. I raised the topic there already: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/B7H6ETA2J5VA4Z63ZJ7UWEL6RGY7IY6D/
Ok, so far still no 0.9.8 podofo in tumbleweed it seems: https://software.opensuse.org/search?baseproject=openSUSE%3AFactory&q=podofo
The mailinglist response was that a podofo098 compatibility package has been kept in tumbleweed until all dependent packages have been updated to be compatible with the latest podofo. Horizon is not in the openSUSE:Factory project, which is feeding tumbleweed, it is in electronics project, therefore it did not trigger to keep the podofo098 package. I could try to submit a podofo098 package to the electronics project, users need then to install this one then to use horizon.
Is there a plan to update horizon for the new podofo API?
Is there a plan to update horizon for the new podofo API?
Eventually yes, but I once tried to do both with a bunch of ifdefs and the code was miserable.
Supporting both would require effectively maintaining two PDF exporters or writing a bunch of useless wrapper code to paper over the API differences.
Since I prefer not doing either of those, my current plan is staying on podofo 0.9.8 until podofo 0.10 has become available in the oldest supported debian and ubuntu releases.
So if we want to keep Horizon EDA working on tumbleweed, I think the only option is adding 0.9.8 to the electronics project.
Would it be possible to apply a patch with the new API changes for those distros that do not have the old libpodofo still available?
Would it be possible to apply a patch with the new API changes for those distros that do not have the old libpodofo still available?
That's more or less writing an maintaining two PDF exporters, just less convenient.
Right now, I don't have the motivation to port the PDF exporter to podofo 0.10. If anyone wants to jump in, I'll probably merge it.
If we want to support both podofos, the way to go would be having two sets of source files that get selected depending on the detected version of podofo.
I started some experimental work trying to adapt to the new libpodofo API here fk0815@1f8f517, but as I'm not a C++ developer, I got lost a bit in the PDFExporter::export_pdf() implementation to get that compiling. So help or hints are welcome.
This one fk0815@a99bc22 compiles, does the export, but the output looks somehow incorrect (duplicated text) and annotations are missing, etc. I'm struggling with c++ here an there, @carrotIndustries do you want to have a look on that early version?