Re: FC15 beta testing result by my 76-year old uncle

[Andy Green]

On 04/23/2011 08:46 PM, Somebody in the thread at some point said:

Hi -

> I've setup FC15 beta for  my 76-year old uncle. The major issues
> encountered:
> * wake up from suspend didn't work on his laptop; on another one does

I thought my suspend was broken on this laptop.  But it turned out it is 
hit by a bug where the driver (nouveau) tries to reload firmwire in its 
resume code while userspace is still frozen.  That fails, but only after 
sitting there looking dead for 60s.  After the timeout, it resumes 
great.  So it might be worth trying.

> * logitech quickcam express doesn't work -- light goes on in
> Cheese/skype, but not image

I don't know about it specifically, but when I use my USB microscope I 
use Camorama.  Notice though it has no UI to select device, you have to 
give a switch --device=/dev/video1 on commandline if it's not the first 
video device.  It also might be worth a try.

-Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

rawhide report: 20110424 changes

[Rawhide Report]

Compose started at Sun Apr 24 08:15:02 UTC 2011

Broken deps for x86_64
--
beldi-0.9.25-3.fc15.x86_64 requires libhal-storage.so.1()(64bit)
beldi-0.9.25-3.fc15.x86_64 requires libhal.so.1()(64bit)
beldi-0.9.25-3.fc15.x86_64 requires hal
callweaver-javascript-1.2.1-8.fc16.x86_64 requires libjs.so.1()(64bit)
camcardsync-0.1.1-4.fc15.x86_64 requires libhal.so.1()(64bit)
couchdb-1.0.2-2.fc16.x86_64 requires libjs.so.1()(64bit)
cpm-0.23-0.3.beta.fc12.x86_64 requires libdotconf-1.0.so.0()(64bit)
db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0
dbmail-3.0.0-0.3.rc1.fc15.x86_64 requires libevent-1.4.so.2()(64bit)
dbmail-auth-ldap-3.0.0-0.3.rc1.fc15.x86_64 requires 
libevent-1.4.so.2()(64bit)
dh-make-0.55-3.fc15.noarch requires debhelper
emerillon-0.1.2-14.fc15.x86_64 requires 
libchamplain-gtk-0.8.so.1()(64bit)
emerillon-0.1.2-14.fc15.x86_64 requires libchamplain-0.8.so.1()(64bit)
exaile-0.3.2.1-1.fc16.noarch requires hal
file-browser-applet-0.6.6-1.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gedit-valencia-0.3.0-4.fc14.x86_64 requires libvala-0.10.so.0()(64bit)
2:gimp-2.6.11-8.fc16.x86_64 requires libhal.so.1()(64bit)
glunarclock-0.34.1-1.fc14.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnomad2-2.9.4-7.fc15.x86_64 requires libhal.so.1()(64bit)
gnome-applet-bubblemon-2.0.15-1.fc13.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-cpufire-1.6-3.fc14.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-globalmenu-0.7.9-1.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-grandr-0.4.1-2.fc12.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-music-2.5.1-5.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-sensors-2.2.7-4.fc15.i686 requires libpanel-applet-2.so.0
gnome-applet-sensors-2.2.7-4.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-sshmenu-3.18-3.fc15.noarch requires ruby(panelapplet2)
gnome-applet-window-picker-0.5.8-2.fc14.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
1:gnome-applets-2.32.0-3.fc15.x86_64 requires 
libpanel-applet-3.so.0()(64bit)
1:gnome-applets-2.32.0-3.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
1:gnome-applets-2.32.0-3.fc15.x86_64 requires libgweather.so.1()(64bit)
gnome-device-manager-0.2-6.fc15.x86_64 requires libhal.so.1()(64bit)
gnome-device-manager-devel-0.2-6.fc15.i686 requires hal-devel >= 
0:0.5.10
gnome-device-manager-devel-0.2-6.fc15.i686 requires pkgconfig(hal)
gnome-device-manager-devel-0.2-6.fc15.x86_64 requires hal-devel >= 
0:0.5.10
gnome-device-manager-devel-0.2-6.fc15.x86_64 requires pkgconfig(hal)
gnome-device-manager-libs-0.2-6.fc15.i686 requires libhal.so.1
gnome-device-manager-libs-0.2-6.fc15.i686 requires hal >= 0:0.5.10
gnome-device-manager-libs-0.2-6.fc15.x86_64 requires 
libhal.so.1()(64bit)
gnome-device-manager-libs-0.2-6.fc15.x86_64 requires hal >= 0:0.5.10
gnome-netstatus-2.28.2-1.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires 
libgpilotdconduit.so.3()(64bit)
gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires 
libgpilotd.so.5()(64bit)
gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires 
libgpilotdcm.so.4()(64bit)
gnome-python2-applet-2.32.0-1.fc14.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires 
libbrasero-burn.so.1()(64bit)
gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires 
libbrasero-media.so.1()(64bit)
gnome-python2-evince-2.32.0-1.fc14.x86_64 requires 
libevview.so.3()(64bit)
gnome-python2-evince-2.32.0-1.fc14.x86_64 requires 
libevdocument.so.3()(64bit)
gnome-python2-evolution-2.32.0-1.fc14.x86_64 requires 
libcamel-1.2.so.19()(64bit)
gnome-python2-gdl-2.25.3-22.fc15.x86_64 requires libgdl-1.so.3()(64bit)
gnome-python2-totem-2.32.0-1.fc14.x86_64 requires 
libgnome-media-profiles.so.0()(64bit)
gnome-rdp-0.2.3-6.fc12.x86_64 requires mono(Mono.Data.SqliteClient) = 
0:2.0.0.0
gnotime-2.3.0-8.fc15.x86_64 requires libgtkhtml-3.15.so.19()(64bit)
gnubiff-2.2.13-4.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit)
gold-2.1.12.2-5.fc15.noarch requires perl(Data::Properties)
gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-0.6.so.0()(64bit)
gpx-viewer-0.2.0-3.fc14.x86_64 requires 
libchamplain-gtk-0.6.so.0()(64bit)
gpx-viewer-0.2.0-3.fc14.x86_64 requires libgdl-1.so.3()(64bit)
gyachi-plugin-libnotify-1.2.10-3.fc14.x86_64 requires 
libnotify.so.1()(64bit)
hal-info-20090716-4.fc15.noarch requires

