FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.

» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

LinkBack Thread Tools
Old 04-15-2008, 11:38 AM
Jesse Keating
Default saving f-spot

On Tue, 2008-04-15 at 04:04 -0700, Alex Lancaster wrote:
> So what exactly was the issue that triggered it? Was tomboy
> attempting to use the version that f-spot provides as opposed to the
> system mono-addins? (and installing f-spot because it won the
> shortest package name contest in yum-land?)

In my particular case I had both f-spot and tomboy installed from the F8
period. There were updates available for tomboy, to use the new system
libraries. All the auto require said was "mono(Mono.Addins) ="
My currently installed f-spot has an autoprovides of "mono(Mono.Addins)
=", so yum considered that dep closed, and saw no need to pull
in the new mono-addins package. Then when tomboy tried to launch, it
failed because it couldn't load the Mono.Addins. I had to manually
install mono-addins to resolve the issue.

Jesse Keating
Fedora -- All my bits are free, are yours?
fedora-devel-list mailing list
Old 04-16-2008, 01:33 AM
Alex Lancaster
Default saving f-spot

>>>>>>> "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

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:


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.


fedora-devel-list mailing list

Thread Tools

All times are GMT. The time now is 11:32 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org