date:20150722



- Original Message -
> From: "Suvayu Ali" 
> To: users@lists.fedoraproject.org
> Sent: Thursday, July 23, 2015 1:07:13 AM
> Subject: Re: dnf update vs Software Udpates
> 
> Hi Pete,
> 
> On Wed, Jul 22, 2015 at 05:42:15PM -0500, Pete Travis wrote:
> > 
> > There is a timer unit, `/usr/lib/systemd/system/dnf-makecache.timer`, that
> > fires ten minutes after each boot then one hour following the execution of
> > each previous run.  It triggers
> > `/usr/lib/systemd/system/dnf-makecache.service`, a service that executes
> > `dnf -v makecache timer`.  When that command runs, dnf will check the age
> > of the current metadata cache and refresh it if it is older than the value
> > of * metadata_timer_sync* (seconds) in `/etc/dnf/dnf.conf`.
> 
> Thank you for this clear and very nice explanation.
> 
> > So, an always-on computer should never have metadata older than 4 hours; in
> > practical terms, I think values >2 hours are increasingly unlikely.  A
> > computer that's been off overnight and turned on in the morning should have
> > a fresh cache within 15 minutes of boot.  If you have, say, a laptop that
> > you power down often and often install or update packages immediately after
> > boot, you might adjust the OnBootSec value by copying dnf-makecache.timer
> > to /etc/systemd/system/ and editing accordingly.  Or, consider appending
> > --refresh on an as-needed basis.
> 
> I think this is where things go wrong.  OnBootSec handles powerdowns,
> what about intermittent connections?  In principle, it is quite possible
> everytime the timer triggers the makecache service, the connection is
> absent.  In fact, the probability to hit the sweet spot is directly
> determined by the reliability of the connection.  So a connection that
> is up 50% of the time, will miss 50% of the makecache jobs.  Maybe the
> makecache jobs can reset the timer to try again in 10 mins in case of no
> network connectivity.  I think that would make the odds more favourable.
> 
> Essentially I'm suggesting to treat no connectivity as a powercycle.
> Hopefully this gives the devs some ideas.
> 
> Cheers,
> 
> --
> Suvayu

Can you please file an RFE?

Thanks
-- 
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech
-- 
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: dnf update vs Software Udpates



- Original Message -
> From: "Rick Stevens" 
> To: "Community support for Fedora users" 
> Sent: Wednesday, July 22, 2015 7:52:32 PM
> Subject: Re: dnf update vs Software Udpates
> 
> On 07/22/2015 10:38 AM, Maurizio Marini wrote:
> > On Tue, 21 Jul 2015 20:33:27 -0400
> > Matthew Miller  wrote:
> >
> >> On Wed, Jul 22, 2015 at 02:10:10AM +0200, Suvayu Ali wrote:
> >>> I'm sorry but "clean all" is not necessary at all!  "clean metadata" or
> >>> "clean expire-cache" should be sufficient.
> >>
> >> You don't even need to do that. Just use the --refresh flag -- `dnf
> >> --refresh upgrade`.
> >
> >
> > dnf --refresh upgrade
> > does not work for me
> >
> > dnf clean expire-cache
> > does not work for me
> >
> > dnf clean metadata
> > does work instaed
> 
> I think that was a typo. You need:
> 
>   dnf --refresh update

Well, "dnf update" is a deprecated alias for "dnf upgrade" 
(http://dnf.readthedocs.org/en/latest/command_ref.html#update-command).

> Running it on my machine:
> 
> [root@prophead conf]# dnf --refresh update
> RPM Fusion for Fedora 21 - Free - Updates44 kB/s | 406 kB
> 00:09
> Adobe Systems Incorporated  1.2 kB/s | 1.8 kB
> 00:01
> RPM Fusion for Fedora 21 - Nonfree - Updates543 kB/s | 152 kB
> 00:00
> RPM Fusion for Fedora 21 - Free  17 kB/s | 508 kB
> 00:29
> google-chrome77 kB/s | 3.5 kB
> 00:00
> RPM Fusion for Fedora 21 - Nonfree  527 kB/s | 179 kB
> 00:00
> Using metadata from Wed Jul 22 10:49:27 2015 (0:00:52 hours old)
> Dependencies resolved.
> 
>   Package  Arch   VersionRepository
>  Size
> 
> Upgrading:
>   google-chrome-stable x86_64 44.0.2403.89-1 google-chrome
>  46 M
> 
> Transaction Summary
> 
> Upgrade  1 Package
> 
> Total download size: 46 M
> Is this ok [y/N]:
> 
> This was on a machine that had been fully updated yesterday.
> --
> - Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com -
> - AIM/Skype: therps2ICQ: 226437340   Yahoo: origrps2 -
> --
> -  The problem with being poor is that it takes up all of your time  -
> --
> --
> 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
> 

-- 
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech
-- 
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: dnf update vs Software Udpates



- Original Message -
> From: "Ralf Corsepius" 
> To: users@lists.fedoraproject.org
> Sent: Wednesday, July 22, 2015 6:58:49 PM
> Subject: Re: dnf update vs Software Udpates
> 
> On 07/22/2015 05:41 PM, Heinz Diehl wrote:
> > On 22.07.2015, Suvayu Ali wrote:
> >
> > I usually update weekly (or at least once within two weeks). And since
> > F22, I get "nothing to do" every time I do this
> 
> What you describe indicates you could be victim of what I conside a
> massive design flaw in dnf, the dnf guys have been ignoring ever since,
> because they believe to know better: When dnf encounters a broken
> dependency, it doesn't tell you about it and ignores it.
> 
> Try "dnf --refresh --best update"
> 
> Ralf

Let's admit that you ignore us as well.

As said many times, we are working on it [1].

First step is dnf-1.0.2.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1210445

-- 
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech
-- 
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: dnf update vs Software Udpates

2015-07-22 Thread Ron Yorston

Gordon Messmer wrote:
>Use "dnf repolist -v" to find out, in the future.  It will print the 
>date from the metadata you have, and the URL of the mirror from which it 
>was retrieved.

OK, today 'dnf repolist -v' tells me:

fedora: using metadata from Wed Jul 22 08:38:59 2015.
rmy: using metadata from Wed Jul 22 08:38:59 2015.
updates: using metadata from Wed Jul 22 08:54:38 2015.
Last metadata expiration check performed 21:22:45 ago on Wed Jul 22 08:54:38 
2015.

Repo-id  : fedora
Repo-updated : Sat May 23 11:23:20 2015
Repo-expire  : 172,800 second(s) (last: Wed Jul 22 08:38:59 2015)

Repo-id  : rmy
Repo-updated : Sat Jun 20 19:40:40 2015
Repo-expire  : 172,800 second(s) (last: Wed Jul 22 08:38:59 2015)

Repo-id  : updates
Repo-updated : Tue Jul 21 06:47:56 2015
Repo-expire  : 21,600 second(s) (last: Wed Jul 22 08:54:38 2015)

The fedora and rmy repos both have the default metadata_expire of 48
hours; updates has 6 hours, as configured in fedora-updates.repo.

fedora and rmy are still within their metadata_expire timeout; updates
has expired.

Running the same commands as yesterday:

[root@vulcan rmyf22]# dnf check-update
Last metadata expiration check performed 0:00:00 ago on Thu Jul 23 06:19:10 
2015.
[root@vulcan rmyf22]# dnf --refresh check-update
Fedora 22 - x86_64 - RMY repository  78 kB/s | 6.0 kB 00:00
Last metadata expiration check performed 0:00:00 ago on Thu Jul 23 06:20:06 
2015.
[root@vulcan rmyf22]# rm -rf /var/cache/dnf/x86_64/22/updates*
[root@vulcan rmyf22]# dnf check-update
Fedora 22 - x86_64 - Updates946 kB/s |  12 MB 00:13
Last metadata expiration check performed 0:00:11 ago on Thu Jul 23 06:23:32 
2015.
[root@vulcan rmyf22]#

What immediately seems odd is that 'dnf --refresh check-update' pulled
in a new version of the rmy metadata (which hasn't expired) but not
the updates metadata (which has).

Forcibly removing the updates metadata causes a download but I get the
same version as yesterday (the one from Jul 21 06:47:56 2015) so there
are no new updates.

Actually, every time I run 'dnf --refresh check-update' the metadata for
the rmy repo is downloaded.  Maybe that's because the rmy repo has an
'ftp://' URL so dnf can't use an 'if-modified-since' request to see if
it's changed.  I wonder if that's confusing 'dnf --refresh'?

Ron
-- 
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: dnf update vs Software Udpates

2015-07-22 Thread Rahul Sundaram

Hi

On Wed, Jul 22, 2015 at 10:55 PM, dwoody5654  wrote:

> Is there a way to make dnf provide info instead of being silent?
>
> The answer was posted earlier in the thread.  Use dnf update --best.
Refer to the man dnf for details.

Rahul
-- 
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: dnf update vs Software Udpates

2015-07-22 Thread dwoody5654


On 07/22/2015 09:41 PM, Ralf Corsepius wrote:

On 07/22/2015 09:32 PM, Ron Yorston wrote:

Matthew Miller  wrote:

On Wed, Jul 22, 2015 at 07:20:11PM +0100, Ron Yorston wrote:

I certainly get the impression that dnf tells me about updates less
frequently than yum did.  It also seems to pull in metadata less
frequently.


Keep in mind that we only push updates once per day *anyway*.


OK, but that's independent of the client being used.  Both yum and
dnf see the same updates, but dnf doesn't seem to be as quick to
pass them on.


IIRC, dnf and yum use different default intervals/timeouts.

dnf by default uses 2 days (search for "metadata_expire" in
"man dnf.conf", while yum used 6 hours (search for "metadata_expire"
in "man yum.conf").


Of course, if you're mixing in private repos or other rpm providers,
there may be different policies.


Sure, different repos have different policies but why would that affect
Fedora updates?

They affect updates when package conflicts occur. The probability to
encounter them when "mixing repos" is much higher.

yum complained about them and forced users to intervene manually.

dnf by default remains silent about such conflicts and doesn't update.
This lets users believe everything was "OK", while their system
actually is partially outdated.

Is there a way to make dnf provide info instead of being silent?

David


Ralf





--
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: dnf update vs Software Udpates


On 07/22/2015 09:32 PM, Ron Yorston wrote:

Matthew Miller  wrote:

On Wed, Jul 22, 2015 at 07:20:11PM +0100, Ron Yorston wrote:

I certainly get the impression that dnf tells me about updates less
frequently than yum did.  It also seems to pull in metadata less
frequently.


Keep in mind that we only push updates once per day *anyway*.


OK, but that's independent of the client being used.  Both yum and
dnf see the same updates, but dnf doesn't seem to be as quick to
pass them on.


IIRC, dnf and yum use different default intervals/timeouts.

dnf by default uses 2 days (search for "metadata_expire" in
"man dnf.conf", while yum used 6 hours (search for "metadata_expire" in 
"man yum.conf").



Of course, if you're mixing in private repos or other rpm providers,
there may be different policies.


Sure, different repos have different policies but why would that affect
Fedora updates?
They affect updates when package conflicts occur. The probability to 
encounter them when "mixing repos" is much higher.


yum complained about them and forced users to intervene manually.

dnf by default remains silent about such conflicts and doesn't update. 
This lets users believe everything was "OK", while their system actually 
is partially outdated.


Ralf



--
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: dnf update vs Software Udpates

2015-07-22 Thread jd1008


On 07/22/2015 09:58 AM, Ralf Corsepius wrote:

What you describe indicates you could be victim of what I conside a
massive design flaw in dnf, the dnf guys have been ignoring ever since,
because they believe to know better: When dnf encounters a broken
dependency, it doesn't tell you about it and ignores it.


...and this is supposed to be better than yum.  Why?



Well improving what is not broken :)

--
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: dnf update vs Software Udpates


On 07/22/2015 07:39 PM, Joe Zeff wrote:

On 07/22/2015 09:58 AM, Ralf Corsepius wrote:

What you describe indicates you could be victim of what I conside a
massive design flaw in dnf, the dnf guys have been ignoring ever since,
because they believe to know better: When dnf encounters a broken
dependency, it doesn't tell you about it and ignores it.


...and this is supposed to be better than yum.  Why?


Don't ask me. I've complained about this behavior many times, but the 
dnf folks/RH prefer not to listen and to be non-cooperational.


Ralf

--
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: dnf update vs Software Udpates


On 07/22/2015 04:57 PM, Pete Travis wrote:


Do you have references for the on-battery behavior? That's news to me.



/usr/lib/systemd/system/dnf-makecache.service:
ExecStart=/usr/bin/dnf -v makecache timer

man dnf:
   dnf [options] makecache timer
  Like  plain  makecache but instructs DNF to be more 
resource-aware, meaning will

  not do anything if running on battery power
...
--
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: dnf update vs Software Udpates

2015-07-22 Thread Pete Travis

On Jul 22, 2015 6:52 PM, "Gordon Messmer"  wrote:
>
> On 07/22/2015 04:07 PM, Suvayu Ali wrote:
>>
>> I think this is where things go wrong.  OnBootSec handles powerdowns,
>> what about intermittent connections?  In principle, it is quite possible
>> everytime the timer triggers the makecache service, the connection is
>> absent.
>
>
> Which shouldn't matter.  If no connection is available, metadata won't
get updated until you run an interactive command that forces a refresh.
Note that if you're on battery, makecache won't run, either.  This is a
convenience function to reduce the delay in running interactive commands,
and nothing more.
> --
>

Do you have references for the on-battery behavior? That's news to me.

--Pete
-- 
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: Creating kvm instance remotely


On 07/22/2015 04:12 PM, Alex wrote:

# virt-install --name demo --hvm --memory 1024 --virt-type kvm \
 -x "ks=/var/lib/libvirt/images/anaconda-ks.cfg" \


https://rhinstaller.github.io/anaconda/boot-options.html#inst-repo

The kickstart location is read by the operating system inside the VM.  
It doesn't have access to the filesystem of the KVM host. You'll 
probably put the kickstart file in a network accessible location, like 
an HTTP server.

--
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: dnf update vs Software Udpates


On 07/22/2015 04:07 PM, Suvayu Ali wrote:

I think this is where things go wrong.  OnBootSec handles powerdowns,
what about intermittent connections?  In principle, it is quite possible
everytime the timer triggers the makecache service, the connection is
absent.


Which shouldn't matter.  If no connection is available, metadata won't 
get updated until you run an interactive command that forces a refresh.  
Note that if you're on battery, makecache won't run, either.  This is a 
convenience function to reduce the delay in running interactive 
commands, and nothing more.

--
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: Creating kvm instance remotely

2015-07-22 Thread Alex

Hi,

>> I'm aware of kickstart, but have never used it. Is that the best
>> option, or is something like chef or puppet easier?
>> ...
>> I've experimented with virt-install, but that apparently doesn't
>> provide the ability to select all of the install config options
>
> It might help to picture the virtual machine as a stack.

Okay, got it, cool.

I've created a kickstart file and passed it to virt-install, but have
had no success in actually getting it to go through an install:

# virt-install --name demo --hvm --memory 1024 --virt-type kvm \
--disk path=/var/lib/libvirt/images/demo.img,size=8 \
--network network:default --os-variant=fedora22 \
--location /var/lib/libvirt/images/fedora22 \
-x "ks=/var/lib/libvirt/images/anaconda-ks.cfg" \
--graphics vnc,password=foobar,listen=0.0.0.0,port=5910

This is from the command-line on a server in the colo. It fails with a
dracut error "Warning: /dev/root does not exist" then the install
fails with a dracut prompt.

What's wrong with that command line?

Thanks,
Alex
-- 
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: dnf update vs Software Udpates

2015-07-22 Thread Suvayu Ali

Hi Pete,

On Wed, Jul 22, 2015 at 05:42:15PM -0500, Pete Travis wrote:
> 
> There is a timer unit, `/usr/lib/systemd/system/dnf-makecache.timer`, that
> fires ten minutes after each boot then one hour following the execution of
> each previous run.  It triggers
> `/usr/lib/systemd/system/dnf-makecache.service`, a service that executes
> `dnf -v makecache timer`.  When that command runs, dnf will check the age
> of the current metadata cache and refresh it if it is older than the value
> of * metadata_timer_sync* (seconds) in `/etc/dnf/dnf.conf`.

Thank you for this clear and very nice explanation.

> So, an always-on computer should never have metadata older than 4 hours; in
> practical terms, I think values >2 hours are increasingly unlikely.  A
> computer that's been off overnight and turned on in the morning should have
> a fresh cache within 15 minutes of boot.  If you have, say, a laptop that
> you power down often and often install or update packages immediately after
> boot, you might adjust the OnBootSec value by copying dnf-makecache.timer
> to /etc/systemd/system/ and editing accordingly.  Or, consider appending
> --refresh on an as-needed basis.

I think this is where things go wrong.  OnBootSec handles powerdowns,
what about intermittent connections?  In principle, it is quite possible
everytime the timer triggers the makecache service, the connection is
absent.  In fact, the probability to hit the sweet spot is directly
determined by the reliability of the connection.  So a connection that
is up 50% of the time, will miss 50% of the makecache jobs.  Maybe the
makecache jobs can reset the timer to try again in 10 mins in case of no
network connectivity.  I think that would make the odds more favourable.

Essentially I'm suggesting to treat no connectivity as a powercycle.
Hopefully this gives the devs some ideas.

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.
-- 
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: dnf update vs Software Udpates

2015-07-22 Thread Pete Travis

On Wed, Jul 22, 2015 at 5:22 PM, Suvayu Ali 
wrote:

> On Wed, Jul 22, 2015 at 07:20:11PM +0100, Ron Yorston wrote:
> > Suvayu Ali wrote:
> > >That said, I sometimes do not understand what's the harm in getting
> > >updates few hours later.  dnf already tells you how old the metadata is
> > >when it starts, you can choose to get the latest metadata if it is too
> > >old.  So what's the big deal?
> >
> > I certainly get the impression that dnf tells me about updates less
> > frequently than yum did.  It also seems to pull in metadata less
> > frequently.
>
> Everyone seems to picked on this post for me, whereas missing on my
> follow-up, with actual numbers:
>
>   
>
> > In fedora-updates.repo I have:  metadata_expire=6h.  I also have the
> > dnf-makecache.timer 'masked'.
>
> In the above post, I say I do not change any of the defaults metadata
> related configs.  From what people are posting, I have the feeling dnf
> relies a lot on _continuous_ network connectivity (which is true in my
> case).  If that is true, if either the connection at the users end is
> intermittent, or the mirrors are unreliable, the cache probably ends up
> being stale more often.
>
> Instead of bashing and complaining, I think trying to analyse why it
> works for me (and maybe a few others who are quiet), and not for the
> other participants in this thread, it would be a lot more helpful to the
> devs.  I can't help here since it actually works for me beautifully.
> Users who see a problem are the ones in a position to contribute an
> effective bug report.
>
> My 2¢, cheers,
>
> --
> Suvayu


There is a timer unit, `/usr/lib/systemd/system/dnf-makecache.timer`, that
fires ten minutes after each boot then one hour following the execution of
each previous run.  It triggers
`/usr/lib/systemd/system/dnf-makecache.service`, a service that executes
`dnf -v makecache timer`.  When that command runs, dnf will check the age
of the current metadata cache and refresh it if it is older than the value
of * metadata_timer_sync* (seconds) in `/etc/dnf/dnf.conf`.

So, an always-on computer should never have metadata older than 4 hours; in
practical terms, I think values >2 hours are increasingly unlikely.  A
computer that's been off overnight and turned on in the morning should have
a fresh cache within 15 minutes of boot.  If you have, say, a laptop that
you power down often and often install or update packages immediately after
boot, you might adjust the OnBootSec value by copying dnf-makecache.timer
to /etc/systemd/system/ and editing accordingly.  Or, consider appending
--refresh on an as-needed basis.

-- Pete
-- 
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: dnf update vs Software Udpates

2015-07-22 Thread Suvayu Ali

On Wed, Jul 22, 2015 at 07:20:11PM +0100, Ron Yorston wrote:
> Suvayu Ali wrote:
> >That said, I sometimes do not understand what's the harm in getting
> >updates few hours later.  dnf already tells you how old the metadata is
> >when it starts, you can choose to get the latest metadata if it is too
> >old.  So what's the big deal?
> 
> I certainly get the impression that dnf tells me about updates less
> frequently than yum did.  It also seems to pull in metadata less
> frequently.

Everyone seems to picked on this post for me, whereas missing on my
follow-up, with actual numbers:

> In fedora-updates.repo I have:  metadata_expire=6h.  I also have the
> dnf-makecache.timer 'masked'.

In the above post, I say I do not change any of the defaults metadata
related configs.  From what people are posting, I have the feeling dnf
relies a lot on _continuous_ network connectivity (which is true in my
case).  If that is true, if either the connection at the users end is
intermittent, or the mirrors are unreliable, the cache probably ends up
being stale more often.

Instead of bashing and complaining, I think trying to analyse why it
works for me (and maybe a few others who are quiet), and not for the
other participants in this thread, it would be a lot more helpful to the
devs.  I can't help here since it actually works for me beautifully.
Users who see a problem are the ones in a position to contribute an
effective bug report.

My 2¢, cheers,

-- 
Suvayu

Open source is the future. It sets us free.
-- 
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

Pinentry fails with gpg-agent and SSH

2015-07-22 Thread Jimmy Thrasibule

Hello,

I'm running Fedora 22. I'm trying to setup GnuPG to have my SSH
connections authenticated using my PGP authentication subkey that is
located on my Yubikey Neo.

I have a systemd unit starting the gpg-agent as following:


/usr/bin/gpg-agent --homedir=%h/.gnupg --daemon --use-standard-socket


And I have enabled SSH support in the configuration:


enable-ssh-support
pinentry-program /usr/bin/pinentry-gtk


Other parts of the setup include adding the [keygrip][1] of my key to
the ~/.gnupg/sshcontrol file, adding my [public key][2] to the remote
host and declaring the [environment variables][3].

Globally looking at the various logs the setup wants to work, I can
see that SSH is finding the key but actually failing to sign with it.
If I look at the logs from gpg-agent, I can see that it is failing to
launch the pinentry program and therefore, no requesting for the PIN
code:


2015-07-22 23:23:28 gpg-agent[6758] DBG: error calling pinentry:
Ioctl() inappropriate for a device 
2015-07-22 23:23:28 gpg-agent[6758] DBG: chan_8 -> BYE
2015-07-22 23:23:28 gpg-agent[6758] DBG: chan_7 -> CAN
2015-07-22 23:23:28 gpg-agent[6758] DBG: chan_7 <- ERR 100663573
The IPC call was canceled 
2015-07-22 23:23:28 gpg-agent[6758] smartcard signing failed:
Ioctl() inappropriate for a device
2015-07-22 23:23:28 gpg-agent[6758] ssh sign request failed:
Ioctl() inappropriate for a device 


What we see here is that when used in combination with SSH, some ioctl
call is failing while calling pinentry. However if I run the
following:


$ echo "Test" | gpg2 -s


The PIN window is popping up and it's all working fine.

Can you help me understand what's going on with this setup and SSH?


[1]: https://lists.gnupg.org/pipermail/gnupg-users/2012-July/045059.html
[2]: https://lists.gnupg.org/pipermail/gnupg-users/2012-July/045115.html
[3]: 
https://www.gnupg.org/documentation/manuals/gnupg/Agent-Examples.html#Agent-Examples

___
Jimmy THRASIBULE 
-- 
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: dnf update vs Software Udpates


On 07/22/2015 11:20 AM, Ron Yorston wrote:

What's going on?


Use "dnf repolist -v" to find out, in the future.  It will print the 
date from the metadata you have, and the URL of the mirror from which it 
was retrieved.

--
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: Thank God for yum-deprecated :-)

2015-07-22 Thread Bruno Wolff III


On Wed, Jul 22, 2015 at 04:22:13 -0400,
 Radek Holy  wrote:

The most precise description is that it sets the SOLVER_FLAG_ALLOW_UNINSTALL 
flag which is described here: 
https://github.com/openSUSE/libsolv/blob/master/doc/libsolv-bindings.txt#L2024


I looked through that and it isn't easy to understand, but I have a theory 
what might be happening that I test after the next set of rawhide updates 
with a soname bump that does cover anything.


My theory is that since I am not listing any specific packages to update, 
it is acting as an upgrade all packages and locking in all installed 
packages and in effect making --allowerasing moot. My plan is when I see 
a warning about a case of interest is to then try to specifically update 
the library with --allowerasing and see what happens.

--
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: dnf update vs Software Udpates

2015-07-22 Thread Ron Yorston

Matthew Miller  wrote:
>On Wed, Jul 22, 2015 at 07:20:11PM +0100, Ron Yorston wrote:
>> I certainly get the impression that dnf tells me about updates less
>> frequently than yum did.  It also seems to pull in metadata less
>> frequently.
>
>Keep in mind that we only push updates once per day *anyway*.

OK, but that's independent of the client being used.  Both yum and
dnf see the same updates, but dnf doesn't seem to be as quick to
pass them on.

>Of course, if you're mixing in private repos or other rpm providers,
>there may be different policies.

Sure, different repos have different policies but why would that affect
Fedora updates?  The commands I quoted clearly show that there was newer
metadata that dnf ignored until I blew away the old cache.

Ron
-- 
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

dnf-langpacks

2015-07-22 Thread tangent08

I wish use dnf-langpacks to install programs in portuguese
brazilian (pt_BR), but I don't know how to do it
Some helpe?
Than you.
Edward
-- 
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

dnf-langpack

2015-07-22 Thread tangent08

I wish use dnf-langpacks to install packages in
portuguese_brazilian (pt_BR), but I don't know ho to do this. Some
help?
Thank you.
Edward
-- 
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: dnf update vs Software Udpates

2015-07-22 Thread Matthew Miller

On Wed, Jul 22, 2015 at 07:20:11PM +0100, Ron Yorston wrote:
> >That said, I sometimes do not understand what's the harm in getting
> >updates few hours later.  dnf already tells you how old the metadata is
> >when it starts, you can choose to get the latest metadata if it is too
> >old.  So what's the big deal?
> I certainly get the impression that dnf tells me about updates less
> frequently than yum did.  It also seems to pull in metadata less
> frequently.

Keep in mind that we only push updates once per day *anyway*.

Of course, if you're mixing in private repos or other rpm providers,
there may be different policies.

-- 
Matthew Miller

Fedora Project Leader
-- 
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: dnf update vs Software Udpates

2015-07-22 Thread Ron Yorston

Suvayu Ali wrote:
>That said, I sometimes do not understand what's the harm in getting
>updates few hours later.  dnf already tells you how old the metadata is
>when it starts, you can choose to get the latest metadata if it is too
>old.  So what's the big deal?

I certainly get the impression that dnf tells me about updates less
frequently than yum did.  It also seems to pull in metadata less
frequently.

In fedora-updates.repo I have:  metadata_expire=6h.  I also have the
dnf-makecache.timer 'masked'.

It's more than 6 hours since I last ran dnf but:

[root@vulcan rmyf22]# dnf check-update
Fedora 22 - x86_64 - RMY repository 131 kB/s | 6.0 kB 00:00
Last metadata expiration check performed 0:00:00 ago on Wed Jul 22 08:38:32 
2015.
[root@vulcan rmyf22]#

No updates.  It pulled in metadata for my private repo but not
fedora-updates.  So is it really telling me "how old the metadata is"?
The message just refers to the last time an expiration check was
performed.  Does that mean the metadata was up to date as of 0:00:00 ago?
Because, as we shall see, it clearly wasn't.

Let's try the --refresh option:

[root@vulcan rmyf22]# dnf --refresh check-update
Fedora 22 - x86_64 - RMY repository 113 kB/s | 6.0 kB 00:00
Last metadata expiration check performed 0:00:00 ago on Wed Jul 22 08:39:01 
2015.
[root@vulcan rmyf22]#

Still no updates.  Time for a bigger hammer (don't try this at home or
offer it as advice to newbies):

[root@vulcan rmyf22]# rm -rf /var/cache/dnf/x86_64/22/updates*
[root@vulcan rmyf22]# dnf check-update
Fedora 22 - x86_64 - Updates774 kB/s |  12 MB 00:16
Last metadata expiration check performed 0:00:16 ago on Wed Jul 22 08:40:02 
2015.

environment-modules.x86_64 3.2.10-16.fc22updates
...

Plus 55 other updates.  What's going on?

Ron
-- 
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: dnf update vs Software Udpates

2015-07-22 Thread Matthew Miller

On Wed, Jul 22, 2015 at 10:57:39AM -0700, Rick Stevens wrote:
> Open mouth, insert foot. While what I did did result in the chrome
> update, a "dnf clean metadata;dnf update" did come up with 21 more
> items to update--even though it said the metadata was 45 seconds old.

Are you sure you're not just hitting a different mirror?

-- 
Matthew Miller

Fedora Project Leader
-- 
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: dnf update vs Software Udpates

2015-07-22 Thread Heinz Diehl

On 22.07.2015, Rick Stevens wrote: 

> Open mouth, insert foot. While what I did did result in the chrome
> update, a "dnf clean metadata;dnf update" did come up with 21 more
> items to update--even though it said the metadata was 45 seconds old.

Welcome to the club..

-- 
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: dnf update vs Software Udpates

2015-07-22 Thread Joe Zeff


On 07/22/2015 10:57 AM, Rick Stevens wrote:


dnf really needs some serious surgery.


I do hope that they don't drop yum (or yum-deprecated as they now call 
it) until dnf is at least as feature-complete as yum.

--
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: dnf update vs Software Udpates

2015-07-22 Thread Rick Stevens


On 07/22/2015 10:52 AM, Rick Stevens wrote:

On 07/22/2015 10:38 AM, Maurizio Marini wrote:

On Tue, 21 Jul 2015 20:33:27 -0400
Matthew Miller  wrote:


On Wed, Jul 22, 2015 at 02:10:10AM +0200, Suvayu Ali wrote:

I'm sorry but "clean all" is not necessary at all!  "clean metadata" or
"clean expire-cache" should be sufficient.


You don't even need to do that. Just use the --refresh flag -- `dnf
--refresh upgrade`.



dnf --refresh upgrade
does not work for me

dnf clean expire-cache
does not work for me

dnf clean metadata
does work instaed


I think that was a typo. You need:

 dnf --refresh update

Running it on my machine:

[root@prophead conf]# dnf --refresh update
RPM Fusion for Fedora 21 - Free - Updates44 kB/s | 406 kB 00:09
Adobe Systems Incorporated  1.2 kB/s | 1.8 kB 00:01
RPM Fusion for Fedora 21 - Nonfree - Updates543 kB/s | 152 kB 00:00
RPM Fusion for Fedora 21 - Free  17 kB/s | 508 kB 00:29
google-chrome77 kB/s | 3.5 kB 00:00
RPM Fusion for Fedora 21 - Nonfree  527 kB/s | 179 kB 00:00
Using metadata from Wed Jul 22 10:49:27 2015 (0:00:52 hours old)
Dependencies resolved.


  Package  Arch   VersionRepository
Size


Upgrading:
  google-chrome-stable x86_64 44.0.2403.89-1 google-chrome
 46 M

Transaction Summary


Upgrade  1 Package

Total download size: 46 M
Is this ok [y/N]:

This was on a machine that had been fully updated yesterday.


Open mouth, insert foot. While what I did did result in the chrome
update, a "dnf clean metadata;dnf update" did come up with 21 more
items to update--even though it said the metadata was 45 seconds old.

dnf really needs some serious surgery.
--
- Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com -
- AIM/Skype: therps2ICQ: 226437340   Yahoo: origrps2 -
--
-  Death is nature's way of dropping carrier -
--
--
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: dnf update vs Software Udpates

2015-07-22 Thread Rick Stevens


On 07/22/2015 10:38 AM, Maurizio Marini wrote:

On Tue, 21 Jul 2015 20:33:27 -0400
Matthew Miller  wrote:


On Wed, Jul 22, 2015 at 02:10:10AM +0200, Suvayu Ali wrote:

I'm sorry but "clean all" is not necessary at all!  "clean metadata" or
"clean expire-cache" should be sufficient.


You don't even need to do that. Just use the --refresh flag -- `dnf
--refresh upgrade`.



dnf --refresh upgrade
does not work for me

dnf clean expire-cache
does not work for me

dnf clean metadata
does work instaed


I think that was a typo. You need:

dnf --refresh update

Running it on my machine:

[root@prophead conf]# dnf --refresh update
RPM Fusion for Fedora 21 - Free - Updates44 kB/s | 406 kB 
00:09
Adobe Systems Incorporated  1.2 kB/s | 1.8 kB 
00:01
RPM Fusion for Fedora 21 - Nonfree - Updates543 kB/s | 152 kB 
00:00
RPM Fusion for Fedora 21 - Free  17 kB/s | 508 kB 
00:29
google-chrome77 kB/s | 3.5 kB 
00:00
RPM Fusion for Fedora 21 - Nonfree  527 kB/s | 179 kB 
00:00

Using metadata from Wed Jul 22 10:49:27 2015 (0:00:52 hours old)
Dependencies resolved.

 Package  Arch   VersionRepository 
Size


Upgrading:
 google-chrome-stable x86_64 44.0.2403.89-1 google-chrome 
46 M


Transaction Summary

Upgrade  1 Package

Total download size: 46 M
Is this ok [y/N]:

This was on a machine that had been fully updated yesterday.
--
- Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com -
- AIM/Skype: therps2ICQ: 226437340   Yahoo: origrps2 -
--
-  The problem with being poor is that it takes up all of your time  -
--
--
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: dnf update vs Software Udpates

2015-07-22 Thread Joe Zeff


On 07/22/2015 09:58 AM, Ralf Corsepius wrote:

What you describe indicates you could be victim of what I conside a
massive design flaw in dnf, the dnf guys have been ignoring ever since,
because they believe to know better: When dnf encounters a broken
dependency, it doesn't tell you about it and ignores it.


...and this is supposed to be better than yum.  Why?
--
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: dnf update vs Software Udpates

2015-07-22 Thread Maurizio Marini

On Tue, 21 Jul 2015 20:33:27 -0400
Matthew Miller  wrote:

> On Wed, Jul 22, 2015 at 02:10:10AM +0200, Suvayu Ali wrote:
> > I'm sorry but "clean all" is not necessary at all!  "clean metadata" or
> > "clean expire-cache" should be sufficient.  
> 
> You don't even need to do that. Just use the --refresh flag -- `dnf
> --refresh upgrade`.
 

dnf --refresh upgrade
does not work for me

dnf clean expire-cache
does not work for me

dnf clean metadata
does work instaed

-m


smime.p7s
Description: S/MIME cryptographic signature
-- 
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: Automatic Bug Reporting Tool


On 07/21/2015 10:56 AM, Michael Schwendt wrote:

As a plea to users of Fedora:

If you get notifications from ABRT, the Automatic Bug Reporting Tool,
please spend a bit of time on submitting the _complete_ report instead
of only enabling shortened reports. Sometimes the shortened reports
may be interesting, but in enough cases they are useless.

FWIW: I once more experienced abrt to send report without user consent.

This is completely inacceptable, these days - I therefore decided to 
pull the plug and uninstalled it on all of my systems. I recommend 
everybody doing the same, who is concerned about data privacy.


(No, I don't have a reproducer. These incidents happened several times 
at occasions since I have installed f22).



Also please don't forget entering a minimum of details, such as whether
the problem/crash is reproducible and how often it can be reproduced,
and how to reproduce it.
Well, you should start think about the causes - IMO, these are very 
obvious: Abrt's GUI non-suiteable for ordinary users.


Ralf


--
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: Creating kvm instance remotely


On 07/22/2015 07:39 AM, Alex wrote:

I'm aware of kickstart, but have never used it. Is that the best
option, or is something like chef or puppet easier?
...
I've experimented with virt-install, but that apparently doesn't
provide the ability to select all of the install config options


It might help to picture the virtual machine as a stack.

At the lowest level is the virtualized and emulated hardware. 
virt-install creates a virtual machine and sets the initial boot 
parameters.  That is, it selects and provides a kernel and initrd, and 
the kernel command line, for the initial boot.


Anaconda, the Fedora installer is another layer in the stack.  It can 
use some command line arguments, but those are mostly for its initial 
internal setup.  Kickstart is the component that can be used to answer 
the questions that Anaconda asks during a normal setup.


After the initial boot, the system will boot from its virtual disks, at 
which point you should have a standard operating system on top of 
virtual hardware.  At that point, you should use a tool (bcfg2, ansible, 
salt, puppet, chef, etc) to finish configuring the system.


You could also run your configuration management tool from the "post" 
script in your kickstart file, so that there is never an unconfigured boot.

--
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: dnf update vs Software Udpates


On 07/22/2015 05:41 PM, Heinz Diehl wrote:

On 22.07.2015, Suvayu Ali wrote:

I usually update weekly (or at least once within two weeks). And since
F22, I get "nothing to do" every time I do this


What you describe indicates you could be victim of what I conside a 
massive design flaw in dnf, the dnf guys have been ignoring ever since, 
because they believe to know better: When dnf encounters a broken 
dependency, it doesn't tell you about it and ignores it.


Try "dnf --refresh --best update"

Ralf




--
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: Creating kvm instance remotely

2015-07-22 Thread Matthew Miller

On Wed, Jul 22, 2015 at 10:39:15AM -0400, Alex wrote:
> I have a fedora22 server with libvirt/kvm/qemu installed and would
> like to use it to create a number of kvm virtual instances remotely,
> non-interactively, according to my parameters (memory, disk layout,
> package options, etc).
> I'm aware of kickstart, but have never used it. Is that the best
> option, or is something like chef or puppet easier?

Kickstart is the way to go for the initial install. You can use a
config management system _after_ that. (Personally, I recommend
ansible, but it's up to you.)


> I've experimented with virt-install, but that apparently doesn't
> provide the ability to select all of the install config options like
> language, disk layout, IP address, etc.

It does, if you feed it a kickstart file.

-- 
Matthew Miller

Fedora Project Leader
-- 
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: dnf update vs Software Udpates

2015-07-22 Thread Suvayu Ali

On Wed, Jul 22, 2015 at 05:41:48PM +0200, Heinz Diehl wrote:
> On 22.07.2015, Suvayu Ali wrote: 
> 
> > That said, I sometimes do not understand what's the harm in getting
> > updates few hours later.  dnf already tells you how old the metadata is
> > when it starts, you can choose to get the latest metadata if it is too
> > old.  So what's the big deal?
> 
> I usually update weekly (or at least once within two weeks). And since
> F22, I get "nothing to do" every time I do this - although there are
> updates waiting. Which is.. annoying. So every time I have to clean
> the cache to be able to update.

This is strange.  I see very different behaviour.  I update once every 2
days or so.  Usually my metadata is a few hours old.  Here are some
examples:

On my laptop:
  # dnf check-update 
  Last metadata expiration check performed 2:01:15 ago on Wed Jul 22 15:47:25 
2015.
and I have a bunch of updates waiting.

On my home server:
  # dnf check-update 
  Last metadata expiration check performed 1:19:48 ago on Wed Jul 22 16:30:00 
2015.
with approximately similar set of updates waiting.

On an old laptop which I have not updated in some time.
  $ sudo dnf check-update
  [sudo] password for jallad:
  Last metadata expiration check performed 2:29:02 ago on Wed Jul 22 15:22:05 
2015.
a much larger set of updates awaiting.

My local time is, 2015-07-22 17:54:30.  So they are all within 2-3
hours.  That is why I find your case a bit puzzling.  Maybe it is
worthwhile to file a bugzilla.  To be complete, I have no metadata
related options set in dnf.conf or yum.conf.  Maybe you have something
like that set?

Hope this helps,

-- 
Suvayu

Open source is the future. It sets us free.
-- 
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: dnf update vs Software Udpates

2015-07-22 Thread Patrick O'Callaghan

On Wed, 2015-07-22 at 17:41 +0200, Heinz Diehl wrote:
> On 22.07.2015, Suvayu Ali wrote: 
> 
> > I'm sorry but "clean all" is not necessary at all!  "clean 
> > metadata" or
> > "clean expire-cache" should be sufficient.  
> 
> Ok.
> 
> > That said, I sometimes do not understand what's the harm in getting
> > updates few hours later.  dnf already tells you how old the 
> > metadata is
> > when it starts, you can choose to get the latest metadata if it is 
> > too
> > old.  So what's the big deal?
> 
> I usually update weekly (or at least once within two weeks). And 
> since
> F22, I get "nothing to do" every time I do this - although there are
> updates waiting. Which is.. annoying. So every time I have to clean
> the cache to be able to update.
> 
> This was at least not how yum behaved. But if it's intended behaviour
> now, well...

I update every day, and most days there are some changes. I never clean
the cache. I also never use anything except dnf.

poc
-- 
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: dnf update vs Software Udpates

2015-07-22 Thread Heinz Diehl

On 22.07.2015, Suvayu Ali wrote: 

> I'm sorry but "clean all" is not necessary at all!  "clean metadata" or
> "clean expire-cache" should be sufficient.  

Ok.

> That said, I sometimes do not understand what's the harm in getting
> updates few hours later.  dnf already tells you how old the metadata is
> when it starts, you can choose to get the latest metadata if it is too
> old.  So what's the big deal?

I usually update weekly (or at least once within two weeks). And since
F22, I get "nothing to do" every time I do this - although there are
updates waiting. Which is.. annoying. So every time I have to clean
the cache to be able to update.

This was at least not how yum behaved. But if it's intended behaviour
now, well...

-- 
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

Creating kvm instance remotely

2015-07-22 Thread Alex

Hi,
I have a fedora22 server with libvirt/kvm/qemu installed and would
like to use it to create a number of kvm virtual instances remotely,
non-interactively, according to my parameters (memory, disk layout,
package options, etc).

I'm aware of kickstart, but have never used it. Is that the best
option, or is something like chef or puppet easier?

I'd really like to create a basic 8GB, 1G RAM fedora22 server setup
with a minimal install.

I've experimented with virt-install, but that apparently doesn't
provide the ability to select all of the install config options like
language, disk layout, IP address, etc.

I'd appreciate any pointers to documents, or tips here, that could
help me get started doing this more quickly...

Thanks,
Alex
-- 
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: which plugin to listen at some radio with firefox?

2015-07-22 Thread John Pilkington

On 19/07/15 19:52, John Pilkington wrote:

On 19/07/15 15:13, Carlos A. Carnero Delgado wrote:

Bonjour,

from a quick network check, you can see they're using MP3 for the audio
stream. So you may want to install that codec. Personally, I just
installed Fedy a while ago and then the multimedia codecs.

HTH,
Carlos.

Despite the FAQ that I quoted in my earlier post, I have no immediate
trouble in playing music from this site, originally broadcast earlier
today, in FF on a laptop running kubuntu trusty. The Page Info shows an
.mp3 audio file.

During experiments playback seems to stop after 5 minutes. I don't know
if this will always happen.

The only plugins shown are ShockwaveFlash and OpenH264

John P

I'll come back on this, because things seem to have changed. In SL7
yesterday PageInfo/Media showed an audio .mp3 file. I clicked on 'save'
and got a playable .mp3 file that grew while FF was running and vanished
on exit. Now I see a Jplayer.swf 'object' but no audio file.

The 'Inspect Element' Console display includes, for example:

Media resource
http://audio.scdn.arkena.com/11008/franceinter-midfi128.mp3 could not be
decoded.
Media resource
http://audiots.scdn.arkena.com/11591/franceinter-midfi128TS.mp3?date=10:05:00
could not be decoded.
Media resource
http://www.franceinter.fr/sites/default/files/sons/2015/07/s30/net-fi-f81756e9-dbad-4fb1-ae0e-cc51bf358527.mp3
could not be decoded.

and

Using //@ to indicate sourceMappingURL pragmas is deprecated. Use //#
instead.

I suspect that some kind of DRM might be in play now. kubuntu still plays.

John

--
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: external screen no longer support native resolution

2015-07-22 Thread Frederic Muller

On 07/21/2015 06:08 PM, Suvayu Ali wrote:
> On Tue, Jul 21, 2015 at 02:32:08PM +0700, Frederic Muller wrote:
>> Hi!
>>
>> I just upgraded to F22 and my external monitor (a Koios 24" 1920x1200)
>> no longer works in its native resolution. I can only get 1280 x 768 to
>> display.
>>
>> Everything was working well before. My video chip is the Intel HD
>> Graphics 5500 (Broadwell GT2) (the laptop is a X1 Carbon 3rd generation).
>>
>> GNOME display settings does offer the native resolution but it just
>> doesn't work (I get an screen switched off).
>>
>> How would you troubleshooting this?
> 
> The first step would be to see what xrandr gives you (try -q).  If that
> works, try to get it working with xrandr first.
> 
> Hope this helps,
> 

Thanks. It actually did help and I really don't know why. I did the
xrandr -q then xrandr --output DP1 -s 1920x1200 which didn't change
anything but then after going back to display in GNOME settings and
selecting 1920x1200 resolution it worked.

Go figure...

So thank you.

Fred
-- 
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: Thank God for yum-deprecated :-)