Possible to submit an update without obsoleting?

[Richard W.M. Jones]

In general I like the auto-obsoleting feature in Bodhi, but is there a
way to disable it for a particular update?

The reason is that I've got libguestfs-1.10.1-1.fc15 waiting to go
into stable.  I've also just built libguestfs-1.10.2-1.fc15 which is a
further update along the upstream stable branch.

If I submit this second update, it will auto-obsolete the first
update.  However the first update is perfectly fine in itself, and
more importantly it fixes a dependency problem.  If it gets obsoleted
then users will have to wait another 3-4 days in order to get the
dependency fix and won't be able to use the package at all during this
time.  My only choice seems to be to not submit the second update at
all, which means no one can test it, and the eventual release of it
will be later than it needs to be.  I'd like to "pipeline" the
updates.

This is a general problem with auto-obsoleting if the period between
releases < the period in updates-testing (which is the case in
libguestfs because of our quite rapid release schedule).  In the past
I've had chains of updates causing delays to get *any* package out of
3-4 weeks.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Possible to submit an update without obsoleting?

[Frank Murphy]

On 24/04/11 11:37, Richard W.M. Jones wrote:
>
> In general I like the auto-obsoleting feature in Bodhi, but is there a
> way to disable it for a particular update?
>

Not an answer to the problem?
But what about a fedorapeople repo?
Ask testers to enable it.


-- 
Regards,

Frank Murphy
UTF_8 Encoded
Friend of Fedora
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Possible to submit an update without obsoleting?

[Michael Schwendt]

On Sun, 24 Apr 2011 11:37:41 +0100, RWMJ wrote:

