10 Aug
2013
10 Aug
'13
2:55 a.m.
Tim,
k3bhalconnection.cpp:845:70: error: no matching function for call
to 'TDEStorageDevice::mountDevice(const TQString&, TQString&)'
Proposed patch, based upon today's tdebase patch:
diff -urN k3b/libk3bdevice/k3bhalconnection.cpp
k3b.new/libk3bdevice/k3bhalconnection.cpp
--- k3b/libk3bdevice/k3bhalconnection.cpp 2013-04-05
22:32:35.000000000 -0500
+++ k3b.new/libk3bdevice/k3bhalconnection.cpp 2013-08-09
21:35:42.121489109 -0500
@@ -840,9 +840,9 @@
TDEStorageDevice* sdevice =
static_cast<TDEStorageDevice*>(hwdevice);
// FIXME
- // Options from 'options' are not currently loaded into
'optionString'
- TQString optionString;
- TQString mountedPath = sdevice->mountDevice(mountPoint,
optionString);
+ // Options from 'options' are not currently loaded into
'mountOptions'
+ TDEStorageMountOptions mountOptions;
+ TQString mountedPath = sdevice->mountDevice(mountPoint,
mountOptions);
if (mountedPath.isNull()) {
return org_freedesktop_Hal_CommunicationError;
}
@@ -869,8 +869,8 @@
TDEStorageDevice* sdevice =
static_cast<TDEStorageDevice*>(hwdevice);
// FIXME
- // Options from 'options' are not currently loaded into
'optionString'
- TQString optionString;
+ // Options from 'options' are not currently loaded into
'mountOptions'
+ TQString mountOptions;
if (!sdevice->unmountDevice(NULL)) {
// Unmount failed!
The patch allowed be to build k3b, although you know more than me
what is happening.
Darrell
10 Aug
10 Aug
8:07 p.m.
New subject: [trinity-devel] Tim: k3b FTBFS & proposed patch
Tim,
k3bhalconnection.cpp:845:70: error: no matching function for call
to 'TDEStorageDevice::mountDevice(const TQString&, TQString&)'
Proposed patch, based upon today's tdebase patch:
diff -urN k3b/libk3bdevice/k3bhalconnection.cpp
k3b.new/libk3bdevice/k3bhalconnection.cpp
--- k3b/libk3bdevice/k3bhalconnection.cpp 2013-04-05
22:32:35.000000000 -0500
+++ k3b.new/libk3bdevice/k3bhalconnection.cpp 2013-08-09
21:35:42.121489109 -0500
@@ -840,9 +840,9 @@
TDEStorageDevice* sdevice =
static_cast<TDEStorageDevice*>(hwdevice);
// FIXME
- // Options from 'options' are not currently loaded into
'optionString'
- TQString optionString;
- TQString mountedPath = sdevice->mountDevice(mountPoint,
optionString);
+ // Options from 'options' are not currently loaded into
'mountOptions'
+ TDEStorageMountOptions mountOptions;
+ TQString mountedPath = sdevice->mountDevice(mountPoint,
mountOptions);
if (mountedPath.isNull()) {
return org_freedesktop_Hal_CommunicationError;
}
@@ -869,8 +869,8 @@
TDEStorageDevice* sdevice =
static_cast<TDEStorageDevice*>(hwdevice);
// FIXME
- // Options from 'options' are not currently loaded into
'optionString'
- TQString optionString;
+ // Options from 'options' are not currently loaded into
'mountOptions'
+ TQString mountOptions;
if (!sdevice->unmountDevice(NULL)) {
// Unmount failed!
The patch allowed be to build k3b, although you know more than me
what is happening.
Darrell
Looks good, go ahead and push. What is happening is that it was brought
to my attention that the TDE HW library API inadvertently assumed the
usage of pmount in all cases. Therefore, I updated the API to use a more
generic method of specifying mount options; apparently I missed a few
users of the TDE HW library such as k3b.
Tim
8:58 p.m.
New subject: [trinity-devel] Tim: k3b FTBFS & proposed patch
2013/8/11 Timothy Pearson <kb9vqf(a)pearsoncomputing.net>
Looks good, go ahead and push. What is happening is
that it was brought
to my attention that the TDE HW library API inadvertently assumed the
usage of pmount in all cases. Therefore, I updated the API to use a more
generic method of specifying mount options; apparently I missed a few
users of the TDE HW library such as k3b.
Tim
It's steel not perfect:
- mediaName parameter is useless for most of other possible backends, so
it would be nice to pass it as a part of mountOptions map.
- the retcode is assumed to be the pmount's returned code it's better to
return a constant from some enum set.
PS when you introduce the new API, you supposed to mark the old one with
KDE_DEPRECATED rather than just replace it.
or at least please make some announce at list before performing such
changes...
9:03 p.m.
New subject: [trinity-devel] Tim: k3b FTBFS & proposed patch
2013/8/11 Timothy Pearson
<kb9vqf(a)pearsoncomputing.net>
R14 is still in development, so I don't need to use KDE_DEPRECATED. After
release then yes, I would need to do that, hence the urgency of the API
change. :-)
mediaName will stay as I consider it a defect (albiet one out of our
control) if a backend is not able to use a user-defined mount label.
retcode can be changed to an enum without any ABI problems, so this is not
too high on my list of priorities.
Tim
Looks good, go ahead and push. What is happening
is that it was brought
to my attention that the TDE HW library API inadvertently assumed the
usage of pmount in all cases. Therefore, I updated the API to use a
more
generic method of specifying mount options; apparently I missed a few
users of the TDE HW library such as k3b.
Tim
It's steel not perfect:
- mediaName parameter is useless for most of other possible backends, so
it would be nice to pass it as a part of mountOptions map.
- the retcode is assumed to be the pmount's returned code it's better to
return a constant from some enum set.
PS when you introduce the new API, you supposed to mark the old one with
KDE_DEPRECATED rather than just replace it.
or at least please make some announce at list before performing such
changes...
9:33 p.m.
New subject: [trinity-devel] Tim: k3b FTBFS & proposed patch
2013/8/11 Timothy Pearson <kb9vqf(a)pearsoncomputing.net>
You have announced the hard freeze some time ago, doesn't that mean, that
we don't want such changes?
mediaName will stay as I consider it a defect (albiet one out of our
2013/8/11
Timothy Pearson <kb9vqf(a)pearsoncomputing.net
It's steel not perfect:
- mediaName parameter is useless for most of other possible backends, so
it would be nice to pass it as a part of mountOptions map.
- the retcode is assumed to be the pmount's returned code it's better to
return a constant from some enum set.
PS when you introduce the new API, you supposed to mark the old one with
KDE_DEPRECATED rather than just replace it.
or at least please make some announce at list before performing such
changes...
R14 is still in development, so I don't need to use KDE_DEPRECATED. After
release then yes, I would need to do that, hence the urgency of the API
change. :-)
control) if a backend is not able to use a
user-defined mount label.
UDisks 2 nor 1, which IMO are the most wanted backends, are unable to do
that.
Anyway, IMHO it would be better to supply it as a part of the map, because
in that case you'll got one less parameter...
retcode can be changed to an enum without any ABI
problems, so this is not
too high on my list of priorities.
Strictly speaking, this would break the API/ABI unless you'll set some
enumes to specific values. But that not a problem.
3914
days inactive
3914
days old
4 comments
3 participants
participants (3)
-
Darrell Anderson -
Fat-Zer -
Timothy Pearson