[Bug 693798] Review Request: octave-image - Image processing for Octave

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=693798

Josà Matos <jamatos@xxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|nobody@xxxxxxxxxxxxxxxxx    |jamatos@xxxxxxxx

--- Comment #3 from Josà Matos <jamatos@xxxxxxxx> 2011-04-08 13:05:40 EDT ---
(In reply to comment #2)
> >  Provides: octave(api) = api-v47+}
> 
> Ah, typo in the macros.  Will get a new octave package out asap. 
> Interestingly, rpm/yum appears to ignore the }..  I could install via yum just
> fine.

As soon as you have a build in koji I will tests it.

> >  Requires: (strange, are this used?)
> >  __bilateral__.oct()(64bit)  
> >  __bwdist.oct()(64bit)  
> >  bwfill.oct()(64bit)  
> >  bwlabel.oct()(64bit)  
> >  __custom_gaussian_smoothing__.oct()(64bit)  
> >  deriche.oct()(64bit)  
> >  graycomatrix.oct()(64bit)  
> >  hough_line.oct()(64bit)  
> >  __imboundary__.oct()(64bit)  
> >  nonmax_supress.oct()(64bit)  
> >  rotate_scale.oct()(64bit)  
> >  __spatial_filtering__.oct()(64bit)  
> 
> Well, these are the octave interfaces that are installed.  I think we can leave
> them.  They already have their own namespace of a sort (.oct).

My question is how can we use this automatically. A notation such as
octave(rotate_scale)

seems easier to remember than
rotate_scale.oct()

In any case I agree that this is an improvement that can be accomplished later.

So not an issue for now.

> > Regarding the rpmlint warnings:
> > 
> > Is the obsolete really necessary? (It is a genuine question and I accept your
> > answer). It just seems strange to see this for a package that has almost two
> > years.
> 
> yes, to provide an upgrade path from octave-forge in F14.

OK.

> > What should we do with the final provides? Probably we need to rework the
> > provides filter for octave packages. What do you think?
> 
> I think it is fine as is.  May actually help with octave package dependencies. 
> Filtering leads to other rpm issues too.

I agree my point as described later is for us to be able to use an automatic
octave filter such that as soon as you have an octave script rpms gets the
right octave module to depend on. Clearly a nice to have but not a requirement
now by any account. :-)

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
_______________________________________________
package-review mailing list
package-review@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/package-review



[Index of Archives]     [Fedora Legacy]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]