Red Hat Bugzilla – Full Text Bug Listing
|Product:||[Fedora] Fedora||Reporter:||Sebastian Dziallas <sebastian>|
|Component:||Package Review||Assignee:||Nobody's working on this, feel free to take it <nobody>|
|Status:||CLOSED NOTABUG||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||fedora-package-review, mario.blaettermann, notting|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-09-12 15:11:48 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
|Bug Blocks:||201449, 674115|
Description Sebastian Dziallas 2011-01-31 12:19:15 EST
Spec URL: http://sdz.fedorapeople.org/rpmbuild/rhino-appjet.spec SRPM URL: http://sdz.fedorapeople.org/rpmbuild/rhino-appjet-1.7-0.1.R1.fc14.src.rpm Description: Package is required for Etherpad!
Comment 1 Alexander Kurtakov 2011-02-01 03:28:21 EST
I propose contacting rhino maintainer(me) and working together to get this both upstream and in our package. Having same source with one additional patch as additional package is not the way we are supposed to work. This means that you will have to update your patch for 1.7R2 of course.
Comment 2 Alexander Kurtakov 2011-02-01 03:30:58 EST
Actually I'll take this one to be sure that we will work it out.
Comment 3 Alexander Kurtakov 2011-03-28 12:12:25 EDT
Any progress ? If not I'll close this review in 2 weeks.
Comment 4 Sebastian Dziallas 2011-04-09 13:46:39 EDT
I'm trying to figure out how to proceed here. Appjet is its own framework and I'm leaning to argue that it needs its own package. It was part of the initial etherpad package and I'm not sure whether the patch (or porting it) will affect other rhino apps. Can you maybe have a look at the patch?
Comment 5 Alexander Kurtakov 2011-04-11 09:17:38 EDT
Well, if you give me some unresolvable reasons why appjet requires its own framework you might convince me. But I don't see any reason to not move to latest rhino even if the patches are unavoidable.
Comment 6 Sebastian Dziallas 2011-04-17 22:52:03 EDT
Well, so the thing is that yuicompressor breaks significantly if anything other than rhino 1.7 R1 is being used. And appjet apparently needs it's own versions of rhino and yuicompressor, which is why this looks like a butchered version of a rhino 1.7 R1 compat package. Now I just found  which might be a way around all this but didn't exist at the time when I filed the review. I'm not sure whether this would work with the appjet changes, though.  https://github.com/tml/yuicompressor-js170
Comment 7 Mat Booth 2011-04-25 07:24:11 EDT
(In reply to comment #6) >  https://github.com/tml/yuicompressor-js170 This link 404s for me.
Comment 8 Sebastian Dziallas 2011-04-25 12:49:04 EDT
That is very true. Sorry. The developer apparently changed the repository name. Here it is now: https://github.com/tml/yuicompressor Mat, do you think this might be useful?
Comment 9 Sebastian Dziallas 2011-07-11 17:41:37 EDT
(In reply to comment #5) > Well, if you give me some unresolvable reasons why appjet requires its own > framework you might convince me. But I don't see any reason to not move to > latest rhino even if the patches are unavoidable. Sorry for taking so long to get back to this. So, let me try pitching it this way: Etherpad's Appjet requires both a modified version of yuicompressor (and hence rhino). I'm not comfortable arguing that these patches won't affect anybody else using rhino -- simply because I don't know. I have tried compiling etherpad against upstream versions of rhino and yuicompressor, but it throws errors during the compilation. I feel that it'd be fair to argue that in this case patched compat packages for both rhino and yuicompressor could be doable. Did I convice you? :)
Comment 10 Sebastian Dziallas 2011-07-11 17:48:13 EDT
(In reply to comment #9) > (In reply to comment #5) > > Well, if you give me some unresolvable reasons why appjet requires its own > > framework you might convince me. But I don't see any reason to not move to > > latest rhino even if the patches are unavoidable. > > Sorry for taking so long to get back to this. So, let me try pitching it this > way: > > Etherpad's Appjet requires both a modified version of yuicompressor (and hence > rhino). I'm not comfortable arguing that these patches won't affect anybody > else using rhino -- simply because I don't know. I have tried compiling > etherpad against upstream versions of rhino and yuicompressor, but it throws > errors during the compilation. > > I feel that it'd be fair to argue that in this case patched compat packages for > both rhino and yuicompressor could be doable. > > Did I convice you? :) And before I forget, upstream has been notified awhile ago, so there'd be tracking of the situation: https://github.com/ether/pad/issues/173
Comment 11 Alexander Kurtakov 2011-11-01 12:19:20 EDT
I give up on this one - I see no hope for proper resolution of the issue.