Re: ACTION REQUIRED - Gitlab and Subversion server migration

2023-07-23 Thread Martin Steigerwald
Ben Cooksley - 23.07.23, 12:01:04 CEST:
> Please ensure you run the following two commands to clear out any
> existing host keys:
> - ssh-keygen -R invent.kde.org -f ~/.ssh/known_hosts
> - ssh-keygen -R svn.kde.org ~/.ssh/known_hosts

The second command misses a "-f":

ssh-keygen -R svn.kde.org -f ~/.ssh/known_hosts

Thanks for all your work, Ben!

Best,
-- 
Martin




Re: Suggestion to Remove KFloppy and hold back K3b

2017-02-22 Thread Martin Steigerwald
Am Mittwoch, 22. Februar 2017, 20:07:09 CET schrieb Wolfgang Bauer:
> Am Mittwoch, 22. Februar 2017, 01:07:42 schrieb Boudhayan Gupta:
> > I really don't see why this has to exist. Anyone who uses floppies in
> > this day and age knows how to use a command line to do a low level
> > format.
> 
> Maybe, but using a GUI is more comfortable and you don't have to remember
> which tools and command line options to use... ;-)
> 
> The original mail here suggested to drop it because it "doesn't work" (which
> is not completely true).
> And I am willing to work on improving it.
> 
> Whether it still "has to exist" is a different topic IMHO, and probably also
> quite subjective.
> I do use it regularly and would be disappointed if it would disappear.
> That's the reason why I stepped up as maintainer a bit over a year ago, and
> invested time and effort to port it to KF5...
> 
> My opinion: you don't have to install it if you have no need for it.

I wonder whether it makes sense to make it a more generic format tool that can 
also format USB sticks. Then it may make sense to give it a more generic name.

In Debian its not installed by default, but available as package. The kdeutils 
metapackage just suggests it. I think thats just fine and as you intend to 
maintain it…

Thanks,
-- 
Martin


Re: [Kde-pim] PIM is not good. Would adding an extra RC help?

2014-04-05 Thread Martin Steigerwald
Hi Albert,

I am mostly a user of KDEPIM, but since I experienced quite some performance 
issues and did some analysis and reports every now and then, I thought I share 
my findings.

Am Samstag, 5. April 2014, 16:40:24 schrieb Albert Astals Cid:
 ** Please CC me and r-t list, i'm not subscribed to pim list. **
 
 Hello guys, as I hope you all know this Wednesday we are supposed to tag the
 final release for 4.13.
 
 I am sending this email to ask for opinions on the value of adding an extra
 RC and delaying the 4.13.0 release for at least a week.
 
 I'm going to explain why I'd like this to happen.
 
 Since the update to 4.13 Beta I've been having lots of CPU and I/O problems
 in pim related stuff, most notably akonadi_baloo_indexer,
 akonadi_maildir_resource  friends.
 
 On every release i've complained on IRC to be told oh yes, we just fixed
 this thing and will be available on the next release.
 
 But here I am, using 4.13 RC and with even KMail closed
 mysqld+akonadiserver+akonadi_maildir_resource are using 100% of one of my
 CPU cores and writing/reading around 10MB/s to my slow disks.

So you are using a POP3 setup? Or how is the maildir resource filled on your 
setup? How big is it?

I reported several bugs regarding slowness of maildir resource with lots of 
folders with lots of mails in it, including a report of 
akonadi_maildir_resource hogging up one Intel Sandybridge core on a Dual SSD 
BTRFS RAID 1 setup for several minutes after filtering about 100 mails into 
their folders[1]. And one for MySQL tuning, but at least from my observation 
the issue isn´t MySQL here, I thought so first, but I am not convinced after a 
deeper look at show innodb engine in MySQL is doing. See recent thread in pim-
ml as well[3]. I am keen to look at it some more, but after spending quite a 
lot of time on analysing I needed a break. Well some other things Mark 
found[4]

But on the other hand my setup might be considered extreme. About 100 folders, 
quite some of them with several ten thousand mails and one (kernel-ml) with 
about 22 unread mails.

