This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 999609 - glpk: No way to retrieve iteration count
glpk: No way to retrieve iteration count
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: glpk (Show other bugs)
rawhide
All Linux
unspecified Severity medium
: ---
: ---
Assigned To: Conrad Meyer
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-21 13:20 EDT by Jerry James
Modified: 2013-11-10 10:15 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-10 10:15:39 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch to add a glp_get_it_cnt() function (1.07 KB, patch)
2013-08-21 13:20 EDT, Jerry James
no flags Details | Diff

  None (edit)
Description Jerry James 2013-08-21 13:20:25 EDT
Created attachment 788940 [details]
Patch to add a glp_get_it_cnt() function

Description of problem:
The versions of glpk in Fedora up through Fedora 19 still supported the old lpx_* routines and LPX* constants.  Those were dropped in the version of glpk now in F-20 and Rawhide.  I have ported all of my glpk-using packages over to the new interface, but there is one element of the old API that cannot be ported, namely:

lpx_get_int_parm(lpx, LPX_K_ITCNT);

There is simply no element of the glp_* interface that exposes this information.  I have one package now in Fedora (latte-integrale) and one package that I am about to submit (cvc4) which make that call.  They need an alternative for F-20 and Rawhide.

I am attaching a candidate patch to solve this problem.  I will ask upstream to include something like this in the next release.  For now, though, would it be possible to add this patch to the Fedora build for the sake of latte-integrale and cvc4?

Version-Release number of selected component (if applicable):
glpk-4.52.1-1.fc20

How reproducible:
N/A

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 1 Jerry James 2013-10-01 22:23:56 EDT
Since the requested function will be included in the next version of glpk (see http://lists.gnu.org/archive/html/help-glpk/2013-08/msg00047.html), adding it now is forward compatible.  Can this patch please be added?  I am still stuck with latte-integrale and cvc4 because of this bug.  Thank you.
Comment 2 Conrad Meyer 2013-10-02 10:36:26 EDT
Hey Jerry,

Should we wrap it in some kind of FEDORA_GLPK_ITCNT macro until it is shipped in a release? Might avoid some cross-distro version<->header confusion. I guess the extra symbol is still there, but there's not too much we can do about that.
Comment 3 Conrad Meyer 2013-10-02 10:40:34 EDT
s/macro/#ifdef/
Comment 4 Jerry James 2013-10-22 11:14:03 EDT
Oops, sorry, got busy and let this drop off my radar.  I'm not sure what problem wrapping it in a macro would solve.  Other software won't expect the symbol to exist, so its existence shouldn't pose a problem.  This is strictly a solution to the disappearance of the old API, which is still in widespread use.  And it is a forward-compatible solution, at that.
Comment 5 Conrad Meyer 2013-10-22 11:23:55 EDT
(In reply to Jerry James from comment #4)
> I'm not sure what
> problem wrapping it in a macro would solve.  Other software won't expect the
> symbol to exist, so its existence shouldn't pose a problem.

People writing software against Fedora 19 with GLPK vX will find that their software doesn't compile or link against GPLK vX on other distributions. That seems problematic.
Comment 6 Jerry James 2013-10-22 11:29:56 EDT
Oh, I see.  Sorry for being dense.  Okay, then wrapping it in a macro seems like a good solution.  It will only be necessary until the next glpk release, anyway.
Comment 7 Conrad Meyer 2013-10-22 11:35:52 EDT
(In reply to Jerry James from comment #6)
> Oh, I see.  Sorry for being dense.  Okay, then wrapping it in a macro seems
> like a good solution.  It will only be necessary until the next glpk
> release, anyway.

No worries. I figure the next release will probably happen pretty soon if it hasn't yet.

From comment #0, you just need this in F-20+, correct?
Comment 8 Jerry James 2013-10-22 11:41:12 EDT
(In reply to Conrad Meyer from comment #7)
> No worries. I figure the next release will probably happen pretty soon if it
> hasn't yet.

It hasn't.  I just checked.  If there will be a new release in the next few weeks, I'm fine with waiting for it.  But I don't see any indication on the mailing list of when the next release might happen.

> From comment #0, you just need this in F-20+, correct?

Yes, that is correct.
Comment 9 Conrad Meyer 2013-10-22 11:53:01 EDT
http://pkgs.fedoraproject.org/cgit/glpk.git/commit/?id=6544de7c0423eebfbda93bd9dae00e94057275b2

I got an RPATH issue (pretty sure it's unrelated to this change) building locally, but maybe Koji won't choke on that:
http://koji.fedoraproject.org/koji/taskinfo?taskID=6087337
Comment 10 Conrad Meyer 2013-10-22 11:56:20 EDT
Ah, tracking Rpath issue in bug 953012.
Comment 11 Conrad Meyer 2013-10-22 12:17:22 EDT
Built for F-20, too: http://koji.fedoraproject.org/koji/taskinfo?taskID=6087368
Comment 12 Fedora Update System 2013-10-22 12:25:58 EDT
glpk-4.52.1-2.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/glpk-4.52.1-2.fc20
Comment 13 Fedora Update System 2013-11-10 02:30:24 EST
glpk-4.52.1-2.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.