> 
> In general I like the auto-obsoleting feature in Bodhi, but is there a
> way to disable it for a particular update?
> 
> The reason is that I've got libguestfs-1.10.1-1.fc15 waiting to go
> into stable.  I've also just built libguestfs-1.10.2-1.fc15 which is a
> further update along the upstream stable branch.
> 
> If I submit this second update, it will auto-obsolete the first
> update.  However the first update is perfectly fine in itself, and
> more importantly it fixes a dependency problem.  If it gets obsoleted
> then users will have to wait another 3-4 days in order to get the
> dependency fix and won't be able to use the package at all during this
> time.  My only choice seems to be to not submit the second update at
> all, which means no one can test it, and the eventual release of it
> will be later than it needs to be.  I'd like to "pipeline" the
> updates.
> 
> This is a general problem with auto-obsoleting if the period between
> releases < the period in updates-testing (which is the case in
> libguestfs because of our quite rapid release schedule).  In the past
> I've had chains of updates causing delays to get *any* package out of
> 3-4 weeks.

It sounds as if bodhi would need to stop obsoleting an update that
is "pending -> stable", so you could submit the next test-update a little
bit earlier.Current behaviour (I think) is that bodhi obsoletes
updates until one is "pushed to stable". 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Possible to submit an update without obsoleting?

[Kevin Kofler]

Michael Schwendt wrote:
> It sounds as if bodhi would need to stop obsoleting an update that
> is "pending -> stable", so you could submit the next test-update a little
> bit earlier.Current behaviour (I think) is that bodhi obsoletes
> updates until one is "pushed to stable".

Bodhi actually doesn't obsolete an update that's queued for stable.

There's only a problem when you can't queue the previous update for stable 
yet because of those darn minimum testing requirements.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Driving ARM secondary rebuild with script - builddep tree?

[Martin Langhoff]

While smarter people than me fix the boostrapping of F14 on ARM, I am
looking at whether we can automate driving koji in an optimal order.

I am looking at mass-rebuild.py from the releng scripts repo; and at
yum-builddep.

 - mass-rebuild gets a git checkout, bumps the rev, commits, pushes,
we don't do that (!)

 - mass-rebuild counts on tags and on koji metadata indicating that a
pkg is blocked -- we don't do tags, and I don't know whether koji's
"blocked" metadata indicates a builddep check

 - if possible, we'd like to prioritize a particular set of packages
that is in the critical path for testing on our hw -- for that, I was
hoping to perform a recursive builddep tree, but it is... more complex
than it seems at first blush. Is there any tool that performs
recursive builddep checks, and defines an order (as yum does with deps
when planning an install?)

thanks!


m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: FC15 beta testing result by my 76-year old uncle

[Marius Andreiana]

Hi Andy

>
> Cheese/skype, but not image
>>
>
> * logitech quickcam express doesn't work -- light goes on in
> I don't know about it specifically, but when I use my USB microscope I use
> Camorama.  Notice though it has no UI to select device, you have to give a
> switch --device=/dev/video1 on commandline if it's not the first video
> device.  It also might be worth a try.
>
Found this 1 year old kernel bug, it affects several cameras
https://bugzilla.redhat.com/show_bug.cgi?id=564597
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Driving ARM secondary rebuild with script - builddep tree?

[Nathanael D. Noblet]

On 04/24/2011 08:56 AM, Martin Langhoff wrote:
> While smarter people than me fix the boostrapping of F14 on ARM, I am
> looking at whether we can automate driving koji in an optimal order.
>
> I am looking at mass-rebuild.py from the releng scripts repo; and at
> yum-builddep.
>
>   - mass-rebuild gets a git checkout, bumps the rev, commits, pushes,
> we don't do that (!)
>
>   - mass-rebuild counts on tags and on koji metadata indicating that a
> pkg is blocked -- we don't do tags, and I don't know whether koji's
> "blocked" metadata indicates a builddep check
>
>   - if possible, we'd like to prioritize a particular set of packages
> that is in the critical path for testing on our hw -- for that, I was
> hoping to perform a recursive builddep tree, but it is... more complex
> than it seems at first blush. Is there any tool that performs
> recursive builddep checks, and defines an order (as yum does with deps
> when planning an install?)