It is my impression that both for my private POP3 setup and my work IMAP setup 
performance got way better on the upgrade from Akonadi 1.11.0 to Akonadi 
1.12.0. Still I see the akonadi_maildir_resource hogging a core for minutes at 
times. But it doesn´t seem to happen after every mail retrieval / mail 
filtering cycle. Sometimes MySQL chimes in using something between one and 
three cores, but I see akonadi_maildir_resource for minutes on 100% CPU 
without any notable CPU activity of mysqld as well.

But when it does, I see it synchronizing folders. In strace I see it getting 
dentries and checking the existance of every little file.

I don´t know whether another week will lead to a fix. I got the impression that 
performance issues with Akonadi are not yet fully understood.

In my eyes there are two things which contribute a lot to KMail being 
basically unusable for times of several minutes:

1) Maildir resource synchronizes folders needlessly. Not sure what triggers it 
tough.

2) Akonadi blocks out KMail almost completely when maildir resource is doing 
so. To me Akonadi appears to be basically single threaded. While I understand 
one of its design goals of Akonadi were that GUI applications like KMail never 
block again.


Also remember for me this is Akonadi 1.12.0 and KDEPIM 4.12.4 still. But for 
these versions, although I see improvements, I still think KDEPIM + Akonadi 
needs serious performance related work. Cause I just don´t get how filtering 
100-200 mails to their folders can lead to a usage of one Sandybridge core for 
minutes unless I assume somewhere something does unnecessary work. Its not a 
I/O bottleneck according to atop.


That said:

- I don´t think the performance issues are new. So they are no regression. Or 
did you found it regressing recently?

- I am not sure whether another week would help with fixing them, as… my bet 
is: If the cause is understood someone likely would have fixed them already.

I do think the KDEPIM / Akonadi team needs helping hands. I tried to help a 
bit, but I didn´t come around at looking at the code and when I do I first need 
to understand some of it before I can consider proposing a patch. :)


[1] [Akonadi] [Bug 332684] New: [Maildir] lots of stats calls to 
/etc/localtime on synchronizing folders

= can be work-arounded by setting TZ env var, yet folder synchronization 
still is slow.

[2] [Akonadi] [Bug 332626] MySQL tuning: adaption of MySQL tuning options for 
larger accounts

[3] [Kde-pim] Akonadi MySQL backend: tuning for larger accounts or switching 
to MariaDB with a different storage engine?

[4] PIM Sprint, Calendar progress and Akonadi
Datum:Donnerstag 17:13 
Autor:Mark Gaiser (markg)

http://kdeblog.mageprojects.com/2014/04/03/pim-sprint-calendar-progress-and-akonadi/

[5] Re: [Kde-pim] Akonadi MySQL backend: tuning for larger accounts or 
switching to MariaDB with a…

This is not the 

Re: [Nepomuk] Exception for Dolphin - KFileMetadataWidget

2013-01-06 Thread Martin Steigerwald
Hi Frank,

Am Sonntag, 6. Januar 2013 schrieb Frank Reininghaus:
 Please note that I'm not blaming anyone for anything here, I'm just
 trying to answer the obvious question why did the maintainer not
 notice this before? in advance.

Just a KDE users oppinion on this:

I didn´t have that question from reading the rest of the thread. (I know not 
everyone read it.)

I was quite surprised that on beta testing instructions in wiki the new 
FileMetadataWidget was mentioned after the release delay anouncement, cause I 
thought it was clear it wouldn´t go in.

Anyway, I think its clear that you are not responsible for this.

Now that it is in, I agree that it makes sense to fix any regressions
it may cause. And from what I read in this thread Vishesh agreed to take the 
responsibility to look after them should the widget go in.

 I'm sorry if this message is considered offensive, but I'm seriously
 fed up with the way Nepomuk repeatedly broke things in the last years
 and caused extra work for everyone. I'm still willing to collaborate
 constructively with Nepomuk and Vishesh in particular, but IMHO, the
 way Nepomuk interacts with the rest of the KDE community has to
 change.

Indeed does not make sense to blame anybody, but look at what can be improved 
in future.

Thanks for maintaining Dolphin,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team