On Sun, 2004-12-12 at 14:05 +0000, Jonathan Leighton [Turnip] wrote:

Looks like we've come to a dead end on this one :( I there anything that I can do? Any more info I can give?

I built a new RPM according to the Fedora packaging guidelines, but it has the same problem.

I think I have an idea. I had what I believe is the same problem; however, then I realized that i had the gtkmm stack built for Fedora Core 2 installed. Now, GCC as bumped from version 3.3 to 3.4 switching from FC2 to FC3, and with this transition the C++ ABI changed, and there's a new libstdc++ version. After recompiling the entire gtkmm stack (the necessary SRPMs are libsigc++20, glibmm24 and gtkmm24) and gc (I'm not sure if that was necessary) I can run my freshly built CVS Inkscape just fine.

I've uploaded my rebuilt RPMs (just did 'rpmbuild --clean --rebuild <blah>.src.rpm' on my FC3 system) to http://www.stanford.edu/~perbj/Fedora/inkscape-deps/ You need the basic and -devel rpms, the -debuginfo rpms give you the symbol table for debugging.

For the benefit of the list archives: This is _not_ a canonical location, I may need to take it down in a couple of weeks or so. Hopefully the real Fedora Extras for FC3 will be up soon so official versions can be had from there.

By the way, since I didn't do anything at all to the SRPMs, the resulting RPMs have the exact same version as the latest Fedora.us RPMs, so you might need to use 'rpm -Uvh --replacepkgs' to install them.

If you want to rebuild from the SRPM instead, get it from the fedora.us download areas or a mirror.

Alternatively, perhaps I could take a peek at your SRPM and see if it builds and runs for me with my dependency packages? I only saw a link to the binary RPM, I'd need the SRPM to rebuild and test it, and a rebuild might be needed to get this right.

Cheers, Per

I've signed and uploaded my RPMs. They're all now in http://turnipspatch.com/misc/rpm/, with a GPG key too. If anyone can test them out I'd be extremely grateful, be aware that if you're going to try to rebuild the SRPM then you'll need to install Per's rebuilt gtkmm packages (http://www.stanford.edu/~perbj/Fedora/inkscape-deps/) first otherwise it will crash on startup.

I've sent a self introduction to the Fedora.us development list, so hopefully I'll be able to get the packages in QA soon.

Cheers Jonathan

Jonathan Leighton [Turnip] wrote:

Per Bjornsson, I officially declare you a genious! I would never have realised that...

I now have a working build, so I'll try to get it approved at fedora.us and then send it to Bryce for the SourceForge downloads page. FYI I took down that RPM I linked to previously, as it's old now anyway. If anyone wants to test the new (S)RPM out, I'll upload it. Just let me know.

Thanks a lot! :) Jonathan

Per Bjornsson wrote:

...

On Sun, 2004-12-12 at 14:05 +0000, Jonathan Leighton [Turnip] wrote:

...

Looks like we've come to a dead end on this one :( I there anything that I can do? Any more info I can give?

I built a new RPM according to the Fedora packaging guidelines, but it has the same problem.

I think I have an idea. I had what I believe is the same problem; however, then I realized that i had the gtkmm stack built for Fedora Core 2 installed. Now, GCC as bumped from version 3.3 to 3.4 switching from FC2 to FC3, and with this transition the C++ ABI changed, and there's a new libstdc++ version. After recompiling the entire gtkmm stack (the necessary SRPMs are libsigc++20, glibmm24 and gtkmm24) and gc (I'm not sure if that was necessary) I can run my freshly built CVS Inkscape just fine.

I've uploaded my rebuilt RPMs (just did 'rpmbuild --clean --rebuild <blah>.src.rpm' on my FC3 system) to http://www.stanford.edu/~perbj/Fedora/inkscape-deps/ You need the basic and -devel rpms, the -debuginfo rpms give you the symbol table for debugging.

For the benefit of the list archives: This is _not_ a canonical location, I may need to take it down in a couple of weeks or so. Hopefully the real Fedora Extras for FC3 will be up soon so official versions can be had from there.

By the way, since I didn't do anything at all to the SRPMs, the resulting RPMs have the exact same version as the latest Fedora.us RPMs, so you might need to use 'rpm -Uvh --replacepkgs' to install them.

If you want to rebuild from the SRPM instead, get it from the fedora.us download areas or a mirror.

Alternatively, perhaps I could take a peek at your SRPM and see if it builds and runs for me with my dependency packages? I only saw a link to the binary RPM, I'd need the SRPM to rebuild and test it, and a rebuild might be needed to get this right.

Cheers, Per

On Tue, 2004-12-14 at 00:15 -0600, Derek P. Moore wrote:

With the standard FreshRPMs, NewRPMs, Dag RPMs, and Dries RPMs in your repository list, it's as simple as:

yum install libgc libgc-devel glibmm glibmm-devel gtkmm24 gtkmm24-devel \ libsigc++2 libsigc++2-devel

or shorter: yum install gtkmm24-devel libgc-devel

The rest are pulled in by dependency resolution. (argh, annoying that there are packages with different names providing GC...)

Especially if you're in the world of Fedora Core 3, you should ditch fedora.us and livna.org in favor of FreshRPMs/NewRPMs/Dag/Dries combo.