Not sure if it'll do the ordering the way you want - however look at 
smock.pl... It works well for me to build a set of RPMS where one 
depends on the other. I made two modifications to the original smock.pl 
I found online, one allows for multiple arch builds independently, the 
other uses threads to build each arch independently. My personal testing 
using time had the build finish ~50% faster when using threads. (3-4min 
vs 7min). I provided upstream with the patches but I'm not sure if they 
were applied or not. Either way not sure if it will solve your problem. 
If it does and you need/want the threaded patches let me know.


-- 
Nathanael d. Noblet
t 403.875.4613
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: wireless-tools/net-tools are DEPRECATED

[Ben Boeckel]

Chris Adams  wrote:
> Once upon a time, Kevin Kofler  said:
>> Newsflash: the network service is DEPRECATED!!! That's what NetworkManager 
>> is for.
> 
> Newsflash: NM doesn't replace the network service yet.  Maybe when NM
> can do everything ifup/ifdown can do, the discussion about deprecation
> can happen, but until then, please stop saying NM replaces the network
> service.

One thing I liked a lot with my ifconfig scripts/wpa_supplicant pairing
is that when wireless is spotty, the network doesn't keep going up and
down. Instead, applications see lots of dropped packets. When
reauthentication can take 5 to 10s (or more), assuming that the
connection is steady when its just spotty can result in better behavior.
Also nice when quickly swapping ethernet cables. A "network is gone"
event gets different reactions from applications (particularly those
that are NM-aware which makes those applications MUCH more annoying to
deal with in these cases) than "some packets were lost". An option to
"persist connections despite something probably not actually existing"
would be nice for situations like this.

--Ben

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: FC15 beta testing result by my 76-year old uncle

[Orcan Ogetbil]

On Sun, Apr 24, 2011 at 12:04 PM, Marius Andreiana wrote:
> Hi Andy
>>
>>> Cheese/skype, but not image
>>
>> * logitech quickcam express doesn't work -- light goes on in
>> I don't know about it specifically, but when I use my USB microscope I use
>> Camorama.  Notice though it has no UI to select device, you have to give a
>> switch --device=/dev/video1 on commandline if it's not the first video
>> device.  It also might be worth a try.
>
> Found this 1 year old kernel bug, it affects several cameras
> https://bugzilla.redhat.com/show_bug.cgi?id=564597
>

There is also this skype workaround which helped me at some point:
http://www.fedoraforum.org/forum/showthread.php?p=1121790#post1121790

Orcan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: wireless-tools/net-tools are DEPRECATED

[Kevin Kofler]

Ben Boeckel wrote:
> One thing I liked a lot with my ifconfig scripts/wpa_supplicant pairing
> is that when wireless is spotty, the network doesn't keep going up and
> down. Instead, applications see lots of dropped packets. When
> reauthentication can take 5 to 10s (or more), assuming that the
> connection is steady when its just spotty can result in better behavior.
> Also nice when quickly swapping ethernet cables. A "network is gone"
> event gets different reactions from applications (particularly those
> that are NM-aware which makes those applications MUCH more annoying to
> deal with in these cases) than "some packets were lost". An option to
> "persist connections despite something probably not actually existing"
> would be nice for situations like this.

I've found NM to actually be quite tolerant of spotty wireless connections. 
In fact, usually, it's me who triggers a reconnect (or if possible, a 
connect to a different access point, e.g. when I'm at the university in a 
shared building with the business university (WU), I try switching from 
eduroam to eduroam-wu when reception of my university's eduroam is poor), NM 
just happily stays "connected" even with 100% packet loss.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: wireless-tools/net-tools are DEPRECATED

[Ben Boeckel]

Kevin Kofler  wrote:
> I've found NM to actually be quite tolerant of spotty wireless connections. 
> In fact, usually, it's me who triggers a reconnect (or if possible, a 
> connect to a different access point, e.g. when I'm at the university in a 
> shared building with the business university (WU), I try switching from 
> eduroam to eduroam-wu when reception of my university's eduroam is poor), NM 
> just happily stays "connected" even with 100% packet loss.

Ah, that's different than when I last used NM on my laptop due to these
issues (F13 beta-ish timeframe).

--Ben

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

PackageKit in Fedora 15 (beta)

[Ilyes Gouta]

Hi,

Removing PackageKit In Fedora 14 was easy and painless since it causes up to
5 packages, all *really* related to PackageKit in the form of a yum-plugin
and few other things.

On Fedora 15, trying to "yum remove PackageKit" causes the system to attempt
removing up to 74 MB worth of software, including gdm, empathy, bluez and
gnome-shell  Which is pointless.

Is it *really* required to have PackageKit so deeply integrated and made an
essential package on the system. AFAIK, it's essentially a helper and a
front-end for yum, right?

Is it possible to recover Fedora 14's lightweight dependencies set, for
PackageKit?

Thanks,

-Ilyes
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: PackageKit in Fedora 15 (beta)

[Reindl Harald]

Am 24.04.2011 20:04, schrieb Ilyes Gouta:
> Hi,
> 
> Removing PackageKit In Fedora 14 was easy and painless since it causes up to 
> 5 packages, all *really* related to
> PackageKit in the form of a yum-plugin and few other things.
> 
> On Fedora 15, trying to "yum remove PackageKit" causes the system to attempt 
> removing up to 74 MB worth of
> software, including gdm, empathy, bluez and gnome-shell  Which is 
> pointless.
> 
> Is it *really* required to have PackageKit so deeply integrated and made an 
> essential package on the system. AFAIK,
> it's essentially a helper and a front-end for yum, right?
> 
> Is it possible to recover Fedora 14's lightweight dependencies set, for 
> PackageKit?
> 
> Thanks,
> -Ilyes

generellay the dependecies are getting bigger with every release
it should be possible to install a leightweigt system

yes, hard-disk are getting cheaper but time!
on the other hand running 20-30 Fedora VMs on a SAN-Storage
disk space is not so cheap as at home and the overhead multiplies

means: i like to remove everything that is not active used because
distupgrades and normal updates are much bigger and especially on
servers everything which is not installed is not vulnerable



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: PackageKit in Fedora 15 (beta)

[Ilyes Gouta]

Hi,

I filed a bug: https://bugzilla.redhat.com/show_bug.cgi?id=699263

-Ilyes

On Sun, Apr 24, 2011 at 7:12 PM, Reindl Harald wrote:

>
>
> Am 24.04.2011 20:04, schrieb Ilyes Gouta:
> > Hi,
> >
> > Removing PackageKit In Fedora 14 was easy and painless since it causes up
> to 5 packages, all *really* related to
> > PackageKit in the form of a yum-plugin and few other things.
> >
> > On Fedora 15, trying to "yum remove PackageKit" causes the system to
> attempt removing up to 74 MB worth of
> > software, including gdm, empathy, bluez and gnome-shell  Which is
> pointless.
> >
> > Is it *really* required to have PackageKit so deeply integrated and made
> an essential package on the system. AFAIK,
> > it's essentially a helper and a front-end for yum, right?
> >
> > Is it possible to recover Fedora 14's lightweight dependencies set, for
> PackageKit?
> >
> > Thanks,
> > -Ilyes
>
> generellay the dependecies are getting bigger with every release
> it should be possible to install a leightweigt system
>
> yes, hard-disk are getting cheaper but time!
> on the other hand running 20-30 Fedora VMs on a SAN-Storage
> disk space is not so cheap as at home and the overhead multiplies
>
> means: i like to remove everything that is not active used because
> distupgrades and normal updates are much bigger and especially on
> servers everything which is not installed is not vulnerable
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: PackageKit in Fedora 15 (beta)

[Richard Hughes]

On 24 April 2011 19:24, Ilyes Gouta  wrote:
> I filed a bug: https://bugzilla.redhat.com/show_bug.cgi?id=699263

