[Sebastian Treug] Problems compiling kdebase-4.3 due to trig
Sebastian Trueg
trueg at kde.org
Mon Nov 9 18:57:12 GMT 2009
Abhinav Chaturvedi wrote:
> 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.
redland-config --version
should help here.
> 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).
Could you get the cmake output from your own Soprano compilation to me?
> 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.
Nepomuk is based on Soprano.
> 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
> <mailto:kde-core-devel-request at kde.org>>
>
> Send kde-core-devel mailing list submissions to
> kde-core-devel at kde.org <mailto: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
> <mailto:kde-core-devel-request at kde.org>
>
> You can reach the person managing the list at
> kde-core-devel-owner at kde.org
> <mailto: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 <mailto:elcuco at kde.org>>
> Subject: Re: Qt KDE integration in kdereview.
> To: kde-core-devel at kde.org <mailto:kde-core-devel at kde.org>
> Message-ID: <200911042107.11986.elcuco at kde.org
> <mailto: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 <mailto:gladhorn at kde.org>>
> Subject: Re: Attica moved to kdereview
> To: kde-core-devel at kde.org <mailto:kde-core-devel at kde.org>
> Message-ID: <4af1d3da.0f1abc0a.68f4.3f25 at mx.google.com
> <mailto: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 <mailto:aacid at kde.org>>
> Subject: Re: device-automounter moved to kdereview
> To: kde-core-devel at kde.org <mailto:kde-core-devel at kde.org>
> Message-ID: <200911042041.56630.aacid at kde.org
> <mailto: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
> <mailto: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 <mailto:kde-core-devel at kde.org>>
> Message-ID:
> <a2c126ef0911041214n5613e97cv2ff945f1994cb28f at mail.gmail.com
> <mailto: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 <mailto:trueg at kde.org>>
> Subject: Re: [newbie]: Problems compiling kdebase-4.3 due to trig
> To: kde-core-devel at kde.org <mailto:kde-core-devel at kde.org>
> Message-ID: <200911042132.09880.trueg at kde.org
> <mailto: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
> <http://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 <mailto:ogoffart at kde.org>>
> Subject: Re: Qt KDE integration in kdereview.
> To: kde-core-devel at kde.org <mailto:kde-core-devel at kde.org>
> Message-ID: <200911042133.21442.ogoffart at kde.org
> <mailto: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 <mailto:neundorf at kde.org>>
> Subject: Re: KDE is not an OS platform... (And neither is Gnome)
> To: kde-core-devel at kde.org <mailto:kde-core-devel at kde.org>
> Message-ID: <200911042153.25201.neundorf at kde.org
> <mailto: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 <mailto:neundorf at kde.org>>
> Subject: Re: Qt KDE integration in kdereview.
> To: kde-core-devel at kde.org <mailto:kde-core-devel at kde.org>
> Message-ID: <200911042159.54853.neundorf at kde.org
> <mailto: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
> <mailto: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 <mailto:tumaix at gmail.com>>
> Subject: Re: Rocs moved to kdereview.
> To: kde-core-devel at kde.org <mailto:kde-core-devel at kde.org>
> Message-ID:
> <7ebbb4b50911041448g42da8498gf938ec5aae8436f8 at mail.gmail.com
> <mailto: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 <mailto: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)
More information about the kde-core-devel
mailing list