Re: Review Request: UDisks mount vfat filesystems with flush option.
On Jun 13, 2012, at 2:32 PM, Konstantinos Smanis wrote: On Tue, Jun 12, 2012 at 11:33 AM, Maarten De Meyer de.meyer.maar...@gmail.com wrote: This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105224/ Review request for kdelibs, Solid and Lukáš Tinkl. By Maarten De Meyer. Description This patch mounts vfat filesystems (mostly usb devices) with the flush option when using the UDisks backend. The hal backend already did this. The flush option makes sure changes are written to the device immediately. Please let me know it this should be implemented in an other (optional) way or if this should be in the UDev rules directly. ps. I do not have commit rights. Testing Compiled without error, mounted multiple devices without problems. Bugs: 273792 Diffs solid/solid/backends/udisks/udisksstorageaccess.cpp (7d72a88) View Diff I tested the patch against 4.8.3, works as expected. However, I too think that this option should be implemented somewhere else in the stack (udisks/udev: whatever is most fit). Although a sane default, you should be able to configure it more easily. I'm erring on the side that this smells of policy, which should NOT be hard coded, but rather site or host specified. If I'm a user, I might rather have my application's writer thread not block on write, but cache then write via the kernel, then so be it (yes, I understand the risk related if I remove the disk before the flush has occurred, but in this case, that's what umount is for, which calls flush before unmounting the filesystem. -- Gary L. Greene, Jr. === Developer and Project Lead for the AltimatOS open source project See http://www.altimatos.com/ for more information ===
Re: DrKonqi improvement idea
On Mar 11, 2012, at 3:26 AM, Niko Sams wrote: Hi, I'd like to talk about an idea on how DrKonqi (which is a really useful thing btw) could be further improved. In short: DrKonqi shouldn't create bugs directly but talk to a layer between. DrKonqi - crashes.kde.org - bugs.kde.org crashes.kde.org is a new web application - a bit similar to bugzilla: - lists all reported crashes with intelligent filtering duplicates - developers can set duplicates - developers can link a crash to a bug (or create automatically a bug for a crash) - developers can enter a solution (that will be presented to the user that hits this crash) eg.: - update to version x.y - temporary workaround: don't click button x - you missconfigured x, see http://y.com how to fix - the developers are aware of this issue but have not yet fixed it, see http://bugs.kde.org/... for details - the bug is fixed but an update has not yet been released. Update to version x.y once it released. - comments can be added by users and developers (to ask how to reproduce etc) For the end user there could be the following scenarios: - user posts the crash, crashes.kde.org finds a duplicate crash in it's database and will tell the user on how to proceed (see possible solutions above) - user posts the crash, crashes.kde.org can't find an exact duplicate and will show the user all possible duplicates - user posts the crash, crashes.kde.org doesn't find a duplicate. User gets the possibility to subscribe to updates for this crash to get an email when a solution for his crash was entered by the developers One big difference in implementation I would propose: DrKonqi makes a *single* POST to crashes.kde.org including all information and then just shows a WebView where the server side can do anything. That gives greater independence of the used KDE version and changes on the server side. Advantages over current solution: - bugs.kde.org isn't filled with duplicates - crashes.kde.org can be specialized on crashes - sending a crash would not only help developers fixing that bug but also help the user by showing a solution for his issue. What software could crashes.kde.org run? I'm not sure, maybe a bugzilla installation or something custom written. Or some other bugtracking software. So, what do you think? Niko Ubuntu has something similar iirc, same goes with the Linux Kernel project. (I recall hearing about it a couple years ago while at Google, so my memory could be a little fuzzy….) -- Gary L. Greene, Jr. === Developer and Project Lead for the AltimatOS open source project Volunteer Developer for the KDE open source project See http://www.altimatos.com/ and http://www.kde.org/ for more information === Please avoid sending me MS Office attachments.
Re: Go Daddy root certificates
On Jul 23, 2011, at 10:33 AM, Martin Koller wrote: Hi, can anyone answer the case https://bugs.kde.org/show_bug.cgi?id=277319 , please ? -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at Honestly, I really wish that Mozilla/KDE/Google/Wget/insert FOSS group that has their own root certificate store here would get together on fdo and create a common project that the root certificates could be aggregated at instead of each project doing it themselves... -- Gary L. Greene, Jr. smime.p7s Description: S/MIME cryptographic signature
Re: US Week Numbers - USian Advice Needed
On 5 May 2011, at 12:24 AM, John Layt wrote: On Wednesday 04 May 2011 23:07:38 Keith Rusler wrote: A new week starts every Sunday. So yeah, week one starts on the first Sunday of the year, regardly of wherever January 1st starts on. Btw, we aren't called USians, but Americans ;). So consensus seems to be Week 1 starts on the first Sunday, the question then is what week number do the days before that receive, Week 0 or Week 52/53 of the previous year? Anyone seen the the Jan 1 == partial Week 1 used, as it's a very well documented scheme in various places including a number of software vendors. Normally, that's just 52/53, since it's a continuance of the week started in the previous year. -- Gary L. Greene, Jr. === Developer and Project Lead for the AltimatOS open source project Volunteer Developer for the KDE open source project See http://www.altimatos.com/ and http://www.kde.org/ for more information === Please avoid sending me MS Office attachments. smime.p7s Description: S/MIME cryptographic signature
Re: US Week Numbers - USian Advice Needed
On 4 May 2011, at 3:03 PM, John Layt wrote: Hi, I'm implementing support for US week numbers, but there's conflicting information on the great interweb tubes as to what the standard is. Some sources say the US Standard is Week 1 is from Jan 1 to the first Saturday of the year (which may be less than 7 days) then each following week starts from Sunday. Other sources say Week 1 starts on the first Sunday in the year, with the days preceeding it being labelled either Week 0 or the last week of the previous year. Finally there's some suggestion the US military uses simple week numbering, i.e. week 1 starts on Jan 1 and lasts 7 days, with each week following in order. All 3 may even be in regular use and so all will require support. A lot of this confusion seems to stem from our dear friends in Redmond who's aversion to standards leaves them equally unable to correctly implement the US Week as the ISO Week. Beatings with the clue-stick gratefully received. John. ducking and bowing out of the whole USian vs. American discussion John, While I'm odd and view the week as starting on Monday (don't ask, don't want a debate on my views...) the common perception in the US is that the first full week of January is week 1. -- Gary L. Greene, Jr. === Developer and Project Lead for the AltimatOS open source project Volunteer Developer for the KDE open source project See http://www.altimatos.com/ and http://www.kde.org/ for more information === Please avoid sending me MS Office attachments. smime.p7s Description: S/MIME cryptographic signature
Re: Userconfig: A KCModule for users and groups configuration
On 3 May 2011, at 10:47 AM, Romain Perier wrote: Hello, I am a kubuntu contributor, we develop userconfig, a kcmodule for users and groups configuration. Basically, It has almost the same features than kuser, except it's graphically integrated into systemsettings and no longer runs as root (not official yet but I write a patch which works like a charm). Since kuser is not maintained anymore and the kdeadmin maintainer connot be contacted, I thought it was a good idea to send an email here. I have also contacted each kdeadmin authors (of each subproject). I propose to move userconfig in kdeadmin as an alternative of kuser. userconfig is written in python, see https://code.launchpad.net/~kubuntu-members/guidance/userconfig-kde4 for more details. would you be interested ? Does it allow for RFC 2307 based LDAP users? Loosing that feature of KUser would be a downside for me, as UNIX is far more than local shadow users. -- Gary L. Greene, Jr. === Developer and Project Lead for the AltimatOS open source project Volunteer Developer for the KDE open source project See http://www.altimatos.com/ and http://www.kde.org/ for more information === Please avoid sending me MS Office attachments. smime.p7s Description: S/MIME cryptographic signature
Re: kwin crashes short after start
On 18 Apr 2011, at 1:31 PM, Thomas Lübking wrote: Am 18.04.2011, 21:57 Uhr, schrieb Ingo Klöcker kloec...@kde.org: This was meant as a workaround. And, of course, you can edit kwinrc (or whatever rc file) without having a desktop. given the comments in bug #271166 this is a) on vmware (they cheat a gallium driver) b) only on first login to a fresh new account (since then kwin should have figure: compositing doesn't work) In particular shader support seems incomplete but is activated for the gallium driver. Disabling all shader effects and setting the scale method to smooth (ie, avoid the laczos filter) will probably do - otherwise we'll just blacklist vmware completely. Cheers, Thomas Please don't, re blacklisting. I actually have a working VMware Fusion with full Compositing, and would be very unhappy to have to go back to a non-composited desktop. (No crash here, using an ATI Radeon HD 2400 on the host system.) -- Gary L. Greene, Jr. === Developer and Project Lead for the AltimatOS open source project Volunteer Developer for the KDE open source project See http://www.altimatos.com/ and http://www.kde.org/ for more information === Please avoid sending me MS Office attachments. smime.p7s Description: S/MIME cryptographic signature
Re: Future of KSysguard - removing remote monitoring
On 9 Mar 2011, at 7:54 AM, John Tapsell wrote: Thanks for the feedback - this is why I put out such emails before I make any changes. It's good to know that people actually use this app - sometimes it's hard to know if anyone actually uses it. I'll hold off on any rash changes for now. Thanks! John Has ksysguard (at least the front-end) been ported to Mac OS X? This would save me a lot of time in having to invest time and effort in creating a web-monitoring system for a few sites I do admin stuff for If not, what is preventing it from working on that platform (if any), and would you welcome any help for getting it completed?
Re: About remove nfs filesharing support
On 31 Dec 2010, at 4:26 AM, David Faure wrote: On Tuesday 28 December 2010, Allan Sandfeld Jensen wrote: On Tuesday 28 December 2010, Jonathan Riddell wrote: On Tue, Dec 28, 2010 at 01:18:10PM -0200, Raphael Kubo da Costa wrote: Does that mean making KDE completely oblivious to NFS at all? No, NFS is almost always system mounted. I've never come across anyone actually using it for user mounts. Far better to work on support for protocols that are designed for the job and standardied like SMB (designed for the job, Rodrigo already implemented), and Webdav (standardised, could be intergrated with OwnCloud). I use it like that. NFS integrates much better than SMB with unix filesystems, and auto-mounting is not always possible with a laptop that can be moved between different local networks. Note that the nfs://host ioslave will still be working (*), in addition to system mounts. The only thing discussed here is the suid script (and related GUI) that allows users to make nfs shares. (*) so even if almost always system mounted is not so true, we still have a client solution that doesn't require mounting. Which I like very much because it doesn't make your machine hang when the server is shut down and you forgot to umount the share... (But then again, sftp:// is easier to setup and more secure). Anyway, I don't know if user-controlled sharing should be kept or removed. It would be interesting to have Mandriva's feedback, since the feature was coded by Mandriva developers, years ago. Actually, David, you were the one that did the work of helping shepherding that in (I remember as I was the one that got the original author and you talking to get it into KDE back around the 3.2(I think...) series) To be frank, I'd be loath to remove both the ability to create exports or connect to NFS from KDE, as it is a feature that is trivially easy to do on Mac, and Windows (with SFU installed). Please don't remove another system level thing as has been done before. Best option here is to create a KAuth shim app to do the work for this. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).
Re: Suspending mailinglists due to lack of moderators.
On 1 Jan 2011, at 1:25 PM, Tom Albers wrote: Hi, These are the top mailinglists with the most amount of moderation requests. For most of them we have tried to contact the current moderators without much success last year. So now I suggest we get rid of these mailinglists. Note that if you object, you are volunteering for taking over moderation. 312 decibel 150 kde-imaging 102 kjsembed 80 kmobiletools 46 kde-contests 42 quanta 42 kde-i18n-pt 40 kdelibs-bugs 36 cervisia 32 quanta-devel 32 kde-enterprise 29 klik-devel 29 kde-java 28 plasma-bugs 28 dot-stories Best, -- Tom Albers KDE Sysadmin As KDE and the Enterprise is something I am passionate about (though didn't know about this list) and 32 moderation requests are easy to manage in my flow of email, I'll take on moderation of that list.