Hi. Сitation from official cite, March 2008: "FLTK 1.3.0 will be the direct successor to FLTK 1.1.8, sporting the addition of UTF-8, Doxygen-based manuals, a bunch of new widgets, and a handful of other features including printing. FLTK 2 uses a quite different API than FLTK 1.3. Both version will remain incompatible for quite a while, until a merge of APIs and code base may become feasible." So, 1.3.x is main branch now, most actively developed. It should be in gentoo. Thanks in advance! Reproducible: Always
Created attachment 185779 [details] fltk-1.3_pre6700 weekly snapshot this is ebuild for FLTK 1.3.x Weekly Snapshot, r6700.
Created attachment 185781 [details, diff] fluid.desktop patch this is the same as for fltk-1.1.9 from portage
Works excellent for me. Thank you!
Created attachment 185952 [details] fltk-1.3_pre6700 weekly snapshot this is ebuild for FLTK 1.3.x Weekly Snapshot, r6700. fix email - sory
Created attachment 190039 [details] current snapshot update to the current snapshot. fltk support now rotated text with xft.
... or, at the very least stable 1.3.x-r8114 version! From what I read on the FLTK website, 2.0 development is dropped indefinitely and is considered deprecated for now in favor of 1.3. (fltk-2.0 should probably be masked to prevent unknowingly people from compiling against them and filing bugs.) I push some votes on this bug as I use FLTK quite a lot here!
Created attachment 258210 [details] the first release candidat fltk-1.3.0 ebuild fltk-1.3.0-rc1 is out
Created attachment 258474 [details] fltk-1.3.0_rc2.ebuild
Created attachment 258475 [details, diff] install patch for rc2
Created attachment 259504 [details] fltk-1.3.0_rc3 ebuild updated to 1.3.0_rc3
Can anyone please change name in "Thanks for preliminary ebuild" message in fltk's ChangeLog to "Yury Fedorchenko", because he is an author of those preliminary ebuilds, not me. I have only filled this bug. Thanks.
FYI: 1.3.0_rc3 ebuild works here on x86
As fltk 1.1 and 1.3 has compatible API maybe 1.1 slot should be changed to just 1? Because thats confusing to have fltk-1.3 in 1.1 slot.
This is likely upstream, why are fltk-1.3 libs being installed into a folder named /usr/lib/fltk-1.1? I have no install fltk-1.1 packages. fltk-2 is installed as a dep of dillo. fltk-1.3 is installed as a dep for htmldoc. /usr/lib/fltk <- fltk-2 /usr/lib/fltk-1.1/ <-fltk-1.3 Although they're probably doing this for portability, there's also a good chance they don't realize where fltk-1.3 libs are being installed on 'make install' -- are you on their mailing list? Can you report upstream?
Created attachment 260111 [details, diff] Fixes to install libs/includes into /usr/lib/fltk-$PV and /usr/include/fltk-$PV Fixes to install libs/includes into /usr/lib/fltk-$PV and /usr/include/fltk-$PV instead of using $SLOT which resulted in /usr/lib/fltk-1.1 & /usr/include/fltk-1.1. Should now see /usr/lib/fltk-1.3_rc3 /usr/include/fltk-1.3_rc3 (*Note: $PV does not include Gentoo -r1 release version fields.) Fixed post install ewarn comments to reflect better spelling/grammar. $ patch --dry-run -i fltk-1.3.0_rc3.ebuild-roger-20110117.patch (omitting --dry-run or use -R to undo a patched file.)
Created attachment 260112 [details] metadata.xml file Here's a metadata.xml file for this package. Feel free to fill in the blanks if you know anymore of the information. I can proxy for this package as I use dill & fltk quite a lot here. But I'm sure Grygoriy will want to be a primary proxy for his bug/ebuild.
Created attachment 260115 [details] metadata.xml Corrected errors
(In reply to comment #14) > This is likely upstream, why are fltk-1.3 libs being installed into a folder > named /usr/lib/fltk-1.1? > Thats our ebuilds installs it into fltk-${SLOT} folder, where 1.1 is slot. I think that fltk-${SLOT} is right place to install it, not fltk-${PV} one. Because several versions within one slot at once is not supposed to be installed. But as 1.3 and 1.1 are in same slot, slot name should be changed from 1.1 to more general name - "1". This way both 1.1 and 1.3 would be installed into fltk-1 directory, causing no confusion. Also all ebuilds dependent on fltk:1.1 should be fixed to be dependent on fltk:1 (In reply to comment #14) > Can you report upstream? Upstream seem to be unrelated, their build system allow to install fltk in arbitrary place.
Looking over python-2 & python-3 ebuilds, guess you're right. Instead SLOT="1.3" is probably more appropriate? And then, it's up to the packages requiring a specific FLTK version to find it's appropriate version during compile. Sorry about the patch then, I was wrong... but you could probably utilize the grammar fixes if you want. ;-)
... sorry, either SLOT="1" or SLOT="1.3" would be appropriate. Else, developer's upstream will stumble over "/usr/lib/fltk-1.1" or "/usr/lib/fltk-1.1" within the compilation logs and constantly wonder why people are compiling against fltk-1.1. I'm guessing, if you define SLOT="1", then you need to make sure this package is masked, else it will take over stable fltk 1.x stable versions. If you define SLOT="1.3", then this package will have it's own slot and will only be pulled in when a package requests fltk-1.3 explicitly. ... correct me if I'm wrong ...
(In reply to comment #20) > ... sorry, either SLOT="1" or SLOT="1.3" would be appropriate. > > Else, developer's upstream will stumble over "/usr/lib/fltk-1.1" or > "/usr/lib/fltk-1.1" within the compilation logs and constantly wonder why > people are compiling against fltk-1.1. > > I'm guessing, if you define SLOT="1", then you need to make sure this package > is masked, else it will take over stable fltk 1.x stable versions. If you > define SLOT="1.3", then this package will have it's own slot and will only be > pulled in when a package requests fltk-1.3 explicitly. ... correct me if I'm > wrong ... > > 1.3.0_rc3 is stable enough at Gentoo The reason that 1.3 not yet release is mostly concern to MacOS port. I've used snapshots during about 2 years 'cause I'm one of fltk developers (see ebuilds history). IMHO no reasons to create new slot for 1.3. some apps need trivial patches (see bug #351963 for example) to build with 1.3. P.S. from fltk-1.3 installation of symlinks is dropped.
> I've used snapshots during about 2 years 'cause I'm one of fltk developers (see > ebuilds history). Good to hear, I will drop you a mail to discuss what is the best for slotting and streamlining fltk.
FYI: There is now a port of www-client/dillo using fltk-1.3. Not really relevant to this bug, but worthy of mention. Also, these aren't publicly posted as of yet. $ hg clone --uncompress http://hg.dillo.org/dillo_port1.3 Google for these two patches recently posted to the Dillo mailing list: 1.3_ui_hardcoded.patch (Fixes most GUI bugs) pthread_ldadd.patch (Else, you need to --disable-threaded-dns and comment out Flock within sources) $ ./autogen (if needed) && ./configure && make (binary will be at ./src/dillo)
It might be a great idea, instead of doing snapshots, pull the cvs/svn copy of fltk-1.3. (Just noticed now, dillo requires a recent modification now included within the fltk-1.3 development sources. Things seem to be picking up speed.) Something like fltk-1.3.9999.ebuild for the versioning field? Doing this will likely also save a lot of time from commiting snapshot ebuilds.
Created attachment 266249 [details] fltk-1.3 SVN ebuild This should just work after copying over the current fltk-1.3.0_rc3-r1 patches now in portage (but not listed within this page). The files needed for epatch are /usr/portage/x11-libs/fltk/files: fltk-1.3.0-as-needed.patch fltk-1.3.0-conf-tests.patch fltk-1.3.0-share.patch Simply doing something like "cp /usr/portage/x11-libs/fltk/files/fltk-1.3.0* /usr/local/portage/x11-libs/fltk/files" should work after downloading this svn r9999 ebuild. Feel free to clean this up if I did something wrong! I don't think I did anything wrong aside from not including the current patches. And, I'm not going to open a separate bug for this as it should probably take the place of the snapshots. Seems the snapshots are not being updated anymore? (SVN ebuild version seems more appropriate anyways. And, once the 1.3 releases are published, then roll those ebuilds out like the snapshots. Currently stuck being able to build Dillo using fltk-1.3 as it requires a more recent snapshot.)
Thanks for reminding me. I will try to get this all fixed on the weekend.
So guys, it is bump, we (I) will not maintain a live ebuild in the tree and everything is moved to SLOT=1. Please open bugs for broken packages. For the live ebuild, please try sunrise.
FYI: Message forwarded from Dillo mailing list. (Seen in http://fltk.org/newsgroups.php?s11135+gfltk.development+v11151+T0) "1.3.0 will go final Sunday unless there is a major show-stopper." Do we have a fltk-1.3.0.ebuild ebuild ready to publish?
FYI: FLTK 1.3.0 version released. http://www.fltk.org/articles.php?L1086 (I can reopen this bug if somebody wants to attach an ebuild. As to why I won't reopen immediately, I don't have enough time right now, but may if I find myself resting w/o anything to do.)
Created attachment 277327 [details] fltk-1.3.0.ebuild OK, never mind. Here's a fltk-1.3.0.ebuild. (Copied from fltk-1.3.0_rc6.ebuild currently within Gentoo Portage. No fixes or hacks apparently needed. Just copied & renamed the ebuild.) So far, this Ebuild compiles fine here on x86. Also tested using dillo_port1.3 and it seems to compile and execute just fine here with this (final/stable) release of fltk-1.3.0. TODO: Any missing docs? fltk-1.3.0 release seems to have separate fltk-1.3.0-docs-pdf.tar.gz & fltk-1.3.0-docs-html.tar.gz files listed on the FLTK download page. There is a "doc" USE flag, so does the source tarball make these additional pdf/html files using docbook/doxygen? Following text output after emerge: <<< !needed sym /usr/lib/fltk-1.1/libfltk.so <<< !needed obj /usr/lib/fltk-1.1/libfltk.so.1.3 And I'm showing the ebuild installed/slotted them here: /usr/lib/fltk-1/libfltk.so /usr/lib/fltk-1/libfltk.so.1.3
Please do not reassign bugs.
+*fltk-1.3.0 (17 Jun 2011) + + 17 Jun 2011; Justin Lecher <jlec@gentoo.org> -files/fltk-1.1.7-amd64.patch, + -files/fltk-1.1.7-as-needed.patch, -files/fltk-1.1.7-dieonerrors.patch, + -files/fltk-1.1.7-maxmin-typo.patch, -files/fltk-1.1.7-xft-and-misc.patch, + -fltk-1.1.9-r2.ebuild, -files/fltk-1.1.9-share.patch, -fltk-1.1.10-r1.ebuild, + -fltk-1.3.0_rc3-r1.ebuild, -fltk-1.3.0_rc5.ebuild, -fltk-1.3.0_rc6.ebuild, + -fltk-1.3.0_rc7.ebuild, +fltk-1.3.0.ebuild, + +files/fltk-1.3.0-as-needed.patch, +files/fltk-1.3.0-conf-tests.patch, + +files/fltk-1.3.0-share.patch, -files/fltk-1.3.0_rc3-as-needed.patch, + -files/fltk-1.3.0_rc3-conf-tests.patch, -files/fltk-1.3.0_rc3-share.patch, + -files/fltk-1.3.0_rc5-as-needed.patch, -files/fltk-1.3.0_rc5-share.patch, + -files/libs-1.7.diff: + Version BUmp, Cleaned old, #262395 +
Dunno what happened there. Only intended to reopen -- and not divert from your assigned status. I just marked another bug as confirmed and did not see reassignment. Likely accidentally ticked something, somehow. (Seen this sporadically before. Stuff happens. I'll see if I can remember/catch this on my next edit 6-12 mos. from now!)
Ah. Now I see it. Happens during when I submit attachment. It gives an option to "take bug" and change status. I probably was trying to elect to just change status and ticked without thinking. ;-)
