Re: /var/cache

2017-07-06 Thread Patrick O'Callaghan 
On Thu, 2017-07-06 at 11:36 +0200, Patrick Dupre wrote:
> Yes, there is good reasons,
> 
> Moving from one version to another one requires a lot of work
> after all. For example, I have to recompile my own codes.

I think you misunderstood what I said. I'm suggesting you *not* change
versions until F26 is released (soon) which will save you effort in the
long run.

[Please don't top-post on this list]

poc
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: /var/cache

2017-07-06 Thread Patrick Dupre 
Yes, there is good reasons,

Moving from one version to another one requires a lot of work
after all. For example, I have to recompile my own codes.

===
 Patrick DUPRÉ | | email: pdu...@gmx.com
 Laboratoire de Physico-Chimie de l'Atmosphère | |
 Université du Littoral-Côte d'Opale   | |
 Tel.  (33)-(0)3 28 23 76 12   | | Fax: 03 28 65 82 44
 189A, avenue Maurice Schumann | | 59140 Dunkerque, France
===


> Sent: Thursday, July 06, 2017 at 11:10 AM
> From: "Patrick O'Callaghan" <pocallag...@gmail.com>
> To: users@lists.fedoraproject.org
> Subject: Re: /var/cache
>
> On Thu, 2017-07-06 at 01:57 +0200, Patrick Dupre wrote:
> > Sorry, I am using fedora 24. I will move to fedora 26 ASAP.
> 
> F26 has not been released yet. There is no reason not to keep using F24
> until that happens.
> 
> poc
> ___
> users mailing list -- users@lists.fedoraproject.org
> To unsubscribe send an email to users-le...@lists.fedoraproject.org
>
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: /var/cache

2017-07-06 Thread Patrick O'Callaghan 
On Thu, 2017-07-06 at 01:57 +0200, Patrick Dupre wrote:
> Sorry, I am using fedora 24. I will move to fedora 26 ASAP.

F26 has not been released yet. There is no reason not to keep using F24
until that happens.

poc
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: /var/cache

2017-07-05 Thread Heinz Diehl 
On 05.07.2017, Patrick Dupre wrote: 

> I have directory
> /var/log/journal which seems large:
[]

Just delete all under /var/cache and reboot.

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: /var/cache

2017-07-05 Thread Samuel Sieb 

On 07/05/2017 01:16 AM, Patrick Dupre wrote:

I have directory
/var/log/journal which seems large:
1646960


I will assume that you are using "du" and these numbers are in KB.  I 
recommend using the "-h" parameter to du which gives you nice "human 
readable" numbers.


1.6GB for the journal doesn't seem that bad.  You can change the 
journald settings if you want it to keep less info.



105988  /var/cache/yum/x86_64/21/fedora/gen


Anything in /var/cache/yum should be deleted, at least if it's for 
versions less than you are currently running.  It's possible that 
PackageKit stores some data in there, but I'm not sure.



113170  
/var/cache/mock/fedora-24-x86_64/dnf_cache/updates-c4f1c95f64c2b794/packages


Looks like you've run "mock" at some point.  Feel free to remove the cache.


126424  /var/cache/system-upgrade/updates/gen


This is an old upgrade directory that's not used now.


340198  /var/cache/dnf


You'll want to keep this, otherwise the next time you run dnf, it will 
just download all the metadata again and you'll have the same usage.



10930952/var/cache/PackageKit


This is where most of the space is wasted.  PackageKit has an issue 
where it doesn't delete old packages that were downloaded, but not 
installed.  Delete this.  I don't use PackageKit, so I mask the service 
as well, but that's up you.

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: /var/cache

2017-07-05 Thread Jon LaBadie 
On Thu, Jul 06, 2017 at 01:53:29AM +0200, Patrick Dupre wrote:
> Why do you say that it is not a a multiple of 4k?
> dumpe2fs provides:
> Block size:   4096
> 
> At least 1646960 / 4 = 411740

Duh, 4 is not 4096.  1646960 / 4096 is 402.0898 (approximately).

> 
> du seems providing the size in k
> du /var/log/journal
> 1646956   /var/log/journal/f14e53f3162847d4ae17fd1ca988e33c
> 1646960   /var/log/journal

And what does du have to do with the size of a directory
that normally is obtained with "ls -ld".

> ls -i /var/log/journal
> 1117919 f14e53f3162847d4ae17fd1ca988e33c
> 

Another, what does the inode number of a file under 'journal'
have to do with the size of journal?  Or for that matter,
the size of the file under journal?

> Is there something wrong?
> 

I suspect you feel the 41 directories you listed contain
lots of big files, possibly wasting a lot of space.  That
is a different topic than the one you asked.  It would
have helped if you had shown how you obtained the numbers
you posted, i.e. what commands were used.  I'm now guessing
it was something like "du -s ".

-- 
Jon H. LaBadie  jo...@jgcomp.com
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: /var/cache

2017-07-05 Thread Rick Stevens 
On 07/05/2017 04:53 PM, Patrick Dupre wrote:
> Why do you say that it is not a a multiple of 4k?
> dumpe2fs provides:
> Block size:   4096
> 
> At least 1646960 / 4 = 411740
> 
> du seems providing the size in k
> du /var/log/journal
> 1646956   /var/log/journal/f14e53f3162847d4ae17fd1ca988e33c
> 1646960   /var/log/journal
> ls -i /var/log/journal
> 1117919 f14e53f3162847d4ae17fd1ca988e33c
> 
> Is there something wrong?

Why are you trying to compare "du"'s output (a file's allocated disk
size) and "ls -i" (index of files first inode inode)? They aren't
measuring the same thing.

Unless overridden by an argument, "du" uses 1kibibyte (1024-byte)
blocks. You can set environment variables to change this default. It
checks for environment variables in this order:

DU_BLOCK_SIZE
BLOCK_SIZE
BLOCKSIZE

So set those to whatever you wish. With none of those set, 1K is the
default unless the environment variable POSIXLY_CORRECT is set,
where the default display would be in 512-byte chunks. This is all
in the man page.

