Re: abiword
On 04/16/2016 02:29 AM, Yasha Karant wrote: I may be in a university environment, but we do not waste time reinventing the wheel for research or research support activities -- and neither does any other viable research group. No insult was intended, incidentally, but you are still in a different environment than most of us, myself included. In my environment I run the IT department (and we run an open IT using as much open source as possible, with as much user feedback listened to as is practical). I am cognizant that my situation is probably also a bit unique in that I have flexibility (and authority in my environment as CIO) that many people on this list do not have. However, it was my understanding that the EPEL or other similar automata are not readily available -- for deploying production code through porting there is no reason not to use an existing "automaton" that can resolve dependencies (I recall a correspondent referring to these sorts of things as :dependency hell") from whatever source code repositories as required and ultimately build a working executable application. The full EPEL build system is open source; it's called koji and is what the Fedora Project uses to build packages. You can replicate the full Fedora build infrastructure yourself on your own server farm if you wished (and had time/resources) to do so. See the following links: https://fedoraproject.org/wiki/Infrastructure/KojiBuildSystem https://fedoraproject.org/wiki/Koji https://fedoraproject.org/wiki/Koji/ServerHowTo Your understanding of the availability of the EPEL buildsystem was correct only in part; EPEL is built against RHEL packages that are not publicly available, but there is nothing preventing you from using the koji software to build/rebuild EPEL (Fedora) source packages using ScientificLinux packages to populate the buildroot. And, in my opinion, EPEL needs to continue to be built using RHEL packages to populate the buildroot, as that seems to be the most compatible with the from-source rebuilds like SL and CentOS. But your own, private, Fedora Extra Packages for SL is not impossible to do, and all software and processes are openly available. ...But -- I would very much like a working SL7 binary executable of a reasonably current Abiword. There are channels to request EPEL packages (especially if the package is already in Fedora), and that mechanism has been documented in this thread; thanks, Pat! I chimed in on this thread because I also have application for abiword on 7; my particular need has not yet been pressing. Had the need been pressing I would have built my own abiword packages (following the process Russ did and recursively building the dependencies) and gone about my merry way without commenting on the list. and, in fact, I have done that with other packages in the past that I have needed; I have a number of packages that I have built myself because no repo had the particular version I needed (a slightly older kicad, for instance). But I am not in the business of being a repo, either; there are definite ramifications for binary distribution, and I have no desire to be 'responsible' again for a widely distributed binary package, outside of an established repository, and I would have to have a pressing need to do that. As an explanation for that, I would just point you to the following archived mailing list messages: http://www.postgresql.org/message-id/200410251354.53583.j...@agliodbs.com http://www.postgresql.org/message-id/200410251334.36550.lo...@pari.edu Since it appears EPEL7 will have abiword reasonably soon, I'm not going to duplicate the effort for my own non-pressing need, but I will thank Russ for poking the process along.
Re: abiword
On 04/15/2016 12:54 PM, Lamar Owen wrote: On 04/15/2016 11:48 AM, R P Herrold wrote: as well as a well documented, and solved problem with the buildsystem which EPEL uses (I was perhaps too eliptical yesterday), and thus my dis-interest in re-inventing or re-documenting this wheel ** yet again ** -- Russ herrold Thanks for working on this, Russ. While reinventing the wheel is frowned upon most of the time, there are settings where reinventing wheels should be encouraged, particularly the educational setting. Sometimes it is worthwhile to do some calculations by hand or by slide rule, then go back to the calculators and spreadsheets; the act of reinventing enhances the understanding of why things are done the way that they are done. You better appreciate koji if you build your own mini-beehive. For most of us, though, it's just a time sink. Yasha is in a different environment than most of us. I may be in a university environment, but we do not waste time reinventing the wheel for research or research support activities -- and neither does any other viable research group. However, it was my understanding that the EPEL or other similar automata are not readily available -- for deploying production code through porting there is no reason not to use an existing "automaton" that can resolve dependencies (I recall a correspondent referring to these sorts of things as :dependency hell") from whatever source code repositories as required and ultimately build a working executable application. At the moment, my group does not have a porting machine that we could dedicate to this sort of problem. This is not an issue of "critical thinking", etc., but rather pure technological implementation. However, the development of that technology does require a variety of "critical thinking" activities. I definitely do not want to get into the repo "business" at this time -- we do not have the resources that we can spare from other activities, and are not likely to get the necessary external funding to become a repo development "house". But -- I would very much like a working SL7 binary executable of a reasonably current Abiword. Yasha Karant
Re: abiword
On 04/14/2016 03:49 PM, R P Herrold wrote: Lamar -- could you please pull and build SRPMs out of the 'local' path, and confirm that no gremlins have crept in, via a cross-check on your buildsystem? I don't use 'mock' for scratch solves I did not get this done; too many work-related things having to do with GNUradio, an ODroid C2, and CentOS 7/aarch64.
Re: abiword
On 04/15/2016 11:48 AM, R P Herrold wrote: as well as a well documented, and solved problem with the buildsystem which EPEL uses (I was perhaps too eliptical yesterday), and thus my dis-interest in re-inventing or re-documenting this wheel ** yet again ** -- Russ herrold Thanks for working on this, Russ. While reinventing the wheel is frowned upon most of the time, there are settings where reinventing wheels should be encouraged, particularly the educational setting. Sometimes it is worthwhile to do some calculations by hand or by slide rule, then go back to the calculators and spreadsheets; the act of reinventing enhances the understanding of why things are done the way that they are done. You better appreciate koji if you build your own mini-beehive. For most of us, though, it's just a time sink. Yasha is in a different environment than most of us.
Re: abiword
On Fri, 15 Apr 2016, Lamar Owen wrote: > On 04/14/2016 03:49 PM, R P Herrold wrote: > > Lamar -- could you please pull and build SRPMs out of the 'local' path, and > > confirm that no gremlins have crept in, via a cross-check on your > > buildsystem? I don't use 'mock' for scratch solves Thanks -- Russ > scratch builds on C7 yet, although I need to do so. we all need more round tuits ;) as you were the original desiring 'consumer' of abiword, I had asked you. Events have moved a bit in that I have been now added as a co-administrator of abiword at EPEL 7, and so anticipate moving it through that buildsystem over the next week > Yasha, this is a classic automaton problem, and should be > solved accordingly. The state machine needs inputs of > dependencies, and the build order for the dependencies will > become clear. It is also a *solved* problem, in the form of > the 'smock' perl script, which you can find at > https://github.com/richm/scripts/blob/master/smock.pl as well as a well documented, and solved problem with the buildsystem which EPEL uses (I was perhaps too eliptical yesterday), and thus my dis-interest in re-inventing or re-documenting this wheel ** yet again ** -- Russ herrold
Re: abiword
On 04/14/2016 03:49 PM, R P Herrold wrote: Lamar -- could you please pull and build SRPMs out of the 'local' path, and confirm that no gremlins have crept in, via a cross-check on your buildsystem? I don't use 'mock' for scratch solves Thanks -- Russ Russ, I'll try to look at it later today. While I have a full-blown mock buildsystem on the IA64 box, that's CentOS 5. I haven't done the same on CentOS 7 as yet, as I haven't had the need. Yeah, I've not been doing clean scratch builds on C7 yet, although I need to do so. I need to add RAM to make it faster, and I need to add disk for the repo cache (I have 20GB of RAM now in my laptop (Dell M6500 Core i7), but I need 32GB to really be able to put the buildroot entirely in RAM during the build, and a second 1TB drive (putting the boot SSD on mSATA module for three drives) Well, I don't *need* to do that, but I *want* to do that, as 'buildroot in RAMdisk' makes builds fly. at least that has been my experience on the Altix IA64 boxen, where putting the buildroot in a RAMdisk cut build iteration times (especially for the kernel, glibc, and gcc) to 10% of what they had been, since the Altix is not an I/O monster, but the RAM bandwidth is very high. Yasha, this is a classic automaton problem, and should be solved accordingly. The state machine needs inputs of dependencies, and the build order for the dependencies will become clear. It is also a *solved* problem, in the form of the 'smock' perl script, which you can find at https://github.com/richm/scripts/blob/master/smock.pl But you may want to not pass up the teaching opportunity of applying 'critical thinking' about 'what constitutes an automaton?' as it relates to depsolving. Russ has done the legwork of getting all the inputs you need in the ftp area he posted. Simple (and not so simple) depsolving is a really good way to get state machine theory into a hands-on learning activity to bring the abstract into the realm of the concrete. At least I think it is an interesting problem. The next step is solving something like the fpc (Free Pascal Compiler) build dependencies.
Re: abiword
On Thu, Apr 14, 2016 at 6:04 PM, Yasha Karant wrote: > On 04/14/2016 02:01 PM, R P Herrold wrote: >> >> On Thu, 14 Apr 2016, R P Herrold wrote: >> >>> The content is now at: >>> ftp://ftp.owlriver.com/pub/local/ORC/abiword/ >>> and will move to: >>> ftp://ftp.owlriver.com/pub/mirror/ORC/abiword/ >> >> just got a clean build with RawHide's >> abiword-3.0.1-4.orc7.src.rpm >> >> which I have pushed and will appear in 'local' >> >> -- R > > > This probably will require either EPEL or someone on this list who can > generate a working binary. A naive rpmbuild --rebuild yields: > > error: Failed build dependencies: > aiksaurus-devel is needed by abiword-1:3.0.1-4.el7.x86_64 > aiksaurus-gtk-devel is needed by abiword-1:3.0.1-4.el7.x86_64 > asio-devel is needed by abiword-1:3.0.1-4.el7.x86_64 > goffice-devel is needed by abiword-1:3.0.1-4.el7.x86_64 > gtkmathview-devel is needed by abiword-1:3.0.1-4.el7.x86_64 > librevenge-devel is needed by abiword-1:3.0.1-4.el7.x86_64 > libwmf-devel is needed by abiword-1:3.0.1-4.el7.x86_64 > libwpd-devel is needed by abiword-1:3.0.1-4.el7.x86_64 > libwpg-devel is needed by abiword-1:3.0.1-4.el7.x86_64 > link-grammar-devel is needed by abiword-1:3.0.1-4.el7.x86_64 > loudmouth-devel is needed by abiword-1:3.0.1-4.el7.x86_64 > ots-devel is needed by abiword-1:3.0.1-4.el7.x86_64 > poppler-devel is needed by abiword-1:3.0.1-4.el7.x86_64 > t1lib-devel is needed by abiword-1:3.0.1-4.el7.x86_64 > telepathy-glib-devel is needed by abiword-1:3.0.1-4.el7.x86_64 > wv-devel is needed by abiword-1:3.0.1-4.el7.x86_64 It's a lot of backporting to get things like this onto older OS releases, such as RHEL. versus Fedora. I publish a *lot* of these over at https://github.com/nkadel/ including backports of Samba 4.x, and used to publish Subversion backports over at RPMforge. Repoforge has an out of date abiword compatible for SL 6, perhaps you could start from there, so you might try starting from http://apw.sw.be/source/ EPEL is unwilling to replace RHEL, and thus CentOS and Scientitific Linux, base packages, and building up the dependency tree for older packages can get into dependency hell *really fast*. If it's only a few components, it's fairly easy to set up a local SRPM build environment, with a localized yum repo setup, to build up the components with "mock". Take a look at my setup for RT 4.4, at https://github.com/nkadel/rt4builder-4.4.x, for a pretty powerful example with subdirectories for individual components, and the dependencies laid out to build in order. That was for RT, which has a *big* Perl dependency tree. I used to backport it to SL 6, but the dependencies cot out of hand when I had to update libwww. I've been trying to do it for the awscli, the AWS command line interface, and that is *really, really painful*.
Re: abiword
On 04/14/2016 02:01 PM, R P Herrold wrote: On Thu, 14 Apr 2016, R P Herrold wrote: The content is now at: ftp://ftp.owlriver.com/pub/local/ORC/abiword/ and will move to: ftp://ftp.owlriver.com/pub/mirror/ORC/abiword/ just got a clean build with RawHide's abiword-3.0.1-4.orc7.src.rpm which I have pushed and will appear in 'local' -- R This probably will require either EPEL or someone on this list who can generate a working binary. A naive rpmbuild --rebuild yields: error: Failed build dependencies: aiksaurus-devel is needed by abiword-1:3.0.1-4.el7.x86_64 aiksaurus-gtk-devel is needed by abiword-1:3.0.1-4.el7.x86_64 asio-devel is needed by abiword-1:3.0.1-4.el7.x86_64 goffice-devel is needed by abiword-1:3.0.1-4.el7.x86_64 gtkmathview-devel is needed by abiword-1:3.0.1-4.el7.x86_64 librevenge-devel is needed by abiword-1:3.0.1-4.el7.x86_64 libwmf-devel is needed by abiword-1:3.0.1-4.el7.x86_64 libwpd-devel is needed by abiword-1:3.0.1-4.el7.x86_64 libwpg-devel is needed by abiword-1:3.0.1-4.el7.x86_64 link-grammar-devel is needed by abiword-1:3.0.1-4.el7.x86_64 loudmouth-devel is needed by abiword-1:3.0.1-4.el7.x86_64 ots-devel is needed by abiword-1:3.0.1-4.el7.x86_64 poppler-devel is needed by abiword-1:3.0.1-4.el7.x86_64 t1lib-devel is needed by abiword-1:3.0.1-4.el7.x86_64 telepathy-glib-devel is needed by abiword-1:3.0.1-4.el7.x86_64 wv-devel is needed by abiword-1:3.0.1-4.el7.x86_64 and when I start with the first failed dependency: yum install aiksaurus-devel No package aiksaurus-devel available. Error: Nothing to do Hopefully, someone will have both the time (and required effort) to build abiword (more or less current) and to be able to release either a consistent and ready to build set of rpm.src files for SL7, etc., or a built binary RPM along with whatever other built RPMs are required again for SL7. As it appears that there are business restrictions that prevent Owlriver from offering any such binaries, I hope that someone else may -- or EPEL will come through in short order. (I was under the impression that a business could offer executable software without cost for download provided the usual "disclaim all" was part of the download and use "license".) abiword is available for ubuntu http://abiword.en.uptodown.com/ubuntu/download (not to claim that Ubuntu LTS is somehow better than SL) from at least one site on the web . Yasha Karant
Re: abiword
On Thu, 14 Apr 2016, R P Herrold wrote: > The content is now at: > ftp://ftp.owlriver.com/pub/local/ORC/abiword/ > and will move to: > ftp://ftp.owlriver.com/pub/mirror/ORC/abiword/ just got a clean build with RawHide's abiword-3.0.1-4.orc7.src.rpm which I have pushed and will appear in 'local' -- R
Re: abiword
On Thu, 14 Apr 2016, Yasha Karant wrote: > Thank you very much for providing the above URLs. > > From the above reference web site, I am guessing that only > orc7 (owlriver 7) extension files are needed for SL 7, in > which case here is the list of what I have downloaded: no idea if your guess is right, and checking my binary solve environment is not something that is fast or free -- SRPMs are offered for what they are. If the main distribution, or something EPEL should happen to 'overtake' and displace something in that pile while running a 'yum update ...' it would be fine with me, as I strive, but to not test that > Are there other files that are needed other than those > provided in the "standard" EL7 public repos? (I believe > that the Red Hat subscriber repos are not readily available > to the non-paying, only CentOS repos under the Red Hat > "umbrella".) The Red Hat provided 'git' which CentOS is fed from may be used to build SRPMs seemingly without change by the CentOS folks > By the way, as a university (not a business), are we allowed > to redistribute binary RPMS made from the above .src.rpm > files with the usual acknowledgement (thanking you and your > firm, but no guarantee that anything works and no guarantee > that the binaries will not "destroy" any system upon which > these are installed)? If we do build from your .src.rpm s > and things work, why should others have re-invent the wheel > and/or redo the labor? umm -- at the top of the archive: ftp://ftp.owlriver.com/pub/mirror/ORC/README (go read -- I'll wait) I add no non-freely licensed content to the archive at: ftp.owlriver.com all is redistributable save that something might be retro-actively found as containing non-free matter. As I don't patrol for that, I would not remove such (There was an instance some years ago where an upstream CD respin was needed when non-free content was found in (as memory serves) a non-free font was found in RHL. I would miss seeing that] -- Russ herrold
Re: abiword
On 04/14/2016 12:49 PM, R P Herrold wrote: On Thu, 14 Apr 2016, R P Herrold wrote: I have a local solution in a 'scratch build' environment, yielding: abiword-3.0.1-2.el7.centos.src.rpm. It 'runs' at soon, soon and now done The content is now at: ftp://ftp.owlriver.com/pub/local/ORC/abiword/ and will move to: ftp://ftp.owlriver.com/pub/mirror/ORC/abiword/ Lamar -- could you please pull and build SRPMs out of the 'local' path, and confirm that no gremlins have crept in, via a cross-check on your buildsystem? I don't use 'mock' for scratch solves Thanks -- Russ Thank you very much for providing the above URLs. From the above reference web site, I am guessing that only orc7 (owlriver 7) extension files are needed for SL 7, in which case here is the list of what I have downloaded: abiword-3.0.1-2.orc7.src.rpm abiword.spec aiksaurus-1.2.1-33.orc7.src.rpm aiksaurus.spec asio-1.4.8-3.orc7.src.rpm asio.spec gtkmathview-0.8.0-19.orc7.src.rpm gtkmathview.spec librevenge-0.0.2-6.orc7.src.rpm librevenge.spec link-grammar-5.0.8-6.orc7.src.rpm link-grammar.spec loudmouth-1.4.3-17.orc7.src.rpm loudmouth.spec ots-0.5.0-11.orc7.src.rpm ots.spec wv-1.2.9-12.orc7.src.rpm wv.spec Are there other files that are needed other than those provided in the "standard" EL7 public repos? (I believe that the Red Hat subscriber repos are not readily available to the non-paying, only CentOS repos under the Red Hat "umbrella".) By the way, as a university (not a business), are we allowed to redistribute binary RPMS made from the above .src.rpm files with the usual acknowledgement (thanking you and your firm, but no guarantee that anything works and no guarantee that the binaries will not "destroy" any system upon which these are installed)? If we do build from your .src.rpm s and things work, why should others have re-invent the wheel and/or redo the labor? Yasha Karant
Re: abiword
On Thu, 14 Apr 2016, R P Herrold wrote: > I have a local solution in a 'scratch build' environment, > yielding: abiword-3.0.1-2.el7.centos.src.rpm. It 'runs' at > soon, soon and now done The content is now at: ftp://ftp.owlriver.com/pub/local/ORC/abiword/ and will move to: ftp://ftp.owlriver.com/pub/mirror/ORC/abiword/ Lamar -- could you please pull and build SRPMs out of the 'local' path, and confirm that no gremlins have crept in, via a cross-check on your buildsystem? I don't use 'mock' for scratch solves Thanks -- Russ
Re: abiword
On Thu, 14 Apr 2016, Yasha Karant wrote: > > so, thus, my earlier mention of poking EPEL As the day has passed, I 'poked' the EPEL package database https://admin.fedoraproject.org/pkgdb/package/rpms/abiword/ and as the link Pat noted earlier in the day says, this starts a countdown clock to slide the package into eligibility for EPEL 7 > Although EPEL "should", being like CentOS these days a > more-or-less "wholly owned subsidiary" of Red Hat, but the > time it is done we may be at RHEL 8. only if one does not poke ;) > You indicated that you are willing to release the SRPMs that > have already been ported (both for source code and > dependencies) to SL 7 and that upon using a command syntax > like: ... snip snip package building has many paths for solution -- At this state of the art, the one EPEL uses with 'mock' and 'koji' and signing and bugzilla and more is mature and worth using, in deference to local solutions I have a local solution in a 'scratch build' environment, yielding: abiword-3.0.1-2.el7.centos.src.rpm. It 'runs' at least to the extent of showing the Help | About dialog [1]. I have it rebuilding 'for external record' and in about an hour MY version of the SRPM will be up at my FTP site. I know it pulls out some Pythonic API and 'gir' parts. As I don't use them, I don't care about ripping them out According to 'RawHide', Fedora and so EPEL should be at: $ srcfind abiword | grep -i rawhide ... /var/ftp/pub/nfs/mirror/redhat/rawhide2016/a/abiword-3.0.1-4.fc23.src.rpm with some minor changes in the Changelog after the point I forked from: * Sat May 02 2015 Kalev Lember - 1:3.0.1-4 - Rebuilt for GCC 5 C++11 ABI change * Thu Mar 26 2015 Richard Hughes - 1:3.0.1-3 - Add an AppData file for the software center * Tue Jan 27 2015 Petr Machata - 1:3.0.1-2 - Rebuild for boost 1.57.0 * Wed Dec 24 2014 Peter Robinson 1:3.0.1-1 - Update to 3.0.1 stable soon, soon -- Russ herrold 1. http://gallery.herrold.com/stuff/abiword-3.0.1.png
Re: abiword
On 04/14/2016 11:22 AM, R P Herrold wrote: On Thu, 14 Apr 2016, Yasha Karant wrote: I don't and haven't 'publish' binaries for a long time now, Although you evidently are not a "repo", are you willing to allow others access to the built RPMs (not SRPMs) needed for an executable install of abiword? The RPMs I have are all 2.x, nothing in 3.x . Are there any "conflicts" between what is needed by a more recent abiword and the standard install (from SL/CentOS, EPEL, ElRepo repos)? That is, package M conflicts with whatever during the binary install? Long ago and far away, with the pre-cursor product to CentOS (cAos), I built and released binaries. With the turn-down of RHL, and the rise of the 'Enterprise' distributions, I spent some time considering 'policy' as to releasing sources vs. binaries, and concluded that there were obligations to 'stand behind' binaries, which did not arise with a simple set of related sources. Unless one is a commercial customer of Owl River, binaries are not available ( contrariwise, all binaries installed at any customer are backed by availability of sources at the site previously indicated, thus satisfying GPL and related 'source availability' obligations ) so, thus, my earlier mention of poking EPEL I could attempt to put personnel (grad students, undergrads) on the build, but I really do have higher priority work for these persons. I myself do not have the spare time right now to contribute much to the porting effort of a standard "office enduser" package. And wonderfully, in the FOSS ethic, EPEL should solve this for all of us with any luck -- Russ herrold Although EPEL "should", being like CentOS these days a more-or-less "wholly owned subsidiary" of Red Hat, but the time it is done we may be at RHEL 8. You indicated that you are willing to release the SRPMs that have already been ported (both for source code and dependencies) to SL 7 and that upon using a command syntax like: rpmbuild --rebuild /tmp/mypackage-1.0.0-1.src.rpm where .src.rpm is the same as .srpm (as I recall). will result in a (set) of binary RPM files that will install application "binaries" that will execute under SL7. Any dependencies (e.g., other development packages, not just header file RPMs, but ".so" file RPMs) will be revealed by the rpmbuild step and can be "fixed" through yum install foobar (where foobar is the dependency) from either SL, EPEL, or ElRepo, not RPMs for which one has the merry chase on the web (sometimes resulting in other incompatibilities or real vulnerabilities). I am not trying to be overly specific here, but my group (as I am certain have others on this list) has more than once had to chase down RPM dependencies (e.g., libraries) that only were made at one laboratory somewhere -- and never made it into the "mainstream" EL repos (say ported from some other Linux family). Thanks for any clarification. Yasha Karant
Re: abiword
On Thu, 14 Apr 2016, Yasha Karant wrote: > > I don't and haven't 'publish' binaries for a long time now, > Although you evidently are not a "repo", are you willing to > allow others access to the built RPMs (not SRPMs) needed for > an executable install of abiword? The RPMs I have are all > 2.x, nothing in 3.x . Are there any "conflicts" between > what is needed by a more recent abiword and the standard > install (from SL/CentOS, EPEL, ElRepo repos)? That is, > package M conflicts with whatever during the binary install? Long ago and far away, with the pre-cursor product to CentOS (cAos), I built and released binaries. With the turn-down of RHL, and the rise of the 'Enterprise' distributions, I spent some time considering 'policy' as to releasing sources vs. binaries, and concluded that there were obligations to 'stand behind' binaries, which did not arise with a simple set of related sources. Unless one is a commercial customer of Owl River, binaries are not available ( contrariwise, all binaries installed at any customer are backed by availability of sources at the site previously indicated, thus satisfying GPL and related 'source availability' obligations ) so, thus, my earlier mention of poking EPEL > I could attempt to put personnel (grad students, undergrads) > on the build, but I really do have higher priority work for > these persons. I myself do not have the spare time right > now to contribute much to the porting effort of a standard > "office enduser" package. And wonderfully, in the FOSS ethic, EPEL should solve this for all of us with any luck -- Russ herrold
Re: abiword
On 04/14/2016 08:28 AM, R P Herrold wrote: On Thu, 14 Apr 2016, R P Herrold wrote: I'll poke at it today and with an older abiword-3.0.1-1 spec I have been working with, I get a complete build save for: abiword-3.0.1/plugins/openxml/imp/xp/OXML_LangToScriptConverter.gperf and abiword-3.0.1-1.el7.centos.x86_64/usr/lib64/girepository-1.0/Abi-3.0.typelib ... the RPM build turn cycle is slow as there are so many moving parts, but looking good I don't and haven't 'publish' binaries for a long time now, and have a day's delay between 'inside' local content, and formal mirrored content ... looking, it appears I've been doing this package for over a decade (it is also my preferred 'Word' format file editing tool, and I have large corpus of content in such form). Gnumeric is the other I rely on, to avoid the LibreOffice trap but SRPMs end up with a day's delay at: ftp://ftp.owlriver.com/pub/mirror/ORC/abiword/ -- Russ herrold Although you evidently are not a "repo", are you willing to allow others access to the built RPMs (not SRPMs) needed for an executable install of abiword? The RPMs I have are all 2.x, nothing in 3.x . Are there any "conflicts" between what is needed by a more recent abiword and the standard install (from SL/CentOS, EPEL, ElRepo repos)? That is, package M conflicts with whatever during the binary install? I could attempt to put personnel (grad students, undergrads) on the build, but I really do have higher priority work for these persons. I myself do not have the spare time right now to contribute much to the porting effort of a standard "office enduser" package. Yasha Karant
Re: abiword
On Thu, 14 Apr 2016, R P Herrold wrote: > I'll poke at it today and with an older abiword-3.0.1-1 spec I have been working with, I get a complete build save for: abiword-3.0.1/plugins/openxml/imp/xp/OXML_LangToScriptConverter.gperf and abiword-3.0.1-1.el7.centos.x86_64/usr/lib64/girepository-1.0/Abi-3.0.typelib ... the RPM build turn cycle is slow as there are so many moving parts, but looking good I don't and haven't 'publish' binaries for a long time now, and have a day's delay between 'inside' local content, and formal mirrored content ... looking, it appears I've been doing this package for over a decade (it is also my preferred 'Word' format file editing tool, and I have large corpus of content in such form). Gnumeric is the other I rely on, to avoid the LibreOffice trap but SRPMs end up with a day's delay at: ftp://ftp.owlriver.com/pub/mirror/ORC/abiword/ -- Russ herrold
Re: abiword
On Thu, 14 Apr 2016, R P Herrold wrote: > looks like libasio -- sounds like a task for EPEL devel ML actually I got a build there as well, with only a minimal rpmlint snark /home/herrold/rpmbuild/SRPMS/asio-1.4.8-3.orc7.src.rpm /home/herrold/rpmbuild/RPMS/x86_64/asio-devel-1.4.8-3.orc7.x86_64.rpm made a local: asio-1.4.8-3.orc7.src.rpm CWD: /home/herrold/build/7/abiword CWD: /tmp/rph-rpmbuild.rpmlint.lJ6q BAS_NEWSR: asio-1.4.8-3.orc7.src.rpm asio.src: E: specfile-error warning: bogus date in %changelog: Tue Aug 3 2011 Peter Robinson - 1.4.8-1 1 packages and 0 specfiles checked; 1 errors, 0 warnings. I'll poke at it today -- Russ herrold
Re: sci-l-u] Re: abiword
On Thu, 14 Apr 2016, Lamar Owen wrote: > Several of abiword's buildrequires are not in the various EL7 repos. There > aren't very many of them; in attempting to rebuild the FC22 Abiword and > attempting to install the buildreqs I get: > No package aiksaurus-devel available. > No package aiksaurus-gtk-devel available. > No package gtkmathview-devel available. > No package link-grammar-devel available. > No package loudmouth-devel available. > No package ots-devel available. > No package wv-devel available. > > Not sure how difficult that will be to get those packages (and the packages > the -devel packages depend upon) built. I have a client who is waiting on a > CentOS 7-compatible Abiword to migrate to CentOS 7 from CentOS 6, and Abiword > is a blocker. I made a run at it a while back -- most of that list build, but there was some blocker ... memory fades [herrold@centos-7 abiword]$ date ; rpm -q wv ots loudmouth link-grammar libwpd librevenge libmspack libasyncns hspell gtkmathview aiksaurus asio cabextract fribidi enchant centos-release Thu Apr 14 10:43:18 EDT 2016 wv-1.2.9-12.orc7.x86_64 ots-0.5.0-11.orc7.x86_64 loudmouth-1.4.3-17.orc7.x86_64 link-grammar-5.0.8-6.orc7.x86_64 libwpd-0.10.0-1.el7.x86_64 librevenge-0.0.2-6.orc7.x86_64 libmspack-0.5-0.4.alpha.el7.x86_64 libasyncns-0.8-7.el7.x86_64 hspell-1.2-6.el7.x86_64 gtkmathview-0.8.0-19.orc7.x86_64 aiksaurus-1.2.1-33.orc7.x86_64 package asio is not installed cabextract-1.5-1.el7.x86_64 fribidi-0.19.4-6.el7.x86_64 enchant-1.6.0-8.el7.x86_64 centos-release-7-2.1511.el7.centos.2.10.x86_64 [herrold@centos-7 abiword]$ looks like libasio -- so8nds like a task for EPEL devel ML -- Russ herrold
Re: abiword
On 04/11/2016 07:02 AM, Yasha Karant wrote: Is there any EL7 rpm or other successful build of a recent stable release of abiword? If so, what is URL to download the build including whatever other rpms are required (or a large static image that does not require any .so components that are not part of the standard SL 7 repo)? Yasha Karant Several of abiword's buildrequires are not in the various EL7 repos. There aren't very many of them; in attempting to rebuild the FC22 Abiword and attempting to install the buildreqs I get: No package aiksaurus-devel available. No package aiksaurus-gtk-devel available. No package gtkmathview-devel available. No package link-grammar-devel available. No package loudmouth-devel available. No package ots-devel available. No package wv-devel available. Not sure how difficult that will be to get those packages (and the packages the -devel packages depend upon) built. I have a client who is waiting on a CentOS 7-compatible Abiword to migrate to CentOS 7 from CentOS 6, and Abiword is a blocker.
Re: abiword
On 12/09/2014 05:25 PM, Yasha Karant wrote: > I have been attempting to build abiword from the source > > abiword-3.0.0.tar.gz > > configure: error: Package requirements ( > fribidi >= 0.10.4 > glib-2.0 >= 2.6.0 gthread-2.0 >= 2.6.0 gobject-2.0 >= 2.6.0 > libgsf-1 >= 1.14.18 > wv-1.0 >= 1.2.0 > libxslt > gio-2.0 libebook-1.2 libecal-1.2 libical >= 0.46 > cairo-pdf cairo-ps pangocairo > gtk+-3.0 >= 3.0.8 gtk+-unix-print-3.0 librsvg-2.0 >= 2.16.0 cairo-fc > x11) were not met: > > Does anyone have a SL 7 abiword ? Does anyone know how to satisfy for SL 7 > the unmet package requirements > found by configure? > > Yasha Karant Many of those appear to be available. The ones I'm not seeing trying to build the Fedora abiword rpm on EL7 are: DEBUG util.py:283: Error: No Package found for aiksaurus-devel DEBUG util.py:283: Error: No Package found for aiksaurus-gtk-devel DEBUG util.py:283: Error: No Package found for gtkmathview-devel DEBUG util.py:283: Error: No Package found for librevenge-devel DEBUG util.py:283: Error: No Package found for link-grammar-devel DEBUG util.py:283: Error: No Package found for loudmouth-devel DEBUG util.py:283: Error: No Package found for ots-devel DEBUG util.py:283: Error: No Package found for wv-devel Again, I would suggest filing a bug against abiword in Fedora EPEL asking for an EPEL7 build. Found requirements: DEBUG util.py:283: --> autoconf-2.69-11.el7.noarch DEBUG util.py:283: --> automake-1.13.4-3.el7.noarch DEBUG util.py:283: --> asio-devel-1.10.4-2.el7.x86_64 DEBUG util.py:283: --> bison-2.7-4.el7.x86_64 DEBUG util.py:283: --> boost-devel-1.53.0-18.el7.x86_64 DEBUG util.py:283: --> bzip2-devel-1.0.6-12.el7.x86_64 DEBUG util.py:283: --> cairo-devel-1.12.14-6.el7.x86_64 DEBUG util.py:283: --> dbus-glib-devel-0.100-7.el7.x86_64 DEBUG util.py:283: --> desktop-file-utils-0.21-4.el7.x86_64 DEBUG util.py:283: --> 1:enchant-devel-1.6.0-8.el7.x86_64 DEBUG util.py:283: --> flex-2.5.37-3.el7.x86_64 DEBUG util.py:283: --> fribidi-devel-0.19.4-6.el7.x86_64 DEBUG util.py:283: --> gobject-introspection-devel-1.36.0-4.el7.x86_64 DEBUG util.py:283: --> goffice08-devel-0.8.17-10.el7.x86_64 DEBUG util.py:283: --> gtk3-devel-3.8.8-5.el7.x86_64 DEBUG util.py:283: --> libgsf-devel-1.14.26-6.el7.x86_64 DEBUG util.py:283: --> 2:libpng-devel-1.5.13-5.el7.x86_64 DEBUG util.py:283: --> librsvg2-devel-2.39.0-1.el7.x86_64 DEBUG util.py:283: --> libsoup-devel-2.42.2-3.el7.x86_64 DEBUG util.py:283: --> libwmf-devel-0.2.8.4-39.el7.x86_64 DEBUG util.py:283: --> libwpd-devel-0.9.9-3.el7.x86_64 DEBUG util.py:283: --> libwpg-devel-0.2.2-4.el7.x86_64 DEBUG util.py:283: --> libxslt-devel-1.1.28-5.el7.x86_64 DEBUG util.py:283: --> poppler-devel-0.22.5-6.el7.x86_64 DEBUG util.py:283: --> popt-devel-1.13-16.el7.x86_64 DEBUG util.py:283: --> pygobject3-3.8.2-4.el7.x86_64 DEBUG util.py:283: --> python-devel-2.7.5-16.el7.x86_64 DEBUG util.py:283: --> python-setuptools-0.9.8-3.el7.noarch DEBUG util.py:283: --> readline-devel-6.2-9.el7.x86_64 DEBUG util.py:283: --> t1lib-devel-5.1.2-14.el7.x86_64 DEBUG util.py:283: --> telepathy-glib-devel-0.20.4-5.el7.x86_64 DEBUG util.py:283: --> zlib-devel-1.2.7-13.el7.x86_64 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com
