Re: saving f-spot

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

 



>>>>>>> "AL" == Alex Lancaster writes:

[...]

AL> https://bugzilla.redhat.com/show_bug.cgi?id=442343

AL> 1) there are no binary .DLLs in the package that don't have
AL> associated source, so legally OK

>>>>> "TK" == Toshio Kuratomi  writes:

TK> Yep.  I didn't list f-spot as binary in my message.

I know, I think Jesse thought so when we were discussing it on IRC.

AL> 2) most of the provides listed by Toshio in his original message
AL> appear to part of f-spot itself (like semweb, FlickNet etc) and
AL> *do* have associated source

TK> Uhm.... They do have source, but I don't think they are part of
TK> f-spot. I could be wrong but: semweb:
TK> http://razor.occams.info/code/semweb/ flickrNet:
TK> http://www.codeplex.com/FlickrNet

Yes, in discussion with the Debian maintainer on #f-spot, it does
appear that they do have upstreams, but nothing else in Fedora yet
depends on them.  Ultimately, yes they should be packed separately if
possible.

TK> I googled everything that I specifically wrote into my message and
TK> looked to see if the sources had corresponding filenames or other
TK> indications of matching the library that was found.

AL> 2) of the DLLs that could be potentially provided by other packages
AL> we have:

AL> /usr/lib/f-spot/libgphoto2-sharp.dll (effectively this is upstream
AL> for libgphoto apparently, it could be patched to use system one)

TK> This should be fixed.  Jesse didn't report any problems with it
TK> currently, though.

Yes, again in discussion with the Debian maintainer it appears that
newer f-spot's will include this ability.  It's a little unclear
because the official libgphoto2-sharp apparently pulls from the f-spot
SVN, if I understand the f-spot maintainer correctly.

AL> /usr/lib/f-spot/Mono.Addins* (a patched version of upstream)

TK> This one is the problem child as it's causing issues for other
TK> packages that require mono(Mono.Addins).... rpm is satisfying the
TK> dep with f-spot which doesn't actually work for the packages that
TK> need mono(Mono.Addins).

Yes, this is now done in the latest build on f-spot:

http://koji.fedoraproject.org/koji/buildinfo?buildID=46254

again got a patch thanks to the Debian maintainer (who apparently has
had to go through some of the same hoops as us with f-spot, since the
f-spot maintainer has only recently included the ability to link
against some of the system libs).

AL> /usr/lib/f-spot/Tao.* (there is an upstream apparently, but it's
AL> not yet packaged by Fedora and not installed in gac yet anyway)
AL> /usr/lib/f-spot/gnome-keyring-sharp.dll (there is upstream, not yet
AL> packaged in Fedora, and not yet stable to be in gac apparently)

TK> If this package were undergoing review in its current state it
TK> would not be able to go into the repo until these dependencies
TK> were packaged. Still, by itself, it's not a reason to yank it for
TK> F-9.  It could be a reason to remove them from the start of the
TK> F10 devel cycle, though.

Right, keep it in F-9.  I think everything should be able to be
packaged separately, so I see no reason to remove it from F-10, it
needs some time to allow the other deps to be packaged.  Remember this
is hold over from the pre-Merge days, and has it's own merge review
somewhere, and we're not necessarily yanking those because the merge
reviews aren't finished or have problems.

AL> So the only files that conflicts as far as also being provided by
AL> other packages appears to be Mono.Addins*.dll.  This should
AL> probably be fixed (and Tao and gnome-keyring-sharp packaged) very
AL> soon, but based on this analysis I don't see any need to yank the
AL> package itself from f9-final as it appears to legally OK.

TK> I think Jesse was noting the problem with tomboy and
TK> mono(Mono.Addins) as the reason to yank.  If the choice were to
TK> have a working tomboy and a removed f-spot or vice-versa I'd have
TK> a hard time figuring out which was the more necessary application.
TK> If someone adds the Debian patches for f-spot to fix this by F-9
TK> that will be the best outcome overall.

As I said above, this is done now, so the tomboy/f-spot conflict
shouldn't be a problem anymore.  I have to build mono-addins to fix a
potential problem with addins disappearing from f-spot.  But once
done, they can both be tagged f9-final.

A.

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux