Re: [arch-general] Making pacman check multiple repos
On Sat, 2009-12-12 at 02:13 +0100, Heiko Baums wrote: > Am Sat, 12 Dec 2009 08:58:17 +0800 > schrieb Ng Oon-Ee : > > > Because sometimes all the mirrors listed in mirrorlist will not have > > the file, if its just been uploaded. Also not everyone stays > > up-to-the-minute with updates, judging by the "updated after a month" > > posts we see once in a while. > > > > I'm concerned about the last bit, if a package was just uploaded and > > only exists on one mirror, everyone who updates and has that package > > in the period between its uploading and its appearance on their local > > mirrors will 'fall-back' on varying mirrors (lengthening the update > > process) and all end up on the poor main server (or Tier 1/2 mirrors). > > Bad for both the mirror bandwidth as well as most probably much slower > > for the user, who could probably just wait a day or so for the update > > to come to his (faster, presumably) local mirror. > > > Wouldn't it be possible to first upload the packages and update the db > files when the packages on the mirrors (at least on several mirrors) > are updated? > > If I have such a "problem" that a package is on no mirrors, which > doesn't happen often, I usually abort the system update and wait one > day. I think that's the normal and easiest way of solving this issue. > > Greetings, > Heiko The few mirrors which sync first would have quite much higher bandwidth usage =). The concern then is that in the period of time between uploading of packages and updating of db, the db would point to a package (foo-1.3) while the mirror would only have the new version (foo-1.4), since I don't think many mirrors keep multiple copies of the same package (schlunix I know off, any others?). So that would break updating as well, just in a different direction, and this would not be recoverable from.
Re: [arch-general] Making pacman check multiple repos
Am Sat, 12 Dec 2009 08:58:17 +0800 schrieb Ng Oon-Ee : > Because sometimes all the mirrors listed in mirrorlist will not have > the file, if its just been uploaded. Also not everyone stays > up-to-the-minute with updates, judging by the "updated after a month" > posts we see once in a while. > > I'm concerned about the last bit, if a package was just uploaded and > only exists on one mirror, everyone who updates and has that package > in the period between its uploading and its appearance on their local > mirrors will 'fall-back' on varying mirrors (lengthening the update > process) and all end up on the poor main server (or Tier 1/2 mirrors). > Bad for both the mirror bandwidth as well as most probably much slower > for the user, who could probably just wait a day or so for the update > to come to his (faster, presumably) local mirror. Wouldn't it be possible to first upload the packages and update the db files when the packages on the mirrors (at least on several mirrors) are updated? If I have such a "problem" that a package is on no mirrors, which doesn't happen often, I usually abort the system update and wait one day. I think that's the normal and easiest way of solving this issue. Greetings, Heiko
Re: [arch-general] Making pacman check multiple repos
On Sat, 2009-12-12 at 00:35 +0100, Xavier wrote: > On Sat, Dec 12, 2009 at 12:20 AM, Ng Oon-Ee wrote: > > While I'm not as concerned about security as some (most) here, I do > > think "db files from one site and packages from another" is a good idea. > > (some) Mirrors will be slow, however, and there will be additional > > complexity since the db would perhaps be several steps ahead of most > > mirrors. For example if package foo-1.2 is installed, package foo-1.4 is > > in the db, and package foo-1.3 is in the mirror, pacman would have to be > > smart enough to install foo-1.3 > > > > Why should it do that ? And that would make the security aspect > completely irrelevant. > > You did say you were not concerned about security (and to be honest, > me neither), but it's still not a reason to ignore it. > > By the way, when you use more than one mirror, pacman will just switch > to the second one if it doesn't find the file it wants. Because sometimes all the mirrors listed in mirrorlist will not have the file, if its just been uploaded. Also not everyone stays up-to-the-minute with updates, judging by the "updated after a month" posts we see once in a while. I'm concerned about the last bit, if a package was just uploaded and only exists on one mirror, everyone who updates and has that package in the period between its uploading and its appearance on their local mirrors will 'fall-back' on varying mirrors (lengthening the update process) and all end up on the poor main server (or Tier 1/2 mirrors). Bad for both the mirror bandwidth as well as most probably much slower for the user, who could probably just wait a day or so for the update to come to his (faster, presumably) local mirror.
Re: [arch-general] makechrootpkg and long union unmount time
On 12/12/2009 01:01 πμ, Ionut Biru wrote: On 12/12/2009 12:55 AM, Evangelos Foutras wrote: Hello, When I'm building a package using makechrootpkg and the build fails or I happen to interrupt it, sometimes it gets stuck at the "cleaning up unioned mounts" stage for a very long time (from several seconds up to a few minutes). During this time, the disk shows intense activity. Does this happen to others too? Any idea why this is occurring and how to prevent it? happen to me too. since 2.6.32 upgrade the cleanup sometimes take even 20 minutes. dmesg shows that aufs crashes Yeah, it's gotten much worse for me too with the latest kernel, maybe because I'm using ext4 and some recent corrections applied to it had a negative effect on performance [1]. Since it's not just me, I opened a bug report [2] so we can hopefully resolve this annoying behavior. [1] http://bbs.archlinux.org/viewtopic.php?id=85731 [2] http://bugs.archlinux.org/task/17469
Re: [arch-general] Making pacman check multiple repos
On Sat, Dec 12, 2009 at 12:20 AM, Ng Oon-Ee wrote: > While I'm not as concerned about security as some (most) here, I do > think "db files from one site and packages from another" is a good idea. > (some) Mirrors will be slow, however, and there will be additional > complexity since the db would perhaps be several steps ahead of most > mirrors. For example if package foo-1.2 is installed, package foo-1.4 is > in the db, and package foo-1.3 is in the mirror, pacman would have to be > smart enough to install foo-1.3 > Why should it do that ? And that would make the security aspect completely irrelevant. You did say you were not concerned about security (and to be honest, me neither), but it's still not a reason to ignore it. By the way, when you use more than one mirror, pacman will just switch to the second one if it doesn't find the file it wants.
Re: [arch-general] Making pacman check multiple repos
On Sat, 2009-12-12 at 00:54 +0200, Rogutės Sparnuotos wrote: > Aaron Griffin (2009-12-11 15:38): > > On Fri, Dec 11, 2009 at 3:14 PM, Brendan Long wrote: > > > For a little while I've been confused because pacman -Syu always said > > > that everything was up to date (for a week or more). I talked to a > > > friend at school and he had the same thing happening and I realized > > > something might be wrong and commented out mirrors one at a time until I > > > found one with updates (I think easynews is the one I used). The new > > > update comes with a mirrorlist that doesn't contain the mirror I was > > > using before (gigenet) > > > > > > The problem is that there's no warning that something is wrong with the > > > old mirrors, so I'd like to suggest some sort of test so that if no > > > updates are found for some amount of time, pacman tries a known good > > > mirror (like the main one). To save on bandwidth, it might work best to > > > make it only check the main repo for an updated package list and then > > > tries the normal mirrors until it finds one with a matching package > > > list. > > > > > > I'm not sure how complicated this would be be, or how worthwhile it is > > > (I suppose Arch users are more likely than most to realize that > > > something is wrong when updates stop), but I think it would be helpful > > > to have some sort of test to make sure you're not updating off a > > > seriously out of date mirror. > > > > Well, technically there's nothing "wrong" with the mirror. No one > > defined "matching archlinux.org exactly" to be "right". > > > > That said, there was some discussion in the past to use one server for > > DB files and another for packages. That'd cover this case here - get > > the db files from archlinux.org and use other servers for packages. > > Having DB files in a central place would do much trust wise. Currently, > one has to totally trust a mirror, because a mirror has total control > over the contents of binary packages and their checksums. But I guess this > is what the past discussion was about? > While I'm not as concerned about security as some (most) here, I do think "db files from one site and packages from another" is a good idea. (some) Mirrors will be slow, however, and there will be additional complexity since the db would perhaps be several steps ahead of most mirrors. For example if package foo-1.2 is installed, package foo-1.4 is in the db, and package foo-1.3 is in the mirror, pacman would have to be smart enough to install foo-1.3
Re: [arch-general] makechrootpkg and long union unmount time
On 12/12/2009 12:55 AM, Evangelos Foutras wrote: Hello, When I'm building a package using makechrootpkg and the build fails or I happen to interrupt it, sometimes it gets stuck at the "cleaning up unioned mounts" stage for a very long time (from several seconds up to a few minutes). During this time, the disk shows intense activity. Does this happen to others too? Any idea why this is occurring and how to prevent it? happen to me too. since 2.6.32 upgrade the cleanup sometimes take even 20 minutes. dmesg shows that aufs crashes
[arch-general] makechrootpkg and long union unmount time
Hello, When I'm building a package using makechrootpkg and the build fails or I happen to interrupt it, sometimes it gets stuck at the "cleaning up unioned mounts" stage for a very long time (from several seconds up to a few minutes). During this time, the disk shows intense activity. Does this happen to others too? Any idea why this is occurring and how to prevent it?
Re: [arch-general] Making pacman check multiple repos
Aaron Griffin (2009-12-11 15:38): > On Fri, Dec 11, 2009 at 3:14 PM, Brendan Long wrote: > > For a little while I've been confused because pacman -Syu always said > > that everything was up to date (for a week or more). I talked to a > > friend at school and he had the same thing happening and I realized > > something might be wrong and commented out mirrors one at a time until I > > found one with updates (I think easynews is the one I used). The new > > update comes with a mirrorlist that doesn't contain the mirror I was > > using before (gigenet) > > > > The problem is that there's no warning that something is wrong with the > > old mirrors, so I'd like to suggest some sort of test so that if no > > updates are found for some amount of time, pacman tries a known good > > mirror (like the main one). To save on bandwidth, it might work best to > > make it only check the main repo for an updated package list and then > > tries the normal mirrors until it finds one with a matching package > > list. > > > > I'm not sure how complicated this would be be, or how worthwhile it is > > (I suppose Arch users are more likely than most to realize that > > something is wrong when updates stop), but I think it would be helpful > > to have some sort of test to make sure you're not updating off a > > seriously out of date mirror. > > Well, technically there's nothing "wrong" with the mirror. No one > defined "matching archlinux.org exactly" to be "right". > > That said, there was some discussion in the past to use one server for > DB files and another for packages. That'd cover this case here - get > the db files from archlinux.org and use other servers for packages. Having DB files in a central place would do much trust wise. Currently, one has to totally trust a mirror, because a mirror has total control over the contents of binary packages and their checksums. But I guess this is what the past discussion was about? -- -- Rogutės Sparnuotos
Re: [arch-general] Making pacman check multiple repos
On Fri, Dec 11, 2009 at 3:14 PM, Brendan Long wrote: > For a little while I've been confused because pacman -Syu always said > that everything was up to date (for a week or more). I talked to a > friend at school and he had the same thing happening and I realized > something might be wrong and commented out mirrors one at a time until I > found one with updates (I think easynews is the one I used). The new > update comes with a mirrorlist that doesn't contain the mirror I was > using before (gigenet) > > The problem is that there's no warning that something is wrong with the > old mirrors, so I'd like to suggest some sort of test so that if no > updates are found for some amount of time, pacman tries a known good > mirror (like the main one). To save on bandwidth, it might work best to > make it only check the main repo for an updated package list and then > tries the normal mirrors until it finds one with a matching package > list. > > I'm not sure how complicated this would be be, or how worthwhile it is > (I suppose Arch users are more likely than most to realize that > something is wrong when updates stop), but I think it would be helpful > to have some sort of test to make sure you're not updating off a > seriously out of date mirror. Well, technically there's nothing "wrong" with the mirror. No one defined "matching archlinux.org exactly" to be "right". That said, there was some discussion in the past to use one server for DB files and another for packages. That'd cover this case here - get the db files from archlinux.org and use other servers for packages.
[arch-general] Making pacman check multiple repos
For a little while I've been confused because pacman -Syu always said that everything was up to date (for a week or more). I talked to a friend at school and he had the same thing happening and I realized something might be wrong and commented out mirrors one at a time until I found one with updates (I think easynews is the one I used). The new update comes with a mirrorlist that doesn't contain the mirror I was using before (gigenet) The problem is that there's no warning that something is wrong with the old mirrors, so I'd like to suggest some sort of test so that if no updates are found for some amount of time, pacman tries a known good mirror (like the main one). To save on bandwidth, it might work best to make it only check the main repo for an updated package list and then tries the normal mirrors until it finds one with a matching package list. I'm not sure how complicated this would be be, or how worthwhile it is (I suppose Arch users are more likely than most to realize that something is wrong when updates stop), but I think it would be helpful to have some sort of test to make sure you're not updating off a seriously out of date mirror. -Brendan Long signature.asc Description: This is a digitally signed message part
Re: [arch-general] Away from my PC -> away from bugtracker.
On Thu, Dec 10, 2009 at 10:13 PM, Gerardo Exequiel Pozzi wrote: > Hello all > > I will be away from now for about two or more weeks. I recently surfered > an small irritation on my eyss, so I can not stay on my PC :( Leaving > the bugtracker in their hands, I hope to be with you again soon. Good luck, hope it all goes well. But hey, you can wear an eyepatch now and pretend you're a pirate!
Re: [arch-general] suggestion for pacman: Recommended packages.
On Fri, 2009-12-11 at 16:02 +0100, Xavier wrote: > On Fri, Dec 11, 2009 at 1:54 PM, Hussam Al-Tayeb > wrote: > > On Fri, 2009-12-11 at 22:45 +1000, Allan McRae wrote: > >> Hussam Al-Tayeb wrote: > >> > The current case for many packages that use optdepends is as > >> follows. > >> > >> > >> I think some of this would be solved if/when we implement this: > >> http://wiki.archlinux.org/index.php/User:Allan/Pacman_OptDepends > > > > Thanks Allan. this is a good solution especially "optdepends can be > > removed with -Rs" and "optdepends are not orphans unless a flag is > > specified". > > Thank you :) > > > > Your proposal is not stupid, it would indeed make the optdepends > problems obsolete by getting rid of most of the optdepends, and > provide cleaner packages and dependencies. > Nagy had the same thought in a private discussion we had a while ago. > > Of course then there is also an increased complexity of packaging with > a lot of splitting and a much bigger number of packages. > And with that example of pacman and rankmirrors, rankmirrors is a 190 > lines python script. I don't think it deserved a package on its own. > Anyway for that specific example, some people were not happy about the > python dependency and rewrote rankmirrors in bash. pacman package may have been a bad example but you get the general idea.
Re: [arch-general] suggestion for pacman: Recommended packages.
On Fri, Dec 11, 2009 at 1:54 PM, Hussam Al-Tayeb wrote: > On Fri, 2009-12-11 at 22:45 +1000, Allan McRae wrote: >> Hussam Al-Tayeb wrote: >> > The current case for many packages that use optdepends is as >> follows. >> >> >> I think some of this would be solved if/when we implement this: >> http://wiki.archlinux.org/index.php/User:Allan/Pacman_OptDepends > > Thanks Allan. this is a good solution especially "optdepends can be > removed with -Rs" and "optdepends are not orphans unless a flag is > specified". > Thank you :) > Your proposal is not stupid, it would indeed make the optdepends problems obsolete by getting rid of most of the optdepends, and provide cleaner packages and dependencies. Nagy had the same thought in a private discussion we had a while ago. Of course then there is also an increased complexity of packaging with a lot of splitting and a much bigger number of packages. And with that example of pacman and rankmirrors, rankmirrors is a 190 lines python script. I don't think it deserved a package on its own. Anyway for that specific example, some people were not happy about the python dependency and rewrote rankmirrors in bash.
Re: [arch-general] suggestion for pacman: Recommended packages.
vlad wrote: Hi, On Fri, Dec 11, 2009 at 02:54:30PM +0200, Hussam Al-Tayeb wrote: On Fri, 2009-12-11 at 22:45 +1000, Allan McRae wrote: Hussam Al-Tayeb wrote: The current case for many packages that use optdepends is as follows. I think some of this would be solved if/when we implement this: http://wiki.archlinux.org/index.php/User:Allan/Pacman_OptDepends Thanks Allan. this is a good solution especially "optdepends can be removed with -Rs" and "optdepends are not orphans unless a flag is specified". Thank you :) Or install optdepende with the "--asdeps" flag. Sure, but then they are orphans and do not associate with the package that "needs" them.
Re: [arch-general] suggestion for pacman: Recommended packages.
Hi, On Fri, Dec 11, 2009 at 02:54:30PM +0200, Hussam Al-Tayeb wrote: > On Fri, 2009-12-11 at 22:45 +1000, Allan McRae wrote: > > Hussam Al-Tayeb wrote: > > > The current case for many packages that use optdepends is as > > follows. > > > > > > I think some of this would be solved if/when we implement this: > > http://wiki.archlinux.org/index.php/User:Allan/Pacman_OptDepends > > Thanks Allan. this is a good solution especially "optdepends can be > removed with -Rs" and "optdepends are not orphans unless a flag is > specified". > Thank you :) Or install optdepende with the "--asdeps" flag. --
Re: [arch-general] suggestion for pacman: Recommended packages.
On Fri, 2009-12-11 at 22:45 +1000, Allan McRae wrote: > Hussam Al-Tayeb wrote: > > The current case for many packages that use optdepends is as > follows. > > > I think some of this would be solved if/when we implement this: > http://wiki.archlinux.org/index.php/User:Allan/Pacman_OptDepends Thanks Allan. this is a good solution especially "optdepends can be removed with -Rs" and "optdepends are not orphans unless a flag is specified". Thank you :)
Re: [arch-general] suggestion for pacman: Recommended packages.
Hussam Al-Tayeb wrote: The current case for many packages that use optdepends is as follows. I think some of this would be solved if/when we implement this: http://wiki.archlinux.org/index.php/User:Allan/Pacman_OptDepends
Re: [arch-general] suggestion for pacman: Recommended packages.
On Fri, 2009-12-11 at 22:29 +1100, James Rayner wrote: > On Fri, 11 Dec 2009 10:40 +0200, "Hussam Al-Tayeb" > > wrote: > > The current case for many packages that use optdepends is as > follows. > > Let's say a package called package1 installs some extra binaries or > > plugins. Those extra not so used binaries or plugins have extra > > dependencies (let's call them libsomething) marked as optdepends. > > so on installation pacman will say something: > > optional dependency: libsomething needed for package1 plugins to > work. > > > > How about instead those extra binary files or plugins are split into > > another package called package1-plugins and have libsomething as > plain > > dependency? > > Then on package1 installation, pacman should say something like: > > Recommended packages: package1-plugins for blah blah functionality. > > This is known as 'debian'. > > I think it's overkill and offers no practical benefit. There is a benefit. You quoted part of my email. Did you read the rest? It also better then downsteam "deciding" which goes to depends and which goes to "optdepends"
Re: [arch-general] [arch-dev-public] Packaging Chromium for [extra]
On Fri, Dec 11, 2009 at 7:49 AM, Pierre Schmitz wrote: > OK, just uploaded -2 to testing; let me know, if it does work or not. Now it is working with youtube. A local site with flash videos continues to work. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? --- Denis A. Altoe Falqueto ---
Re: [arch-general] suggestion for pacman: Recommended packages.
James Rayner schrieb: How about instead those extra binary files or plugins are split into another package called package1-plugins and have libsomething as plain dependency? Then on package1 installation, pacman should say something like: Recommended packages: package1-plugins for blah blah functionality. This is known as 'debian'. That made me laugh. I think it's overkill and offers no practical benefit. Agreed. Just because we are now able to split packages, we should not overdo it like other distributions have. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Away from my PC -> away from bugtracker.
On Fri, Dec 11, 2009 at 6:13 AM, Gerardo Exequiel Pozzi wrote: > Hello all > > I will be away from now for about two or more weeks. I recently surfered > an small irritation on my eyss, so I can not stay on my PC :( Leaving > the bugtracker in their hands, I hope to be with you again soon. > > Best regards. take care and get well soon -- Ionut
Re: [arch-general] suggestion for pacman: Recommended packages.
On Fri, 11 Dec 2009 22:29:03 +1100 "James Rayner" wrote: > On Fri, 11 Dec 2009 10:40 +0200, "Hussam Al-Tayeb" > wrote: > > The current case for many packages that use optdepends is as > > follows. Let's say a package called package1 installs some extra > > binaries or plugins. Those extra not so used binaries or plugins > > have extra dependencies (let's call them libsomething) marked as > > optdepends. so on installation pacman will say something: > > optional dependency: libsomething needed for package1 plugins to > > work. > > > > How about instead those extra binary files or plugins are split into > > another package called package1-plugins and have libsomething as > > plain dependency? > > Then on package1 installation, pacman should say something like: > > Recommended packages: package1-plugins for blah blah functionality. > > This is known as 'debian'. > > I think it's overkill and offers no practical benefit. and what problem would that solve? it is exactly the same "we suggest you install this because it may be useful to you so we explain it to you in a line of text and you could take manual action if you want", just a different (and a more complicated) implementation.
Re: [arch-general] suggestion for pacman: Recommended packages.
On Fri, 11 Dec 2009 10:40 +0200, "Hussam Al-Tayeb" wrote: > The current case for many packages that use optdepends is as follows. > Let's say a package called package1 installs some extra binaries or > plugins. Those extra not so used binaries or plugins have extra > dependencies (let's call them libsomething) marked as optdepends. > so on installation pacman will say something: > optional dependency: libsomething needed for package1 plugins to work. > > How about instead those extra binary files or plugins are split into > another package called package1-plugins and have libsomething as plain > dependency? > Then on package1 installation, pacman should say something like: > Recommended packages: package1-plugins for blah blah functionality. This is known as 'debian'. I think it's overkill and offers no practical benefit.
Re: [arch-general] Kernel 2.6.32 and Radeon KMS
Am Freitag 11 Dezember 2009 schrieb Tobias Powalowski: > Am Montag 07 Dezember 2009 schrieb Tom: > > So, any news on this? > > I 'fixed' it by removing radeon from initramfs, but as has been pointed > > out, thats not really a solution!? > Please get files from bugreport http://bugs.archlinux.org/task/17461 Thanks greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org signature.asc Description: This is a digitally signed message part.
Re: [arch-general] Kernel 2.6.32 and Radeon KMS
Am Montag 07 Dezember 2009 schrieb Tom:
> So, any news on this?
> I 'fixed' it by removing radeon from initramfs, but as has been pointed
> out, thats not really a solution!?
>
HI guys,
This kms firmware issue revealed a bug in initcpio and firmware handling.
Would you mind to test a fix for the firmware loading?
2 files attached:
This will load udevd before executing MODULES=
- Replace /lib/initcpio/init and /lib/initcpio/hooks/udev
- Remove the yourself created radeon hook from /etc/mkinitcpio.conf hooks
array
- Add radeon again to modules array in /etc/mkinitcpio.conf
- Recreate a test initrd with mkinitcpio -g test.img
and launch this initrd from your bootloader.
- Don't forget to reinstall original initcpio files after that!
pacman -S initcpio
Thanks for your help.
greetings
tpowa
--
Tobias Powalowski
Archlinux Developer & Package Maintainer (tpowa)
http://www.archlinux.org
tp...@archlinux.org
# vim: set ft=sh:
run_hook ()
{
/sbin/udevadm trigger
/sbin/udevadm settle
msg "done."
}
signature.asc
Description: This is a digitally signed message part.
[arch-general] suggestion for pacman: Recommended packages.
The current case for many packages that use optdepends is as follows. Let's say a package called package1 installs some extra binaries or plugins. Those extra not so used binaries or plugins have extra dependencies (let's call them libsomething) marked as optdepends. so on installation pacman will say something: optional dependency: libsomething needed for package1 plugins to work. How about instead those extra binary files or plugins are split into another package called package1-plugins and have libsomething as plain dependency? Then on package1 installation, pacman should say something like: Recommended packages: package1-plugins for blah blah functionality. A good example is the pacman package itself which has an optional dependency on python for rankmirrors script. Maybe we could split it into a separate pacman-rankmirrors which depends on python the when a user installs/upgrades pacman package, he/she is prompted for recommended package pacman-rankmirrors for blah blah functionality. pacman-rankmirrors would depend on python. I think this is a better and cleaner approach. Obviously not every package can use that approach but it will clean some optdepends and remove some ldd errors because of uninstalled optdepends. Another thing, anyway to make pacman -Rns somepackage also remove optional dependencies that no other package uses?
Re: [arch-general] kde4/kmail slow - anybody else notice or is it just me?
On 12/09/2009 01:14 AM, Fabian Schölzel wrote: 2009/12/8 David C. Rankin: Specifically I see a slowdown when I access a mail folder containing>2000 messages or so. Each time I leave and return to a folder (my arch folder for example) kmail reloads and re-sorts the entire folder taking some 20+ seconds each time. It is like all 'folder state' caching (for lack of better words) has been turned off. (if that is possible) Anybody else seeing a slow down in kmail? I filed a bug report some time ago, maybe this is what you are experiencing? It's about having more than 1000 unreaded mails in a folder. (Yes, exactly 1000. 999 are fine.) http://bugs.kde.org/show_bug.cgi?id=207628 Fabian, That looks exactly like what is going on. I have a few very active subscriptions 300-400 emails/day. Go away for the weekend and you are big trouble :-) -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
Re: [arch-general] kde4/kmail slow - anybody else notice or is it just me?
On 12/08/2009 08:00 PM, Atanas Zhelev wrote: 2009/12/8 David C. Rankin: On Tuesday 08 December 2009 01:55:36 and regarding: Am Dienstag 08 Dezember 2009 08:41:15 schrieb David C. Rankin: Anybody else seeing a slow down in kmail? Hi, i have 11000+ messages in my POP3 account and don't see the slowdown you are experiencing. I can't offer an explanation why you have such a problem though. -- BRS Atanas Zhelev Thanks Atanas, I don't know what it is either. I know it didn't used to be there. For testing, I loaded thunderbird again, and the responsiveness of tbird is perfect. I know tbird is using mbox and kmail defaults to maildir, but honestly, the largest folder I have has a little over 41k messages in it and I can literally go get a Dr. Pepper waiting for kmail to read and thread the messages each time I access any folder with 8K plus messages. I'll check on a box with a fresh ~/ directory (without all the setting mods in ~/.kde4/share/... I have on my arch box). I'll report back if I hit on something. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
Re: [arch-general] go-openoffice not opening templates - anybody else?
On 12/10/2009 06:00 AM, Magnus Therning wrote: 2009/12/10 Ng Oon-Ee: On Thu, 2009-12-10 at 04:13 -0600, David C. Rankin wrote: Guys, I had to uninstall go-openoffice today and install the regular (beta) version so my templates would open again. When I would try and open them in go-oo, the window would open like it was trying to open the template, then the window would just disappear. Has anyone else had a problem with go-oo and templates? Yes, I have. Posted a forum topic about it. No real response (wonder how many people actually use OO regularly). Am running the beta currently due to that. Ah, does the beta open templates properly? I ended up running OO in Windows, just to open the template and save it as a regular document... this doc then opened find in Linux and I could carry on there. /M Yes, I have had no problems with my templates in oo-beta. No crashes either. A few quirks, but nothing more out of the ordinary. Well worth the install. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
