Bug 173301

Summary:	ddskk needs apel 10.6 to build
Product:	[Fedora] Fedora	Reporter:	Jens Petersen <petersen>
Component:	xemacs-sumo	Assignee:	Ville Skyttä <scop>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	extras-qa
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	20051208-1	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-12-23 21:25:57 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jens Petersen 2005-11-16 02:51:51 UTC

Description of problem:
It is not possible current to build ddskk (or wl) in Extras since
the version of apel (10.2) included in  xemacs-sumo  is too old.

How reproducible:
Every time

Comment 1 Ville Skyttä 2005-11-21 18:41:21 UTC

Ok, I've given this a bit of thought, and the two feasible alternative 
solutions I can come up with are:  
  
1) Update the apel contained in xemacs-sumo to 10.6 (or later). 
  
2) Update/patch only bits of apel contained in xemacs-sumo so that it  
works with ddskk and wl, and leave it at 10.2 and as is otherwise.  
  
If the number of packages in xemacs-sumo that depend on apel would be fewer  
than currently, I'd gladly remove it and use an external apel.  But there are 
quite a few packages that depend/build-depend on it, and besides, apel itself 
build-depends on other things in xemacs-sumo -> we have a chicken-egg problem. 
 
In case I'm doing the work, I'm pretty strongly leaning towards option 2) 
above; I guess that would be fairly easily acceptable upstream too.  Your 
thoughts?

Comment 2 Jens Petersen 2005-11-21 23:59:40 UTC

I forgot now why the newer apel was removed from the Fedora xemacs-sumo again...
but naively (1) sounds like less work than (2).  What advantage does (2) have?

But I'm pragmatic about this, as long as wl and ddskk, etc build and work ok with
xemacs-sumo I  mind less how it is done.

Comment 3 Ville Skyttä 2005-11-22 09:19:08 UTC

The version of apel distributed with xemacs-sumo is 10.2 plus some 15 changes  
committed by XEmacs folks after it, and it's possible that it was a patched  
one already when it was synced with upstream 10.2 5+ years ago.  
  
When done properly (ie. not just dumping 10.6 in the tree, ignoring all  
XEmacs-specific patches, but finding out what the changes are, and if they're  
still needed for something in xemacs-sumo or XEmacs in general), I think 1)  
could actually be more work than 2).  1) would be more "future proof", though.  
  
Anyway, I'll try to find time this week to take a look at 1) first.

Comment 4 Ville Skyttä 2005-12-02 10:29:19 UTC

I have submitted a patch upstream that syncs apel in the XEmacs packages tree to
10.6 for review, and unless there are objections, I intend to commit it early
next week.

Then, when that patch is in and a new upstream apel package or updated sumos
including it are available, it will be included in the next xemacs-sumo packages
in FE.

Comment 5 Ville Skyttä 2005-12-10 21:03:57 UTC

New 20051208 sumo including bundled apel 10.6 is now in CVS/devel.

No builds yet, because apel 10.6 triggers a bug in latin-unity for which I
believe an upstream fix will follow soon.  If you have the time, you can build
the new xemacs-sumo from CVS locally already now and test if wl and ddskk build
and work with it.  If you do so, be sure to post experiences here.

Comment 6 Jens Petersen 2005-12-12 05:53:36 UTC

Thanks, Ville: I tested building ddskk with apel-1.32-pkg.tar.gz
in my .xemacs and it seems to be fine - so looks good to me. :)

Comment 7 Ville Skyttä 2005-12-23 21:25:57 UTC

Thanks for testing.  I heard that Santa has just delivered
xemacs-sumo-20051208-1 to Extras FC-4 and devel ;)