I've commented on this, and closed it NOTABUG. Sorry.

Richard
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: wireless-tools/net-tools are DEPRECATED

[Rahul Sundaram]

On 04/24/2011 10:43 PM, Ben Boeckel wrote:
> Kevin Kofler  wrote:
>> I've found NM to actually be quite tolerant of spotty wireless connections. 
>> In fact, usually, it's me who triggers a reconnect (or if possible, a 
>> connect to a different access point, e.g. when I'm at the university in a 
>> shared building with the business university (WU), I try switching from 
>> eduroam to eduroam-wu when reception of my university's eduroam is poor), NM 
>> just happily stays "connected" even with 100% packet loss.
> Ah, that's different than when I last used NM on my laptop due to these
> issues (F13 beta-ish timeframe)

It isn't useful to talk about NM from that time period anymore.  There
has been major rewrites of it and current NM is not even comparable
really.  Try the latest and then offer comments. 

Rahul

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: PackageKit in Fedora 15 (beta)

[Rahul Sundaram]

On 04/24/2011 11:54 PM, Ilyes Gouta wrote:
> Hi,
>
> I filed a bug:  https://bugzilla.redhat.com/show_bug.cgi?id=699263
>
> -Ilyes

PackageKit isn't just a yum frontend and is likely to be integrated more
and more with key components as we go forward.  If you aren't actively
using the GNOME or KDE frontend, just remove those and leave the
framework as it is. 

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: PackageKit in Fedora 15 (beta)

[Ilyes Gouta]

Rahul,

> If you aren't actively using the GNOME or KDE frontend, just remove those
and leave the
> framework as it is.

That was tough :)

AFAIK (and I might be wrong) deep PacakgeKit integration wasn't clearly
mentioned in Fedora 15's feature set list.

I was just asking if it was possible to recover to a situation where the
user would still have the choice, to use or not use PackageKit. That's all.
Fedora 14 gave that choice.

Alright, thanks for explaining!

-Ilyes

On Sun, Apr 24, 2011 at 7:55 PM, Rahul Sundaram  wrote:

> On 04/24/2011 11:54 PM, Ilyes Gouta wrote:
> > Hi,
> >
> > I filed a bug:  https://bugzilla.redhat.com/show_bug.cgi?id=699263
> >
> > -Ilyes
>
> PackageKit isn't just a yum frontend and is likely to be integrated more
> and more with key components as we go forward.  If you aren't actively
> using the GNOME or KDE frontend, just remove those and leave the
> framework as it is.
>
> Rahul
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: PackageKit in Fedora 15 (beta)

[Rahul Sundaram]

On 04/25/2011 12:36 AM, Ilyes Gouta wrote:
> Rahul,
>
> > If you aren't actively using the GNOME or KDE frontend, just remove
> those and leave the
> > framework as it is.
>
> That was tough :)
>
> AFAIK (and I might be wrong) deep PacakgeKit integration wasn't
> clearly mentioned in Fedora 15's feature set list.

It isn't a feature that is driven by Fedora and hence it won't be in the
feature list.  It is just what happens when more upstream software take
advantage of it over time.. 

>
> I was just asking if it was possible to recover to a situation where
> the user would still have the choice, to use or not use PackageKit.
> That's all. Fedora 14 gave that choice.
>
> Alright, thanks for explaining!

Just leave it installed.  You don't have to use it.  That is still a
choice. 

Rahul

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: PackageKit in Fedora 15 (beta)

[Ilyes Gouta]

Hi Rahul,

> It isn't a feature that is driven by Fedora and hence it won't be in the
> feature list.  It is just what happens when more upstream software take
> advantage of it over time..

Yes, NOW it's clear! Thanks Rahul!

-Ilyes

On Sun, Apr 24, 2011 at 8:16 PM, Rahul Sundaram  wrote:

> On 04/25/2011 12:36 AM, Ilyes Gouta wrote:
> > Rahul,
> >
> > > If you aren't actively using the GNOME or KDE frontend, just remove
> > those and leave the
> > > framework as it is.
> >
> > That was tough :)
> >
> > AFAIK (and I might be wrong) deep PacakgeKit integration wasn't
> > clearly mentioned in Fedora 15's feature set list.
>
> It isn't a feature that is driven by Fedora and hence it won't be in the
> feature list.  It is just what happens when more upstream software take
> advantage of it over time..
>
> >
> > I was just asking if it was possible to recover to a situation where
> > the user would still have the choice, to use or not use PackageKit.
> > That's all. Fedora 14 gave that choice.
> >
> > Alright, thanks for explaining!
>
> Just leave it installed.  You don't have to use it.  That is still a
> choice.
>
> Rahul
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Possible to submit an update without obsoleting?

[Richard W.M. Jones]

On Sun, Apr 24, 2011 at 03:57:00PM +0200, Kevin Kofler wrote:
> Michael Schwendt wrote:
> > It sounds as if bodhi would need to stop obsoleting an update that
> > is "pending -> stable", so you could submit the next test-update a little
> > bit earlier.Current behaviour (I think) is that bodhi obsoletes
> > updates until one is "pushed to stable".
> 
> Bodhi actually doesn't obsolete an update that's queued for stable.

OK, good to know.  I'm about to submit an update based on this
knowledge ...

> There's only a problem when you can't queue the previous update for
> stable yet because of those darn minimum testing requirements.

... however as you say there are deeper problems here like the
arbitrary testing period (which is stupid) and the fact that we can't
pipeline updates.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: wireless-tools/net-tools are DEPRECATED

[Tomasz Torcz]

On Sun, Apr 24, 2011 at 07:10:48PM +0200, Kevin Kofler wrote:
> Ben Boeckel wrote:
> > One thing I liked a lot with my ifconfig scripts/wpa_supplicant pairing
> > is that when wireless is spotty, the network doesn't keep going up and
> > down. Instead, applications see lots of dropped packets. When
> > reauthentication can take 5 to 10s (or more), assuming that the
> > connection is steady when its just spotty can result in better behavior.
> > Also nice when quickly swapping ethernet cables. A "network is gone"
> > event gets different reactions from applications (particularly those
> > that are NM-aware which makes those applications MUCH more annoying to
> > deal with in these cases) than "some packets were lost". An option to
> > "persist connections despite something probably not actually existing"
> > would be nice for situations like this.
> 
> I've found NM to actually be quite tolerant of spotty wireless connections. 
> In fact, usually, it's me who triggers a reconnect (or if possible, a 
> connect to a different access point, e.g. when I'm at the university in a 
> shared building with the business university (WU), I try switching from 
> eduroam to eduroam-wu when reception of my university's eduroam is poor), NM 
> just happily stays "connected" even with 100% packet loss.

  Well, I have opposite experience with my wired connection.  It takes only
about 5 flip-flop (carrier on/carrier off) in 10 seconds for NM to consider
connection down.

-- 
Tomasz Torcz "God, root, what's the difference?"
xmpp: zdzich...@chrome.pl "God is more forgiving."

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

F-15 Branched report: 20110424 changes

[Branched Report]

Compose started at Sun Apr 24 13:16:25 UTC 2011

Broken deps for x86_64
--
collectd-mysql-4.10.2-2.fc15.x86_64 requires 
libmysqlclient.so.16()(64bit)
collectd-mysql-4.10.2-2.fc15.x86_64 requires 
libmysqlclient.so.16(libmysqlclient_16)(64bit)
cpm-0.23-0.3.beta.fc12.x86_64 requires libdotconf-1.0.so.0()(64bit)
db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0
dbmail-3.0.0-0.3.rc1.fc15.x86_64 requires libevent-1.4.so.2()(64bit)
dbmail-auth-ldap-3.0.0-0.3.rc1.fc15.x86_64 requires 
libevent-1.4.so.2()(64bit)
dh-make-0.55-3.fc15.noarch requires debhelper
eog-plugins-2.91.90-1.fc15.x86_64 requires 
libchamplain-gtk-0.10.so.0()(64bit)
eog-plugins-2.91.90-1.fc15.x86_64 requires 
libchamplain-0.10.so.0()(64bit)
1:fife-0.3.2-1.fc15.i686 requires libboost_regex.so.1.44.0
1:fife-0.3.2-1.fc15.i686 requires libboost_system.so.1.44.0
1:fife-0.3.2-1.fc15.i686 requires libboost_filesystem.so.1.44.0
1:fife-0.3.2-1.fc15.x86_64 requires libboost_regex.so.1.44.0()(64bit)
1:fife-0.3.2-1.fc15.x86_64 requires libboost_system.so.1.44.0()(64bit)
1:fife-0.3.2-1.fc15.x86_64 requires 
libboost_filesystem.so.1.44.0()(64bit)
file-browser-applet-0.6.6-1.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::ScrolledWindow)
gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::Dialog)
gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::Toolbar)
gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::TreeView)
gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::MenuBar)
gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::VBox)
gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::Window)
gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::MessageDialog)
glunarclock-0.34.1-1.fc14.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-bubblemon-2.0.15-1.fc13.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-cpufire-1.6-3.fc14.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-globalmenu-0.7.9-1.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-grandr-0.4.1-2.fc12.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-music-2.5.1-5.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-sensors-2.2.7-4.fc15.i686 requires libpanel-applet-2.so.0
gnome-applet-sensors-2.2.7-4.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-sshmenu-3.18-3.fc15.noarch requires ruby(panelapplet2)
gnome-applet-window-picker-0.5.8-2.fc14.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
1:gnome-applets-2.32.0-3.fc15.x86_64 requires 
libpanel-applet-3.so.0()(64bit)
1:gnome-applets-2.32.0-3.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
1:gnome-applets-2.32.0-3.fc15.x86_64 requires libgweather.so.1()(64bit)
gnome-netstatus-2.28.2-1.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires 
libgpilotd.so.5()(64bit)
gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires 
libgpilotdcm.so.4()(64bit)
gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires 
libgpilotdconduit.so.3()(64bit)
gnome-python2-applet-2.32.0-1.fc14.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires 
libbrasero-media.so.1()(64bit)
gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires 
libbrasero-burn.so.1()(64bit)
gnome-python2-evince-2.32.0-1.fc14.x86_64 requires 
libevview.so.3()(64bit)
gnome-python2-evince-2.32.0-1.fc14.x86_64 requires 
libevdocument.so.3()(64bit)
gnome-python2-evolution-2.32.0-1.fc14.x86_64 requires 
libcamel-1.2.so.19()(64bit)
gnome-python2-gdl-2.25.3-22.fc15.x86_64 requires libgdl-1.so.3()(64bit)
gnome-python2-totem-2.32.0-1.fc14.x86_64 requires 
libgnome-media-profiles.so.0()(64bit)
gnome-rdp-0.2.3-6.fc12.x86_64 requires mono(Mono.Data.SqliteClient) = 
0:2.0.0.0
gnome-themes-2.32.0-5.fc15.noarch requires gtk-theme-engine-clearlooks
gnomeradio-1.8-9.fc15.x86_64 requires libgtk-3.0.so.0()(64bit)
gnomeradio-1.8-9.fc15.x86_64 requires libgdk-3.0.so.0()(64bit)
gnotime-2.3.0-8.fc15.x86_64 requires libgtkhtml-3.15.so.19()(64bit)
gnubiff-2.2.13-4.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit)
gnustep-back-0.18.0-4.fc14.x86_64 requires libobjc.so.2()(64bit)
gnustep-back-0.18.0-4.fc14.x86_64 requires 
libgnustep-base.so.1.20()(64bit)
gnustep-examples-1.3.0-4.fc15.x86_64 requires 
libgnustep-base.so.1.20()(64bit)
gnustep-examples-1.3.0-4.fc15.x86_64 requires libobjc.so.2()(64bit)
gnustep-gui-0.18.0-2.fc14.x86_64 requires 
libgnustep-base.so.1.20()(64bit)
gnu