On 14. 1. 2014 at 23:21:15, Peter Oliver wrote:
> On Mon, 13 Jan 2014, Miroslav Suchý wrote:
> > On 01/13/2014 09:57 AM, Frank Murphy wrote:
> >> On Mon, 13 Jan 2014 09:53:53 +0100
> >>
> >> Miroslav Suchý wrote:
> >>> On 01/13/2014 08:56 AM, Frank Murphy wrote:
> to be certain you can do "d
On Mon, 13 Jan 2014, Miroslav Suchý wrote:
On 01/13/2014 09:57 AM, Frank Murphy wrote:
On Mon, 13 Jan 2014 09:53:53 +0100
Miroslav Suchý wrote:
On 01/13/2014 08:56 AM, Frank Murphy wrote:
to be certain you can do "dnf(yum) --enablerepo=* clean all"
if your intention is truly to remove all c
On Mon, 13 Jan 2014 10:16:52 -0800
Adam Williamson wrote:
> >
> > You can also "after some research"
> > modify the dnf-makecache.service file
> > to change the frequency of makecache.
>
> It's a lot cleaner to just define a metadata expiry time in the
> repository config file.
Discovered aft
On Mon, 2014-01-13 at 08:45 +, Frank Murphy wrote:
> On Sun, 12 Jan 2014 14:06:30 -0500
> "Garry T. Williams" wrote:
>
>
> >
> > sudo dnf --enablerepo=updates-testing clean expire-cache
> > sudo dnf --enablerepo=updates-testing upgrade kernel\*
> >
>
> You can also "after some res
On Mon, 13 Jan 2014 14:38:39 +0100
Miroslav Suchý wrote:
> No. This command is accepted (to my surprise). But it delete nothing.
> And just create new directory sturcture in '/var/cache/yum/x86_64/*'.
>
That does suck then
if someone with more that F20 cache needs to clean.
as Harald posted yo
On 01/13/2014 09:57 AM, Frank Murphy wrote:
> On Mon, 13 Jan 2014 09:53:53 +0100
> Miroslav Suchý wrote:
>
>> On 01/13/2014 08:56 AM, Frank Murphy wrote:
>>> to be certain you can do "dnf(yum) --enablerepo=* clean all"
>>> if your intention is truly to remove all cache.
>>
>> Not true if you ever
Am 13.01.2014 09:57, schrieb Frank Murphy:
> On Mon, 13 Jan 2014 09:53:53 +0100
> Miroslav Suchý wrote:
>
>> On 01/13/2014 08:56 AM, Frank Murphy wrote:
>>> to be certain you can do "dnf(yum) --enablerepo=* clean all"
>>> if your intention is truly to remove all cache.
>>
>> Not true if you ever
On 13/01/14 10:14, Frank Murphy wrote:
On Mon, 13 Jan 2014 09:33:09 +
Tom Hughes wrote:
You can also "after some research"
modify the dnf-makecache.service file
to change the frequency of makecache.
I don't think that will help as that service simply controls when it
considers updating -
On Mon, 13 Jan 2014 09:33:09 +
Tom Hughes wrote:
> > You can also "after some research"
> > modify the dnf-makecache.service file
> > to change the frequency of makecache.
>
> I don't think that will help as that service simply controls when it
> considers updating - the expire_metadata set
On Mon, 13 Jan 2014 09:51:27 +
Frank Murphy wrote:
> Where is this setting?
> besides metadata expire in *.repos.
> I couldn't find in on the wiki
Duh! man 8 dnf.conf,
so behaviour can be changed without running
dnf clean * && dnf update
for those that may want it,
by adding it in.
___
Re
On Mon, 13 Jan 2014 09:33:09 +
Tom Hughes wrote:
the expire_metadata setting still applies,
Where is this setting?
besides metadata expire in *.repos.
I couldn't find in on the wiki
___
Regards,
Frank
www.frankly3d.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.f
On 13/01/14 08:45, Frank Murphy wrote:
On Sun, 12 Jan 2014 14:06:30 -0500
"Garry T. Williams" wrote:
sudo dnf --enablerepo=updates-testing clean expire-cache
sudo dnf --enablerepo=updates-testing upgrade kernel\*
You can also "after some research"
modify the dnf-makecache.service f
On Mon, 13 Jan 2014 09:53:53 +0100
Miroslav Suchý wrote:
> On 01/13/2014 08:56 AM, Frank Murphy wrote:
> > to be certain you can do "dnf(yum) --enablerepo=* clean all"
> > if your intention is truly to remove all cache.
>
> Not true if you ever used --releasever option.
>
dnf --enablerepo=* --
On 01/13/2014 07:32 AM, Miroslav Suchy wrote:
>
> Let leave yum as is, but let try to redefine this behavior for dnf:
> https://bugzilla.redhat.com/show_bug.cgi?id=1052020
If you want this change please vote for this bug (by adding yourself to CC of
that bug). Otherwise it will stay as
CLOSED WO
On 01/13/2014 08:56 AM, Frank Murphy wrote:
> to be certain you can do "dnf(yum) --enablerepo=* clean all"
> if your intention is truly to remove all cache.
Not true if you ever used --releasever option.
--
Miroslav Suchy, RHCE, RHCDS
Red Hat, Software Engineer, #brno, #devexp, #fedora-buildsys
On Sun, 12 Jan 2014 14:06:30 -0500
"Garry T. Williams" wrote:
>
> sudo dnf --enablerepo=updates-testing clean expire-cache
> sudo dnf --enablerepo=updates-testing upgrade kernel\*
>
You can also "after some research"
modify the dnf-makecache.service file
to change the frequency of ma
On Mon, 13 Jan 2014 09:36:38 +0100
Alec Leamas wrote:
> If you continue reading the thread you'll see what happened (short
> story: too late fo rme)
> --alec
>
>
Refreshing my email would have helped, too early for me :(
___
Regards,
Frank
www.frankly3d.com
--
devel mailing list
devel@list
If you continue reading the thread you'll see what happened (short story:
too late fo rme)
--alec
On Mon, Jan 13, 2014 at 8:59 AM, Frank Murphy wrote:
> On Mon, 13 Jan 2014 00:43:13 +0100
> Alec Leamas wrote:
>
> > First of all, this is not, and have never been a question of disabled
> > repos
On Mon, 13 Jan 2014 00:43:13 +0100
Alec Leamas wrote:
> First of all, this is not, and have never been a question of disabled
> repos. Or should not have. "yum clean all" refers to cleaning all
> metadata, not all repos. It only operates on one single repo, be it
> implicit (the default link) or
On Mon, 13 Jan 2014 07:51:22 +0200
Ahmad Samir wrote:
> Right, I missed that bit.
> >
>
to be certain you can do "dnf(yum) --enablerepo=* clean all"
if your intention is truly to remove all cache.
___
Regards,
Frank
www.frankly3d.com
--
devel mailing list
devel@lists.fedoraproject.org
http
On 01/12/2014 11:23 PM, Alec Leamas wrote:
Well, IMHO the docs are actually quite clear on that 'all' refers to all
metadata rather than all repositories.
That said, perhaps enough people has been confused by this to make some
kind of improvement motivated.
Let leave yum as is, but let try to
On 12 January 2014 21:27, Reindl Harald wrote:
>
> Am 12.01.2014 20:24, schrieb Ahmad Samir:
>> On 12 January 2014 21:06, Garry T. Williams wrote:
>>> On 1-12-14 18:18:00 M A Young wrote:
On Sun, 12 Jan 2014, Garry T. Williams wrote:
> On 1-9-14 15:43:50 Ales Kozumplik wrote:
>> New
Yes, sorry, forget what I wrote. I messed up mock with yum, that's why.
It's too late for me to chime in here. Sorry for the noise.
On Mon, Jan 13, 2014 at 12:49 AM, Reindl Harald wrote:
>
>
> Am 13.01.2014 00:43, schrieb Alec Leamas:
> > First of all, this is not, and have never been a question
Am 13.01.2014 00:43, schrieb Alec Leamas:
> First of all, this is not, and have never been a question of disabled repos.
> Or should not have. "yum clean all"
> refers to cleaning all metadata, not all repos. It only operates on one
> single repo, be it implicit (the default
> link) or an expli
First of all, this is not, and have never been a question of disabled
repos. Or should not have. "yum clean all" refers to cleaning all metadata,
not all repos. It only operates on one single repo, be it implicit (the
default link) or an explicit -r option.
This is what confuses. I know: been the
Am 13.01.2014 00:17, schrieb Orcan Ogetbil:
> On Sun, Jan 12, 2014 at 5:23 PM, Alec Leamas wrote:
>> Well, IMHO the docs are actually quite clear on that 'all' refers to all
>> metadata rather than all repositories.
>>
>> That said, perhaps enough people has been confused by this to make some kin
On Sun, Jan 12, 2014 at 5:23 PM, Alec Leamas wrote:
> Well, IMHO the docs are actually quite clear on that 'all' refers to all
> metadata rather than all repositories.
>
> That said, perhaps enough people has been confused by this to make some kind
> of improvement motivated.
>
I am pretty sure if
Well, IMHO the docs are actually quite clear on that 'all' refers to all
metadata rather than all repositories.
That said, perhaps enough people has been confused by this to make some
kind of improvement motivated.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.o
from a developers point of view the current behavior is clear and perfect
"what is not enabled is handeled as it would not exist"
means:
repos with "enabled=0" are completly ignored until --enablrepo with no
but and if - clear and straight logical decision
from a users point of view "all" has a d
I have come to understand that for yum, commands like clean only applies to
the actual buildroot. So without a -r argument, the cleaning is done on the
default root, whatever this might be(?).
Actually, there is probably nothing wrong with this - it works fine when
using the -r option. Problems co
Am 12.01.2014 22:42, schrieb Miroslav Suchy:
> On 01/12/2014 08:27 PM, Reindl Harald wrote:
>> "dnf clean all" without "dnf --enablerepo=updates-testing clean all" does
>> exactly *nothing* in case of "updates-testing", the same for YUM simply
>> because folders of non-enabled repos are not relev
On 01/12/2014 08:27 PM, Reindl Harald wrote:
"dnf clean all" without "dnf --enablerepo=updates-testing clean all" does
exactly*nothing* in case of "updates-testing", the same for YUM simply
because folders of non-enabled repos are not relevant for any operation
And is this correct behavior? (a
Am 12.01.2014 21:38, schrieb Garry T. Williams:
> On 1-12-14 20:27:26 Reindl Harald wrote:
>> "dnf clean all" without "dnf --enablerepo=updates-testing clean all"
>> does exactly *nothing* in case of "updates-testing", the same for
>> YUM simply because folders of non-enabled repos are not releva
On 1-12-14 20:27:26 Reindl Harald wrote:
> "dnf clean all" without "dnf --enablerepo=updates-testing clean all"
> does exactly *nothing* in case of "updates-testing", the same for
> YUM simply because folders of non-enabled repos are not relevant for
> any operation
Yeah, I feel pretty stupid now.
On 12/01/14 19:28, Garry T. Williams wrote:
And yes, as Michael commented, dnf doesn't expire meta-data as often
as yum.
It's quite a big difference as well - yum is 6 hours and dnf is 48 hours
by default.
So if you're used to running update once a day then you'll find it will
only work ev
Am 12.01.2014 20:24, schrieb Ahmad Samir:
> On 12 January 2014 21:06, Garry T. Williams wrote:
>> On 1-12-14 18:18:00 M A Young wrote:
>>> On Sun, 12 Jan 2014, Garry T. Williams wrote:
On 1-9-14 15:43:50 Ales Kozumplik wrote:
> New DNF release is out. See the blog [1], the release notes
On 1-12-14 11:30:31 you wrote:
> On 1-9-14 15:43:50 Ales Kozumplik wrote:
> > New DNF release is out. See the blog [1], the release notes [2] and
> > the F20 update [3]. Rawhide build went smooth this time too!
>
> I see this using 0.4.11. What am I doing wrong?
[snip]
> garry@vfr$ sudo dnf cle
On 12 January 2014 21:06, Garry T. Williams wrote:
> On 1-12-14 18:18:00 M A Young wrote:
>> On Sun, 12 Jan 2014, Garry T. Williams wrote:
>> > On 1-9-14 15:43:50 Ales Kozumplik wrote:
>> >> New DNF release is out. See the blog [1], the release notes [2] and
>> >> the F20 update [3]. Rawhide build
On 1-12-14 18:18:00 M A Young wrote:
> On Sun, 12 Jan 2014, Garry T. Williams wrote:
> > On 1-9-14 15:43:50 Ales Kozumplik wrote:
> >> New DNF release is out. See the blog [1], the release notes [2] and
> >> the F20 update [3]. Rawhide build went smooth this time too!
> >
> > I see this using 0.4.1
On Sun, 12 Jan 2014, Garry T. Williams wrote:
On 1-9-14 15:43:50 Ales Kozumplik wrote:
New DNF release is out. See the blog [1], the release notes [2] and
the F20 update [3]. Rawhide build went smooth this time too!
I see this using 0.4.11. What am I doing wrong?
garry@vfr$ sudo dnf --enabl
Am 12.01.2014 18:43, schrieb Garry T. Williams:
> On 1-12-14 11:39:35 Rahul Sundaram wrote:
>> On Sun, Jan 12, 2014 at 11:30 AM, Garry T. Williams wrote:
>>> On 1-9-14 15:43:50 Ales Kozumplik wrote:
New DNF release is out. See the blog [1], the release notes [2] and
the F20 update [3].
On 1-12-14 11:39:35 Rahul Sundaram wrote:
> On Sun, Jan 12, 2014 at 11:30 AM, Garry T. Williams wrote:
> > On 1-9-14 15:43:50 Ales Kozumplik wrote:
> > > New DNF release is out. See the blog [1], the release notes [2] and
> > > the F20 update [3]. Rawhide build went smooth this time too!
> >
> > I
Hi
On Sun, Jan 12, 2014 at 11:30 AM, Garry T. Williams wrote:
> On 1-9-14 15:43:50 Ales Kozumplik wrote:
> > New DNF release is out. See the blog [1], the release notes [2] and
> > the F20 update [3]. Rawhide build went smooth this time too!
>
> I see this using 0.4.11. What am I doing wrong?
On 1-9-14 15:43:50 Ales Kozumplik wrote:
> New DNF release is out. See the blog [1], the release notes [2] and
> the F20 update [3]. Rawhide build went smooth this time too!
I see this using 0.4.11. What am I doing wrong?
garry@vfr$ sudo dnf --enablerepo=updates-testing update kernel\*
[sudo] pa
://admin.fedoraproject.org/updates/dnf-0.4.11-1.fc20
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
45 matches
Mail list logo
