mail archive kde-hardware-devel.kde.org
(List home) (Recent threads) (157 other KDE lists)
Subscription Options
- RSS or Atom: Read-only subscription using a browser or aggregator. This is the recommended way if you don't need to send messages to the list. You can learn more about feed syndication and clients here.
- Conventional: All messages are delivered to your mail address, and you can reply. To subscribe, send an email to the list's subscribe address with "subscribe" in the subject line, or visit the list's homepage here.
- Low traffic list: less than 3 messages per day
- This list contains about 2,207 messages, beginning Jan 2006
- 0 messages added yesterday
Report the Spam
This button sends a spam report to the moderator. Please use it sparingly. For other removal requests, read this.
Are you sure? yes no
4.7 Release is coming, are we ready?
Ad
Hi there fellow metalworkers! I just noticed that we're 1 month and a few days away from the KDE SC 4.7 releae, so I thought that would be a good idea to ask this question, are we ready? From my side, there are a few things to fix or to improve before the release: BlueDevil 1.2 must be released on time, with better kio_obexftp support and fixing all crashes. LibSolid: I'd like to take a look at one crash and fix the support for iPod devices, one of the most requested features. If you have any doubts just aks :) these are my questions: Where are we on NetworkManagement? Can we say that we have support for NM0.9? Is the current NetworkManagement status documented somewhere? (we've at least 3 development branches) Will, how is the Solid::Control removing going? PowerDevil: Is inhibition working? if it is, can we make sure that Phonon has support for it? UPnP: What's the status? Thanks!
Em Saturday 11 June 2011, Alex Fiestas escreveu: > Hi there fellow metalworkers!Hi Alex and everybody.> If you have any doubts just aks :) these are my questions:> > Where are we on NetworkManagement?Development is progressing in both master and nm09 branches, Will is working on libnm-qt branch. Every couple of weeks we have one or two new features implemented and several bugs fixed (specially in nm09 branch). Things are improving fast compared to one year ago. We also have more people contributing regularly, like Ilia Kats and Rajeesh K Nambiar. > Can we say that we have support for NM0.9? Yes, nm09 branch supports everything that the master branch does now. We still need to implement some NM-0.8 features in both branches, such as Bluetooth Cdma tethering, Cdma interfade details (signal quality, operator's name, etc) and VPN interface details, hidden essid wifi. We also need to implement some NM-0.9 new features, like support to LTE modems and Wimax.> Is the current NetworkManagement status documented somewhere? (we've at > least 3 development branches)Only in my blog posts and for the libnm-qt branch there is the MERGE_NOTES file in the the root directory. There is only one problem for KDE SC 4.7.0: kdelibs' Solid::Networking::status() depends on a NetworkManager backend to get network status from NM. Some programs like Gluon depends on S::N::status() to work properly. Since the NM backend in kde-workspace does not work with NM-0.9 there can be problems for those who do not use any of the Plasma NM branches (nm09, libnm-qt) or the Fedora in-house solution. That accounts for everybody who uses nm-applet in Plasma desktop.
On Saturday, June 11, 2011 06:20:00 PM you wrote: > Em Saturday 11 June 2011, Alex Fiestas escreveu: > > Hi there fellow metalworkers! > > Hi Alex and everybody. > > > If you have any doubts just aks :) these are my questions: > > > > Where are we on NetworkManagement? > > Development is progressing in both master and nm09 branches, Will is > working on libnm-qt branch. Every couple of weeks we have one or two new > features implemented and several bugs fixed (specially in nm09 branch). > Things are improving fast compared to one year ago. We also have more > people contributing regularly, like Ilia Kats and Rajeesh K Nambiar.Perfect to see that more people is helping, do you know if they're subscribed to this mailist? would be nice to have them on board for Berlin Dekstop Summit and for the Sprint.> > Can we say that we have support for NM0.9? > > Yes, nm09 branch supports everything that the master branch does now. We > still need to implement some NM-0.8 features in both branches, such as > Bluetooth Cdma tethering, Cdma interfade details (signal quality, operator's > name, etc) and VPN interface details, hidden essid wifi. We also need to > implement some NM-0.9 new features, like support to LTE modems and Wimax.Great news! we've to find a good way of documenting this.> > Is the current NetworkManagement status documented somewhere? (we've at > > least 3 development branches) > > Only in my blog posts and for the libnm-qt branch there is the > MERGE_NOTES file in the the root directory. > > There is only one problem for KDE SC 4.7.0: kdelibs' > Solid::Networking::status() depends on a NetworkManager backend to get > network status from NM. Some programs like Gluon depends on S::N::status() > to work properly. Since the NM backend in kde-workspace does not work with > NM-0.9 there can be problems for those who do not use any of the Plasma NM > branches (nm09, libnm-qt) or the Fedora in-house solution. That accounts > for everybody who uses nm-applet in Plasma desktop.I see, we've to fix that ASAP since kdelibs will be freezed until KDE Framworks is released, meaning that either we fix this now or we have to wait 1 year at least. I will start working on it today.
Em Saturday 11 June 2011, Alex Fiestas escreveu: > On Saturday, June 11, 2011 06:20:00 PM you wrote: > > Development is progressing in both master and nm09 branches, Will is > > working on libnm-qt branch. Every couple of weeks we have one or two new > > features implemented and several bugs fixed (specially in nm09 branch). > > Things are improving fast compared to one year ago. We also have more > > people contributing regularly, like Ilia Kats and Rajeesh K Nambiar. > > Perfect to see that more people is helping, do you know if they're > subscribed to this mailist? would be nice to have them on board for Berlin > Dekstop Summit and for the Sprint.I do not think they are subscribed here, they are subscribed in kde- networkmanagement. I am adding then to the conversation.> > There is only one problem for KDE SC 4.7.0: kdelibs' > > Solid::Networking::status() depends on a NetworkManager backend to get > > network status from NM. Some programs like Gluon depends on > > S::N::status() to work properly. Since the NM backend in kde-workspace > > does not work with NM-0.9 there can be problems for those who do not use > > any of the Plasma NM branches (nm09, libnm-qt) or the Fedora in-house > > solution. That accounts for everybody who uses nm-applet in Plasma > > desktop. > > I see, we've to fix that ASAP since kdelibs will be freezed until KDE > Framworks is released, meaning that either we fix this now or we have to > wait 1 year at least.I think we can change the NM backend in kde-workspace to handle at least the NM-0.9's networking status, that can be done without changing anything in kdelibs.
On Sun, Jun 12, 2011 at 3:50 AM, Alex Fiestas wrote: >> Development is progressing in both master and nm09 branches, Will is >> working on libnm-qt branch. Every couple of weeks we have one or two new >> features implemented and several bugs fixed (specially in nm09 branch). >> Things are improving fast compared to one year ago. We also have more >> people contributing regularly, like Ilia Kats and Rajeesh K Nambiar. > Perfect to see that more people is helping, do you know if they're subscribed > to this mailist? would be nice to have them on board for Berlin Dekstop Summit > and for the Sprint.Thanks, but I will not be able to attend the summit/sprint, as I have not done the necessary visa and travel assistance. :-(> > I see, we've to fix that ASAP since kdelibs will be freezed until KDE Framworks > is released, meaning that either we fix this now or we have to wait 1 year at > least. > > I will start working on it today. > _______________________________________________ > Kde-hardware-devel mailing list > > https://mail.kde.org/mailman/listinfo/kde-har... >
Hi Alex,On Sun, Jun 12, 2011 at 2:18 AM, Alex Fiestas wrote: > Hi there fellow metalworkers! > > I just noticed that we're 1 month and a few days away from the KDE SC 4.7 > releae, so I thought that would be a good idea to ask this question, are we > ready? > > From my side, there are a few things to fix or to improve before the release: > > BlueDevil 1.2 must be released on time, with better kio_obexftp support and > fixing all crashes.Is bluetooth tethering (GSM/CDMA) support planned? AFAIK, all the necessary bits are already in Plasma NM.> > LibSolid: I'd like to take a look at one crash and fix the support for iPod > devices, one of the most requested features.I have an iDevice, and would be happy to help. Yesterday I've built and tested kio_afc (https://github.com/JonathanBeck/kio_afc) and works perfectly. It would be very nice if this gets integrated. I've looked around kde-runtime and kde-workspace code to do so, but couldn't figure out much yet :-)> > If you have any doubts just aks :) these are my questions: > > Where are we on NetworkManagement? > Can we say that we have support for NM0.9? > Is the current NetworkManagement status documented somewhere? (we've at least > 3 development branches) > Will, how is the Solid::Control removing going? > > PowerDevil: Is inhibition working? if it is, can we make sure that Phonon has > support for it? > > UPnP: What's the status? > > Thanks! > _______________________________________________ > Kde-hardware-devel mailing list > > https://mail.kde.org/mailman/listinfo/kde-har... >
On Sunday, June 12, 2011 11:43:04 AM Rajeesh K Nambiar wrote: > Hi Alex, > > On Sun, Jun 12, 2011 at 2:18 AM, Alex Fiestas wrote: > > Hi there fellow metalworkers! > > > > I just noticed that we're 1 month and a few days away from the KDE SC > > 4.7 > > releae, so I thought that would be a good idea to ask this question, are > > we ready? > > > > From my side, there are a few things to fix or to improve before the > > release: > > > > BlueDevil 1.2 must be released on time, with better kio_obexftp support > > and fixing all crashes. > > Is bluetooth tethering (GSM/CDMA) support planned? AFAIK, all the > necessary bits are already in Plasma NM.Yes.> > LibSolid: I'd like to take a look at one crash and fix the support for > > iPod devices, one of the most requested features. > > I have an iDevice, and would be happy to help. Yesterday I've built > and tested kio_afc (https://github.com/JonathanBeck/kio_afc) and works > perfectly. It would be very nice if this gets integrated. I've looked > around kde-runtime and kde-workspace code to do so, but couldn't > figure out much yet :-)Tom Gundersen is also looking to improve the situation, maybe you can work together on this? I would love to see some libimobiledevice integration in KDE, for example akonadi_agents to synchronize and so on.
> Hi there fellow metalworkers! > > I just noticed that we're 1 month and a few days away from the KDE SC 4.7 > releae, so I thought that would be a good idea to ask this question, are we > ready? > > From my side, there are a few things to fix or to improve before the release: > > BlueDevil 1.2 must be released on time, with better kio_obexftp support and > fixing all crashes. > > LibSolid: I'd like to take a look at one crash and fix the support for iPod > devices, one of the most requested features. > > If you have any doubts just aks :) these are my questions:There are a few bugreports that have been reported against the device notifier and that are indeed mostly relevant to solid-udisks https://bugs.kde.org/show_bug.cgi?id=270490 https://bugs.kde.org/show_bug.cgi?id=274982 which are indeed related to the fix to https://bugs.kde.org/show_bug.cgi?id=267398 and in general to the udisks teardown routine, which appears to have some issues; Would it be possible to coordinate some tests among us using different removable devices to see if the first two bugs can be reproduced? Apparently there are issues when deciding if and how a device should be ejected on unmount. At the moment the fix to bug 267398 forces basically all devices with a valid parent device to be ejected, even if they don't require so, since apparently most devices don't set the "DriveIsEjectable" property when they should. This causes bug 270490. Something related should indeed cause bug 274982. I don't believe the current approach (eject anyways) is correct, if the device doesn't set the property correctly, there should be a udev rule to fix that instead, pretty much as we solvedthe eSATA business. Thanks __J -- Plasma Device Notifier mantainer