Currently Red Hat has really screwed up the Fedora.us->official Extras transition, I agree with that much. However, the Fedora.us packages have the nice property that they actually see some QA before getting published. Personally I see that as a good thing. The wrong typo/thinko in a spec file really can do some pretty serious damage to your system, and with the one-person repos I don't know who checks the packages at all. To me it sounds like a good idea that someone other than the packager gives the package a once-over before spreading it worldwide...

By the way, livna.org has an FC3 rebuild. It depends on the FC2 Fedora.us packages though. Basically, apart from some C++ libraries this mostly works.

...

I've sent a self introduction to the Fedora.us development list, so hopefully I'll be able to get the packages in QA soon.

You're wasting your time. *smile*

Heh. Long term, the Red Hat hosted Extras should definitely be the canonical add-on for Fedora Core, and the stuff going in there to begin with is what's in Fedora.us now. Going with th others at the moment may work just fine, but might put you in a hole later; likely one that you can dig yourself out of if you know what you're doing, I admit. I at least wanted the option to stick with the Fedora packages.

/Per

On Tue, 14 Dec 2004 turnip@...583... wrote:

Okay, well as the Fedora.us people have assured us that there *is* an Inkscape 0.40 FC3 package, there's not much point in me doing any more work on this.

Bryce, if you'd like to use my package (http://turnipspatch.com/misc/rpm/) for the SourceForge downloads page until an official Fedora one is available, feel free.

Thanks, posted.

Bryce

OK, hang on for a second... What packages does this RPM need to work? I presume it's built against the rebuilt GTKmm stack? Since those RPMs aren't available in public anywhere (well, except my download page, which I specifically don't want to make into a yum repo since it's not really supposed to be there...) I'm not so sure that providing this binary is really a good idea; the sane option in that case would be to provide the whole rebuilt stack (gtkmm, glibmm, libsigc++) until the FC3 Extras downloads are available.

Or point to the publicly available (and apt/yum compatible) stack of gtkmm24, glibmm, and libsigc++2 at NewRPMs and libgc at Dag RPMs. NewRPMs/Dag is really the only public place to get these packages at the moment (unless you're a Mandrake or PLD user).

People should have no problems building the source RPM on the Inkscape site, provided they've installed the stack with devel packages from NewRPMs/Dag. Theoretically, if users have the NewRPMs/Dag libraries installed, Turnip's Inkscape RPM should in fact work without problems. (I can confirm this later in the day.)

Until Fedora Extras goes live, NewRPMs/Dag is the only place to get these packages (and have any sort of quality assurance).

Btw, in Mandrake Cooker, the RPMs are named the same as in NewRPMs/Dag. And we should be able to reasonably expect they'll have the same names as Cooker/NewRPMs/Dag once Fedora Extras goes live, so there shouldn't be any conflicts in the future. (In PLD, libgc is called simply gc, but all the other package names are the same in PLD.)

Currently Red Hat has really screwed up the Fedora.us->official Extras transition, I agree with that much. However, the Fedora.us packages have the nice property that they actually see some QA before getting published. Personally I see that as a good thing. The wrong typo/thinko in a spec file really can do some pretty serious damage to your system, and with the one-person repos I don't know who checks the packages at all. To me it sounds like a good idea that someone other than the packager gives the package a once-over before spreading it worldwide...

Fedora.us is mostly a one man project as well, that one man is Warren Togami. And rpm.livna.org is even more of a one man project than Fedora.us. In open source, most things are one person projects.

And with Fedora.us, where you have people who have never packaged an RPM before submitting SPEC files to the QA queue... Well, in those sorts of circumstances, you *really do* need some sort of QA.

But with, say, FreshRPMs.net, where Matthias has been building RPMs quite literally for years... Why, he really just doesn't need as much QA. The Quality Assurance in inherent in the fact that Matthias is a damn fine packager with plenty of experience.

Besides, it'd be very easy to argue that FreshRPMs.net has a /much/ larger user community than, say, rpm.livna.org. If Matthias makes a mistake in one of his packages, you can be sure his users will let them know right away, you can also be sure he'll fix it right away.

And that's to say nothing of the fact that the individuals of the major non-Fedora.us repos do indeed cooperate and coordinate their build efforts, spec files, and source tarballs with one another under the banner of RPMForge.net. (Nothing yet at that domain other than their email addresses, but you can expect the major repos to merge under that domain sometime in the future.)

...

...

I've sent a self introduction to the Fedora.us development list, so hopefully I'll be able to get the packages in QA soon.

You're wasting your time. *smile*

I was only joking here, of course. I never actually mean to disuade valient efforts.

Going with th others at the moment may work just fine, but might put you in a hole later; likely one that you can dig yourself out of if you know what you're doing, I admit. I at least wanted the option to stick with the Fedora packages.

I've been mixing fedora.us, rpm.livna.org, FreshRPMs, Dag, Dries, NewRPMs, and PlanetCCRMA for quite a long time now. I've never run into a serious problem. As a matter of fact, I've found that FreshRPMs/Dag/Dries/NewRPMs has often had newer versions sooner and higher quality packages than their corresponding duplicates in Extras/Livna (xine, mplayer, totem, and DVD stuffs come to mind here).

There are, of course, things in Extras/Livna that aren't in the other repos. I don't want to be downgrading the usefulness of Extras/Livna, they certainly belong in your repository configuration.

But I attribute repo mixing phobia to pure FUD, spread mostly by the Fedora.us folks.

You really should run into *very few* problems using all the high quality repositories available to the RPM user community. And if you do run into problems, there's nothing easier than 'rpm -e package'. :)