[Sebastian Treug] Problems compiling kdebase-4.3 due to trig
Abhinav Chaturvedi
achaturvedi at gmail.com
Fri Nov 6 14:37:38 GMT 2009
Hi Sebastian,
I cannot seem to find which version of libredland and libraptor I have.
But what I can tell you is that I downloaded Soprano-2.3.1 and compiled it
into /usr/local.
It is this Soprano that I then used during kdebase compilation. I was
compiling KDE-4.3.3 on an OpenSuse-11.1 system (which has KDE-4.1.x). For
now, I have managed to compile kdebase by disabling Nepomuk compilation
(BUILD_nepomuk:BOOL=OFF in CMakeCache.txt).
I don't know whether there is any connection between Soprano and Nepomuk.
So, i don't know whether you can infer redland and raptor versions from the
Soprano version number.
But if you could tell me of a way to find the redland and raptor versions,
then I'll hurry the answers back to you.
Thanks for your help
Abhinav.
2009/11/5 <kde-core-devel-request at kde.org>
> Send kde-core-devel mailing list submissions to
> kde-core-devel at kde.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.kde.org/mailman/listinfo/kde-core-devel
> or, via email, send a message with subject or body 'help' to
> kde-core-devel-request at kde.org
>
> You can reach the person managing the list at
> kde-core-devel-owner at kde.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of kde-core-devel digest..."
>
>
> Today's Topics:
>
> 1. Re: Qt KDE integration in kdereview. (Diego Iastrubni)
> 2. Re: Attica moved to kdereview (Frederik Gladhorn)
> 3. Re: device-automounter moved to kdereview (Albert Astals Cid)
> 4. Re: Bugreporting barrier is too low with the new Dr. Konqi
> (Dar?o Andr?s)
> 5. Re: [newbie]: Problems compiling kdebase-4.3 due to trig
> (Sebastian Tr?g)
> 6. Re: Qt KDE integration in kdereview. (Olivier Goffart)
> 7. Re: KDE is not an OS platform... (And neither is Gnome)
> (Alexander Neundorf)
> 8. Re: Qt KDE integration in kdereview. (Alexander Neundorf)
> 9. Re: Rocs moved to kdereview. (Tomaz Canabrava)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 4 Nov 2009 21:07:11 +0200
> From: Diego Iastrubni <elcuco at kde.org>
> Subject: Re: Qt KDE integration in kdereview.
> To: kde-core-devel at kde.org
> Message-ID: <200911042107.11986.elcuco at kde.org>
> Content-Type: Text/Plain; charset="iso-8859-1"
>
> On Tuesday 03 November 2009 21:11:21 David Faure wrote:
> > On Tuesday 03 November 2009, Diego Iastrubni wrote:
> > > On Tuesday 03 November 2009 17:55:51 Olivier Goffart wrote:
> > > > Hello.
> > > >
> > > > I have just submitted a new plugin in kdereview:
> > > > qguiplatformplugin_kde
> > > >
> > > > The objective of this plugin is to allow pure Qt Application (not KDE
> > > > ones) to get better integration into KDE.
> > >
> > > How about integrating KDE widgets directly into pure Qt applications?
> > >
> > > I see that QMainWindow::menuBar(), QMainWindow::statusBar() and
> > > QMainWindow::addToolBar(QString) can be hacked. Maybe that plugin can
> > > provide the menu/statusbar/toolbar "virtual constructors" or
> something.
> >
> > You mean in order to create KMainWindows and KToolBars?
> > What would this provide to the Qt applications?
> making a KMainWindow, from a QMainWindow should be difficult. However, one
> of
> the most missing features for me in QToolBars are the icon/text settings
> and
> the lock toolbars command.
>
> I am just thinking aloud: how hard can this be?
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 04 Nov 2009 20:12:06 +0100
> From: Frederik Gladhorn <gladhorn at kde.org>
> Subject: Re: Attica moved to kdereview
> To: kde-core-devel at kde.org
> Message-ID: <4af1d3da.0f1abc0a.68f4.3f25 at mx.google.com>
> Content-Type: text/plain; charset="ISO-8859-1"
>
> Hola Albert,
> thanks a lot for the review!
> I hope that we addressed your points by now.
>
> Albert Astals Cid wrote:
> > A Dimarts, 3 de novembre de 2009, Frederik Gladhorn va escriure:
> >> Hi all,
> >> after spending some time with libattica, we decided that now is a good
> >> point to get a review for it and eventually have it used in KDE.
> >
> > The licensing is unclear, activity.h is GPL2+ while downloaditem.h is
> > LGPL2+
> Done, we forgot to make it the same everywhere, it's relicensed to LGPL2+
> in
> agreement with all authors now.
>
> > You have one foreach without const & in the "iterator"
> /me hides :D
>
> > Maybe it would make sense to d-pointify Attica:BaseJob::Metadata,
> > Attica::DownloadUrlDescription, Attica::GetJob, Attica::PostJob
> Mostly done, will be finished tomorrow.
>
> > In Attica::DownloadUrlDescription if you put the two bools together your
> > struct will use less memory
> Done.
> > Should downloadUrlDescription(), previewPicture(), license(), author() of
> > Attica::Content be const?
> Done.
> > Should url() in Attica::DownloadItem be const?
> Yes.
> > Any reason to make Attica::DownloadItem use a
> > QExplicitlySharedDataPointer?
> Total nonsense and an oversight by me.
> Seems like I wasn't quite awake when writing that class...
>
> > From the application point of view, it would make sense to me that if for
> > example it makes no sense that the application ever calls
> > Folder::setMessageCount it should be private and called by a friend
> class.
> > But maybe it makes sense calling Folder::setMessageCount and it's ok :D
> Since we support creating items and sending them to the server again, most
> setters make sense. The case you asked about is indeed questionable.
>
> >
> > After a quick look at the API i'm not sure if the Jobs are supposed to be
> > part of the public API or not. Their headers are installed an the classes
> > exported, but
> >
> > GetJob(const QSharedPointer<Internals>& internals, const QNetworkRequest&
> > request);
> > seems a bit weird, what's that QSharedPointer<Internals>?
> >
> Yep, this is supposed to be used only internally. You just get instances of
> these classes back from Attica::Provider. Constructors changed to private
> or
> protected now.
>
> Thanks!
>
> Greetings
> Frederik
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 4 Nov 2009 20:41:56 +0100
> From: Albert Astals Cid <aacid at kde.org>
> Subject: Re: device-automounter moved to kdereview
> To: kde-core-devel at kde.org
> Message-ID: <200911042041.56630.aacid at kde.org>
> Content-Type: Text/Plain; charset="iso-8859-15"
>
> A Dimecres, 4 de novembre de 2009, Trever Fischer va escriure:
> > On Tuesday 03 November 2009 6:18:43 pm Albert Astals Cid wrote:
> > > A Dimarts, 3 de novembre de 2009, Jacopo De Simoi va escriure:
> > > > On Tuesday 03 November 2009 02:15:20 Trever Fischer wrote:
> > > > > On Monday 02 November 2009 6:45:18 pm Jacopo De Simoi wrote:
> > > > > > On Monday 02 November 2009 23:56:14 Jacopo De Simoi wrote:
> > > > > > > > So you /don't / have to use UDIs (unless you're manually
> adding
> > > > > > > > to the list) to use the feature.
> > > > > > >
> > > > > > > I believe we need to get rid of the UDIs and provide some more
> > > > > > > not just user-friendly, but "human-friendly" strings.. Having
> to
> > > > > > > deal with them even in some cases is not really acceptable.
> I'll
> > > > > > > try to have a look into this to see how we can sort this out
> > > > > >
> > > > > > Just quickly playing with the solid minibrowser I have a few
> > > > > > suggestions
> > > > > >
> > > > > > First of all, show whichever icon solids give to the device, it
> > > > > > really really helps to figure out what we are talking about even
> > > > > > before we start reading.
> > > > > >
> > > > > > The volume property info.product is quite uninformative (usually
> > > > > > Volume(ext3)), but if you jump back to the closest relative
> which
> > > > > > has a info.product property you will find quite interesting
> things,
> > > > > > such as ExpressCard, or stuff like that.
> > > > > >
> > > > > > Then I'd compose a string with the following field (with parent I
> > > > > > mean the closest device in the hierarchy which has the infos
> > > > > > required)
> > > > > >
> > > > > > parent.info.vendor parent.info.product volume.info.product (size)
> > > > > > Some real-life examples:
> > > > > >
> > > > > > Seagate FreeAgent Go Backup_HD (160 Go)
> > > > > > ST325082 0A MediaHD (250 Go)
> > > > > > Lexar ExpressCard ssdhome (5 Go)
> > > > > > Lexar ExpressCard ssdroot (3 Go)
> > > > > > SD02G Volume (ext3) (2 Go) (with SD icon)
> > > > > > Kingston FCR-HS219/1 MicroSD (2 Go) (I'm cheating here... MicroSD
> > > > > > is the volume label)
> > > > > >
> > > > > > Still, as you can see there's room for improvement, in particular
> > > > > > the second guy was giving quite debatable information about
> itself
> > > > > > (however still better than
> > > > > > /org/freedesktop/Hal/devices/volume_uuid_ECBF_30CC)
> > > > >
> > > > > Nonetheless a good idea. I added it to the GUI.
> > > >
> > > > Ok, now this looks much better; what about this, now, to make it look
> > > > even better;
> > > >
> > > > If (and only if) there exists more than one volume with the same
> > > > parent, group them with the parent; then the parent will be shown
> with
> > > > vendor() and product() and total size (should be available with
> > > > storage.removable.media_size) and then each child (partition) would
> > > > just show description() and size This is visually better since it
> > > > removes redundant information for partitions of the same drive. and
> > > > makes it easier to browse.
> > > >
> > > > On the other hand, if a volume is an only child, then don't add
> another
> > > > node and use the long description we talked about yesterday.
> > > >
> > > > Also, imho the informations should be refreshed even if it's already
> > > > present in the .rc file whenever possible; besides; who is
> responsible
> > > > to fill in the devices in the .rc file? the daemon I suppose; would
> it
> > > > be possible to save the pretty name we have found for our device at
> the
> > > > daemon level? so that whenever you connect the drive, the user would
> > > > find it with its pretty name in the disconnected devices node as
> well.
> > > > Having it set up at the daemon level could make the kcm part merely
> > > > read it from the .rc since it will be automagically updated.
> > > >
> > > > Moreover, I believe that the Add device button is useless; nobody
> would
> > > > really enter the udi of a device.
> > >
> > > I agree here, and the forget device is not of much use either
> >
> > The reason I put it in was I figured there needs to be some way to undo
> the
> > otherwise permanent memorization of "automount this device because it has
> > been mounted before".
> >
> > > > Nice job!
> > > > @Albert, what do you think about the ui fixes?
> > >
> > > The list let's you do multiple selection, i don't think that makes much
> > > sense. Also i tried to change Automount on login and Automount on
> attach
> > > from No to Yes on my pendrive but wasn't able to do it.
> >
> > Multiple selection lets you forget more than one device at a time. Also,
> > those two fields only change when the device list is rebuilt. I'm
> thinking
> > I should build a model specifically for the KCM so that the updating of
> > this is done when the checkboxes are toggled, and it'd be a lot cleaner
> > than just a qstandardmodel.
>
> Ok, makes sense, thanks for the clarification.
>
> Albert
>
> >
> > > Albert
> >
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 4 Nov 2009 17:14:03 -0300
> From: Dar?o Andr?s <andresbajotierra at gmail.com>
> Subject: Re: Bugreporting barrier is too low with the new Dr. Konqi
> To: KDE-Devel <kde-core-devel at kde.org>
> Message-ID:
> <a2c126ef0911041214n5613e97cv2ff945f1994cb28f at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Ok, I have currently implemented some features in order to improve the
> situation:
>
> - The duplicate list that DrKonqi provides should be smarter and a bit
> smaller (as it uses a stricter query to bugzilla)
> - The duplicate list now includes the bug status in a tag, with
> no-jargon (ex ."[Open]", "[Fixed]", "[Already Reported]", "[Invalid]")
> - When you want to open a possible duplicate report, if that report
> "X" is already marked as duplicate of another report "Z", you can
> choose to show the report you wanted to open ("X") or the main report
> ("Z") <- Resolving nested duplicate levels
>
> Other fixes that I have coded but I haven't commited yet:
>
> - If there are possible duplicates listed and the user didn't selected
> anyone, nor marked anyone to attach the new information to it, a
> messagebox will appear asking if he is sure.
>
> - In the description step, if the user haven't entered a proper amount
> of input, the user is *forced* to do so (we need to discuss the amount
> of characters to be considered good input) (the user already selected
> the checkbox "I can provide information about the crash"). If the user
> doesn't accept this, the dialog is closed (but a warning about the
> dialog being closed appears, if the user changes his/her mind...)
>
> In both messages I'm explicitly saying that not following this advices
> will *waste* the time of the KDE developers and triagers, so at least
> they can think a bit before sending pseudo-crap. (yes, the text needs
> to be improved, may be it is too harsh...)
>
> Screenshots of earlier implementation of this features:
>
> http://imagebin.ca/view/XY3uu1W.html
> http://imagebin.ca/view/i2-0cQ.html
> http://imagebin.ca/view/0jSX7VP.html
>
> I would like to get some feedback about all this things
>
> Thanks in advance.
> Regards
>
> Dar?o A.
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 4 Nov 2009 21:32:09 +0100
> From: Sebastian Tr?g <trueg at kde.org>
> Subject: Re: [newbie]: Problems compiling kdebase-4.3 due to trig
> To: kde-core-devel at kde.org
> Message-ID: <200911042132.09880.trueg at kde.org>
> Content-Type: Text/Plain; charset="iso-8859-15"
>
> which version of libredland and libraptor do you have installed?
>
> On Tuesday 03 November 2009 22:58:14 Abhinav Chaturvedi wrote:
> > Hi all,
> >
> > I am having problems compiling kdebase (of KDE-4.3 branch) and its seems
> to
> > because of nepomuk.
> > i downloaded soprano-2.3.1 from sourceforge.net, compiled it and
> installed
> > it in /usr/local.
> > Hence, when I do cmakekde in kdebase, I get the following message:
> >
> >
> > Found Soprano Plugin Dir: /usr/local/share/soprano/
> > plugins/soprano/plugins
> > -- Found Soprano Plugins: nquadparser nquadserializer raptorparser
> > raptorserializer redlandbackend sesame2backend
> >
> > There is no 'trig'. I am assuming there should be a parser for it like
> > there are for raptor, redland etc.
> > And that this parser should have been included in Soprano-2.3.1. But
> > apparently it is not. Which is why
> > I get the following message when compiling kdebase.
> >
> > [ 10%] Generating nie.h,
> > nie.cpp
> >
> > Could not find parser plugin for encoding
> > trig
> >
> > make[2]: *** [runtime/nepomuk/strigibackend/nie.h] Error
> > 1
> > make[1]: ***
> > [runtime/nepomuk/strigibackend/CMakeFiles/sopranobackend.dir/all] Error
> > 2
> > make[1]: *** Waiting for unfinished
> > jobs....
> >
> > Linking CXX executable
> > knotify4
> >
> > [ 10%] Built target
> > knotify
> >
> > make: *** [all] Error 2
> >
> >
> > I was wondering if you have seen this problem before. I must tell you
> that
> > I did *not* checkout anything other
> > than kdepimlibs, kdebase, kdelibs and phonon. These were enough when I
> > tried compiling KDE-4.3 some
> > months back.
> >
> > Is there anyway in which I can bypass 'nepomuk' compilation altogether?
> > If not, then how can I solve the above problem? Do I need to checkout
> some
> > other KDE packages?
> >
> > Thanks for your help
> > Abhinav.
> >
>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 4 Nov 2009 22:33:21 +0200
> From: Olivier Goffart <ogoffart at kde.org>
> Subject: Re: Qt KDE integration in kdereview.
> To: kde-core-devel at kde.org
> Message-ID: <200911042133.21442.ogoffart at kde.org>
> Content-Type: Text/Plain; charset="iso-8859-1"
>
> Le Wednesday 04 November 2009, Diego Iastrubni a ?crit :
>
> > making a KMainWindow, from a QMainWindow should be difficult. However,
> one
> > of the most missing features for me in QToolBars are the icon/text
> > settings and the lock toolbars command.
> >
> > I am just thinking aloud: how hard can this be?
>
> Regarding the icon/text settings in a QToolBar:
> - The default icon size is read from the KDE config for the default KDE
> icon
> size in toolba
> - The default text position is read from the KDE config if using
> Qt::ToolButtonFollowStyle as QToolBar::toolButtonStyle (new in 4.6, we
> could
> not make it the default because it was a too huge behaviour change)
>
> There is currently no plan to support being able to edit QToolBar as KDE
> does.
>
>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 4 Nov 2009 21:53:25 +0100
> From: Alexander Neundorf <neundorf at kde.org>
> Subject: Re: KDE is not an OS platform... (And neither is Gnome)
> To: kde-core-devel at kde.org
> Message-ID: <200911042153.25201.neundorf at kde.org>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Wednesday 04 November 2009, David Faure wrote:
> > On Wednesday 04 November 2009, nf2 wrote:
> > > * But Qt-only apps?
> > >
> > > And i do believe Qt is quite important for getting more apps written
> > > for the FOSS desktop. As its portability is very attractive.
> >
> > OK, that's a good point. However QFile/QDir is not the answer IMHO.
> > Qt has a nice API for async networking requests already:
> > QNetworkAccessManager (for which we have a KIO backend; the qt-kde
> platform
> > plugin (cf the thread from Olivier) could even use that when kdelibs is
> > around).
> > But for file dialogs, it misses directory listing, and stat, at least.
>
> I think QAbstractFileEngine comes quite close, you can use to to plug
> in "virtual" filesystems based on URLs into Qt apps, including the file
> dialog.
>
> Alex
>
>
> ------------------------------
>
> Message: 8
> Date: Wed, 4 Nov 2009 21:59:54 +0100
> From: Alexander Neundorf <neundorf at kde.org>
> Subject: Re: Qt KDE integration in kdereview.
> To: kde-core-devel at kde.org
> Message-ID: <200911042159.54853.neundorf at kde.org>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Wednesday 04 November 2009, David Faure wrote:
> > On Wednesday 04 November 2009, George Kiagiadakis wrote:
> > > On Wed, Nov 4, 2009 at 3:19 AM, David Faure <faure at kde.org> wrote:
> > > > On Wednesday 04 November 2009, Michael Pyne wrote:
> > > >> On Tuesday 03 November 2009 17:10:19 Kevin Krammer wrote:
> > > >> > Maybe startkde could set KDEHOME to localprefix if it is not set
> > > >> > yet?
> > > >>
> > > >> That wouldn't be a bad idea either, it's easier just to always have
> > > >> KDEHOME set than special-casing it.
> > > >
> > > > Yep, excellent idea.
> > >
> > > No, bad idea. If you are using both kde3 and kde4 apps and you want
> > > them to use different KDEHOMEs, setting KDEHOME in startkde is just
> > > going to force them both to use the same KDEHOME, which is not what we
> > > want.
> >
> > True.
> > And I just realized that it wouldn't help making sure KDEHOME is always
> > set, since one can also run kde apps outside of a kde workspace (-> no
> > startkde run).
> >
> > > That's why the KDE4_DEFAULT_HOME cmake variable exists.
> >
> > Yeah but that's not introspectable.
> > Hmm, actually, it is: `kde4-config --localprefix`, but calling a process
> > probably too slow for doing from Qt?
>
> Hmm, if it's done once on application startup it might be acceptable.
>
> It's also saved in share/apps/cmake/modules/KDELibsDependencies.cmake, in
> the
> KDE_DEFAULT_HOME variable.
> You can basically rely on the format of that line:
> set(KDE_DEFAULT_HOME ".kde")
> So without really parsing it just matching a regexp should do.
>
> Alex
>
>
> ------------------------------
>
> Message: 9
> Date: Wed, 4 Nov 2009 20:48:04 -0200
> From: Tomaz Canabrava <tumaix at gmail.com>
> Subject: Re: Rocs moved to kdereview.
> To: kde-core-devel at kde.org
> Message-ID:
> <7ebbb4b50911041448g42da8498gf938ec5aae8436f8 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Ok, I'v managed to fix 2 crashes, workarounding a well known
> qt-problem on trees & graphicsview.
> it shoudn't crash no more.
>
> and improved the showing of the properties of the nodes and edges.
>
> tomorrow I will do nothing ( beach time ), but I plan to have
> everything that anyone say here fixed by next sunday.
>
>
> ------------------------------
>
> _______________________________________________
> kde-core-devel mailing list
> kde-core-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-core-devel
>
>
> End of kde-core-devel Digest, Vol 80, Issue 27
> **********************************************
>
--
It's the peoples' will, I am their leader, I must follow them. (Jim Hacker
in Yes Minister)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20091106/997268b9/attachment.htm>
More information about the kde-core-devel
mailing list