will there be a Jaunty backport?
--
"Reading Database" takes too long
https://bugs.launchpad.net/bugs/398870
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.c
Could we get a pointer to the commit which fixed this in apt? I assume
this will go in lucid-proposed and such, yes?
--
"Reading Database" takes too long
https://bugs.launchpad.net/bugs/398870
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubunt
** Changed in: apt (Ubuntu)
Status: Confirmed => Fix Released
--
"Reading Database" takes too long
https://bugs.launchpad.net/bugs/398870
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lis
This bug has been fixed in Lucid.
--
"Reading Database" takes too long
https://bugs.launchpad.net/bugs/398870
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.
I'd like to remember you all dpkg/experimental is a lot faster now...
from about 14sec to 3sec here. Well using the database would be about
1sec but I wouldn't recommend to a distribution to use a wrapper (just
like I don't recommend installing the library in your system, not
because it's unstable
In fact a database has already been implemented. See the following
Brainstorm Idea: http://brainstorm.ubuntu.com/idea/24027/
If you want that feature, please vote for this idea!
--
"Reading Database" takes too long
https://bugs.launchpad.net/bugs/398870
You received this bug notification because
edit to my comment above - apt-get clean doesn't actually solve this
problem. I was seeing a speed-up simply due to the database being in the
hard drive cache :(
--
"Reading Database" takes too long
https://bugs.launchpad.net/bugs/398870
You received this bug notification because you are a member
For me, this solved the problem:
apt-get clean
This basically deletes all the downloaded ".deb" files (which are no
longer needed after they have been installed), which has the added
advantage of freeing up some disk space.
--
"Reading Database" takes too long
https://bugs.launchpad.net/bugs/39
This helps: http://ubuntuforums.org/showthread.php?t=1004376
--
"Reading Database" takes too long
https://bugs.launchpad.net/bugs/398870
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubunt
I don't know what exactly this "workaround" does, but it does NOT work
for me at all. "Reading database" in Karmic still lasts ages as opposed
to what used to be in Hardy.
--
"Reading Database" takes too long
https://bugs.launchpad.net/bugs/398870
You received this bug notification because you ar
Sorry, the "long-term solution" does not explain why "Reading database"
used to be fast under older versions of Ubuntu. Can anyone explain why
fragmentation came to be a problem for /var/lib/dpkg/info in recent
versions of Ubuntu?
--
"Reading Database" takes too long
https://bugs.launchpad.net/b
Cron work-around: a weekly "cd /var/lib/dpkg && mv info info.bak && cp
-a info.bak info && rm -R info.bak" to keep the directory contiguous.
ReiserFS work-around: create a ReiserFS partition especially to hold
/var/lib/dpkg/info. ReiserFS was specifically designed to handle
zillions of tiny files
It is a workaround, not a solution.
A solution would be if this were solved automatically so users wouldn't
have to track down this bug report in order to have sane package
database reading times.
--
"Reading Database" takes too long
https://bugs.launchpad.net/bugs/398870
You received this bug n
we should get a button to mark a comment as a viable solution.
Just like graham, the first copy took ages, but the reading now takes place
within 2 seconds, where it used to be 30s.
Thanks! Philipp Weissenbacher, this is some HUGE performance gain, I always
suspected fragmentation was an issue o
A moment ago, I did another copy of "/var/lib/dpkg/info"
This time it took 1 second to copy, whereas the first time took about 3
minutes.
So for me, I conclude that the cause of reading database taking 5+
seconds was fragmentation of /var/lib/dpkg/info
--
"Reading Database" takes too long
http
#12 (Phillip Weissenbacher's) solution worked for me! -
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/398870/comments/12
I don't know how much good the dpkg --merge-avail "$x" did, but making a
copy of "/var/lib/dpkg/info" to defragment it did take a few minutes to
complete, and afterwards t
Philipp Weissenbacher >> unfortunately, this workaround doesn't change anything
for me...
Maybe it's because I was using aptitude full-upgrade ? I'll try with apt-get
next time ;)
--
"Reading Database" takes too long
https://bugs.launchpad.net/bugs/398870
You received this bug notification beca
On the Debian mailing-list this has been dicussed here http://www.mail-
archive.com/debian-de...@lists.debian.org/msg245661.html.
One solution that helped me a bit (just one or two seconds faster) is the
following (taken from ):
1. $ sudo su
1. % for x in /var/lib/apt/lists/*Packages;do dpkg --me
I can confirm this issue on Karmic too
--
"Reading Database" takes too long
https://bugs.launchpad.net/bugs/398870
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://list
This dpkg-related bug isn't actually what we're talking about. Sure, it
causes apt to be slower than it could be but it still doesn't explain
Karmic regression here.
--
"Reading Database" takes too long
https://bugs.launchpad.net/bugs/398870
You received this bug notification because you are a me
On my 4-year-old notebook on Hardy "Reading database" used to go fast.
Now I have Core2 Duo P8600 (2,4 GHz) and on Karmic it goes slowly with
steps 5%-sized, maybe 3 such steps per second. What takes so much time?
It was faster in the past...
On the other side, I don't get why apt in Ubuntu still
Moreover, I checked and this "reading database" goes fast even on
virtual machine run on VirtualBox if only I run older Ubuntu! What has
happened to apt?
--
"Reading Database" takes too long
https://bugs.launchpad.net/bugs/398870
You received this bug notification because you are a member of Ubun
You mean OS upgrades or package upgrades?
Still, it feels like a regression in Karmic, because I cannot recall anything
like this since I've been running Feisty on this machine.
--
"Reading Database" takes too long
https://bugs.launchpad.net/bugs/398870
You received this bug notification because
Is this just a problem for upgrades? If so, maybe it would be
sufficient to just make the commands above part of the upgrade process.
--
"Reading Database" takes too long
https://bugs.launchpad.net/bugs/398870
You received this bug notification because you are a member of Ubuntu
Bugs, which is s
** Changed in: dpkg (Debian)
Status: Unknown => New
--
"Reading Database" takes too long
https://bugs.launchpad.net/bugs/398870
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.
** Also affects: dpkg (Debian) via
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=69192
Importance: Unknown
Status: Unknown
--
"Reading Database" takes too long
https://bugs.launchpad.net/bugs/398870
You received this bug notification because you are a member of Ubuntu
Bugs, which
Thanks, Arnaud, that really helped me too!
Every time I use apt I get annoyed when I remember how much faster
pacman for Arch Linux is. I've used Arch, but don't want to go back
there -- can't something be done to speed up apt?
--
"Reading Database" takes too long
https://bugs.launchpad.net/bugs
I remembered seeing a blog entry about it some time ago...
http://antti-juhani.kaijanaho.fi/newblog/archives/521
I did the two steps mentioned there and it really made a difference for me:
$ sudo dpkg --clear-avail
$ sudo dpkg --forget-old-unavail
Hope this helps.
--
"Reading Database" takes t
This bug report http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=69192
is 9 years old, is it still not taken care of?
--
"Reading Database" takes too long
https://bugs.launchpad.net/bugs/398870
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubu
This problem is also discused in bug report #69192 on bugs.debian.org
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=69192).
** Bug watch added: Debian Bug tracker #69192
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=69192
--
"Reading Database" takes too long
https://bugs.launchpad.net/
I recently notices a significant slow down in the "reading database"
operation after updating to Jaunty. This is most probably a similar
issue, though not necessarily identical.
** Changed in: apt (Ubuntu)
Status: New => Confirmed
--
"Reading Database" takes too long
https://bugs.launchpa
** Tags added: apt
--
"Reading Database" takes too long
https://bugs.launchpad.net/bugs/398870
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/lis
32 matches
Mail list logo
