|
»
Re: [Sebastian Treug] Problems compiling kdebase-4.3 due to trig
|
View:
New views
2 Messages
—
Rating Filter:
Alert me
|
 |
Re: [Sebastian Treug] Problems compiling kdebase-4.3 due to trig
by abhinavc
::
Rate this Message:
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@...> Send kde-core-devel mailing list submissions to -- It's the peoples' will, I am their leader, I must follow them. (Jim Hacker in Yes Minister) |
|
|
Re: [Sebastian Treug] Problems compiling kdebase-4.3 due to trig
by Sebastian Trueg
::
Rate this Message:
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@... > <mailto:kde-core-devel-request@...>> > > Send kde-core-devel mailing list submissions to > kde-core-devel@... <mailto:kde-core-devel@...> > > 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@... > <mailto:kde-core-devel-request@...> > > You can reach the person managing the list at > kde-core-devel-owner@... > <mailto:kde-core-devel-owner@...> > > 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@... <mailto:elcuco@...>> > Subject: Re: Qt KDE integration in kdereview. > To: kde-core-devel@... <mailto:kde-core-devel@...> > Message-ID: <200911042107.11986.elcuco@... > <mailto:200911042107.11986.elcuco@...>> > 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@... <mailto:gladhorn@...>> > Subject: Re: Attica moved to kdereview > To: kde-core-devel@... <mailto:kde-core-devel@...> > Message-ID: <4af1d3da.0f1abc0a.68f4.3f25@... > <mailto:4af1d3da.0f1abc0a.68f4.3f25@...>> > 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@... <mailto:aacid@...>> > Subject: Re: device-automounter moved to kdereview > To: kde-core-devel@... <mailto:kde-core-devel@...> > Message-ID: <200911042041.56630.aacid@... > <mailto:200911042041.56630.aacid@...>> > 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@... > <mailto:andresbajotierra@...>> > Subject: Re: Bugreporting barrier is too low with the new Dr. Konqi > To: KDE-Devel <kde-core-devel@... <mailto:kde-core-devel@...>> > Message-ID: > <a2c126ef0911041214n5613e97cv2ff945f1994cb28f@... > <mailto:a2c126ef0911041214n5613e97cv2ff945f1994cb28f@...>> > 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@... <mailto:trueg@...>> > Subject: Re: [newbie]: Problems compiling kdebase-4.3 due to trig > To: kde-core-devel@... <mailto:kde-core-devel@...> > Message-ID: <200911042132.09880.trueg@... > <mailto:200911042132.09880.trueg@...>> > 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@... <mailto:ogoffart@...>> > Subject: Re: Qt KDE integration in kdereview. > To: kde-core-devel@... <mailto:kde-core-devel@...> > Message-ID: <200911042133.21442.ogoffart@... > <mailto:200911042133.21442.ogoffart@...>> > 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@... <mailto:neundorf@...>> > Subject: Re: KDE is not an OS platform... (And neither is Gnome) > To: kde-core-devel@... <mailto:kde-core-devel@...> > Message-ID: <200911042153.25201.neundorf@... > <mailto:200911042153.25201.neundorf@...>> > 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@... <mailto:neundorf@...>> > Subject: Re: Qt KDE integration in kdereview. > To: kde-core-devel@... <mailto:kde-core-devel@...> > Message-ID: <200911042159.54853.neundorf@... > <mailto:200911042159.54853.neundorf@...>> > 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@... > <mailto:faure@...>> 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@... <mailto:tumaix@...>> > Subject: Re: Rocs moved to kdereview. > To: kde-core-devel@... <mailto:kde-core-devel@...> > Message-ID: > <7ebbb4b50911041448g42da8498gf938ec5aae8436f8@... > <mailto:7ebbb4b50911041448g42da8498gf938ec5aae8436f8@...>> > 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@... <mailto:kde-core-devel@...> > 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) |
| Free embeddable forum powered by Nabble | Forum Help |