The allocation block size is dependent on how the filesystem was set up.
By default, the ext[2|3|4] filesystems use a block size that's
determined heuristically from the underlying device (partition) size and
default inode counts. It will choose 1024-, 2048- or 4096-byte blocks.
For most uses and with modern big-horking disks (yes, a highly technical
term), that usually comes out to 4K. You can change it as you see fit
but generally the default is "good enough".

>> Sent: Wednesday, July 05, 2017 at 10:44 PM
>> From: "Jon LaBadie" <jo...@jgcomp.com>
>> To: users@lists.fedoraproject.org
>> Subject: Re: /var/cache
>>
>> On Wed, Jul 05, 2017 at 10:16:34AM +0200, Patrick Dupre wrote:
>>> Hello,
>>>
>>> I have directory
>>> /var/log/journal which seems large:
>>> 1646960
>>>
>>
>> What type of file system are you using?  ext? or xfs or ??
>> I ask as ext expands its directories in 4K chunks and the
>> sizes you give above and below are not 4K multiples.
>>
>> Are you sure those are not inode numbers (ls -i)?
>>
>> If they are sizes, the total size of those 40+ directories
>> is just 61MB, about 0.5% of a small, 10GB file system.
>> It may not be worth worrying about recovering the space.
>>
>> On some file systems directories, once expanded, never
>> contract.  In that case, the "cure" is to create a new
>> temporary directory (eg. /var.new).  Set the ownership
>> and permissions of /var.new to match /var (don't forget
>> SELinux and extended attribute properties).  Move the
>> data to the new directory (mv /var/* /var.new).  Don't
>> forget any "dot" files/directories. Rename /var to
>> /var.old, rename /var.new to /var.
>>
>> When satisfied, repeat 40 times for the large
>> subdirectories and remove the empty old directories.
>>
>> This is best done from a boot off of external media and
>> mounting the hard disk filesystems under the portable
>> medium.  Often /a is a directory provided for this.
>>
>> Jon
>>
>>> but it is even worst for /var/cache: 14338744
>>> I gives the largest sub directories:
>>>
>>> 100602  /var/cache/PackageKit/hawkey
>>> 104278  /var/cache/PackageKit/25/hawkey
>>> 105988  /var/cache/yum/x86_64/21/fedora/gen
>>> 112622  /var/cache/yum/x86_64/22/fedora/gen
>> ...
>>> 6548048 /var/cache/PackageKit/24/metadata/updates
>>> 7287012 /var/cache/PackageKit/24/metadata
>>> 7424876 /var/cache/PackageKit/24
>>> 10930952/var/cache/PackageKit
>>>
>>>
>>> How can I clean this?
>>>
>>> Thank.
>>>
>>> ===
>>>  Patrick DUPRÉ | | email: pdu...@gmx.com
>>>  Laboratoire de Physico-Chimie de l'Atmosphère | |
>>>  Université du Littoral-Côte d'Opale   | |
>>>  Tel.  (33)-(0)3 28 23 76 12   | | Fax: 03 28 65 82 44
>>>  189A, avenue Maurice Schumann | | 59140 Dunkerque, France
>>> ===
>>> ___
>>> users mailing list -- users@lists.fedoraproject.org
>>> To unsubscribe send an email to users-le...@lists.fedoraproject.org
>>>>> End of included message <<<
>>
>> -- 
>> Jon H. LaBadie  jo..

Re: /var/cache

2017-07-05 Thread Patrick Dupre 
Sorry, I am using fedora 24. I will move to fedora 26 ASAP.

-rw-r-+ 1 root systemd-journal  83886080 Jul  6 01:55 
/var/log/journal/f70316db1f884a5884466d17111bd615/system.journal
-rw-r-+ 1 root systemd-journal  16777216 Jul  6 01:54 
/var/log/journal/f70316db1f884a5884466d17111bd615/user-1000.journal

===
 Patrick DUPRÉ | | email: pdu...@gmx.com
 Laboratoire de Physico-Chimie de l'Atmosphère | |
 Université du Littoral-Côte d'Opale   | |
 Tel.  (33)-(0)3 28 23 76 12   | | Fax: 03 28 65 82 44
 189A, avenue Maurice Schumann | | 59140 Dunkerque, France
===


> Sent: Wednesday, July 05, 2017 at 10:43 PM
> From: "  sixpack13" <sixpac...@fedoraproject.org>
> To: users@lists.fedoraproject.org
> Subject: Re: /var/cache
>
> I assume
> - that you don't use Fedora elder than 25 any more'
> - you don't need aged log messages any more
> - PackageKit re-creates it's directory under /var/cache during each run as 
> dnf does
> 
> then:
> 
>  sudo rm -rf /var/log/journal/*/*;
> 
>  sudo systemctl kill --signal=SIGUSR2 systemd-journald;
> 
>  sudo rm -rf /var/cache/{dnf,mock,yum,system-upgrade,PackageKit};
> ___
> users mailing list -- users@lists.fedoraproject.org
> To unsubscribe send an email to users-le...@lists.fedoraproject.org
>
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: /var/cache

2017-07-05 Thread Patrick Dupre 
Why do you say that it is not a a multiple of 4k?
dumpe2fs provides:
Block size:   4096

At least 1646960 / 4 = 411740

du seems providing the size in k
du /var/log/journal
1646956 /var/log/journal/f14e53f3162847d4ae17fd1ca988e33c
1646960 /var/log/journal
ls -i /var/log/journal
1117919 f14e53f3162847d4ae17fd1ca988e33c

Is there something wrong?

Thank.

===
 Patrick DUPRÉ | | email: pdu...@gmx.com
 Laboratoire de Physico-Chimie de l'Atmosphère | |
 Université du Littoral-Côte d'Opale   | |
 Tel.  (33)-(0)3 28 23 76 12   | | Fax: 03 28 65 82 44
 189A, avenue Maurice Schumann | | 59140 Dunkerque, France
===


> Sent: Wednesday, July 05, 2017 at 10:44 PM
> From: "Jon LaBadie" <jo...@jgcomp.com>
> To: users@lists.fedoraproject.org
> Subject: Re: /var/cache
>
> On Wed, Jul 05, 2017 at 10:16:34AM +0200, Patrick Dupre wrote:
> > Hello,
> > 
> > I have directory
> > /var/log/journal which seems large:
> > 1646960
> > 
> 
> What type of file system are you using?  ext? or xfs or ??
> I ask as ext expands its directories in 4K chunks and the
> sizes you give above and below are not 4K multiples.
> 
> Are you sure those are not inode numbers (ls -i)?
> 
> If they are sizes, the total size of those 40+ directories
> is just 61MB, about 0.5% of a small, 10GB file system.
> It may not be worth worrying about recovering the space.
> 
> On some file systems directories, once expanded, never
> contract.  In that case, the "cure" is to create a new
> temporary directory (eg. /var.new).  Set the ownership
> and permissions of /var.new to match /var (don't forget
> SELinux and extended attribute properties).  Move the
> data to the new directory (mv /var/* /var.new).  Don't
> forget any "dot" files/directories. Rename /var to
> /var.old, rename /var.new to /var.
> 
> When satisfied, repeat 40 times for the large
> subdirectories and remove the empty old directories.
> 
> This is best done from a boot off of external media and
> mounting the hard disk filesystems under the portable
> medium.  Often /a is a directory provided for this.
> 
> Jon
> 
> > but it is even worst for /var/cache: 14338744
> > I gives the largest sub directories:
> > 
> > 100602  /var/cache/PackageKit/hawkey
> > 104278  /var/cache/PackageKit/25/hawkey
> > 105988  /var/cache/yum/x86_64/21/fedora/gen
> > 112622  /var/cache/yum/x86_64/22/fedora/gen
> ...
> > 6548048 /var/cache/PackageKit/24/metadata/updates
> > 7287012 /var/cache/PackageKit/24/metadata
> > 7424876 /var/cache/PackageKit/24
> > 10930952/var/cache/PackageKit
> > 
> > 
> > How can I clean this?
> > 
> > Thank.
> > 
> > ===
> >  Patrick DUPRÉ | | email: pdu...@gmx.com
> >  Laboratoire de Physico-Chimie de l'Atmosphère | |
> >  Université du Littoral-Côte d'Opale   | |
> >  Tel.  (33)-(0)3 28 23 76 12   | | Fax: 03 28 65 82 44
> >  189A, avenue Maurice Schumann | | 59140 Dunkerque, France
> > ===
> > ___
> > users mailing list -- users@lists.fedoraproject.org
> > To unsubscribe send an email to users-le...@lists.fedoraproject.org
> >>> End of included message <<<
> 
> -- 
> Jon H. LaBadie  jo...@jgcomp.com
> ___
> users mailing list -- users@lists.fedoraproject.org
> To unsubscribe send an email to users-le...@lists.fedoraproject.org
>
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: /var/cache

2017-07-05 Thread sixpack13 
If I understand this command correct: it deletes 
/var/cache/{cups,ibus,libvirt,man}/* too ... 
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: /var/cache

2017-07-05 Thread Jon LaBadie 
On Wed, Jul 05, 2017 at 10:16:34AM +0200, Patrick Dupre wrote:
> Hello,
> 
> I have directory
> /var/log/journal which seems large:
> 1646960
> 

What type of file system are you using?  ext? or xfs or ??
I ask as ext expands its directories in 4K chunks and the
sizes you give above and below are not 4K multiples.

Are you sure those are not inode numbers (ls -i)?

If they are sizes, the total size of those 40+ directories
is just 61MB, about 0.5% of a small, 10GB file system.
It may not be worth worrying about recovering the space.

On some file systems directories, once expanded, never
contract.  In that case, the "cure" is to create a new
temporary directory (eg. /var.new).  Set the ownership
and permissions of /var.new to match /var (don't forget
SELinux and extended attribute properties).  Move the
data to the new directory (mv /var/* /var.new).  Don't
forget any "dot" files/directories. Rename /var to
/var.old, rename /var.new to /var.

When satisfied, repeat 40 times for the large
subdirectories and remove the empty old directories.

This is best done from a boot off of external media and
mounting the hard disk filesystems under the portable
medium.  Often /a is a directory provided for this.

Jon

> but it is even worst for /var/cache: 14338744
> I gives the largest sub directories:
> 
> 100602    /var/cache/PackageKit/hawkey
> 104278    /var/cache/PackageKit/25/hawkey
> 105988    /var/cache/yum/x86_64/21/fedora/gen
> 112622    /var/cache/yum/x86_64/22/fedora/gen
...
> 6548048   /var/cache/PackageKit/24/metadata/updates
> 7287012   /var/cache/PackageKit/24/metadata
> 7424876   /var/cache/PackageKit/24
> 10930952  /var/cache/PackageKit
> 
> 
> How can I clean this?
> 
> Thank.
> 
> ===
>  Patrick DUPRÉ | | email: pdu...@gmx.com
>  Laboratoire de Physico-Chimie de l'Atmosphère | |
>  Université du Littoral-Côte d'Opale   | |
>  Tel.  (33)-(0)3 28 23 76 12   | | Fax: 03 28 65 82 44
>  189A, avenue Maurice Schumann | | 59140 Dunkerque, France
> ===
> ___
> users mailing list -- users@lists.fedoraproject.org
> To unsubscribe send an email to users-le...@lists.fedoraproject.org
>>> End of included message <<<

-- 
Jon H. LaBadie  jo...@jgcomp.com
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: /var/cache

2017-07-05 Thread sixpack13 
I assume
- that you don't use Fedora elder than 25 any more'
- you don't need aged log messages any more
- PackageKit re-creates it's directory under /var/cache during each run as dnf 
does

then:

 sudo rm -rf /var/log/journal/*/*;

 sudo systemctl kill --signal=SIGUSR2 systemd-journald;

 sudo rm -rf /var/cache/{dnf,mock,yum,system-upgrade,PackageKit};
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: /var/cache

2017-07-05 Thread Gordon Messmer 

On 07/05/2017 01:16 AM, Patrick Dupre wrote:

How can I clean this?



rpm -qf /var/cache/*/* | grep 'is not owned' | awk '{print $2}' | xargs 
rm -rf


___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: /var/cache

2017-07-05 Thread Ralf Corsepius 

On 07/05/2017 10:16 AM, Patrick Dupre wrote:


but it is even worst for /var/cache: 14338744
I gives the largest sub directories:



How can I clean this?


Files under /var/cache are supposed to be automatically regenerated by 
the programs which create them (Hence the name "cache").


I.e. in theory, you can erase everything under /var/cache
whenever you want. If this breaks something, this would qualify as a bug.

Ralf
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

/var/cache

2017-07-05 Thread Patrick Dupre 
Hello,

I have directory
/var/log/journal which seems large:
1646960

but it is even worst for /var/cache: 14338744
I gives the largest sub directories:

100602  /var/cache/PackageKit/hawkey
104278  /var/cache/PackageKit/25/hawkey
105988  /var/cache/yum/x86_64/21/fedora/gen
112622  /var/cache/yum/x86_64/22/fedora/gen
113170  
/var/cache/mock/fedora-24-x86_64/dnf_cache/updates-c4f1c95f64c2b794/packages
123804  /var/cache/yum/x86_64/21/fedora
125536  /var/cache/yum/x86_64/24/fedora/gen
126424  /var/cache/system-upgrade/updates/gen
131320  /var/cache/yum/x86_64/22/fedora
134702  /var/cache/mock/fedora-24-x86_64/dnf_cache/updates-c4f1c95f64c2b794
137862  /var/cache/PackageKit/24/hawkey
146778  /var/cache/system-upgrade/updates
150620  /var/cache/yum/x86_64/24/fedora
178804  /var/cache/mock/fedora-24-x86_64/root_cache
189314  /var/cache/yum/x86_64/22
191956  /var/cache/yum/x86_64/21
196922  /var/cache/PackageKit/25
215362  /var/cache/yum/x86_64/24
223472  /var/cache/system-upgrade/default-installrepo/packages
242710  /var/cache/system-upgrade/default-installrepo
278874  /var/cache/mock/fedora-24-x86_64/dnf_cache
313804  /var/cache/system-upgrade/fedora/gen
340198  /var/cache/dnf
457680  /var/cache/mock/fedora-24-x86_64
457682  /var/cache/mock
557502  /var/cache/PackageKit/24/metadata/virtualbox/packages
557636  /var/cache/PackageKit/24/metadata/virtualbox
596634  /var/cache/yum/x86_64
596636  /var/cache/yum
1133676 /var/cache/system-upgrade/fedora/packages
1495078 /var/cache/system-upgrade/fedora
1955442 /var/cache/system-upgrade
3067536 /var/cache/PackageKit/metadata/updates/packages
3090236 /var/cache/PackageKit/metadata/updates
3208270 /var/cache/PackageKit/metadata
6524434 /var/cache/PackageKit/24/metadata/updates/packages
6548048 /var/cache/PackageKit/24/metadata/updates
7287012 /var/cache/PackageKit/24/metadata
7424876 /var/cache/PackageKit/24
10930952/var/cache/PackageKit


How can I clean this?

Thank.

===
 Patrick DUPRÉ | | email: pdu...@gmx.com
 Laboratoire de Physico-Chimie de l'Atmosphère | |
 Université du Littoral-Côte d'Opale   | |
 Tel.  (33)-(0)3 28 23 76 12   | | Fax: 03 28 65 82 44
 189A, avenue Maurice Schumann | | 59140 Dunkerque, France
===
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: 3.3 gigs in /var/cache/PackageKit/24/metadata after dnf system-upgrade

2016-12-29 Thread Chris Murphy 
On Tue, Dec 27, 2016 at 7:22 AM, Dario Lesca <d.le...@solinos.it> wrote:

>
> Il giorno mar, 27/12/2016 alle 14.32 +0100, Dario Lesca ha scritto:
>
> Il giorno lun, 26/12/2016 alle 20.58 +, Schlaegel ha scritto:
>
>
> What would be a good course of action?
>
>
> After install a new Fedora 24, now 25, I do this step.
>
> sudo systemctl mask dnf-makecache dnf-makecache.timer packagekit
> packagekit-offline-update
> sudo systemctl stop dnf-makecache dnf-makecache.timer packagekit
> packagekit-offline-update
>
> rm -rf /var/cache/PackageKit/*
>
> And all still work.
>
>
> Another way to avoid that PackageKit download tons of package, which it
> will never use and never remove, is:
>
> sudo dnf remove PackageKit
> rm -rf /var/cache/PackageKit/*
>
> This remove also gnome-software, then, if you want a graphical software
> installer you can:
>
> sudo dnf install yumex-dnf
>
>
This is bad advice. Breaking gnome-software just to avoid updates from
being downloaded is the wrong hammer. Instead use,

[chris@f25h ~]$ gsettings set org.gnome.software download-updates false



-- 
Chris Murphy
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: 3.3 gigs in /var/cache/PackageKit/24/metadata after dnf system-upgrade

2016-12-28 Thread Tim 
Dario Lesca:
>> Why not use the same cache of dnf?

Matthew Miller:
> That is work in progress. Both systems use the cache a little
> differently and grew up independently, so there is some work to align
> them. 

Separate caching for the metadata, but pooled caching (and automated
purging control) for the massively huge packages cache, would be a good
interim solution.

-- 
[tim@localhost ~]$ uname -rsvp
Linux 3.9.10-100.fc17.x86_64 #1 SMP Sun Jul 14 01:31:27 UTC 2013 x86_64

Boilerplate:  All mail to my mailbox is automatically deleted, there is
no point trying to privately email me, I only get to see the messages
posted to the mailing list.

less is more when playing with your cat...


___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: 3.3 gigs in /var/cache/PackageKit/24/metadata after dnf system-upgrade

2016-12-28 Thread Matthew Miller 
On Wed, Dec 28, 2016 at 03:21:06PM +0100, Dario Lesca wrote:
> > That cache _is_ the packagekit database. You can remove it safely.
> Why not use the same cache of dnf?

That is work in progress. Both systems use the cache a little
differently and grew up independently, so there is some work to align
them. 

-- 
Matthew Miller

Fedora Project Leader
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: 3.3 gigs in /var/cache/PackageKit/24/metadata after dnf system-upgrade

2016-12-28 Thread Dario Lesca 
Il giorno mar, 27/12/2016 alle 11.42 -0500, Matthew Miller ha scritto:
> That cache _is_ the packagekit database. You can remove it safely.

Why not use the same cache of dnf?

In this way when someone use dnf install something the cache will be
removed.

IMHO Two cache of same (BIG!) things is not a good solution.

-- 
Dario Lesca
(inviato dal mio Linux Fedora 24 Workstation)
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: 3.3 gigs in /var/cache/PackageKit/24/metadata after dnf system-upgrade

2016-12-27 Thread Matthew Miller 
On Mon, Dec 26, 2016 at 08:58:46PM +, Schlaegel wrote:
> What would be a good course of action?
> I'm reluctant to use root to just delete the files, assuming that they are
> in some PackageKit database somewhere.

That cache _is_ the packagekit database. You can remove it safely.

> Is there another step that should be added to the DNF system upgrade
> document to have this directory cleaned?

Possibly, yes.


-- 
Matthew Miller

Fedora Project Leader
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: 3.3 gigs in /var/cache/PackageKit/24/metadata after dnf system-upgrade

2016-12-27 Thread Dario Lesca 
Il giorno mar, 27/12/2016 alle 14.32 +0100, Dario Lesca ha scritto:
> Il giorno lun, 26/12/2016 alle 20.58 +, Schlaegel ha scritto:
> > What would be a good course of action?
> 
> After install a new Fedora 24, now 25, I do this step.
> 
> sudo systemctl mask dnf-makecache dnf-makecache.timer packagekit
> packagekit-offline-update 
> sudo systemctl stop dnf-makecache dnf-makecache.timer packagekit
> packagekit-offline-update 
> 
> 
> rm -rf /var/cache/PackageKit/*
> 
> 
> 
> And all still work.

Another way to avoid that PackageKit download tons of package, which it
will never use and never remove, is:

sudo dnf  remove PackageKit
rm -rf /var/cache/PackageKit/*

This remove also gnome-software, then, if you want a graphical software
installer you can:

sudo dnf install yumex-dnf

bye

-- 
Dario Lesca
(inviato dal mio Linux Fedora 24 Workstation)___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: 3.3 gigs in /var/cache/PackageKit/24/metadata after dnf system-upgrade

2016-12-27 Thread Dario Lesca 
Il giorno lun, 26/12/2016 alle 20.58 +, Schlaegel ha scritto:
> What would be a good course of action?

After install a new Fedora 24, now 25, I do this step.

sudo systemctl mask dnf-makecache dnf-makecache.timer packagekit
packagekit-offline-update 
sudo systemctl stop dnf-makecache dnf-makecache.timer packagekit
packagekit-offline-update 


rm -rf /var/cache/PackageKit/*


And all still work.

-- 
Dario Lesca
(inviato dal mio Linux Fedora 24 Workstation)___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: 3.3 gigs in /var/cache/PackageKit/24/metadata after dnf system-upgrade

2016-12-26 Thread Samuel Sieb 

On 12/26/2016 04:21 PM, Patrick O'Callaghan wrote:

On Mon, 2016-12-26 at 20:58 +, Schlaegel wrote:

After a month of updates, I started seeing warnings about the size of the
var partition. Somehow /var/cache/PackageKit/24/metadata is still there and
very large. I tried `sudo pkcon refresh force -c -1` but I still have 3.3
gigs in PackageKit's Fedora 24 directory.

What would be a good course of action?
I'm reluctant to use root to just delete the files, assuming that they are
in some PackageKit database somewhere.
Is there another step that should be added to the DNF system upgrade
document to have this directory cleaned?


dnf clean packages

For other options: 'man dnf' and look under 'clean'.

That won't have any effect on the packagekit cache.  Packagekit doesn't 
clean up old packages that it has downloaded but not installed.


Deleting /var/cache/PackageKit will have no bad effect other than 
packagekit will have to download the repo metadata again.

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: 3.3 gigs in /var/cache/PackageKit/24/metadata after dnf system-upgrade

2016-12-26 Thread Patrick O'Callaghan 
On Mon, 2016-12-26 at 20:58 +, Schlaegel wrote:
> I followed the instructions in the Fedora 25 Installation Guide and the DNF
> system upgrade document, using `sudo dnf system-upgrade download --refresh
> --releasever=25` and then the `sudo dnf system-upgrade reboot` command.
> 
> I then worked through an issue with the stock repositories and packages
> causing my Nvidia graphics to lock up, and I eventually had a working
> system.
> 
> After a month of updates, I started seeing warnings about the size of the
> var partition. Somehow /var/cache/PackageKit/24/metadata is still there and
> very large. I tried `sudo pkcon refresh force -c -1` but I still have 3.3
> gigs in PackageKit's Fedora 24 directory.
> 
> What would be a good course of action?
> I'm reluctant to use root to just delete the files, assuming that they are
> in some PackageKit database somewhere.
> Is there another step that should be added to the DNF system upgrade
> document to have this directory cleaned?

dnf clean packages

For other options: 'man dnf' and look under 'clean'.

poc
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

3.3 gigs in /var/cache/PackageKit/24/metadata after dnf system-upgrade

2016-12-26 Thread Schlaegel 
I followed the instructions in the Fedora 25 Installation Guide and the DNF
system upgrade document, using `sudo dnf system-upgrade download --refresh
--releasever=25` and then the `sudo dnf system-upgrade reboot` command.

I then worked through an issue with the stock repositories and packages
causing my Nvidia graphics to lock up, and I eventually had a working
system.

After a month of updates, I started seeing warnings about the size of the
var partition. Somehow /var/cache/PackageKit/24/metadata is still there and
very large. I tried `sudo pkcon refresh force -c -1` but I still have 3.3
gigs in PackageKit's Fedora 24 directory.

What would be a good course of action?
I'm reluctant to use root to just delete the files, assuming that they are
in some PackageKit database somewhere.
Is there another step that should be added to the DNF system upgrade
document to have this directory cleaned?
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

/var/cache/PackageKit/metadata gets very big

2016-03-19 Thread D. Hugh Redelmeier 
On my Fedora 23 systems, /var/cache/PackageKit/metadata/updates/packages 
is full of .rpm files.  For example, 2.7G on my desktop.

/var/cache/PackageKit/metadata/fedora/packages has some too.

"sudo dnf clean packages" doesn't seem to change this.  What does it 
change?

What is the purpose of this directory of RPMs?

Why is it considered metadata?

The more obvious place would be /var/cache/PackageKit/downloads/
Why isn't this used?

Is there a way of transplanting the RPMs to another system so that
downloading could be avoided?  I have half a dozen fedora systems and
it seems a waste to download each update for each system.

What is the proper way of deleting these RPMs to free up the space?  I
ask because on some machines (but not all) the space is burdensome.
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: /var/cache/PackageKit/metadata gets very big

2016-03-19 Thread D. Hugh Redelmeier 
| From: stan <stanl-fedorau...@vfemail.net>

Thanks for your useful response.  But there are still things that
puzzle/annoy me.

| On Thu, 17 Mar 2016 10:22:36 -0400 (EDT)
| "D. Hugh Redelmeier" <h...@mimosa.com> wrote:
| 
| > On my Fedora 23
| > systems, /var/cache/PackageKit/metadata/updates/packages is full
| > of .rpm files.  For example, 2.7G on my desktop.
| > /var/cache/PackageKit/metadata/fedora/packages has some too.

| > "sudo dnf clean packages" doesn't seem to change this.  What does it 
| > change?
| 
| The dnf package storage is cleared.  PackageKit is independent of
| dnf.

Isn't dnf the user interface to PackageKit?

"man PackageKit" points to pkmon and pkcon, both with the identical
description: "PackageKit console client".  One of those is wrong.  In
any case, those commands don't seem to have knobs to adjust PackageKit
hoarding instincts.

| > What is the purpose of this directory of RPMs?
| 
| Saved in case of problems.

What kind of problems?

Perhaps they are used to reduce the size of download (so only a
difference needs to be transferred).

In any case, lots of the saved RPMs are obsoleted by other saved RPMs.
That seems like a waste.  So I deleted all the obsolete ones and saved
a lot of space.  I only bothered with
/var/cache/PackageKit/metadata/updates/packages
so far.  That saved me almost 2G!

Here's how I did it.  Not quite a script yet.

cd /var/cache/PackageKit/metadata/updates/packages

# create a list of installed RPM files
rpm -qa | sed -e 's/$/.rpm/' | sort >~/0installed

# create a list of hoarded files
ls >~/0saved

# create a list of files that are obsoleted
diff ~/0saved ~/0installed | sed -n -e 's/^< //p' >~/0obsolete

# Exercise for the reader: delete files list in ~/0obsolete
# This is the first step that requires root.
# Note: ~/ means something different for each user.

Before I did this, "dnf update" failed due to lack of space.  After,
it just worked.  So I guess PackageKit isn't upset by files just
disappearing from this directory.

| > Is there a way of transplanting the RPMs to another system so that
| > downloading could be avoided?
| 
| rsync them into /var/cache/dnf/[hashed directory entry]/packages/

Thanks.  That seems a little hacky so I won't bother.

| > What is the proper way of deleting these RPMs to free up the space?  I
| > ask because on some machines (but not all) the space is burdensome.
| 
| There is a setting in the file
| /etc/PackageKit/PackageKit.conf
| 
| # Keep the packages after they have been downloaded
| #KeepCache=false

Thanks.  It didn't seem to affect old files (it didn't buy back space
that I needed for "dnf update"). I didn't try to debug this.  Perhaps
because PackageKit is a daemon and I didn't tap it on the shoulder to
reload the config.
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: /var/cache/PackageKit/metadata gets very big

2016-03-19 Thread stan 
On Thu, 17 Mar 2016 10:22:36 -0400 (EDT)
"D. Hugh Redelmeier" <h...@mimosa.com> wrote:

> On my Fedora 23
> systems, /var/cache/PackageKit/metadata/updates/packages is full
> of .rpm files.  For example, 2.7G on my desktop.
> 
> /var/cache/PackageKit/metadata/fedora/packages has some too.
> 
> "sudo dnf clean packages" doesn't seem to change this.  What does it 
> change?

The dnf package storage is cleared.  PackageKit is independent of
dnf.

> 
> What is the purpose of this directory of RPMs?

Saved in case of problems.

> Why is it considered metadata?
> 
> The more obvious place would be /var/cache/PackageKit/downloads/
> Why isn't this used?

You'd have to ask the PackageKit devs.

> 
> Is there a way of transplanting the RPMs to another system so that
> downloading could be avoided?  I have half a dozen fedora systems and
> it seems a waste to download each update for each system.

rsync them into /var/cache/dnf/[hashed directory entry]/packages/ on the
other systems.  Then run dnf upgrade.  It will reuse the local
packages.  You might have to set dnf to keep rpms in /etc/dnf/dnf.conf,
and manually run dnf clean packages after the update.

> What is the proper way of deleting these RPMs to free up the space?  I
> ask because on some machines (but not all) the space is burdensome.

There is a setting in the file
/etc/PackageKit/PackageKit.conf

# Keep the packages after they have been downloaded
#KeepCache=false

Remove, as root, the hash mark on this configuration option, and
packages won't be kept.
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: /var/cache/PackageKit/metadata gets very big

2016-03-18 Thread stan 
On Fri, 18 Mar 2016 17:14:29 -0400 (EDT)
"D. Hugh Redelmeier" <h...@mimosa.com> wrote:


> Isn't dnf the user interface to PackageKit?

I always disable PackageKit, so I'm probably not the best person to
answer this.  But, my understanding is that PackageKit operates
independently of dnf.  That when PackageKit updates the system, it
doesn't invoke dnf, but interacts with rpm directly.  I might be wrong.

pkmon is a console debug tool kit for PackageKit, pkcon is just cli
interface without any debug capability.

> What kind of problems?
> 
> Perhaps they are used to reduce the size of download (so only a
> difference needs to be transferred).

No, that's drpm.  If you have a flaky connection, and your update
crashes, if this isn't turned on, all the rpms go away, and your
download starts over from the beginning.

And it allows someone to do what you were thinking of doing, updating a
single box, and then re-using all those RPMs for othep systems.
Especially worthwhile on slow connections, or where people get charged
for usage.

> Here's how I did it.  Not quite a script yet.
> 
>   cd /var/cache/PackageKit/metadata/updates/packages
> 
>   # create a list of installed RPM files
>   rpm -qa | sed -e 's/$/.rpm/' | sort >~/0installed
> 
>   # create a list of hoarded files
>   ls >~/0saved
> 
>   # create a list of files that are obsoleted
>   diff ~/0saved ~/0installed | sed -n -e 's/^< //p' >~/0obsolete
> 
>   # Exercise for the reader: delete files list in ~/0obsolete
>   # This is the first step that requires root.
>   # Note: ~/ means something different for each user.

I use a python program I wrote, that uses regexes to compare the
filenames, and deletes the earlier version.  It's a hack, but it
doesn't have to be perfect.  If it is +/- 5%, no big deal.  And it
seems to be a lot better than that, maybe .5% or less.
 
> Before I did this, "dnf update" failed due to lack of space.  After,
> it just worked.  So I guess PackageKit isn't upset by files just
> disappearing from this directory.

From this, it seems that PackageKit and dnf are sharing an rpm package
directory.
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: /var/cache/PackageKit/metadata gets very big

2016-03-18 Thread John Pilkington 

On 18/03/16 22:15, stan wrote:

On Fri, 18 Mar 2016 17:14:29 -0400 (EDT)
"D. Hugh Redelmeier" <h...@mimosa.com> wrote:



Isn't dnf the user interface to PackageKit?


I always disable PackageKit, so I'm probably not the best person to
answer this.  But, my understanding is that PackageKit operates
independently of dnf.  That when PackageKit updates the system, it
doesn't invoke dnf, but interacts with rpm directly.  I might be wrong.

pkmon is a console debug tool kit for PackageKit, pkcon is just cli
interface without any debug capability.


What kind of problems?

Perhaps they are used to reduce the size of download (so only a
difference needs to be transferred).


No, that's drpm.  If you have a flaky connection, and your update
crashes, if this isn't turned on, all the rpms go away, and your
download starts over from the beginning.

And it allows someone to do what you were thinking of doing, updating a
single box, and then re-using all those RPMs for othep systems.
Especially worthwhile on slow connections, or where people get charged
for usage.


Here's how I did it.  Not quite a script yet.

    cd /var/cache/PackageKit/metadata/updates/packages

# create a list of installed RPM files
rpm -qa | sed -e 's/$/.rpm/' | sort >~/0installed

# create a list of hoarded files
ls >~/0saved

# create a list of files that are obsoleted
diff ~/0saved ~/0installed | sed -n -e 's/^< //p' >~/0obsolete

# Exercise for the reader: delete files list in ~/0obsolete
# This is the first step that requires root.
# Note: ~/ means something different for each user.


I use a python program I wrote, that uses regexes to compare the
filenames, and deletes the earlier version.  It's a hack, but it
doesn't have to be perfect.  If it is +/- 5%, no big deal.  And it
seems to be a lot better than that, maybe .5% or less.


Before I did this, "dnf update" failed due to lack of space.  After,
it just worked.  So I guess PackageKit isn't upset by files just
disappearing from this directory.


 From this, it seems that PackageKit and dnf are sharing an rpm package
directory.

Isn't this what repomanage is for? I used it years ago to clear outdated 
rpms from a local repo.   google 'repomanage  xargs'.


Now (fc23) it appears to be in

python3-dnf-plugins-extras-repomanage

John P

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: NFS Server share /var/cache/yum?

2013-03-16 Thread Bill Davidsen 

Frank Murphy wrote:

Trying to replace an NAS with a PC.

Figured I'd check before creating
Having looked at:
https://fedoraproject.org/wiki/Administration_Guide_Draft/NFS?rd=Docs/Drafts/AGBeta/NFS

How can I share on the NFS server /var/cache/yum.
so it will be available as a local(nfs) cache
to all fedora boxes\vm's
as root shares are discouraged.

Server will  have the following hd for shares /sdc 1tb raid1
(Hope I explained it clear enough, a problem of mine)

I have been doing similar for years (fc9) but what I do is create a local repo 
on the NFS server, set yum.conf to keep packages, and then upload everything I 
install or upgrade to the repo. On a regular basis I run a script that checks 
for new rpm files and runs createrepo as needed. The master repo has all the 
updates ever, for Fedora, with subdirectories for CentOS, RHEL, and ScientificLinux.


The advantage is that I can pull a package in a VM as needed, and it will get 
upload and added to the repository. I share the repository via both NFS and 
http, but fedup doesn't seem to have an obvious way to get to use local 
repositories. Looking into that is on my to-do list, haven't had time to do it.


This may give you some ideas about local repo, I found it easier to keep a repo 
of my own rather than find a clever way to export /var/cache/yum


--
Bill Davidsen david...@tmr.com
  We have more to fear from the bungling of the incompetent than from
the machinations of the wicked.  - from Slashdot
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

NFS Server share /var/cache/yum?

2013-03-15 Thread Frank Murphy 
Trying to replace an NAS with a PC.

Figured I'd check before creating
Having looked at:
https://fedoraproject.org/wiki/Administration_Guide_Draft/NFS?rd=Docs/Drafts/AGBeta/NFS

How can I share on the NFS server /var/cache/yum. 
so it will be available as a local(nfs) cache 
to all fedora boxes\vm's
as root shares are discouraged.

Server will  have the following hd for shares /sdc 1tb raid1
(Hope I explained it clear enough, a problem of mine)

-- 
Regards,
Frank
http//www.frankly3d.com
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: NFS Server share /var/cache/yum?

2013-03-15 Thread agraham 

On 03/15/2013 10:36 AM, Frank Murphy wrote:

Trying to replace an NAS with a PC.

Figured I'd check before creating
Having looked at:
https://fedoraproject.org/wiki/Administration_Guide_Draft/NFS?rd=Docs/Drafts/AGBeta/NFS

How can I share on the NFS server /var/cache/yum.
so it will be available as a local(nfs) cache
to all fedora boxes\vm's
as root shares are discouraged.

Server will  have the following hd for shares /sdc 1tb raid1
(Hope I explained it clear enough, a problem of mine)



I do this no problem, you should probably share the NFS server as 
read-only and also mount it as read-only from the VMs. This will also 
improve caching.


If you have a lot of VMs, you may consider an auto mounter.

Al.
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: /var/cache/abrt-di

2011-10-07 Thread Christoph A. 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 06/02/2011 11:23 PM, Ranjan Maitra wrote:
 Hi,
 
 Looking at my files and diskspace, I note the following:
 
 $ sudo du -sm /var/cache/*
 1961  /var/cache/abrt-di
 1 /var/cache/cups
 1 /var/cache/fontconfig
 1 /var/cache/foomatic
 1 /var/cache/hald
 1 /var/cache/jwhois
 1 /var/cache/ldconfig
 3 /var/cache/man
 1 /var/cache/mash
 1 /var/cache/PackageKit
 217   /var/cache/yum
 
 Googling on how to reduce this abrt-di beast, I came up with the
 solution that you should delete the reports in the abrt GUI tool. But
 these are all deleted for me, and I think there must be a better way to
 remove this cache? Any suggestions on how to do this cleanly?

Hi Ranjan,

did you eventually figure out how to solve your problem?
My /var/cache/abrt-di uses about 4 GB and I would also like to reduce
its size.

thanks,
Christoph

-BEGIN PGP SIGNATURE-

iEYEAREKAAYFAk6PQ18ACgkQrq+riTAIEg1r/wCfUdcq2LtIvqhs2yd80nQxfRwB
CdcAoIDsdHBeD0SbniEYsaIcLjQoFVYo
=WcVm
-END PGP SIGNATURE-
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

/var/cache/abrt-di

2011-06-02 Thread Ranjan Maitra 
Hi,

Looking at my files and diskspace, I note the following:

$ sudo du -sm /var/cache/*
1961/var/cache/abrt-di
1   /var/cache/cups
1   /var/cache/fontconfig
1   /var/cache/foomatic
1   /var/cache/hald
1   /var/cache/jwhois
1   /var/cache/ldconfig
3   /var/cache/man
1   /var/cache/mash
1   /var/cache/PackageKit
217 /var/cache/yum

Googling on how to reduce this abrt-di beast, I came up with the
solution that you should delete the reports in the abrt GUI tool. But
these are all deleted for me, and I think there must be a better way to
remove this cache? Any suggestions on how to do this cleanly?


Many thanks and best wishes,
Ranjan
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

/var/cache/yum format

2010-11-25 Thread Bill Davidsen 
I'm somewhat confused by the many things found in vcy. On some machines 
there are directories for fedora, and updates, and no architecture 
notation. On some the same data is found in i386/14 or similar, while on 
other in i686/i386/14 has the same stuff.

Is there rhyme or reason to this? And should my local repository have to 
look different to update each setup?

Pointers to a document would be useful, my local repo would save a lot 
of time.

-- 
Bill Davidsendavid...@tmr.com
   We can't solve today's problems by using the same thinking we
used in creating them. - Einstein

-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

preupgrade 12-13 and not enough disk space for /var/cache

2010-06-01 Thread Anne Possoz 
Hello,

My / partition, that contains /var, has only 800 MB available and
I will certainly need more.
I have plenty of space in another partition and would like to use
that one for downloading rpm's tu upgrade from fedora 12 to 13.

As preupgrade.cli accept -c yum-xxx.conf, I tried that option including 
cachedir=/my/var.cache.yum
but it didn't work as I got not enough space...
(Pleaso note that the size of my /boot is already 500 MB).

Question :
What is the recommended solution to use a filesystem outside
of /var for preupgrade and then upgrade?

I goggled a lot and only found this closed bug report
https://bugzilla.redhat.com/show_bug.cgi?id=505602

Anne

-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: preupgrade 12-13 and not enough disk space for /var/cache

2010-06-01 Thread Vignesh M 
Hey,

You can mount another partition to /var/cache until the update is complete ?
maybe add it to /etc/fstab as well so it will still be present when fedora
reboots to the installer.

Hope it helps

Vignesh

On Tue, Jun 1, 2010 at 6:38 PM, Anne Possoz anne.pos...@epfl.ch wrote:

 Hello,

 My / partition, that contains /var, has only 800 MB available and
 I will certainly need more.
 I have plenty of space in another partition and would like to use
 that one for downloading rpm's tu upgrade from fedora 12 to 13.

 As preupgrade.cli accept -c yum-xxx.conf, I tried that option including
 cachedir=/my/var.cache.yum
 but it didn't work as I got not enough space...
 (Pleaso note that the size of my /boot is already 500 MB).

 Question :
 What is the recommended solution to use a filesystem outside
 of /var for preupgrade and then upgrade?

 I goggled a lot and only found this closed bug report
 https://bugzilla.redhat.com/show_bug.cgi?id=505602

Anne

 --
 users mailing list
 users@lists.fedoraproject.org
 To unsubscribe or change subscription options:
 https://admin.fedoraproject.org/mailman/listinfo/users
 Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines