gpk-update-viewer vs. yum

[Beartooth]

	Is it just me?? 

	I've noticed, on several machines (PC, laptop, netbook) that if 
the machine has no connection, or thinks it has none, the gpk function 
claims there are no updates; but if I doubt that and run yum update, it 
may immediately get over a hundred -- or at least report a failure to 
connect.

	Couldn't gpk do the same??
-- 
Beartooth Staffwright, Neo-Redneck Not Quite Clueless Power User
I have precious (very precious!) little idea where up is.

[Beartooth]

On Sat, 19 Jun 2010 10:01:08 -0400, D. Hugh Redelmeier wrote:

>  | From: BeartoothHOS <beartooth(a)comcast.net&gt; | Date: Fri, 16
> Apr 2010
>  18:51:05 +0000 (UTC) |
>  | 	Is it just me??
>  |
>  | 	I've noticed, on several machines (PC, laptop, netbook) that if |  
the
>  machine has no connection, or thinks it has none, the gpk function |
>  claims there are no updates; but if I doubt that and run yum update, it
>  | may immediately get over a hundred -- or at least report a failure to
>  | connect.
>  |
>  | 	Couldn't gpk do the same??
>  
>  I've just experienced this.  It seems to be related to
>  <https://bugzilla.redhat.com/show_bug.cgi?id=543871> but that is marked
>  as closed having been fixed for Fedora 13.
>  
>  To compound the problem, when I enable the network using nm,
>  gpk-update-viewer still reports "All software is up to date" without
>  bothering to use the now-available network connection.
>  
>  I've got several other grumbles that I've mentioned in
>  <https://bugzilla.redhat.com/show_bug.cgi?id=543871#c7> 
	Note Hugh's date (June); it's mid December, and I'm still getting 
the same thing.

-- 
Beartooth Staffwright, Neo-Redneck Not Quite Clueless Power User
I have precious (very precious!) little idea where up is.

[D. Hugh Redelmeier]

| From: BeartoothHOS <beartooth(a)comcast.net&gt;
| Date: Fri, 16 Apr 2010 18:51:05 +0000 (UTC)
| 
| 	Is it just me?? 
| 
| 	I've noticed, on several machines (PC, laptop, netbook) that if 
| the machine has no connection, or thinks it has none, the gpk function 
| claims there are no updates; but if I doubt that and run yum update, it 
| may immediately get over a hundred -- or at least report a failure to 
| connect.
| 
| 	Couldn't gpk do the same??

I've just experienced this.  It seems to be related to
<https://bugzilla.redhat.com/show_bug.cgi?id=543871> but that is
marked as closed having been fixed for Fedora 13.

To compound the problem, when I enable the network using nm,
gpk-update-viewer still reports "All software is up to date" without
bothering to use the now-available network connection.

I've got several other grumbles that I've mentioned in
<https://bugzilla.redhat.com/show_bug.cgi?id=543871#c7>

[Richard Hughes]

On 16 April 2010 22:35, Rick Stevens <ricks(a)nerd.com&gt; wrote:
>  Hmmm, I'd call that a work-around, not a solution.  The solution
> is for
>  gpk (in fact, all GUI-based stuff) to query the NICs via something like
>
>         ip link show up | egrep "(eth.:|wlan.:)"
>
>  and see if any network link is up.  Or scan /proc/net/dev (or one of
>  the /proc/net files). 
That doesn't get us the connection type (GPRS dialup, WLAN, wired
data) and the NM API is so much easier to use. That said, to ignore NM
completely just edit /etc/PackageKit/PackageKit.conf and change
UseNetworkManager=false

Richard.

[Beartooth]

On Fri, 16 Apr 2010 16:14:31 -0430, Patrick O'Callaghan wrote:

>  On Fri, 2010-04-16 at 18:51 +0000, BeartoothHOS wrote:
> > 	Is it just me?? 
	[....]
>  Sounds like the old "interface not managed by
> NetworkManager" trick.
>  Some Gnome apps rely on NM to tell them if the machine is connected. If
>  the interface is not managed by NM, they don't realize the connection
>  works. This happens to Evolution for example. Luckily yum is not a Gnome
>  app and therefore is not confused.
>  
>  Solution: mark the interface as NM-managed (in system-control-network). 
	It is certainly true that I stop and disable NM every time I 
catch it. It may have potential that only developers can see, but for me 
as for others here, it's nothing but trouble.

	That being so, wouldn't marking the interface as NM-managed cause 
it to *be* NM-managed?? 

	That's not worth it. Even with ethernet cables, let alone 
wirelessly; I'd be offline -- really offline, unable to use email, Pan, 
or any browser -- all the time, instead of just gpk some of the time. 
IOW, the opposite of a solution.

	How about trying something like "yum remove NetworkManager"?? 
Would that wake those apps up?? Or even make them smell the coffee?
-- 
Beartooth Staffwright, Neo-Redneck Not Quite Clueless Power User
I have precious (very precious!) little idea where up is.

[Bruno Wolff III]

On Fri, Apr 16, 2010 at 14:35:48 -0700,
  Rick Stevens <ricks(a)nerd.com&gt; wrote:
>  
>  The problem is if you have to authenticate using a network-based
>  mechanism (e.g. NIS/NIS+ or LDAP), then you have to use the classic
>  networking stuff since NM doesn't fire until you're logged in AND are
>  using a GUI.
>  
>  Perhaps it'd be better if classic networking and NM would write a temp
>  file somewhere indicating that SOME network device is alive and all 
>  tools could look at it. 
I would think looking at the routing tables for a default route my be
a better way to tell that general networking is expected to work.

[Rick Stevens]

On 04/16/2010 01:44 PM, Patrick O'Callaghan wrote:
>  On Fri, 2010-04-16 at 18:51 +0000, BeartoothHOS wrote:
> > 	Is it just me??
> >
> > 	I've noticed, on several machines (PC, laptop, netbook) that if
> > the machine has no connection, or thinks it has none, the gpk function
> > claims there are no updates; but if I doubt that and run yum update, it
> > may immediately get over a hundred -- or at least report a failure to
> > connect.
> >
> > 	Couldn't gpk do the same??
>
>  Sounds like the old "interface not managed by NetworkManager" trick.
>  Some Gnome apps rely on NM to tell them if the machine is connected. If
>  the interface is not managed by NM, they don't realize the connection
>  works. This happens to Evolution for example. Luckily yum is not a Gnome
>  app and therefore is not confused.
>
>  Solution: mark the interface as NM-managed (in system-control-network). 
Hmmm, I'd call that a work-around, not a solution.  The solution is for
gpk (in fact, all GUI-based stuff) to query the NICs via something like

	ip link show up | egrep "(eth.:|wlan.:)"

and see if any network link is up.  Or scan /proc/net/dev (or one of
the /proc/net files).

The problem is if you have to authenticate using a network-based
mechanism (e.g. NIS/NIS+ or LDAP), then you have to use the classic
networking stuff since NM doesn't fire until you're logged in AND are
using a GUI.

Perhaps it'd be better if classic networking and NM would write a temp
file somewhere indicating that SOME network device is alive and all 
tools could look at it.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, C2 Hosting          ricks(a)nerd.com -
- AIM/Skype: therps2        ICQ: 22643734            Yahoo: origrps2 -
-                                                                    -
-      "Doctor!  My brain hurts!"  "It will have to come out!"      
-
----------------------------------------------------------------------

[Patrick O'Callaghan]

On Fri, 2010-04-16 at 18:51 +0000, BeartoothHOS wrote:
>  	Is it just me?? 
>  
>  	I've noticed, on several machines (PC, laptop, netbook) that if 
>  the machine has no connection, or thinks it has none, the gpk function 
>  claims there are no updates; but if I doubt that and run yum update, it 
>  may immediately get over a hundred -- or at least report a failure to 
>  connect.
>  
>  	Couldn't gpk do the same?? 
Sounds like the old "interface not managed by NetworkManager" trick.
Some Gnome apps rely on NM to tell them if the machine is connected. If
the interface is not managed by NM, they don't realize the connection
works. This happens to Evolution for example. Luckily yum is not a Gnome
app and therefore is not confused.

Solution: mark the interface as NM-managed (in system-control-network).

poc