Re: A comps group for the Design Suite

[Nicu Buculei]

On 10/12/2010 09:25 PM, Bill Nottingham wrote:
> Ankur Sinha (sanjay.an...@gmail.com) said:
>> Since the design team is using a "design suite", would it be possible to
>> please create a group in comps for the purpose? It would make
>> installation of the design suite much easier for end users.
>>
>> The alternative is to create a meta package which isn't welcomed.
>>
>> This[1] is the tentative list of packages.
>>
>> [1]http://fedoraproject.org/wiki/Design_Suite_Planning#Included
>
> There appears to be a lot of overlap here with the graphics group
> (and some with other groups). Perhaps it's best to just expand
> that group into a more full-fledged design suite?

They are different things: the graphics group is the sum of all packages 
about graphics, a "design suite" group would be a way for people to 
install the Design Suite Spin (a collection of "best of breed" apps) if 
they already have Fedora installed.

-- 
nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ethtool not in default system anymore?

[Jeff Garzik]

On 10/12/2010 07:37 PM, Gregory Maxwell wrote:
> On Tue, Oct 12, 2010 at 7:28 PM, Chris Adams  wrote:
>> I noticed that ethtool is not in the default install anymore (probably
>> for a release or so, but I didn't notice it until now).  Why is that?
>> It is the only tool that can show and configure a variety of network
>> device options, such as speed/duplex negotiation, wake-on-LAN, and TCP
>> offloading.  There is support in the ifcfg-eth* files for calling it as
>> part of interface setup (don't know if that's carried forward to NM,
>> should be considered a bug in NM if not).
>
> mii-tool.

mii-tool has been deprecated for ages.  ethtool has a higher likelihood 
of working on modern NICs.

Jeff


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

Re: Git commit in all available branches

[Peter Hutterer]

On Tue, Oct 12, 2010 at 01:08:17PM +1000, Jeffrey Fearn wrote:
> Kevin Fenzi wrote:
> > On Tue, 12 Oct 2010 09:32:15 +1000
> > Jeffrey Fearn  wrote:
> > 
> >> What do you mean "leave it alone"? The people using it WANT the
> >> changes. Why are you telling them how they can use their system?
> > 
> > Not at all. :) 
> > 
> >> They want the changes, it's trivial for me to give them the changes,
> >> why wouldn't I give them the changes?
> > 
> > Because it breaks things or changes behavior for another large group of
> > users? 
> 
> As I said, if I was doing a systems level package I'd not do it, but at 
> the application level you only tend to affect users of your application.
> 
> > Can we perhaps stop talking in the abstract? What package is this?
> 
> publican\*
> 
> > What sort of updates does it get? 
> 
> Large changes of every kind: bug fixes, new features, changes in 
> behavior of existing features. Everything you'd expect of an application 
> that is fairly young and has a demanding user base ... a very demanding 
> user base ... OK, an extremely demanding user base ... yeah, I have ulcers.

the only non-demanding user base is the one of size 0.

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

Re: [Test-Announce] Fedora 14 Final TC1 Available Now! (Live images not yet)

[Adam Williamson]

On Tue, 2010-10-12 at 20:47 -0400, Andre Robatino wrote:
> Fedora 14 Final TC1 is now available [1].  Please refer to the following
> pages for download links and testing instructions.
> 
> Installation:
> 
> https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test
> 
> Desktop:
> 
> https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test

I'm afraid there's no live images yet, which makes desktop validation
testing hard. I have now requested these from release engineering,
hopefully we'll get them tomorrow
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ethtool not in default system anymore?

[Matthew Miller]

On Tue, Oct 12, 2010 at 07:06:50PM -0500, Chris Adams wrote:
> It looks like up through F12, initscripts required ethtool (so it was
> definately installed by default).  I see this in the RPM changelog:

Still the case in RHEL5, FWIW.

-- 
Matthew Miller 
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Test-Announce] Fedora 14 Final TC1 Available Now!

[Andre Robatino]

Fedora 14 Final TC1 is now available [1].  Please refer to the following
pages for download links and testing instructions.

Installation:

https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test

Desktop:

https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test

Ideally, all Alpha, Beta, and Final priority test cases for installation
[2] and desktop [3] should pass in order to meet the Final Release
Criteria [4]. Help is available on #fedora-qa on irc.freenode.net [5],
or on the test list [6].

IMPORTANT: The "real" TC1 (the one that the above test results pages
refer to) is in the "14.TC1.1" directory. The old version is still in
"14.TC1". Be sure to use the "14.TC1.1" version for testing.

[1] http://poelstra.fedorapeople.org/schedules/f-14/f-14-quality-tasks.html
[2] https://fedoraproject.org/wiki/QA:Installation_validation_testing
[3] https://fedoraproject.org/wiki/QA:Desktop_validation_testing
[4] https://fedoraproject.org/wiki/Fedora_14_Final_Release_Criteria
[5] irc://irc.freenode.net/fedora-qa
[6] https://admin.fedoraproject.org/mailman/listinfo/test



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

Re: Ubuntu 10.10's installer looks rather nice

[Jeff Spaleta]

On Tue, Oct 12, 2010 at 12:46 PM, Jeff Spaleta  wrote:
> The low activity on the Ubuntu torrent server generally really leaves
> me scratching my head as to how to evaluate the applicability of the
> alternative image approach.

Just to provide some closure on this. I watched the Ubuntu torrent
tracker for a few hours today and saw the aggregate total downloaded
column at the end of the table drop to a lower number.
>From this I surmise that the ubuntu torrent tracker is not configured
as I would expect. It seems like its purging its aggregate data nearly
continuously.  This makes it an invalid source of trending data.

Evan, you might want to poke at a sysadmin inside your fenceline and
see if they can change the behaviour so that its not purging its
aggregate download stats so aggressively so that it can be used as a
data source for release timescale and multi-release timescale
trending.  There's precious little publicly available information
about linux distribution update trending. It seems a shame to squander
Ubuntu's torrent tracker aggregate stats.

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

Re: ethtool not in default system anymore?

[Chris Adams]

Once upon a time, Michael Cronenworth  said:
> Chris Adams wrote:
> > Maybe ethtool should be added to @Base?
> 
> Or patch initscripts to use ethtool instead of deprecated cruft.

You cut out the part of my email where I quoted the changelog showing
that had already been done.

The net-tools package should be included anyway (although maybe without
mii-tool), as it includes commonly used tools like ifconfig, arp, route,
hostname, netstat, etc.  Even if some of those commands are obsoleted by
ip, they are pretty much required for compatiblity.  net-tools also has
ether-wake for sending wake-on-LAN packets.

-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ethtool not in default system anymore?

[Gregory Maxwell]

On Tue, Oct 12, 2010 at 8:01 PM, Chris Adams  wrote:
> Once upon a time, Gregory Maxwell  said:
>> On Tue, Oct 12, 2010 at 7:28 PM, Chris Adams  wrote:
>> > I noticed that ethtool is not in the default install anymore (probably
>> > for a release or so, but I didn't notice it until now).  Why is that?
>> > It is the only tool that can show and configure a variety of network
>> > device options, such as speed/duplex negotiation, wake-on-LAN, and TCP
>> > offloading.  There is support in the ifcfg-eth* files for calling it as
>> > part of interface setup (don't know if that's carried forward to NM,
>> > should be considered a bug in NM if not).
>>
>> mii-tool.
>
> Does that work with all NICs now?  I used to run into NICs that it
> didn't handle (but ethtool did).  I haven't looked at mii-tool in a
> while though.
>
> In any case, that handles one thing that ethtool does (speed/duplex);
> what about the rest?  Also, AFAIK there's no nice hook to run mii-tool
> (or anything else) in ifup-eth like there is for ethtool.

I don't know— but it also won't let you adjust things like interrupt
mitigation— which is essential for low latency audio over the network
because lots of cards go into idiotic buffering modes at fairly low
PPS rates and the latency shoots through the roof... (my use case)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ethtool not in default system anymore?

[Michael Cronenworth]

Chris Adams wrote:
> Maybe ethtool should be added to @Base?

Or patch initscripts to use ethtool instead of deprecated cruft.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ethtool not in default system anymore?

[Chris Adams]

Once upon a time, Jesse Keating  said:
> Looking at comps, it seems ethtool was never listed, so it must have
> been pulled in as a dep of something (if it ever was installed by
> default).  I'd say look at your older systems and see what, if anything,
> requires ethtool.

It looks like up through F12, initscripts required ethtool (so it was
definately installed by default).  I see this in the RPM changelog:

* Mon Feb 15 2010 Bill Nottingham  - 9.05-1
- network-functions: don't use ethtool for link state, assorted other cleanups

Of course, there's also this:

* Mon Aug 03 2009 Bill Nottingham  - 8.96-1
- only use ethtool for link checking; no more mii-tool

mii-tool gets pulled in by default because initscripts depends on
net-tools.  However, the mii-tool declares itself obsolete and
recommends ethtool.  Maybe ethtool should be added to @Base?
-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ethtool not in default system anymore?

[Chris Adams]

Once upon a time, Gregory Maxwell  said:
> On Tue, Oct 12, 2010 at 7:28 PM, Chris Adams  wrote:
> > I noticed that ethtool is not in the default install anymore (probably
> > for a release or so, but I didn't notice it until now).  Why is that?
> > It is the only tool that can show and configure a variety of network
> > device options, such as speed/duplex negotiation, wake-on-LAN, and TCP
> > offloading.  There is support in the ifcfg-eth* files for calling it as
> > part of interface setup (don't know if that's carried forward to NM,
> > should be considered a bug in NM if not).
> 
> mii-tool.

Does that work with all NICs now?  I used to run into NICs that it
didn't handle (but ethtool did).  I haven't looked at mii-tool in a
while though.

In any case, that handles one thing that ethtool does (speed/duplex);
what about the rest?  Also, AFAIK there's no nice hook to run mii-tool
(or anything else) in ifup-eth like there is for ethtool.

-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ethtool not in default system anymore?

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/12/10 4:28 PM, Chris Adams wrote:
> I noticed that ethtool is not in the default install anymore (probably
> for a release or so, but I didn't notice it until now).  Why is that?
> It is the only tool that can show and configure a variety of network
> device options, such as speed/duplex negotiation, wake-on-LAN, and TCP
> offloading.  There is support in the ifcfg-eth* files for calling it as
> part of interface setup (don't know if that's carried forward to NM,
> should be considered a bug in NM if not).
> 
> Is there a replacement that I'm not aware of?
> 
> I have run into flakey switches and such where you have to force
> speed/duplex to communicate (yes, such switches are crap, but when it
> isn't your network, you don't get to choose).  Not having a tool to do
> that already installed makes it impossible to fix.

Looking at comps, it seems ethtool was never listed, so it must have
been pulled in as a dep of something (if it ever was installed by
default).  I'd say look at your older systems and see what, if anything,
requires ethtool.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAky08rAACgkQ4v2HLvE71NUV5ACgjimTcwkMIfjmV5psXQ56PqYl
1pwAnjkksjdtGQchxySmYhF4iEbOHiHx
=R2u9
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ethtool not in default system anymore?

[Matt McCutchen]

On Tue, 2010-10-12 at 19:37 -0400, Gregory Maxwell wrote:
> On Tue, Oct 12, 2010 at 7:28 PM, Chris Adams  wrote:
> > I noticed that ethtool is not in the default install anymore [...]
> 
> mii-tool.

The mii-tool man page claims it is deprecated in favor of ethtool.  In
fact, neither is in any comps groups:

# yum info-groups ethtool net-tools
...
 Installed Packages 
-- Unknown --  2 (100%)
  2:ethtool-2.6.33-0.1.fc13.x86_64
  net-tools-1.60-103.fc13.x86_64

 Available Packages 
-- Unknown --  3 (100%)
  2:ethtool-2.6.33-0.1.fc13.x86_64
  net-tools-1.60-102.fc13.x86_64
  net-tools-1.60-103.fc13.x86_64

-- 
Matt

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

Re: ethtool not in default system anymore?

[Gregory Maxwell]

On Tue, Oct 12, 2010 at 7:28 PM, Chris Adams  wrote:
> I noticed that ethtool is not in the default install anymore (probably
> for a release or so, but I didn't notice it until now).  Why is that?
> It is the only tool that can show and configure a variety of network
> device options, such as speed/duplex negotiation, wake-on-LAN, and TCP
> offloading.  There is support in the ifcfg-eth* files for calling it as
> part of interface setup (don't know if that's carried forward to NM,
> should be considered a bug in NM if not).

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

ethtool not in default system anymore?

[Chris Adams]

I noticed that ethtool is not in the default install anymore (probably
for a release or so, but I didn't notice it until now).  Why is that?
It is the only tool that can show and configure a variety of network
device options, such as speed/duplex negotiation, wake-on-LAN, and TCP
offloading.  There is support in the ifcfg-eth* files for calling it as
part of interface setup (don't know if that's carried forward to NM,
should be considered a bug in NM if not).

Is there a replacement that I'm not aware of?

I have run into flakey switches and such where you have to force
speed/duplex to communicate (yes, such switches are crap, but when it
isn't your network, you don't get to choose).  Not having a tool to do
that already installed makes it impossible to fix.
-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: It's been a while, but I could do with a hand...

[John5342]

On Wed, Oct 13, 2010 at 00:05, Paul F. Johnson
 wrote:
> Hi,
>
> It's been a while since I've done any sort of uploading and in that time
> my box died, has been rebuilt and is running happily on rawhide.
>
> Problem is my scripts for uploading have gone! I've followed the
> information on the wiki but when I try to upload, I'm getting
>
> [p...@pb3 common]$ ./cvs-import.sh
> ~/rpmbuild/SRPMS/mono-2.8-1.1.fc15.src.rpm
> Checking out module: 'mono'
> Unpacking source package: mono-2.8-1.1.fc15.src.rpm...
> cvs [server aborted]: "remove" requires write access to the repository
>
> I've downloaded a client side cert, changed my gpg key and ssh key
> (uploaded both to my details on the fas system).
>
> I've done export CVS_RSH=ssh and export
> CVSROOT=:ext:p...@cvs.fedoraproject.org:/cvs/pkgs
>
> Have I gone wrong somewhere and to make life easy, is there a GUI way to
> upload to the rawhide repos yet?

Everything uses git now. See
http://fedoraproject.org/wiki/PackageMaintainers/Join and for some
equivelant commands to cvs
http://fedoraproject.org/wiki/Using_Fedora_GIT is useful.

-- 
There are 10 kinds of people in the world: Those who understand binary
and those who don't...
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Chain builds for non-rawhide

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/7/10 11:59 PM, Thomas Spura wrote:
> How about let bodhi do the tagging?
> When there is an update, you could click on "tag this package", and
> bodhi will do the rest. If the update is deleted or obsoleted by
> another one, the tag will be deleted again.
> 
> This doesn't solve the problem, that maintainers could tag a package
> and never push the update out, but that could happen with manual
> tagging too, isn't it?

We've (as in releng and some members of fesco) have discussed something
like this in the past.  We've wanted some functionality out of bodhi to
track things like buildroot contents used for packages, and if an update
is requested to go live it would block on whether or not a buildroot
component also has gone live or is requested to go live.  Until we get
some sort of automation on prevention of this, we won't likely be
automating or making it easier to do buildroot overrides.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAky06r0ACgkQ4v2HLvE71NU9VQCfV9FoOrbsNOiZbu00AibJUtd7
3NkAoIA9DDV1AY9pwAFXEjTbuxCAI8yB
=DW7X
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Git commit in all available branches

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/8/10 7:03 AM, Pavel Alexeev (aka Pahan-Hubbitus) wrote:
>  In most cases I try sync all branches if there no real reasons to make
> differences.
> 
> After made some changes in origin/master and commit is I also must do
> for each available branches something similar:
> fedpkg switch-branch el5;
> git pull
> git merge origin/master
> git push
> fedpkg build
> fedpkg update
> 
> Off course I can script it with shell, but may be there already
> possibility to "commit in few branches"? Something like this:
> fedpkg commit -F clog -B "f12,f13,f14,el5,el6"
> 
> And will be very cool to start build and push updates (by single
> template interactively filled one time) also for several branches.

I believe there is already a filed RFE for this in fedpkg, and if not it
is on my mind for future functionality.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAky06kcACgkQ4v2HLvE71NXfMACgx4uftMi8pnyYCJSzr7Lt0IJu
N1gAnjDA1wn2/qqiSJSjMlNftJXr0kjK
=t82w
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

It's been a while, but I could do with a hand...

[Paul F. Johnson]

Hi,

It's been a while since I've done any sort of uploading and in that time
my box died, has been rebuilt and is running happily on rawhide.

Problem is my scripts for uploading have gone! I've followed the
information on the wiki but when I try to upload, I'm getting

[p...@pb3 common]$ ./cvs-import.sh
~/rpmbuild/SRPMS/mono-2.8-1.1.fc15.src.rpm
Checking out module: 'mono'
Unpacking source package: mono-2.8-1.1.fc15.src.rpm...
cvs [server aborted]: "remove" requires write access to the repository

I've downloaded a client side cert, changed my gpg key and ssh key
(uploaded both to my details on the fas system).

I've done export CVS_RSH=ssh and export
CVSROOT=:ext:p...@cvs.fedoraproject.org:/cvs/pkgs

Have I gone wrong somewhere and to make life easy, is there a GUI way to
upload to the rawhide repos yet?

Paul
-- 
Vertraue mir, ich weiss, was ich mache...

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

Re: OpenLayers update?

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/8/10 11:58 PM, Ankur Sinha wrote:
> (no one uses
> rawhide for development btw,)

That's a pretty broad and unhelpful and untrue statement.  I know of
plenty of people who use rawhide for development.  Continuing to
perpetuate that rawhide is unusable for development only makes things
worse, by spreading the idea that it's OK to break rawhide.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAky06NgACgkQ4v2HLvE71NXOywCfZ4DcUUpIaADDYdL0VGcWK5QQ
wiYAnjTMapZNvq2xVm68CCmPBWGod75X
=aRU1
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Selinux: SSH broken after F-13 --> F-14 upgrade

[yersinia]

On Tue, Oct 12, 2010 at 8:02 PM, Daniel J Walsh  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/12/2010 01:49 PM, Michal Hlavinka wrote:
>> Hi all,
>>
>> I've recently upgraded my system, but after that I was not able to connect 
>> through ssh. More things are wrong (from my POV):
>> 1)SELinux blocks all nondefault ports for ssh
>>
>> I have ssh confugured to use different port than 22 for security reasons and 
>> I think there is a lot of people doing that.
>>
> You need to tell SELinux which port to use for sshd.
>
> semanage port -a -t sshd_port_t -p tcp 6520
>
>> Question: Is it worth blocking all ports for ssh?
>>
>> 2)SELinux did not show any sealert warning about this. Running sealert -b 
>> shows no problem. There is one message in /var/log/messages:
>> kernel: [90346.301108] type=1400 audit(1286901219.350:29): avc:  denied  { 
>> name_bind } for  pid=6830 comm="sshd" src=6520 
>> scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 
>> tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket
>>
>> Question: This should be reported afaik, so it's a bug, right?
>>
> No.  Hacker gets some control over ssh and is able to make it bind to
> port 80, now he can read apache content.
Hmmm, it is  enough that sshd bind to port 80 to access the files of
apache? it seems strange. am i missing something in the TE rule?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Summary/Minutes from today's FESCo meeting (2010-10-12)

[Kevin Fenzi]

===
#fedora-meeting: FESCO (2010-10-12)
===

Meeting started by nirik at 19:30:01 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2010-10-12/fesco.2010-10-12-19.30.log.html

Meeting summary
---
* init process  (nirik, 19:30:01)
  * mclasen said he would be about 15min late.  (nirik, 19:31:10)

* #473 new meeting time (redux)  (nirik, 19:34:03)
  * LINK: https://fedorahosted.org/fesco/ticket/473   (nirik, 19:34:03)
  * AGREED: new meeting time starting next week: Wed at 19 UTC  (nirik,
19:49:45)
  * ACTION: nirik will check with other meeting thats scheduled then.
(nirik, 19:50:11)
  * LINK: http://fedoraproject.org/wiki/Fedora_meeting_channel   (nirik,
19:50:53)

* Updates policy / Vision implementation status  (nirik, 19:52:28)

* #351 Create a policy for updates - status report on implementation
  (nirik, 19:52:28)

* #382 Implementing Stable Release Vision  (nirik, 19:52:28)
  * AGREED: Scratch that last time, will try 18:30UTC next wed.  (nirik,
19:59:10)
  * LINK: http://fedoraproject.org/wiki/Category:Copr   (nirik,
20:11:17)
  * ACTION: cwickert to work on feature updates repo/ideas.  (nirik,
20:13:20)

* #472 About Mozilla's decision to not allow using the system's libvpx
  (nirik, 20:14:19)
  * LINK: https://fedorahosted.org/fesco/ticket/472   (nirik, 20:14:20)
  * LINK: https://bugzilla.mozilla.org/show_bug.cgi?id=577653#c9
(nirik, 20:17:40)
  * AGREED: firefox has a exception with libvpx for now.  (nirik,
20:35:34)

* #302 libssh2 - non-responsive maintainer  (nirik, 20:35:48)
  * LINK: https://fedorahosted.org/fesco/ticket/302   (nirik, 20:35:48)
  * AGREED: will allow kdudka to commit to libssh2  (nirik, 20:43:49)

* #474 Package Criteria 'upgradepath' not clear  (nirik, 20:43:55)
  * LINK: https://fedorahosted.org/fesco/ticket/474   (nirik, 20:43:55)
  * AGREED: Don't consider updates-testing repo for now.  (nirik,
20:57:51)

* Open Floor  (nirik, 20:58:06)
  * LINK: https://fedorahosted.org/fesco/ticket/475   (nirik, 20:59:09)

Meeting ended at 21:03:31 UTC.




Action Items

* nirik will check with other meeting thats scheduled then.
* cwickert to work on feature updates repo/ideas.


Action Items, by person
---
* cwickert
  * cwickert to work on feature updates repo/ideas.
* nirik
  * nirik will check with other meeting thats scheduled then.
* **UNASSIGNED**
  * (none)

People Present (lines said)
---
* nirik (154)
* cwickert (54)
* mjg59 (39)
* pjones (32)
* ajax (32)
* notting (24)
* SMParrish (23)
* jlaska (18)
* spot (17)
* mclasen (12)
* zodbot (6)
* drago01 (3)
* cwickert_ (1)
* skvidal (1)
* kylem (0)
--
19:30:01  #startmeeting FESCO (2010-10-12)
19:30:01  Meeting started Tue Oct 12 19:30:01 2010 UTC.  The chair is 
nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:30:01  Useful Commands: #action #agreed #halp #info #idea #link 
#topic.
19:30:01  #meetingname fesco
19:30:01  #chair mclasen notting nirik SMParrish kylem ajax pjones 
cwickert mjg59
19:30:01  #topic init process
19:30:01  The meeting name has been set to 'fesco'
19:30:01  Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 
nirik notting pjones
19:30:09  Afternoon
19:30:41  morning.
19:31:10  #info mclasen said he would be about 15min late.
19:31:38 * notting is here
19:31:46 * pjones is too
19:32:06 * nirik waits for at least one more to have quorum.
19:32:23  I think so, Brain, but why would anyone want to Pierce Brosnan?
19:32:29 * SMParrish here
19:32:45  har.
19:32:57  Sorry I missed last week but wife totaled the car :(
19:33:03  SMParrish: ugh :/
19:33:05  yikes. :( She ok?
19:33:06  sorry to hear that.
19:33:34  I guess we can go ahead and get started then... shall we start 
with the meeting time discussion?
19:33:40  Yes she is fine, She rolled the car, so now I have to deal 
with insurance and got into debt to buy a new one
19:33:56  :( no fun.
19:34:03  #topic #473 new meeting time (redux)
19:34:03  https://fedorahosted.org/fesco/ticket/473
19:34:27  I talked with cwickert_ the other day... he said his times are 
pretty much the same as always...
19:34:39  so, we have: http://whenisgood.net/ee8prq/results/z5binx
19:35:16  leaving us with our current time that kylem can never make, or 
switching to another time at least one other person cannot make.
19:36:18  thoughts?
19:36:54  So it sounds like no matter what one person is always 
going to miss the mtg
19:37:05  could alternate weeks
19:37:11  Let's pick a random day and time at the start of every week
19:37:22  Fate will guide us
19:37:26 * cwickert_ is here
19:37:31  yeah, because that will encourage more participation.
19:38:25  mclasen says he will get more time wed afternoons, but it's 
unclear to me which 5-6pm he means there? mine/the time the thing is in?
19:38:35  To be honest, it doesn't really seem like mclasen can ma

Re: 'milkymist' group in comps?

[Bill Nottingham]

James Laska (jla...@redhat.com) said: 
> > No, this is well before the tree gets to that state. It would need to
> > be implemented as a check on git push.
> 
> We attempt to validate comps in this test using the comps.rng in git
> (see results logs posted earlier).  I'm not tremendously familiar with
> that part of the test, but I believe it should catch that?

You're validating it after the repo has already been made. In this case,
it was broken such that the repo couldn't even be made.

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

Re: 'milkymist' group in comps?

[James Laska]

On Tue, 2010-10-12 at 16:54 -0400, Bill Nottingham wrote:
> James Laska (jla...@redhat.com) said: 
> > > 1) When you added this to F14/F15/EL6, you added a typo; this
> > > broke the F-14 branched compose and the EPEL updates push.
> > > *Please* verify your changes before pushing. 
> > 
> > How did the compose break?
> 
> The comps file in git failed to parse, such that the with-translations
> comps file could not be made.
> 
> > Is this something that the autoqa
> > rats_sanity test [sh|c]ould have caught?
> 
> No, this is well before the tree gets to that state. It would need to
> be implemented as a check on git push.

We attempt to validate comps in this test using the comps.rng in git
(see results logs posted earlier).  I'm not tremendously familiar with
that part of the test, but I believe it should catch that?

https://fedoraproject.org/wiki/QA:Comps_Validity_Test_Case

Thanks,
James


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 'milkymist' group in comps?

[Bill Nottingham]

James Laska (jla...@redhat.com) said: 
> > 1) When you added this to F14/F15/EL6, you added a typo; this
> > broke the F-14 branched compose and the EPEL updates push.
> > *Please* verify your changes before pushing. 
> 
> How did the compose break?

The comps file in git failed to parse, such that the with-translations
comps file could not be made.

> Is this something that the autoqa
> rats_sanity test [sh|c]ould have caught?

No, this is well before the tree gets to that state. It would need to
be implemented as a check on git push.

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

Re: 'milkymist' group in comps?

[James Laska]

On Mon, 2010-10-11 at 15:42 -0400, Bill Nottingham wrote:
> 1) When you added this to F14/F15/EL6, you added a typo; this
> broke the F-14 branched compose and the EPEL updates push.
> *Please* verify your changes before pushing. 

How did the compose break?  Is this something that the autoqa
rats_sanity test [sh|c]ould have caught?

https://fedorahosted.org/pipermail/autoqa-results/2010-October/046361.html
https://fedorahosted.org/pipermail/autoqa-results/2010-October/046372.html

Thanks,
James


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Ubuntu 10.10's installer looks rather nice

[Jeff Spaleta]

On Tue, Oct 12, 2010 at 11:32 AM, Evan Dandrea  wrote:
> I honestly have no idea.

Hmm. That's unfortunate. It appears from the web pages that the
preferred way to get the alternative images is the torrent ticket (as
it appears ahead of the mirror urls). If users are meant to bump their
head on the low bar of the desktop install and then search for
alternative image, I would have expected them to be showing up in the
torrent tracker stats in significant numbers.

The low activity on the Ubuntu torrent server generally really leaves
me scratching my head as to how to evaluate the applicability of the
alternative image approach.

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

Re: Ubuntu 10.10's installer looks rather nice

[Manuel Wolfshant]

On 10/12/2010 10:35 PM, Manuel Escudero wrote:
>
>
> 2010/10/12 James Antill  >
>
> On Tue, 2010-10-12 at 16:00 +0100, Bastien Nocera wrote:
> > On Mon, 2010-10-11 at 11:11 -0400, Chris Lumens wrote:
> > > >  - suggests a username and hostname based on the user's real
> name
> > > >(Mac OS X's installer also does this -- it's a nice touch)
> > >
> > > If DNS knows a hostname, we will suggest that.  Of course it's not
> > > foolproof.
> >
> > That's not it. Your name is entered (Chris Lumens) and from it you
> > should get a hostname (chris-lumens-fedora-desktop.local) as
> well as a
> > presentation name ("Chris Lumens' Fedora Desktop") which could
> be used
> > for things like services being advertised through avahi, or even the
> > default name for the Bluetooth adapters.
>
>  The Mac does this too, and I'm sure it's great for avahi stuff
> ... but
> it's really annoying for anyone using the hostname anywhere else
> (mainly
> due to the expected size).
>  Is there nowhere else that we could store a "hostsummary" instead of
> hostname?
>
> --
> devel mailing list
> devel@lists.fedoraproject.org 
> https://admin.fedoraproject.org/mailman/listinfo/devel
>
>
>
> I believe anaconda is Ok, But many users complain about it, I honestly 
> can't understand why.
because it's ugly. among ALL installers that I've used ( mint / debian / 
suse >=9 ) anaconda has the ugliest user interface. And I mean all 
versions that I ever used , in RH ( pre-RHEL era), Centos and Fedora.

> What I can undersand and even say is that anaconda needs a little 
> "more polished" experience.
exactly. there are tons of facilities but the aspect "could be improved"

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

Fedora 14 QA retrospective - feedback requested

[James Laska]

Greetings folks,

I'd like to draw attention to the QA retrospective wiki page for Fedora
14.

https://fedoraproject.org/wiki/Fedora_14_QA_Retrospective

As we did for Fedora 13 [1], I'd like to document any
gotchas/hiccups/awesome issues as they happen during a release.  I don't
know about you, but I have an easier time remembering how the group
performed over the past ~4 months when I don't have to remember
everything ... meaning, we took good notes.

Right now this page contains mostly input from me ... which isn't a very
diverse set of ideas.  I'd appreciate additional feedback.  Ideas don't
need to be fully fleshed out, but they do need to be constructive.  We
all need to vent from time to time, but please do so privately, not on
the wiki.

Some leading questions to encourage contributions ...
 1. Were you able to participate in any F14 Alpha or Beta test runs?
What worked well, what prevented you from participating, were
instructions clear?
 2. What worked (or didn't work) well about Fedora Test Days this
release?
 3. Have you signed up as a proventester, was the process well
defined?  Is it understood what is expected of proventesters?
 4. Are you a maintainer, why do you think your critpath updates
haven't been tested?  What could you do to encourage more
testing of your proposed updates?
 5. Did you escalate any bugs for consideration as
{Alpha,Beta,Final} release Blockers?  Why not?  Was the process
well documented and did it make sense?
 6. Did you attend or contribute to any Fedora blocker meetings?
Why not?  What did you like, dislike?  What prevented you from
participating?
 7. Did you use or contribute to
http://fedoraproject.org/wiki/Common_F14_bugs?
 8.  Unlimited time, resource and beer ... what should the QA
team focus on for Fedora 15 and beyond 

Thanks,
James

[1] https://fedoraproject.org/wiki/Fedora_13_QA_Retrospective


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Ubuntu 10.10's installer looks rather nice

[Manuel Escudero]

2010/10/12 James Antill 

> On Tue, 2010-10-12 at 16:00 +0100, Bastien Nocera wrote:
> > On Mon, 2010-10-11 at 11:11 -0400, Chris Lumens wrote:
> > > >  - suggests a username and hostname based on the user's real name
> > > >(Mac OS X's installer also does this -- it's a nice touch)
> > >
> > > If DNS knows a hostname, we will suggest that.  Of course it's not
> > > foolproof.
> >
> > That's not it. Your name is entered (Chris Lumens) and from it you
> > should get a hostname (chris-lumens-fedora-desktop.local) as well as a
> > presentation name ("Chris Lumens' Fedora Desktop") which could be used
> > for things like services being advertised through avahi, or even the
> > default name for the Bluetooth adapters.
>
>  The Mac does this too, and I'm sure it's great for avahi stuff ... but
> it's really annoying for anyone using the hostname anywhere else (mainly
> due to the expected size).
>  Is there nowhere else that we could store a "hostsummary" instead of
> hostname?
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>


I believe anaconda is Ok, But many users complain about it, I honestly can't
understand why.
What I can undersand and even say is that anaconda needs a little "more
polished" experience.

I mean, in the "look part" Fedora needs a re-birthday, we use same graphics
combination in anaconda,
the same Gnome theme, the same themes to pick for (gtk) and mostly the same
that when Fedora started.

I believe we need to polish that look part, as far as I understand an O.S.
Needs to be newer in each
new version not only in features, but also in look. If we can give that to
users, discussions like these ones
will be present in a fewer number.

-- 
<-Manuel Escudero->
Linux User #509052
@GWave: jmlev...@googlewave.com
@Blogger: http://www.blogxenode.tk/ (Xenode Systems Blog)
PGP/GnuPG: DAE3 82E9 D68E 7AE4 ED31  1F8F 4AF4 D00C 50E7 ABC6
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Ubuntu 10.10's installer looks rather nice

[Evan Dandrea]

On Mon Oct 11 21:34:08 UTC 2010 Lars Seipel wrote:
> It may be nice usability-wise but it lacks support for LVM2, LUKS disk
> encryption and practically everything more advanced. It can't be automated
> using some equivalent to kickstart and it fails at all the stuff Anaconda
> subsumes unter "advanced storage devices". You can't even do the install from
> some remote place without setting anything up by hand. Ubuntu users requiring
> more than these very basic features have to go for the Debian text mode
> installer Ubuntu ships on their alternate media.

You absolutely can automate it, using the same preseeding mechanism found in
debian-installer.  See the following wiki page for the differences between
preseeding ubiquity and preseeding the alternate CD:

https://wiki.ubuntu.com/UbiquityAutomation

And the following guide on preseeding, if you are unfamiliar with that:

https://help.ubuntu.com/10.04/installation-guide/i386/appendix-preseed.html

Note that you can use a subset of kickstart with the Ubuntu alternate CD
(debian-installer) via kickseed.  It's technically possible and relatively easy
to include this translation in ubiquity, but it has never been implemented.

As for being able to do the install remotely, I do installs over PXE and NFS
using the Ubuntu live CD all the time.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Ubuntu 10.10's installer looks rather nice

[Evan Dandrea]

I honestly have no idea.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 'milkymist' group in comps?

[Bill Nottingham]

Chitlesh GOORAH (chitlesh.goo...@gmail.com) said: 
> > OK, that's clear. But I am worried that if we go down this road, we'll
> > eventually have 20 or 30 groups for different SoCs for embedded use,
> > and that seems like it will eventually be problematic. Is there some
> > generic moniker that could be used for this usage?
> 
> To be honest that would be a great idea. But I don't know any other
> active and vibrant community like milkymist and openmoko alike. I
> suggest that, let it be like this. If it gets momentum and other HW
> communities pop in, we can rename it, I won't object.

Works for me.

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

Re: 'milkymist' group in comps?

[Przemek Klosowski]

On 10/12/2010 02:23 PM, Bill Nottingham wrote:
> Chitlesh GOORAH (chitlesh.goo...@gmail.com) said:
>> Milkymist community builds and enhance their own toolchain (currently
>> not fully supported by Fedora).
...
> OK, that's clear. But I am worried that if we go down this road, we'll
> eventually have 20 or 30 groups for different SoCs for embedded use,

The electronics lab community is a generic concept, with clearly 
defined, self-evident scope and specific FOSS software products. 
Milkymist on the other hand has two problems:

  - it is not a mainstream interest--I try to keep up with embedded and 
electronic topics and I have never heard of it, which of course doesn't 
mean it isn't worthy. As Bill said, we should be careful how we organize 
the information, because otherwise it'll be hard to find anything. 
Grouping milkymist with something else electronics isn't
a bad idea.

  - related to that, the term 'milkymist' is obscure: google returns 
hits for some sort of VJ software as well. "Milkymist embedded 
visualization hardware project" might be excessively long, but surely 
there's a happy middle somewhere.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 'milkymist' group in comps?

[Chitlesh GOORAH]

On Tue, Oct 12, 2010 at 8:23 PM, Bill Nottingham <> wrote:
> OK, that's clear. But I am worried that if we go down this road, we'll
> eventually have 20 or 30 groups for different SoCs for embedded use,
> and that seems like it will eventually be problematic. Is there some
> generic moniker that could be used for this usage?

To be honest that would be a great idea. But I don't know any other
active and vibrant community like milkymist and openmoko alike. I
suggest that, let it be like this. If it gets momentum and other HW
communities pop in, we can rename it, I won't object.

>From a strategy perspective, let's bring forces together and show that
this model works. It does, then good for us and our efforts brought
several communities into our wagon. What do you think, let it be its
roadmap ?

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

Re: Ubuntu 10.10's installer looks rather nice

[Jeff Spaleta]

On Tue, Oct 12, 2010 at 10:42 AM, Evan Dandrea  wrote:
> You can follow the path to the different desktop CDs from here:
>
> http://www.ubuntu.com/desktop/get-ubuntu/download
>
> The alternate CD can be found under the alternative downloads link,
> with an explanation that it "is suited for computers unable to run the
> graphical desktop based installation, either because their computer
> does not meet the minimum requirements for the live cd or because
> their computer requires configuration after the installation is
> complete in order to use the desktop."

I followed the links and ended up with torrent ticket download links.
Taking a look at the ubuntu torrent tracker stats at
http://torrent.ubuntu.com:6969/ and I'm seeing a _shockingly_ low
amount of activity there. Like disturbingly low.  Much much lower than
what we see on our Fedora torrent tracker
(http://torrent.fedoraproject.org:6969/). Was the Ubuntu torrent
tracker restarted or purged recently?

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

Re: Selinux: SSH broken after F-13 --> F-14 upgrade

[Michael Schwendt]

On Tue, 12 Oct 2010 13:49:41 -0400 (EDT), Michal wrote:

> Hi all,
> 
> I've recently upgraded my system, but after that I was not able to connect 
> through ssh. More things are wrong (from my POV):
> 1)SELinux blocks all nondefault ports for ssh
> 
> I have ssh confugured to use different port than 22 for security reasons and 
> I think there is a lot of people doing that.
> 
> Question: Is it worth blocking all ports for ssh?
> 
> 2)SELinux did not show any sealert warning about this.

Here it did. For port 8080. And it suggested running
"setsebool -P sshd_forward_ports 1" as a work-around.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Ubuntu 10.10's installer looks rather nice

[Evan Dandrea]

On Tue, Oct 12, 2010 at 6:56 PM, Jeff Spaleta  wrote:
> On Tue, Oct 12, 2010 at 9:18 AM, Evan Dandrea  wrote:
>> I'm not challenging your point that the Fedora installer offers more complex
>> options.  I just wanted to clarify our approach, as our users are not screwed
>> in these circumstances, we just clearly separate their use cases to different
>> CDs.
>
>
> We struggle a lot with how to position multiple image targets
> effectively to appease both our existing vocal contributorbase and
> simutenously provide something that appeals to the
> yet-to-be-initiated.  The default Fedora desktop livecd is meant to be
> the installer image for the "go with the defaults." novice user  It's
> not clear to me that we need the traditional installer experience (ie
> non-live) that hides more than it already does. I'm not really sure
> we've identified a usage case for such a thing that shouldn't already
> be a target for the live image installer.
>
> One question for you. Do you have a process by which people coming to
> your web properties can attempt to self-select which install image
> they want before downloading one? Do you chart a course to guide users
> to make a decision on whether to download the alternative image before
> first attempting to use the streamlined live image? Or do users tend
> to reach for the alternative image only after they bump up against
> customization constraints in the live installer you provide?

Sure.  Guiding the users to the correct CD for their particular use
case is not an area of my expertise - that's the job of our design and
marketing teams; however, I'll try to answer your question to the best
of my ability.

You can follow the path to the different desktop CDs from here:

http://www.ubuntu.com/desktop/get-ubuntu/download

The alternate CD can be found under the alternative downloads link,
with an explanation that it "is suited for computers unable to run the
graphical desktop based installation, either because their computer
does not meet the minimum requirements for the live cd or because
their computer requires configuration after the installation is
complete in order to use the desktop."

So I believe that we assume that users will fall into your
last-mentioned path: they will bump up against the customization
constraints of the live CD installer, search for a solution, and find
their way to the alternate CD.

We include the alternate installer on our live DVD image, but getting
to it is not obvious.  A splash screen briefly appears with a keyboard
icon in the bottom-center of the screen at boot.  If you press a key,
then the following menu appears ("text mode" is the alternate
installer):

http://blog.keesmeijs.nl/wp-content/uploads/2010/07/cryptobuntu_boot.png

I realize that I have rudely not introduced myself, so do excuse my
belated attempt.  If it was not already clear, I am the maintainer of
ubiquity, Ubuntu's desktop CD installer.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Selinux: SSH broken after F-13 --> F-14 upgrade

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/12/2010 02:10 PM, Michal Hlavinka wrote:
> 
> - "Daniel J Walsh"  wrote:
> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 10/12/2010 01:49 PM, Michal Hlavinka wrote:
>>> Hi all,
>>>
>>> I've recently upgraded my system, but after that I was not able to
>> connect through ssh. More things are wrong (from my POV):
>>> 1)SELinux blocks all nondefault ports for ssh
>>>
>>> I have ssh confugured to use different port than 22 for security
>> reasons and I think there is a lot of people doing that.
>>>
>> You need to tell SELinux which port to use for sshd.
>>
>> semanage port -a -t sshd_port_t -p tcp 6520
>>
>>> Question: Is it worth blocking all ports for ssh?
>>>
>>> 2)SELinux did not show any sealert warning about this. Running
>> sealert -b shows no problem. There is one message in
>> /var/log/messages:
>>> kernel: [90346.301108] type=1400 audit(1286901219.350:29): avc: 
>> denied  { name_bind } for  pid=6830 comm="sshd" src=6520
>> scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023
>> tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket
>>>
>>> Question: This should be reported afaik, so it's a bug, right?
>>>
>> No.  Hacker gets some control over ssh and is able to make it bind to
>> port 80, now he can read apache content.
> 
> "this should be reported, so it's a bug?"  was related to sealert should show 
> this denial in systray or at least in sealert -b window. Or this denial 
> should be really more silent compared to others reported by sealert?

I have no idea why this would not have shown up in the system tray as a bug.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAky0rWAACgkQrlYvE4MpobNuTQCg2NWkHwnSRUOxiNs8o3k3391a
15IAn1R/nZRd1ndLUNRG6gh8O1LVV2jw
=r7/j
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: A comps group for the Design Suite

[Bill Nottingham]

Ankur Sinha (sanjay.an...@gmail.com) said: 
> Since the design team is using a "design suite", would it be possible to
> please create a group in comps for the purpose? It would make
> installation of the design suite much easier for end users. 
> 
> The alternative is to create a meta package which isn't welcomed. 
> 
> This[1] is the tentative list of packages.
> 
> [1]http://fedoraproject.org/wiki/Design_Suite_Planning#Included

There appears to be a lot of overlap here with the graphics group
(and some with other groups). Perhaps it's best to just expand
that group into a more full-fledged design suite?

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

Re: 'milkymist' group in comps?

[Bill Nottingham]

Chitlesh GOORAH (chitlesh.goo...@gmail.com) said: 
> Milkymist community builds and enhance their own toolchain (currently
> not fully supported by Fedora). They have contributors who contribute
> for tools such as gcc, qemu, other libraries (too software for FEL
> goals). They have many patches that need to push to upstream.
> Milkymist founder and I believe that we can collaborate as the
> milkmist community is situated between FEL and Fedora, in terms of
> tools and upstream patch-push. It is a win-win situation for everyone.

OK, that's clear. But I am worried that if we go down this road, we'll
eventually have 20 or 30 groups for different SoCs for embedded use,
and that seems like it will eventually be problematic. Is there some
generic moniker that could be used for this usage?

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

Something similar to http://susestudio.com/

[Pavel Alexeev (aka Pahan-Hubbitus)]

 Subject.
Have Fedora/RHEL service similar http://susestudio.com/ ? May be plans
to create it?

Just for information.
-- 
With best wishes, Pavel Alexeev aka Pahan-Hubbitus. For fast contact
with me you could use Jabber: hubbi...@jabber.ru
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

A comps group for the Design Suite

[Ankur Sinha]

Hello,

Since the design team is using a "design suite", would it be possible to
please create a group in comps for the purpose? It would make
installation of the design suite much easier for end users. 

The alternative is to create a meta package which isn't welcomed. 

This[1] is the tentative list of packages.

[1]http://fedoraproject.org/wiki/Design_Suite_Planning#Included

-- 
Thanks!
Regards,
Ankur 

https://fedoraproject.org/wiki/User:Ankursinha

"FranciscoD"

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

Re: Selinux: SSH broken after F-13 --> F-14 upgrade

[Michal Hlavinka]

- "Daniel J Walsh"  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 10/12/2010 01:49 PM, Michal Hlavinka wrote:
> > Hi all,
> > 
> > I've recently upgraded my system, but after that I was not able to
> connect through ssh. More things are wrong (from my POV):
> > 1)SELinux blocks all nondefault ports for ssh
> > 
> > I have ssh confugured to use different port than 22 for security
> reasons and I think there is a lot of people doing that.
> > 
> You need to tell SELinux which port to use for sshd.
> 
> semanage port -a -t sshd_port_t -p tcp 6520
> 
> > Question: Is it worth blocking all ports for ssh?
> > 
> > 2)SELinux did not show any sealert warning about this. Running
> sealert -b shows no problem. There is one message in
> /var/log/messages:
> > kernel: [90346.301108] type=1400 audit(1286901219.350:29): avc: 
> denied  { name_bind } for  pid=6830 comm="sshd" src=6520
> scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023
> tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket
> > 
> > Question: This should be reported afaik, so it's a bug, right?
> > 
> No.  Hacker gets some control over ssh and is able to make it bind to
> port 80, now he can read apache content.

"this should be reported, so it's a bug?"  was related to sealert should show 
this denial in systray or at least in sealert -b window. Or this denial should 
be really more silent compared to others reported by sealert?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Ubuntu 10.10's installer looks rather nice

[James Antill]

On Tue, 2010-10-12 at 16:00 +0100, Bastien Nocera wrote:
> On Mon, 2010-10-11 at 11:11 -0400, Chris Lumens wrote:
> > >  - suggests a username and hostname based on the user's real name
> > >(Mac OS X's installer also does this -- it's a nice touch)
> > 
> > If DNS knows a hostname, we will suggest that.  Of course it's not
> > foolproof.
> 
> That's not it. Your name is entered (Chris Lumens) and from it you
> should get a hostname (chris-lumens-fedora-desktop.local) as well as a
> presentation name ("Chris Lumens' Fedora Desktop") which could be used
> for things like services being advertised through avahi, or even the
> default name for the Bluetooth adapters.

 The Mac does this too, and I'm sure it's great for avahi stuff ... but
it's really annoying for anyone using the hostname anywhere else (mainly
due to the expected size).
 Is there nowhere else that we could store a "hostsummary" instead of
hostname?

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

Re: Selinux: SSH broken after F-13 --> F-14 upgrade

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/12/2010 01:49 PM, Michal Hlavinka wrote:
> Hi all,
> 
> I've recently upgraded my system, but after that I was not able to connect 
> through ssh. More things are wrong (from my POV):
> 1)SELinux blocks all nondefault ports for ssh
> 
> I have ssh confugured to use different port than 22 for security reasons and 
> I think there is a lot of people doing that.
> 
You need to tell SELinux which port to use for sshd.

semanage port -a -t sshd_port_t -p tcp 6520

> Question: Is it worth blocking all ports for ssh?
> 
> 2)SELinux did not show any sealert warning about this. Running sealert -b 
> shows no problem. There is one message in /var/log/messages:
> kernel: [90346.301108] type=1400 audit(1286901219.350:29): avc:  denied  { 
> name_bind } for  pid=6830 comm="sshd" src=6520 
> scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 
> tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket
> 
> Question: This should be reported afaik, so it's a bug, right?
> 
No.  Hacker gets some control over ssh and is able to make it bind to
port 80, now he can read apache content.
> 3)After checking /var/log/boot.log there is "Starting ssh ... [ OK ]". 
> I get the same success info after "service sshd start", but immediate service 
> sshd status returns "openssh-daemon is stopped", but I'm not sure if this is 
> fixable because all that daemonize and other stuff.
> 
> Question: What does other network daemons (httpd,...) do? Do they start 
> successfully (from initscript's POV) when they can't use configured port?
> 
> I'm really glad I've found this out before updating my headless F-12 server. 
> 
> 2 of 3 questions are about SELinux, ccing Dan.
> 
> Michal

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAky0oq0ACgkQrlYvE4MpobNA9gCeLbGUI6Vtb3ARVBwnyng0Airc
eJMAoLr3j4urCc+WMJPZ3UqVy5J6Nxvc
=F1ky
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Ubuntu 10.10's installer looks rather nice

[Dennis Jacobfeuerborn]

On 10/12/2010 05:13 PM, Chuck Anderson wrote:
> On Tue, Oct 12, 2010 at 08:06:59AM -0700, Jesse Keating wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 10/12/10 7:20 AM, Matthew Miller wrote:
>>> On Tue, Oct 12, 2010 at 02:16:49PM +0200, Dennis Jacobfeuerborn wrote:
 The only way to accomplish this without actually removing the features is
 to have two anaconda modes one for easy desktop installation and one full
 featured mode. This mode should be chosen not by the user but by the spin
 e.g. the desktop spin would use the easy mode and the server or workstation
 spins would use the full featured one.
>>>
>>> Anaconda actually has the ability to do this with "install classes".
>>>
>>>
>>
>> Anaconda used to have an Advanced mode where things like the complex
>> partitioning and package selection were hidden.  Turns out, the vast
>> majority of people who used anaconda and said something about it had
>> picked advanced mode, because they felt their case was special.  If
>> everybody uses advanced mode, that becomes the norm...
>
> Making "advanced" only a choice at the beginning of a 10 step process
> is a non-starter and leads to the problem you describe above.  If
> instead there were "Advanced Options..." in each step along the way
> that could be opened/closed at will, that would allow users to explore
> the advanced options without worrying that they made the "wrong
> choice" way back at the beginning of the 10 step process, whether or
> not they actually end up using the advanced options.

This assumes that the workflow for both methods is always the same which is 
pretty limiting. Maybe for the simple installation you don't want a storage 
configuration screen at all and simply put up an option to overwrite the hd 
completely or install next to an already present os. Perhaps you can even 
put this on the screen where the user enters his name since this selection 
doesn't really warrant its own screen at all.

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

Re: Ubuntu 10.10's installer looks rather nice

[Jeff Spaleta]

On Tue, Oct 12, 2010 at 9:18 AM, Evan Dandrea  wrote:
> I'm not challenging your point that the Fedora installer offers more complex
> options.  I just wanted to clarify our approach, as our users are not screwed
> in these circumstances, we just clearly separate their use cases to different
> CDs.


We struggle a lot with how to position multiple image targets
effectively to appease both our existing vocal contributorbase and
simutenously provide something that appeals to the
yet-to-be-initiated.  The default Fedora desktop livecd is meant to be
the installer image for the "go with the defaults." novice user  It's
not clear to me that we need the traditional installer experience (ie
non-live) that hides more than it already does. I'm not really sure
we've identified a usage case for such a thing that shouldn't already
be a target for the live image installer.

One question for you. Do you have a process by which people coming to
your web properties can attempt to self-select which install image
they want before downloading one? Do you chart a course to guide users
to make a decision on whether to download the alternative image before
first attempting to use the streamlined live image? Or do users tend
to reach for the alternative image only after they bump up against
customization constraints in the live installer you provide?

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

Selinux: SSH broken after F-13 --> F-14 upgrade

[Michal Hlavinka]

Hi all,

I've recently upgraded my system, but after that I was not able to connect 
through ssh. More things are wrong (from my POV):
1)SELinux blocks all nondefault ports for ssh

I have ssh confugured to use different port than 22 for security reasons and I 
think there is a lot of people doing that.

Question: Is it worth blocking all ports for ssh?

2)SELinux did not show any sealert warning about this. Running sealert -b shows 
no problem. There is one message in /var/log/messages:
kernel: [90346.301108] type=1400 audit(1286901219.350:29): avc:  denied  { 
name_bind } for  pid=6830 comm="sshd" src=6520 
scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket

Question: This should be reported afaik, so it's a bug, right?

3)After checking /var/log/boot.log there is "Starting ssh ... [ OK ]". 
I get the same success info after "service sshd start", but immediate service 
sshd status returns "openssh-daemon is stopped", but I'm not sure if this is 
fixable because all that daemonize and other stuff.

Question: What does other network daemons (httpd,...) do? Do they start 
successfully (from initscript's POV) when they can't use configured port?

I'm really glad I've found this out before updating my headless F-12 server. 

2 of 3 questions are about SELinux, ccing Dan.

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

Re: 'milkymist' group in comps?

[Chitlesh GOORAH]

On Mon, Oct 11, 2010 at 9:42 PM, Bill Nottingham  wrote:
> 1) When you added this to F14/F15/EL6, you added a typo; this
> broke the F-14 branched compose and the EPEL updates push.
> *Please* verify your changes before pushing.

Sorry I missed it

> 2) Aside from that... how does this merit a separate group?
>
> - We already have the electronic lab group
> - If we add a group each for developing for any embedded/custom
>  board, we're going to run into group explosion really quickly

Well it does merit a separate group and we differ in terms of goals.

Fedora/Free Electronic Lab focuses primarily on ASIC design. We were
pretty bad in terms of knowhow in the embedded environment, until
Shakthi joined us. Hence our solutions for embedded tool are
improving. But our FEL goal is not only provide to but also to foster
a community around it.

Milkymist community builds and enhance their own toolchain (currently
not fully supported by Fedora). They have contributors who contribute
for tools such as gcc, qemu, other libraries (too software for FEL
goals). They have many patches that need to push to upstream.
Milkymist founder and I believe that we can collaborate as the
milkmist community is situated between FEL and Fedora, in terms of
tools and upstream patch-push. It is a win-win situation for everyone.

Having a separate group will prevent flooding ASIC engineers (existing
FEL users) with non-useful tools. Having a separate group will
strengthen RedHat/Fedora focus on patch submission for important tools
such as gcc, qemu,.

In short, that was it. It's sad though you can differ FEL goals from the rest.

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

Re: Ubuntu 10.10's installer looks rather nice

[Adam Williamson]

On Tue, 2010-10-12 at 19:15 +0200, drago01 wrote:

> > As I recall, several distros have done usability studies and found that
> > this isn't actually true. People have been *trained* to just press next,
> > next, next under specific circumstances - like Windows software
> > installation - but it's not everyone's default behaviour, especially the
> > kinds of people who tend to install Linux distributions.
> 
> Any pointers to those studies?
> Not saying that you are lying, but I am actually interested to see them.

No, unfortunately - I remember stuff from ages-old blog posts and
mailing lists but I'm not a good note/bookmark taker so I have no
references :(
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

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

Ubuntu 10.10's installer looks rather nice

[Evan Dandrea]

On Mon Oct 11 15:39:44 UTC 2010, Gilboa Davara wrote:
> Comparing the Ubuntu 10.04 DVD installer (which I use a couple of weeks
> ago) to Fedora 13 DVD installer is like comparing the Cessna to a Boeing
> 747.
> Sure, both can accomplish the same task. Read: transporting people from
> one airport to another, but lets see you try transporting 400 peoples
> from London to NY using a Cessna...
>
> The same logic applies to the Ubuntu installer: As long as you require a
> fairly basic -desktop- configuration (Read: No fancy storage, no LVM, no
> fancy setup source [nfs, dvd, http], -very- basic encryption, standard
> software set and repository selection, etc), the Ubuntu installer is a
> great tool, but once you need something complex, you're screwed.

The Ubuntu installer does let you use a NFS root for your installation source.

On the point of needing something more complex, such as LVM or full disk
encryption, that's what we offer our alternate CD installer (debian-installer)
for.

I'm not challenging your point that the Fedora installer offers more complex
options.  I just wanted to clarify our approach, as our users are not screwed
in these circumstances, we just clearly separate their use cases to different
CDs.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Ubuntu 10.10's installer looks rather nice

[drago01]

On Tue, Oct 12, 2010 at 7:03 PM, Adam Williamson  wrote:
> On Tue, 2010-10-12 at 18:34 +0200, drago01 wrote:
>> On Tue, Oct 12, 2010 at 6:30 PM, Adam Williamson  wrote:
>> > On Tue, 2010-10-12 at 10:53 -0400, Neal Becker wrote:
>> >
>> >> I don't agree.  There's nothing unusual about a dumbed-down interface for
>> >> novices, with an 'advanced' tab hiding more options.
>> >
>> > As someone else has pointed out, a lot of usability experts consider
>> > this a bad idea, for two reasons:
>> >
>> > 1) everyone thinks they're an expert, even if they're not, and hits
>> > 'advanced'
>> >
>> > 2) it creates a confusing decision point for *everyone*: how do you know
>> > if you need the 'advanced' options? You can't really know without
>> > looking at them, so you have to look at them to decide if you need them,
>> > so essentially we're presenting the advanced options to everyone...
>>
>> Well most people just press "Next", "Next", "Next" 
>
> As I recall, several distros have done usability studies and found that
> this isn't actually true. People have been *trained* to just press next,
> next, next under specific circumstances - like Windows software
> installation - but it's not everyone's default behaviour, especially the
> kinds of people who tend to install Linux distributions.

Any pointers to those studies?
Not saying that you are lying, but I am actually interested to see them.

> (Have you ever
> observed people trying to use subway ticket machines in an unfamiliar
> city? They certainly don't just click next, next, next, in my
> experience. They read every screen carefully and worry which of the many
> options to choose. Frequently, when the process is too complex, they
> worry that they've somehow got something wrong, cancel, and start
> over.)

It involves money ;)

> Even when people do it, it's more of an 'exasperation fallback': it's
> what people do when they hit their breaking point of potential
> decisions, they go 'oh what the hell, I'll just hit next on everything'.
> If we get to that point we've already 'lost', because we exasperated the
> user: even if they happen to get a fully functional install, they're not
> happy with the experience.

Or they think "don't care, just install the damn thing".
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Ubuntu 10.10's installer looks rather nice

[Adam Williamson]

On Tue, 2010-10-12 at 18:34 +0200, drago01 wrote:
> On Tue, Oct 12, 2010 at 6:30 PM, Adam Williamson  wrote:
> > On Tue, 2010-10-12 at 10:53 -0400, Neal Becker wrote:
> >
> >> I don't agree.  There's nothing unusual about a dumbed-down interface for
> >> novices, with an 'advanced' tab hiding more options.
> >
> > As someone else has pointed out, a lot of usability experts consider
> > this a bad idea, for two reasons:
> >
> > 1) everyone thinks they're an expert, even if they're not, and hits
> > 'advanced'
> >
> > 2) it creates a confusing decision point for *everyone*: how do you know
> > if you need the 'advanced' options? You can't really know without
> > looking at them, so you have to look at them to decide if you need them,
> > so essentially we're presenting the advanced options to everyone...
> 
> Well most people just press "Next", "Next", "Next" 

As I recall, several distros have done usability studies and found that
this isn't actually true. People have been *trained* to just press next,
next, next under specific circumstances - like Windows software
installation - but it's not everyone's default behaviour, especially the
kinds of people who tend to install Linux distributions. (Have you ever
observed people trying to use subway ticket machines in an unfamiliar
city? They certainly don't just click next, next, next, in my
experience. They read every screen carefully and worry which of the many
options to choose. Frequently, when the process is too complex, they
worry that they've somehow got something wrong, cancel, and start
over.) 

Even when people do it, it's more of an 'exasperation fallback': it's
what people do when they hit their breaking point of potential
decisions, they go 'oh what the hell, I'll just hit next on everything'.
If we get to that point we've already 'lost', because we exasperated the
user: even if they happen to get a fully functional install, they're not
happy with the experience.

It'd be nice if anyone who's been involved in Fedora UX studies could
contribute...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

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

libgpod 0.8.0 in F13

[Nathaniel McCallum]

I've just tagged libgpod 0.8.0 for F13 updates-testing.  This is the
first step to an updated Banshee (1.8.0) in F13 as well as better
iPhone/iPad support in the existing Rhythmbox.  I'd really like to get
some testing on this, so please, if you are using updates-testing and
have any Apple-brand device, please check to see that your device will
successfully sync with Rhythmbox with the new libgpod.

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

Re: Ubuntu 10.10's installer looks rather nice

[Jos Vos]

On Tue, Oct 12, 2010 at 09:30:45AM -0700, Adam Williamson wrote:

> 2) it creates a confusing decision point for *everyone*: how do you know
> if you need the 'advanced' options? You can't really know without
> looking at them, so you have to look at them to decide if you need them,
> so essentially we're presenting the advanced options to everyone...

100% agreed.  You do not know in advance what options will not be shown
in non-advanced mode (e.g. custom filesystem layout, MBR at a different
partition, etc.).  As a CLI expert I'm considering myself all but a GUI
expert, but I never understood how people can "guess" the corect answer
to this kind of undefined questions (like "do you want basic or advanced
install mode?").

-- 
--Jos Vos 
--X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364
--Amsterdam, The Netherlands| Fax: +31 20 6948204
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Ubuntu 10.10's installer looks rather nice

[drago01]

On Tue, Oct 12, 2010 at 6:30 PM, Adam Williamson  wrote:
> On Tue, 2010-10-12 at 10:53 -0400, Neal Becker wrote:
>
>> I don't agree.  There's nothing unusual about a dumbed-down interface for
>> novices, with an 'advanced' tab hiding more options.
>
> As someone else has pointed out, a lot of usability experts consider
> this a bad idea, for two reasons:
>
> 1) everyone thinks they're an expert, even if they're not, and hits
> 'advanced'
>
> 2) it creates a confusing decision point for *everyone*: how do you know
> if you need the 'advanced' options? You can't really know without
> looking at them, so you have to look at them to decide if you need them,
> so essentially we're presenting the advanced options to everyone...

Well most people just press "Next", "Next", "Next" 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Ubuntu 10.10's installer looks rather nice

[Adam Williamson]

On Tue, 2010-10-12 at 10:53 -0400, Neal Becker wrote:

> I don't agree.  There's nothing unusual about a dumbed-down interface for 
> novices, with an 'advanced' tab hiding more options.

As someone else has pointed out, a lot of usability experts consider
this a bad idea, for two reasons:

1) everyone thinks they're an expert, even if they're not, and hits
'advanced'

2) it creates a confusing decision point for *everyone*: how do you know
if you need the 'advanced' options? You can't really know without
looking at them, so you have to look at them to decide if you need them,
so essentially we're presenting the advanced options to everyone...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

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

Re: Ubuntu 10.10's installer looks rather nice

[Adam Williamson]

On Tue, 2010-10-12 at 16:40 +0200, Dennis Jacobfeuerborn wrote:
> On 10/12/2010 04:20 PM, Matthew Miller wrote:
> > On Tue, Oct 12, 2010 at 02:16:49PM +0200, Dennis Jacobfeuerborn wrote:
> >> The only way to accomplish this without actually removing the features is
> >> to have two anaconda modes one for easy desktop installation and one full
> >> featured mode. This mode should be chosen not by the user but by the spin
> >> e.g. the desktop spin would use the easy mode and the server or workstation
> >> spins would use the full featured one.
> >
> > Anaconda actually has the ability to do this with "install classes".
> >
> 
> I figured as much and my guess is that anaconda already has most of the 
> required stuff implemented and it's really just a case of lining up the 
> bits and pieces the right way.
> 
> Another question is where to split this off exactly:

Live vs. traditional seems like the obvious split to me.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

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

Re: Git commit in all available branches

[Pavel Alexeev (aka Pahan-Hubbitus)]

 Unfortunately it is not what I initially ask :(

12.10.2010 19:14, matt_dom...@dell.com wrote:
> Correct, it's simply a git merge specifying the merge method, to ensure there 
> are no merge conflicts - just make an exact copy of the origin/master branch 
> onto the current branch. You must still 'fedpkg switch-branch' before 
> invoking this.
>
> --
> Matt Domsch
> Technology Strategist
> Dell | Office of the CTO
>
> -Original Message-
> From: Pavel Alexeev (aka Pahan-Hubbitus) [mailto:fo...@hubbitus.com.ru] 
> Sent: Tuesday, October 12, 2010 3:07 AM
> To: Domsch, Matt
> Subject: Re: Git commit in all available branches
>
>
>  11.10.2010 05:28, Matt Domsch пишет:
>> On Fri, Oct 08, 2010 at 06:03:04PM +0400, Pavel Alexeev (aka Pahan-Hubbitus) 
>> wrote:
>>>  In most cases I try sync all branches if there no real reasons to 
>>> make differences.
>>>
>>> After made some changes in origin/master and commit is I also must do 
>>> for each available branches something similar:
>>> fedpkg switch-branch el5;
>>> git pull
>>> git merge origin/master
>>> git push
>>> fedpkg build
>>> fedpkg update
>> I find this works to apply the version from 'master' into the current 
>> (say, el5) branch.
>>
>> $ git merge -s recursive -X theirs master
>>
> Sorry, I think does not understand you. Where I can there provide on what 
> branches I want do that?? On first glance it us mostly equivalent of present 
> before "git merge origin/master" with additional strategy option only. I've 
> read git-merge man, but still does not understand how it helps. Please 
> describe slightly.
>> There are valid reasons for doing this - e.g. a bug fix release of a 
>> package by the upstream, that doesn't break the ABI.
>>
>> Thanks,
>> Matt
>>

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

[Test-Announce] Fedora 14 ON_QA Blocker bugs needing verification

[James Laska]

Greetings testers!

The bugs listed below are Fedora 14 Blocker bugs that are believed to be
fixed.  Help is needed to ensure Fedora 14 ships on time!  You can
follow the list of ON_QA bugs at http://bit.ly/bLdmof

To get started, for each bug ...
 1. Confirm reported bug is fixed, then change status to VERIFIED
 2. Provide karma feedback to the proposed bodhi update

Now to the list of ON_QA bugs ...

599873 :: ON_QA :: valide :: bioinfornat...@gmail.com :: FTBFS
valide-0.6.1-0.22.20103003svn511.fc14 ::
https://bugzilla.redhat.com/show_bug.cgi?id=599873

635778 :: ON_QA :: anaconda :: b...@redhat.com :: IndexError: list index
out of range :: https://bugzilla.redhat.com/show_bug.cgi?id=635778

528022 :: ON_QA :: vbetool :: a...@redhat.com :: setroubleshoot:
SELinux is preventing /usr/sbin/vbetool "mmap_zero" access on
. :: https://bugzilla.redhat.com/show_bug.cgi?id=528022

635821 :: ON_QA :: anaconda :: anaconda-maint-l...@redhat.com ::
Attempting to submit (scp or bugzilla) an exception report fails if
networking not active :: https://bugzilla.redhat.com/show_bug.cgi?id=6
35821

627789 :: ON_QA :: anaconda :: b...@redhat.com :: Error setting up
repository - 16, Device busy ::
https://bugzilla.redhat.com/show_bug.cgi?id=627789

635333 :: ON_QA :: libgdl :: debarshi@gmail.com :: libgdl needs to
be downgraded to 2.30.x ::
https://bugzilla.redhat.com/show_bug.cgi?id=635333

637495 :: ON_QA :: udev :: har...@redhat.com :: Anaconda loses
InstallMedia repo. :: https://bugzilla.redhat.com/show_bug.cgi?id=637495

639395 :: ON_QA :: intellij-idea :: lkund...@v3.sk :: Broken dependency:
intellij-idea-9.0.1.94.399-11.fc14.x86_64 requires jna-examples ::
https://bugzilla.redhat.com/show_bug.cgi?id=639395

639391 :: ON_QA :: spacewalk-certs-tools :: msu...@redhat.com :: Broken
dependency: spacewalk-certs-tools-1.1.1-2.1.fc14.noarch requires
spacewalk-backend-libs >= 0:0.8.28 :: https://bugzilla.redhat.com/
show_bug.cgi?id=639391

636099 :: ON_QA :: anaconda :: rvyky...@redhat.com :: [anaconda]
keys-wlan0 world readable after wireless network install ::
https://bugzilla.redhat.com/show_bug.cgi?id=636099

640951 :: ON_QA :: anaconda :: rvyky...@redhat.com :: IPV4 DHCP
configuration is always used in stage 2 network enablement. ::
https://bugzilla.redhat.com/show_bug.cgi?id=640951

Thanks,
James


signature.asc
Description: This is a digitally signed message part
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Four Days to Fix Remaining Fedora 14 Blocker Bugs

[John Poelstra]

Hello Fedora 14 Blocker Bug Owners (all copied on this message),

The list of bugs below are currently blocking the final release of 
Fedora 14. These bugs MUST be fixed by this coming Monday, 2010-10-18 
(Final Change Deadline) or Release Engineering will be unable to create 
the Final Release Candidate on time, resulting in the possibility of a 
delayed release.

We need your help *NOW*.  As a maintainer, here is how you can help ...

--If you are the OWNER of one of these bugs, PLEASE add a comment to the 
bug ...
   1) letting us know how things are going
   2) what you are planning to do next
   3) when you expect to complete the work--the sooner the better

--If your bug is in MODIFIED, please make sure ...
   1) a build and bodhi update have been submitted.
   2) the bug status is set to ON_QA (bodhi should do this for you, but 
if not set it manually)

639146 :: NEW :: xorg-x11-drv-intel :: a...@redhat.com :: Blank display 
(backlight on) after KMS initialization :: 
https://bugzilla.redhat.com/show_bug.cgi?id=639146
  * next steps ...
1) Really really need feedback from maintainer

629192 :: NEW :: pino :: rosset.fil...@gmail.com :: Twitter isn't 
functioning :: https://bugzilla.redhat.com/show_bug.cgi?id=629192
  * next steps ...
1) add release note documenting the change (Fedora docs team), then ...
2) confirm release note and remove from F14Blocker list (anyone)

641846 :: NEW :: gnome-panel :: rstr...@redhat.com :: Panel applets 
(clock, workspace switcher, window selector, ...) randomly disappear :: 
https://bugzilla.redhat.com/show_bug.cgi?id=641846
  * next steps ...
 1) Decide whether bug meets the release criteria, early indications 
are "no"
 2) Feedback from reporter and maintainer would be helpful

641474 :: ASSIGNED :: lvm2 :: a...@redhat.com :: libdm does not present 
method to assign UUID after map creation :: 
https://bugzilla.redhat.com/show_bug.cgi?id=641474
  * next steps ...
 1) Maintainer resolve issue and submit update as soon as possible

641476 :: ASSIGNED :: kernel :: a...@redhat.com :: devicemapper UUID 
field cannot be assigned after map creation :: 
https://bugzilla.redhat.com/show_bug.cgi?id=641476
  * next steps ...
 1) Maintainer resolve issue and submit update as soon as possible

641991 :: ASSIGNED :: xorg-x11-server :: a...@redhat.com :: Fedora 14 
xorg qxl drv does not work with a RHEV-2.2 virtual machine :: 
https://bugzilla.redhat.com/show_bug.cgi?id=641991
  * next steps ...
 1) No release criteria impacting RHEV, will be removed from list
 2) Feedback from reporter and maintainer would be helpful

641338 :: ASSIGNED :: qemu :: jfor...@redhat.com :: f14 qemu-kvm guests 
boot very slowly :: https://bugzilla.redhat.com/show_bug.cgi?id=641338
  * next steps ...
 1) Are KDE-only bugs considered a release blockers?  If not, remove 
from list
 2) Feedback from reporter and maintainer would be helpful

640766 :: ASSIGNED :: kernel :: linvi...@redhat.com :: b43legacy wlan0 
fails DHCP requests :: https://bugzilla.redhat.com/show_bug.cgi?id=640766
  * next steps ...
 1) Maintainer and reporter work to resolve issue and submit update 
as soon as possible

584328 :: ASSIGNED :: python-pyblock :: pjo...@redhat.com :: 
AttributeError: 'NoneType' object has no attribute 'name' :: 
https://bugzilla.redhat.com/show_bug.cgi?id=584328
  * next steps ...
 1) Maintainer resolve issue and submit update as soon as possible

620635 :: ASSIGNED :: antlr3 :: xja...@fi.muni.cz :: antlr3 needs to be 
rebuilt against python 2.7 in F14 and devel :: 
https://bugzilla.redhat.com/show_bug.cgi?id=620635
  * next steps ...
1) Need communication from maintainer OR a proven packager needs to 
take action ASAP

625894 :: MODIFIED :: mesa :: a...@redhat.com :: kwin freezes when 
changing related settings in systemsettings while compositing is active 
:: https://bugzilla.redhat.com/show_bug.cgi?id=625894
  * next steps ...
1) Build new package and and make sure bodhi submission has been 
completed.
2) Change the bug status to ON_QA (bodhi should do this for you, but 
if not set it manually)
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-Math-GMP] Created tag perl-Math-GMP-2.06-5.fc14

[Paul Howarth]

The lightweight tag 'perl-Math-GMP-2.06-5.fc14' was created pointing to:

 4f8e760... Use hunspell dictionary for spell check test
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Net-SSH-Perl] Created tag perl-Net-SSH-Perl-1.34-8.fc14

[Paul Howarth]

The lightweight tag 'perl-Net-SSH-Perl-1.34-8.fc14' was created pointing to:

 aabdbf4... Use hunspell back-end for spell check test
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

F-14 Branched report: 20101012 changes

[Branched Report]

Compose started at Tue Oct 12 13:15:43 UTC 2010

Broken deps for x86_64
--
antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6
gnome-pilot-conduits-2.0.17-4.fc13.x86_64 requires 
libgpilotdconduit.so.2()(64bit)
gnome-pilot-conduits-2.0.17-4.fc13.x86_64 requires 
libgpilotd.so.2()(64bit)
gnome-pilot-conduits-2.0.17-4.fc13.x86_64 requires 
libgpilotdcm.so.2()(64bit)
intellij-idea-9.0.1.94.399-11.fc14.x86_64 requires jna-examples
qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit)
spacewalk-certs-tools-1.1.1-2.1.fc14.noarch requires 
spacewalk-backend-libs >= 0:0.8.28
valide-0.6.1-0.22.20103003svn511.fc14.i686 requires libvala.so.0
valide-0.6.1-0.22.20103003svn511.fc14.x86_64 requires 
libvala.so.0()(64bit)



Broken deps for i386
--
antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6
gnome-pilot-conduits-2.0.17-4.fc13.i686 requires libgpilotdcm.so.2
gnome-pilot-conduits-2.0.17-4.fc13.i686 requires libgpilotd.so.2
gnome-pilot-conduits-2.0.17-4.fc13.i686 requires libgpilotdconduit.so.2
intellij-idea-9.0.1.94.399-11.fc14.i686 requires jna-examples
qtgpsc-0.2.3-6.fc12.i686 requires libgps.so.18
spacewalk-certs-tools-1.1.1-2.1.fc14.noarch requires 
spacewalk-backend-libs >= 0:0.8.28
valide-0.6.1-0.22.20103003svn511.fc14.i686 requires libvala.so.0



New package: jpanoramamaker-5-2.fc14
 Tool for stitching photos to panorama in linear curved space

New package: libphidget-2.1.7.20100621-5.fc14
 Drivers and API for Phidget devices

New package: motoya-lcedar-fonts-1.00-0.1.20100928git.fc14
 Japanese Gothic-typeface TrueType fonts by MOTOYA Co,LTD

New package: nautilus-terminal-0.7-1.fc14
 Terminal embedded in Nautilus

New package: perl-KinoSearch1-1.00-2.fc14
 Search engine library

New package: perl-Lingua-EN-Tagger-0.16-2.fc14
 Part-of-speech tagger for English natural language processing


Updated Packages:

almanah-0.7.3-4.fc14

* Mon Oct 04 2010 Bill Nottingham  - 0.7.3-4
- Release bump and build to fix libedataserver broken dep


avr-gcc-4.5.1-2.fc14

* Fri Sep 24 2010 Thibault North  - 4.5.1-2
- Fix bug #637019 (gcc bug #45263) with the patch of Alastair D'Silva


bind-9.7.2-2.P2.fc14

* Wed Sep 29 2010 Adam Tkac  32:9.7.2-2.P2
- update to 9.7.2-P2


bind-dyndb-ldap-0.1.0-0.14.b.fc14
-
* Thu Sep 30 2010 Adam Tkac  - 0.1.0-0.14.b
- rebuild against new bind


certmonger-0.30-4.fc14
--
* Thu Sep 30 2010 Nalin Dahyabhai  0.30-4
- explicitly require "dbus" to try to ensure we have a running system bus
  when we get started (#639126)

* Wed Sep 29 2010 jkeating - 0.30-2.1
- Rebuilt for gcc bug 634757

* Thu Sep 23 2010 Nalin Dahyabhai  0.30-2
- try to SIGHUP the messagebus daemon at first install so that it'll
  let us claim our service name if it isn't restarted before we are
  first started (#636876)


dnsperf-1.0.1.0-21.fc14
---
* Thu Sep 30 2010 Adam Tkac  - 1.0.1.0-21
- rebuild against new bind


docbook-utils-0.6.14-26.fc14

* Mon Oct 04 2010 Ondrej Vasik  0.6.14-26
- fix autogenerated manpage header format(#639347)

* Tue Sep 28 2010 Ondrej Vasik  0.6.14-25
- make [[:space:]] class syntax compatible with new grep(#637594)

* Mon May 31 2010 Ondrej Vasik  0.6.14-24
- do not produce final echo, it causes some manpage noise
  with new perl(#513271, #587012)


dssi-1.1.0-2.fc14
-
* Sun Sep 26 2010 Orcan Ogetbil  - 1.1.0-2
- Fix 64bit plugin paths, once again

* Sat Sep 25 2010 Orcan Ogetbil  - 1.1.0-1
- Update to 1.1.0


eclipse-3.6.1-1.fc14

* Tue Oct 05 2010 Alexander Kurtakov  1:3.6.1-1
- Update to 3.6.1.


empathy-2.32.0.1-1.fc14
---
* Mon Oct 04 2010 Brian Pepple  - 2.32.0.1-1
- Update to 2.32.0.1.

* Fri Oct 01 2010 Brian Pepple  - 2.32.0-1
- Update to 2.32.0.


eric-4.4.8-1.fc14
-
* Fri Sep 24 2010 Johan Cwiklinski  4.4.8-1
- 4.4.8

* Mon Aug 02 2010 Johan Cwiklinski  4.4.7-1
- 4.4.7


g2clib-1.2.1-1.fc14
---
* Sat Oct 02 2010 Orion Poplawski  - 1.2.1-1
- Update to 1.2.1


ghostscript-8.71-16.fc14

* Mon Sep 13 2010 Tim Waugh  8.71-16
- Pulled in gs_fonts.ps modification for .runlibfileifexists from
  OpenSUSE package (bug #610301).

* Fri Sep 03 2010 Tim Waugh  8.71-15
- Restored Fontmap.local patch, incorrectly dropped after
  ghostscript-8.15.4-3 (bug #610301).
- Applied patch to let gdevcups use automatic memory allocation.  Use
  RIPCache=auto in /etc/cups/cupsd.conf to enable.
- Applied patch to fix NULL dereference in bbox driver (bug #591624).
- Applied upstream patch to fix iname.c seg

Re: Ubuntu 10.10's installer looks rather nice

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/12/10 8:13 AM, Chuck Anderson wrote:
> Making "advanced" only a choice at the beginning of a 10 step process 
> is a non-starter and leads to the problem you describe above.  If 
> instead there were "Advanced Options..." in each step along the way 
> that could be opened/closed at will, that would allow users to explore 
> the advanced options without worrying that they made the "wrong 
> choice" way back at the beginning of the 10 step process, whether or 
> not they actually end up using the advanced options.

So like how the storage screen now has an advanced option...

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAky0e/QACgkQ4v2HLvE71NXe9wCgl07dpZuFFIcAfs6Hs6BsG1av
z4IAoIRCQOdwQNiSzJ7OwM8ff1LPhdv/
=H56v
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Ubuntu 10.10's installer looks rather nice

[Chuck Anderson]

On Tue, Oct 12, 2010 at 08:06:59AM -0700, Jesse Keating wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 10/12/10 7:20 AM, Matthew Miller wrote:
> > On Tue, Oct 12, 2010 at 02:16:49PM +0200, Dennis Jacobfeuerborn wrote:
> >> The only way to accomplish this without actually removing the features is 
> >> to have two anaconda modes one for easy desktop installation and one full 
> >> featured mode. This mode should be chosen not by the user but by the spin 
> >> e.g. the desktop spin would use the easy mode and the server or 
> >> workstation 
> >> spins would use the full featured one.
> > 
> > Anaconda actually has the ability to do this with "install classes".
> > 
> > 
> 
> Anaconda used to have an Advanced mode where things like the complex
> partitioning and package selection were hidden.  Turns out, the vast
> majority of people who used anaconda and said something about it had
> picked advanced mode, because they felt their case was special.  If
> everybody uses advanced mode, that becomes the norm...

Making "advanced" only a choice at the beginning of a 10 step process 
is a non-starter and leads to the problem you describe above.  If 
instead there were "Advanced Options..." in each step along the way 
that could be opened/closed at will, that would allow users to explore 
the advanced options without worrying that they made the "wrong 
choice" way back at the beginning of the 10 step process, whether or 
not they actually end up using the advanced options.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Ubuntu 10.10's installer looks rather nice

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/12/10 7:20 AM, Matthew Miller wrote:
> On Tue, Oct 12, 2010 at 02:16:49PM +0200, Dennis Jacobfeuerborn wrote:
>> The only way to accomplish this without actually removing the features is 
>> to have two anaconda modes one for easy desktop installation and one full 
>> featured mode. This mode should be chosen not by the user but by the spin 
>> e.g. the desktop spin would use the easy mode and the server or workstation 
>> spins would use the full featured one.
> 
> Anaconda actually has the ability to do this with "install classes".
> 
> 

Anaconda used to have an Advanced mode where things like the complex
partitioning and package selection were hidden.  Turns out, the vast
majority of people who used anaconda and said something about it had
picked advanced mode, because they felt their case was special.  If
everybody uses advanced mode, that becomes the norm...

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAky0eZMACgkQ4v2HLvE71NUwgQCeMHsEFND/FgjGNzX60qPRL3G/
63wAn0PrhCneDRX3Kc0EG08dSSiheGFP
=9tU9
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Ubuntu 10.10's installer looks rather nice

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/12/10 7:20 AM, Rudolf Kastl wrote:
> I am doing the same setup, nice to see someone else with those
> requirements. actually without kickstart setting up softraid in
> anaconda was broken (try it manually without precreated partitions...
> it will drive you insane). out of the box booting didnt work when
> /boot was on a mirror raid and the mbr wasnt cloned either. not that
> great of an out of the box experience. i had those issues in f11 f12
> and f13.
> but hey... instead of redundancy having some colored automatically
> selected flags and languages is probably more important after all.

Have you been participating in the test days and filing bugs?  We've
done many raid setups, it's part of our release criteria, and we haven't
ran into the issues you seem to be describing above.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAky0eG4ACgkQ4v2HLvE71NV3hACgq6Wuii5Vue4Kg7ZI4hkfFJ5J
qGMAoJ3/hd/jzljK+OUlgE/SbR9l1iaz
=lxeC
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Ubuntu 10.10's installer looks rather nice

[Máirín Duffy]

On Mon, 2010-10-11 at 19:23 -0700, Adam Williamson wrote:
> On Mon, 2010-10-11 at 15:44 -0400, Jon Masters wrote:
> > Sadly enough, this means that a shiny Ubuntu installer is to the whole
> > distribution what GNOME shell is to the GNOME project. It doesn't matter
> > if you've got a lot of bells and whistles underneath, or what you can
> > do, if you don't look pretty while you do it. It's just the reality. I
> > would venture that one of the reasons Rich sent his mail originally is
> > that he's aware of this mentality and pointing out its effects.
> 
> You forgot to qualify the above paragraph: it doesn't matter _to a
> distribution reviewer_. We aren't necessarily making Fedora for
> distribution reviewers.

But impressions that get spread around do tend to haunt you.

The most technically-superior solution unfortunately doesn't always
enjoy the popularity it could have. (e.g. Beta max :) )

~m

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

Re: Ubuntu 10.10's installer looks rather nice

[Bastien Nocera]

On Mon, 2010-10-11 at 11:41 +0100, Richard W.M. Jones wrote:
> I installed and played with Ubuntu 10.10 over the weekend (in a VM),
> and I have to say that their installer is very smooth indeed.  It's
> starting to make anaconda look distinctly clunky.
> 
> Some of the things it does which are IMHO better:
> 
>  - starts disk formatting / copying / installing in parallel
>with asking user questions
> 
>  - downloads updates in parallel too
> 
>  - uses IP geolocation to guess the user's timezone and keyboard
>settings (it's been 100% correct for me each time)
> 
>  - suggests a username and hostname based on the user's real name
>(Mac OS X's installer also does this -- it's a nice touch)
> 
> This is in contrast to anaconda (certainly from the live CD install)
> which seems to be a usability no-go area.
> 
> Thoughts?

Could somebody send in bug numbers for the RFEs they filed already?

>   Can we switch to their installer?
> 
> Rich.
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming blog: http://rwmj.wordpress.com
> Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
> http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora


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

Re: Ubuntu 10.10's installer looks rather nice

[Bastien Nocera]

On Mon, 2010-10-11 at 11:11 -0400, Chris Lumens wrote:
> >  - downloads updates in parallel too
> 
> Package updates?
> 
> >  - uses IP geolocation to guess the user's timezone and keyboard
> >settings (it's been 100% correct for me each time)
> 
> We can do this, it's just never really been brought up.  I'd like to
> rework a lot of the l10n stuff anyway, there just never seems to be
> time.

Would like to see this as well.

> >  - suggests a username and hostname based on the user's real name
> >(Mac OS X's installer also does this -- it's a nice touch)
> 
> If DNS knows a hostname, we will suggest that.  Of course it's not
> foolproof.

That's not it. Your name is entered (Chris Lumens) and from it you
should get a hostname (chris-lumens-fedora-desktop.local) as well as a
presentation name ("Chris Lumens' Fedora Desktop") which could be used
for things like services being advertised through avahi, or even the
default name for the Bluetooth adapters.

See xdg-hostname on Freedesktop.org. I'd definitely like to see
something like that move forward so people can have nice names for their
Bluetooth adapters on the machines, and remove the need for me to show a
text entry to change that name in gnome-bluetooth.

> mgracik is working on the username suggestion thing already.
> 
> > Thoughts?  Can we switch to their installer?
> 
> No.
> 
> - Chris


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

Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft

[Brandon Lozza]

On Tue, Oct 12, 2010 at 9:48 AM, Michal Schmidt  wrote:
> On Tue, 12 Oct 2010 09:43:16 -0400 Brandon Lozza wrote:
>> On Tue, Oct 12, 2010 at 6:17 AM, Michal Schmidt wrote:
>>
>> >  - remove any features

Gnome is known for removing features, it was a joke.

>
> Perhaps you're confusing me with someone else. I have nothing to do with
> Gnome.
> But did Gnome ever remove features within a Fedora release?
> I don't think so.
>
> Michal

Not confusing anything, was just making a Gnome joke.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Ubuntu 10.10's installer looks rather nice

[Neal Becker]

Dennis Jacobfeuerborn wrote:

> On 10/12/2010 10:28 AM, Gerd Hoffmann wrote:
>> Hi,
>>
>>> Striving for usability and pleasantness for the untechnical users
>>> certainly is a good thing. It gets problematic when you choose to make
>>> things technically inferior just to please those kind of users.
>>
>> We don't have to make things inferior to improve usability.  To stick
>> with the "advanved storage" example:  IMHO the selection screen between
>> basic and advanced storage is confusing and superfluous.  First it
>> should probably be named "local storage" and "SAN storage".  Second
>> anaconda can default to local storage if a local disk is present (option
>> to add SAN storage needs to be there of course).  If no local disk is
>> present it can go straight to SAN setup.  One screen and one mouse click
>> less for most of the users.
> 
> If you want to appeal to the same audience Ubuntu is going for then you
> have to remove choice. The whole storage bit needs to be completely
> removed or at least stripped down. "advanced storage" certainly has to
> disappear completely.

I don't agree.  There's nothing unusual about a dumbed-down interface for 
novices, with an 'advanced' tab hiding more options.

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

Re: Git commit in all available branches

[Chuck Anderson]

On Tue, Oct 12, 2010 at 12:19:42PM +1000, Jeffrey Fearn wrote:
> Matthew Garrett wrote:
> > On Tue, Oct 12, 2010 at 09:32:15AM +1000, Jeffrey Fearn wrote:
> > 
> >> What do you mean "leave it alone"? The people using it WANT the changes. 
> >> Why are you telling them how they can use their system?
> > 
> > Because by pushing updates you're also potentially making it impossible 
> > for people who don't want new bugs to use Fedora. The board have decided 
> > that that's a class of user that we want to support.
> 
> They also won't get old bugs fixed because I for one don't have the time 
> , or the will, to maintain multiple versions.

It is a bit of a judgement call, but I think it is better to err on 
the side of not fixing minor bugs on older Fedora releases if that 
would mean making other disruptive changes that usually come with 
updating software versions, because someone who runs an older Fedora 
will at least be able to deal with known bugs, or if they can't, then 
they can schedule an update to newer Fedora (or pull in the newer 
package to their older release manually) on their own terms.

Also, if there is enough interest in having those bugs fixed in older 
releases without introducing disruptive changes, then perhaps a 
co-maintainer will step up and offer to do that 
backporting/cherry-picking patch work.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Ubuntu 10.10's installer looks rather nice

[Dennis Jacobfeuerborn]

On 10/12/2010 04:20 PM, Matthew Miller wrote:
> On Tue, Oct 12, 2010 at 02:16:49PM +0200, Dennis Jacobfeuerborn wrote:
>> The only way to accomplish this without actually removing the features is
>> to have two anaconda modes one for easy desktop installation and one full
>> featured mode. This mode should be chosen not by the user but by the spin
>> e.g. the desktop spin would use the easy mode and the server or workstation
>> spins would use the full featured one.
>
> Anaconda actually has the ability to do this with "install classes".
>

I figured as much and my guess is that anaconda already has most of the 
required stuff implemented and it's really just a case of lining up the 
bits and pieces the right way.

Another question is where to split this off exactly:

1) Different spins
2) Boot menu option (default=easy and an "advanced" option)
3) Selection screen when anaconda starts
4) "advanced" buttons in the anaconda pages

 From top to bottom I would say the implementation work probably decreases 
but the danger of one install path "contaminating" the other probably 
increases. What that means is that at 1) you end up with two completely 
distinct installation procedures which requires more work to implement but 
can really be customized for the different target audiences whereas at 4) 
you share a lot of stuff even in the interface but the different 
installation methods must have a similar workflow which doesn't allow for 
much individualization.

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

Re: Ubuntu 10.10's installer looks rather nice

[Matthew Miller]

On Tue, Oct 12, 2010 at 02:16:49PM +0200, Dennis Jacobfeuerborn wrote:
> The only way to accomplish this without actually removing the features is 
> to have two anaconda modes one for easy desktop installation and one full 
> featured mode. This mode should be chosen not by the user but by the spin 
> e.g. the desktop spin would use the easy mode and the server or workstation 
> spins would use the full featured one.

Anaconda actually has the ability to do this with "install classes".


-- 
Matthew Miller 
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Ubuntu 10.10's installer looks rather nice

[Rudolf Kastl]

2010/10/11 Gilboa Davara :
> On Mon, 2010-10-11 at 12:09 -0400, Jon Masters wrote:
>> On Mon, 2010-10-11 at 17:39 +0200, Gilboa Davara wrote:
>>
>> > Comparing the Ubuntu 10.04 DVD installer (which I use a couple of weeks
>> > ago) to Fedora 13 DVD installer is like comparing the Cessna to a Boeing
>> > 747.
>> > Sure, both can accomplish the same task. Read: transporting people from
>> > one airport to another, but lets see you try transporting 400 peoples
>> > from London to NY using a Cessna...
>> >
>> > The same logic applies to the Ubuntu installer: As long as you require a
>> > fairly basic -desktop- configuration (Read: No fancy storage, no LVM, no
>> > fancy setup source [nfs, dvd, http], -very- basic encryption, standard
>> > software set and repository selection, etc), the Ubuntu installer is a
>> > great tool, but once you need something complex, you're screwed.
>>
>> That's all true. I've found the Ubuntu installer looks /very/ polished
>> and nice for very common install cases, but I always use LVM on every
>> install that I do, and last time I did a VM install of Ubuntu, I had to
>> switch to a VT and get LVM sorted on the command line. Not super user
>> friendly as compared with Anaconda. Other installers were even more of a
>> joke doing this stuff. Tried doing LVM on Gentoo? :) Things like LVM and
>> VNC do really matter, and not just for "Enterprise" users. You don't
>> need to use LVM w/wo RAID, you can just do bare partitions if you don't
>> care about being able to do anything useful with your disks at all :)
>
> Amen to that.
> Given the absurdly cheap price of HD these days, I usually opt for LVM
> over software RAID1 / RAID5 on each and every workstation machine I
> install.
> Achieving the same using the Ubuntu installer would have required a lot
> of manual mdadm and lvm pv/vg/lv** commands. (Let alone their basic disk
> partitioning tool)
>
> ... In their race for Joe-six-pack and Apple like polish, Ubuntu gave up
> on many Linux core capabilities. Hopefully Fedora will -not- follow
> suite.

Hello,

I am doing the same setup, nice to see someone else with those
requirements. actually without kickstart setting up softraid in
anaconda was broken (try it manually without precreated partitions...
it will drive you insane). out of the box booting didnt work when
/boot was on a mirror raid and the mbr wasnt cloned either. not that
great of an out of the box experience. i had those issues in f11 f12
and f13.
but hey... instead of redundancy having some colored automatically
selected flags and languages is probably more important after all.

kind regards,
Rudolf Kastl


>
> - Gilboa
>
> - Gilboa
>
> --
> 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: Ubuntu 10.10's installer looks rather nice

[Dennis Jacobfeuerborn]

On 10/12/2010 02:57 PM, Jean-Francois Saucier wrote:
> On Tue, Oct 12, 2010 at 8:16 AM, Dennis Jacobfeuerborn
>   wrote:
>> On 10/12/2010 10:28 AM, Gerd Hoffmann wrote:
>>>  Hi,
>>>
 Striving for usability and pleasantness for the untechnical users 
 certainly is
 a good thing. It gets problematic when you choose to make things 
 technically
 inferior just to please those kind of users.
>>>
>>> We don't have to make things inferior to improve usability.  To stick
>>> with the "advanved storage" example:  IMHO the selection screen between
>>> basic and advanced storage is confusing and superfluous.  First it
>>> should probably be named "local storage" and "SAN storage".  Second
>>> anaconda can default to local storage if a local disk is present (option
>>> to add SAN storage needs to be there of course).  If no local disk is
>>> present it can go straight to SAN setup.  One screen and one mouse click
>>> less for most of the users.
>>
>> If you want to appeal to the same audience Ubuntu is going for then you
>> have to remove choice. The whole storage bit needs to be completely removed
>> or at least stripped down. "advanced storage" certainly has to disappear
>> completely.
>> The only way to accomplish this without actually removing the features is
>> to have two anaconda modes one for easy desktop installation and one full
>> featured mode. This mode should be chosen not by the user but by the spin
>> e.g. the desktop spin would use the easy mode and the server or workstation
>> spins would use the full featured one.
>>
>> You cannot make two distinct target audiences happy with one workflow
>> especially if one of those groups requires a limitation of choice.
>>
>> Regards,
>>Dennis
>> --
>> devel mailing list
>> devel@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/devel
>>
>
> Why this mode could not be selected by the user?
>
> I would say that the default mode be more like the Ubuntu installer
> and give the choice of an advanced mode like the current one. When you
> boot the CD/DVD, you could easily add the new choice in the list
> (Install, Install (advanced features), Boot from hard drive, etc).
>

That would certainly be an option. The key point here is that you need a 
way to provide a distinct experience for regular users that is not hampered 
by considerations for more advanced ones. That's one of the things that 
Ubuntu does differently than Fedora in my opinion although with the latest 
ideas for a simplified package manager Fedora is certainly heading in the 
right direction.

Let me clarify my position: I have no problem with with providing advanced 
features but in order to create a truly polished experience for regular 
users you need to be able to truly focus on them. If every time you think 
"If we did X, Y and Z we could make the lives of users a lot easier" you 
have to immediately go to "but because of the advanced audience we can't do 
X and Y and we can only do an awkward implementation of Z" than you will 
not be able to create a truly exceptional experience.

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

Re: Ubuntu 10.10's installer looks rather nice

[Chris Lumens]

> Anaconda goes though everything step-by-step instead, asking one 
> question after another, doing some work inbetween (partitining), asking 
> more questions (packages to install) ...

We have worked a little to reduce this over time, too.  If you remember
we used to have a confirmation screen after picking your packages.  The
result of that was that many people would click Next, go away to do
something thinking packages were being installed, then come back much
later only to see that the confirmation screen is still there.

But yes, there is always more to do.

> Dunno how hard it would be to change anaconda to have such an overview 
> screen.  Maybe it isn't *that* hard after all as we have kickstart.  So 
> for a interactive install anaconda could collect all info from the user, 
> compile a kickstart file from that, then feed the install machinery with 
> the just-generated kickstart file.

We have talked about doing just this.  I don't imagine it's terribly
difficuly, with the exception of storage.

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

Re: Ubuntu 10.10's installer looks rather nice

[Dennis Jacobfeuerborn]

On 10/12/2010 02:52 PM, Ralf Corsepius wrote:
> On 10/12/2010 02:16 PM, Dennis Jacobfeuerborn wrote:
>> On 10/12/2010 10:28 AM, Gerd Hoffmann wrote:
>>>   Hi,
>>>
 Striving for usability and pleasantness for the untechnical users 
 certainly is
 a good thing. It gets problematic when you choose to make things 
 technically
 inferior just to please those kind of users.
>>>
>>> We don't have to make things inferior to improve usability.  To stick
>>> with the "advanved storage" example:  IMHO the selection screen between
>>> basic and advanced storage is confusing and superfluous.  First it
>>> should probably be named "local storage" and "SAN storage".  Second
>>> anaconda can default to local storage if a local disk is present (option
>>> to add SAN storage needs to be there of course).  If no local disk is
>>> present it can go straight to SAN setup.  One screen and one mouse click
>>> less for most of the users.
>>
>> If you want to appeal to the same audience Ubuntu is going for then you
>> have to remove choice.
>
> Why? All that would be required would be to move it out of this
> audience's way (the "defaults").

Now we are really talking semantics. The point is that users should not be 
confronted with choices they don't really need to make or they don't 
understand.

> As Gerd mentioned in another mail, SUSE's installer seems interesting
> wrt. this. Its "defaults" cater the demands of "uneducated desktop
> installers", while still allows many kinds of complex setups outside of
> the "defaults" in "advanced menus".

As long as most of these defaults and menus are not displayed initially 
that would probably be fine.
The problem here is that every time you present the user with data dumps 
(e.g. lists of defaults) or menus you create a cognitive hurdle where the 
user wonders what he's supposed to do or gets worried that he breaks 
something. Minimizing that is really key to creating a streamlined 
installation interface.

The second aspect is that you want to talk to the user in terms of his 
"problem" and not in terms of the underlying technology. For example a user 
wants to either replace the current System completely or install the 
distribution into free space on his HD and but into either the old or the 
new installed system. The user doesn't care at all about "partitions", 
"LVM" or "mountpoints". This is different from the more apt user who wants 
to actually have control over these details (where exactly to put 
partition(s) on the disk for example).

The issue here is that keeping these advanced features available could have 
a negative impact on the "easy-mode" experience. If you manage to prevent 
that from happening than more power to you but if not then creating two 
distinct workflows is really the only option.

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

Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft

[Michal Schmidt]

On Tue, 12 Oct 2010 09:43:16 -0400 Brandon Lozza wrote:
> On Tue, Oct 12, 2010 at 6:17 AM, Michal Schmidt wrote:
> 
> >  - remove any features
> 
> > Michal
> 
> 
> How do you guys update Gnome then? ;)

Perhaps you're confusing me with someone else. I have nothing to do with
Gnome.
But did Gnome ever remove features within a Fedora release?
I don't think so.

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

Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft

[Brandon Lozza]

On Tue, Oct 12, 2010 at 6:17 AM, Michal Schmidt  wrote:

>  - remove any features

> Michal


How do you guys update Gnome then? ;)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

rawhide report: 20101012 changes

[Rawhide Report]

Compose started at Tue Oct 12 08:15:31 UTC 2010

Broken deps for x86_64
--
Inventor-2.1.5-39.fc14.i686 requires 
/usr/share/fonts/liberation/LiberationMono-Regular.ttf
Inventor-2.1.5-39.fc14.i686 requires 
/usr/share/fonts/liberation/LiberationSerif-Regular.ttf
Inventor-2.1.5-39.fc14.i686 requires 
/usr/share/fonts/liberation/LiberationSans-Regular.ttf
Inventor-2.1.5-39.fc14.x86_64 requires 
/usr/share/fonts/liberation/LiberationMono-Regular.ttf
Inventor-2.1.5-39.fc14.x86_64 requires 
/usr/share/fonts/liberation/LiberationSerif-Regular.ttf
Inventor-2.1.5-39.fc14.x86_64 requires 
/usr/share/fonts/liberation/LiberationSans-Regular.ttf
almanah-0.7.3-4.fc15.x86_64 requires libcamel-1.2.so.19()(64bit)
antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6
clutter-gst-devel-1.2.0-1.fc15.i686 requires pkgconfig(clutter-1.0) < 
0:1.3.0
clutter-gst-devel-1.2.0-1.fc15.x86_64 requires pkgconfig(clutter-1.0) < 
0:1.3.0
deskbar-applet-2.32.0-1.fc15.x86_64 requires libcamel-1.2.so.19()(64bit)
dreampie-python3-1.1-5.fc14.noarch requires python(abi) = 0:3.1
empathy-2.32.0-1.fc15.x86_64 requires libcamel-1.2.so.19()(64bit)
evolution-couchdb-0.5.0-1.fc15.x86_64 requires 
libcamel-provider-1.2.so.19()(64bit)
evolution-couchdb-0.5.0-1.fc15.x86_64 requires 
libcamel-1.2.so.19()(64bit)
evolution-sharp-0.21.1-9.fc14.x86_64 requires 
libcamel-1.2.so.19()(64bit)
1:gedit-devel-2.91.0-4.fc15.i686 requires gtksourceview2-devel >= 0:2.91
1:gedit-devel-2.91.0-4.fc15.x86_64 requires gtksourceview2-devel >= 
0:2.91
1:gnome-games-extra-2.31.91.1-1.fc15.x86_64 requires 
libclutter-gtk-0.10.so.0()(64bit)
gnome-pilot-eds-2.32.0-1.fc14.x86_64 requires 
libcamel-1.2.so.19()(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 
libevdocument.so.3()(64bit)
gnome-python2-evince-2.32.0-1.fc14.x86_64 requires 
libevview.so.3()(64bit)
gnome-python2-evolution-2.32.0-1.fc14.x86_64 requires 
libcamel-1.2.so.19()(64bit)
gnome-python2-totem-2.32.0-1.fc14.x86_64 requires 
libgnome-media-profiles.so.0()(64bit)
gpx-viewer-0.1.2-2.fc14.x86_64 requires 
libchamplain-gtk-0.4.so.0()(64bit)
gpx-viewer-0.1.2-2.fc14.x86_64 requires 
libclutter-gtk-0.10.so.0()(64bit)
gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-0.4.so.0()(64bit)
hornsey-1.5.2-0.3.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit)
jana-0.4.5-0.10.20100520gitacd72f2.fc15.i686 requires libcamel-1.2.so.19
jana-0.4.5-0.10.20100520gitacd72f2.fc15.x86_64 requires 
libcamel-1.2.so.19()(64bit)
lcdtest-1.18-3.fc13.x86_64 requires 
/usr/share/fonts/liberation/LiberationMono-Regular.ttf
1:libopensync-plugin-evolution2-0.22-8.fc14.x86_64 requires 
libcamel-1.2.so.19()(64bit)
mail-notification-evolution-plugin-5.4-24.fc15.x86_64 requires 
libcamel-provider-1.2.so.19()(64bit)
mail-notification-evolution-plugin-5.4-24.fc15.x86_64 requires 
libcamel-1.2.so.19()(64bit)
moblin-panel-people-0.1.14-1.fc14.x86_64 requires 
libcamel-1.2.so.19()(64bit)
moblin-panel-status-0.1.21-6.fc14.x86_64 requires 
libsocialweb-client.so.1()(64bit)
moblin-panel-status-0.1.21-6.fc14.x86_64 requires 
libchamplain-0.6.so.0()(64bit)
moblin-panel-status-0.1.21-6.fc14.x86_64 requires 
libclutter-gtk-0.10.so.0()(64bit)
pidgin-evolution-2.7.3-5.fc15.x86_64 requires 
libcamel-1.2.so.19()(64bit)
planner-eds-0.14.4-26.fc15.x86_64 requires 
libcamel-provider-1.2.so.19()(64bit)
planner-eds-0.14.4-26.fc15.x86_64 requires libcamel-1.2.so.19()(64bit)
plplot-tk-5.9.7-1.fc15.i686 requires 
/usr/share/plplot5.9.7/examples/tk/xtk02
plplot-tk-5.9.7-1.fc15.i686 requires 
/usr/share/plplot5.9.7/examples/tk/xtk01
plplot-tk-5.9.7-1.fc15.i686 requires 
/usr/share/plplot5.9.7/examples/tk/xtk04
plplot-tk-5.9.7-1.fc15.x86_64 requires 
/usr/share/plplot5.9.7/examples/tk/xtk02
plplot-tk-5.9.7-1.fc15.x86_64 requires 
/usr/share/plplot5.9.7/examples/tk/xtk01
plplot-tk-5.9.7-1.fc15.x86_64 requires 
/usr/share/plplot5.9.7/examples/tk/xtk04
qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit)
rakudo-0.0.2010.08_2.7.0-1.fc14.x86_64 requires 
libparrot.so.2.7.0()(64bit)
stardict-3.0.1-21.fc13.x86_64 requires libgucharmap.so.7()(64bit)
1:syncevolution-libs-1.0.99.7-1.fc15.i686 requires libcamel-1.2.so.19
1:syncevolution-libs-1.0.99.7-1.fc15.x86_64 requires 
libcamel-1.2.so.19()(64bit)
totem-2.90.5-5.fc15.i686 requires libpeasui-1.0.so.0
totem-2.90.5-5.fc15.x86_64 requires libpeasui-1.0

Re: Ubuntu 10.10's installer looks rather nice

[Jean-Francois Saucier]

On Tue, Oct 12, 2010 at 8:16 AM, Dennis Jacobfeuerborn
 wrote:
> On 10/12/2010 10:28 AM, Gerd Hoffmann wrote:
>>     Hi,
>>
>>> Striving for usability and pleasantness for the untechnical users certainly 
>>> is
>>> a good thing. It gets problematic when you choose to make things technically
>>> inferior just to please those kind of users.
>>
>> We don't have to make things inferior to improve usability.  To stick
>> with the "advanved storage" example:  IMHO the selection screen between
>> basic and advanced storage is confusing and superfluous.  First it
>> should probably be named "local storage" and "SAN storage".  Second
>> anaconda can default to local storage if a local disk is present (option
>> to add SAN storage needs to be there of course).  If no local disk is
>> present it can go straight to SAN setup.  One screen and one mouse click
>> less for most of the users.
>
> If you want to appeal to the same audience Ubuntu is going for then you
> have to remove choice. The whole storage bit needs to be completely removed
> or at least stripped down. "advanced storage" certainly has to disappear
> completely.
> The only way to accomplish this without actually removing the features is
> to have two anaconda modes one for easy desktop installation and one full
> featured mode. This mode should be chosen not by the user but by the spin
> e.g. the desktop spin would use the easy mode and the server or workstation
> spins would use the full featured one.
>
> You cannot make two distinct target audiences happy with one workflow
> especially if one of those groups requires a limitation of choice.
>
> Regards,
>   Dennis
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>

Why this mode could not be selected by the user?

I would say that the default mode be more like the Ubuntu installer
and give the choice of an advanced mode like the current one. When you
boot the CD/DVD, you could easily add the new choice in the list
(Install, Install (advanced features), Boot from hard drive, etc).


-- 
Jean-Francois Saucier (djf_jeff)
GPG key : 0xA9E6E953
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Ubuntu 10.10's installer looks rather nice

[Ralf Corsepius]

On 10/12/2010 02:16 PM, Dennis Jacobfeuerborn wrote:
> On 10/12/2010 10:28 AM, Gerd Hoffmann wrote:
>>  Hi,
>>
>>> Striving for usability and pleasantness for the untechnical users certainly 
>>> is
>>> a good thing. It gets problematic when you choose to make things technically
>>> inferior just to please those kind of users.
>>
>> We don't have to make things inferior to improve usability.  To stick
>> with the "advanved storage" example:  IMHO the selection screen between
>> basic and advanced storage is confusing and superfluous.  First it
>> should probably be named "local storage" and "SAN storage".  Second
>> anaconda can default to local storage if a local disk is present (option
>> to add SAN storage needs to be there of course).  If no local disk is
>> present it can go straight to SAN setup.  One screen and one mouse click
>> less for most of the users.
>
> If you want to appeal to the same audience Ubuntu is going for then you
> have to remove choice.

Why? All that would be required would be to move it out of this 
audience's way (the "defaults").

As Gerd mentioned in another mail, SUSE's installer seems interesting 
wrt. this. Its "defaults" cater the demands of "uneducated desktop 
installers", while still allows many kinds of complex setups outside of 
the "defaults" in "advanced menus".

Apart of what Gerd already said, SUSE's installer also comes with clever 
GUI-implementation details, which I think might be worth a look into for 
the anaconda folks ;)

Ralf

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

Re: Ubuntu 10.10's installer looks rather nice

[Dennis Jacobfeuerborn]

On 10/12/2010 10:28 AM, Gerd Hoffmann wrote:
> Hi,
>
>> Striving for usability and pleasantness for the untechnical users certainly 
>> is
>> a good thing. It gets problematic when you choose to make things technically
>> inferior just to please those kind of users.
>
> We don't have to make things inferior to improve usability.  To stick
> with the "advanved storage" example:  IMHO the selection screen between
> basic and advanced storage is confusing and superfluous.  First it
> should probably be named "local storage" and "SAN storage".  Second
> anaconda can default to local storage if a local disk is present (option
> to add SAN storage needs to be there of course).  If no local disk is
> present it can go straight to SAN setup.  One screen and one mouse click
> less for most of the users.

If you want to appeal to the same audience Ubuntu is going for then you 
have to remove choice. The whole storage bit needs to be completely removed 
or at least stripped down. "advanced storage" certainly has to disappear 
completely.
The only way to accomplish this without actually removing the features is 
to have two anaconda modes one for easy desktop installation and one full 
featured mode. This mode should be chosen not by the user but by the spin 
e.g. the desktop spin would use the easy mode and the server or workstation 
spins would use the full featured one.

You cannot make two distinct target audiences happy with one workflow 
especially if one of those groups requires a limitation of choice.

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

Re: Ubuntu 10.10's installer looks rather nice

[Farkas Levente]

On 10/12/2010 09:53 AM, Gilboa Davara wrote:
> 
>>
>> the other point of richards is what the whole fedora community and
>> redhat should have to understand: "most users like ubuntu rather then
>> fedora/redhat". why? because:
>> -... better is what most user like. period.
> 
> Following your simplistic logic, we should mimic the Windows Vista/7 UAC
> (Even if it's insecure by design) or even consider running as root by
> default, why?

with "better" i simple refer here to the style (ie. which one looks
better) it's nothing to do functionality or security. of course if you
wouldn't like to understand that's a different story.

ps. and yes most of the case windows and windows apps looks better the
linux and we'd have to learn a lot from them.

-- 
  Levente   "Si vis pacem para bellum!"
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft

[Michal Schmidt]

On Wed, 6 Oct 2010 12:50:00 -0600 Kevin Fenzi wrote:
> On Wed, 29 Sep 2010 09:19:08 +0200
> Michal Schmidt  wrote:
> > In the policy I do not see as clear distinction between F(n)
> > (current stable) and F(n-1) (old stable) as Jaroslav proposes. The
> > closest to it is this sentence:
> >   The update rate for any given release should drop off over time,
> >   approaching zero near release end-of-life.
> > The wording suggests a continuous rate of change which is weird and
> > hard to get right.
> > 
> > An explicit distinction between F(n) and F(n-1) would make sense for
> > at least these reasons:
> >  - Many users of F(n) desire current versions of end-user software
> >in updates (of course given that it gets tested sufficiently
> > before being pushed there and that the new version is not a
> > revolutionary change since the previous version).
> >  - Some users intentionally install F(n-1) only after F(n) is
> > released, believing it to be more stable and more conservative about
> > updates (important fixes only) than F(n). I guess this is intuitive
> > to users.
> >  - F(n)-updates-testing usually has a reasonable amount of users,
> > but much fewer people use F(n-1)-updates-testing.
> 
> How would you suggest wording this? The above is what people might
> expect from a F(n-1), but what policy would match these goals?
> 
> ie, how can we explain how F(n-1) is different from F(n) for
> maintainers? What updates should be in one and not the other? 

The idea is to relax the restrictions on updates to F(n) a bit, while
keeping very strict rules for F(n-1).

Updates to any release must NOT:
 - change API, ABI
 - change data or configuration formats
 - change the GUI in a major way
 - change command-line options incompatibly
 - remove any features
(Exceptions to these rules will granted only if fixing a security or
data loss bug would be impossible otherwise.)

Given the restrictions above, updates to F(n) are allowed to:
 - rebase to new upstream releases
 - add new features
 - make minor user interface changes
 - fix bugs

Updates to F(n-1) are ONLY allowed to:
 - fix bugs
   - the complete list of which must be included in the update
 description; the update must not change anything else.
   - cherry-picking of patches may be necessary

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

Re: Ubuntu 10.10's installer looks rather nice

[Nicolas Mailhot]

Le Lun 11 octobre 2010 23:44, Farkas Levente a écrit :

> imho, the never drop any feature since raid, lvm, iscsi are important
> (what's more i use them:-), BUT most user don't ie. 80% of the users
> never use them.

If you fail one way or another 20% of users you fail period. That's not an
acceptable failure rate for something like the installer everyone has to use
at a time.

-- 
Nicolas Mailhot

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

Re: Ubuntu 10.10's installer looks rather nice

[Gerd Hoffmann]

   Hi,

> Striving for usability and pleasantness for the untechnical users certainly is
> a good thing. It gets problematic when you choose to make things technically
> inferior just to please those kind of users.

We don't have to make things inferior to improve usability.  To stick 
with the "advanved storage" example:  IMHO the selection screen between 
basic and advanced storage is confusing and superfluous.  First it 
should probably be named "local storage" and "SAN storage".  Second 
anaconda can default to local storage if a local disk is present (option 
to add SAN storage needs to be there of course).  If no local disk is 
present it can go straight to SAN setup.  One screen and one mouse click 
less for most of the users.

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

Re: Ubuntu 10.10's installer looks rather nice

[Gerd Hoffmann]

On 10/11/10 19:31, Bruno Wolff III wrote:
> On Mon, Oct 11, 2010 at 11:41:13 +0100,
>"Richard W.M. Jones"  wrote:
>>
>> Some of the things it does which are IMHO better:
>>
>>   - starts disk formatting / copying / installing in parallel
>> with asking user questions
>
> I think that is a misfeature. I don't want anything irreversible to be done
> until I say go.

I always liked the way suse does the install.  It comes up with a 
*single* overview screen showing *everything* it suggests to do 
(partitioning, packages to install, some basic settings, ...).  Then you 
can go and change stuff if you want, and after changing settings it goes 
back to the overview screen, showing what it would do now after applying 
your changes. This way you are not bothered with lots of interactive 
questions but still have the option to change everything as you like if 
you want.  When you are happy with everything you say 'go!' and it goes. 
It doesn't touch your hard disk before.

Anaconda goes though everything step-by-step instead, asking one 
question after another, doing some work inbetween (partitining), asking 
more questions (packages to install) ...

Dunno how hard it would be to change anaconda to have such an overview 
screen.  Maybe it isn't *that* hard after all as we have kickstart.  So 
for a interactive install anaconda could collect all info from the user, 
compile a kickstart file from that, then feed the install machinery with 
the just-generated kickstart file.

Anaconda can try to figure reasonable defaults.  Using geoip. By 
inspecting the hardware.  Have 'klick here to change' buttons to change 
things, which can probably handled by the existing screens for timezone 
/ keyboard / ... selection.  Maybe even reading stuff from a kickstart 
file and present it in the overview, so you could stick your favorite 
non-default settings there.

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

Re: Git commit in all available branches

[Pavel Alexeev (aka Pahan-Hubbitus)]

 11.10.2010 21:26, Kevin Fenzi wrote:
> On Mon, 11 Oct 2010 09:07:17 +1000
> Jeff Fearn  wrote:
>
>> On Fri, 2010-10-08 at 13:56 -0600, Kevin Fenzi wrote:
>>> On Fri, 08 Oct 2010 18:03:04 +0400
>>> "Pavel Alexeev (aka Pahan-Hubbitus)"  wrote:
>>>
  In most cases I try sync all branches if there no real reasons to
 make differences.
>>> ...snip... 
>>>
>>> I would hope a real reason would be that the update is not a
>>> security or bugfix only update, right? 
>> IMHO it depends on what kind of software it is.
>>
>> I push releases of applications to all current Fedora releases. The
>> users want the new features, it's what they have been bugging me for.
>>
>> If I was working on glibc or X I might not do that, but applications
>> should be pushed back unless there is some system level constraint
>> preventing it.
>>
>> So I too would like a "commit to all branches" or "sync all branches
>> to this one" command. 
> If it doesn't change the user experience, and fixes bugs or security
> issues, then great. ;) If it's a major update which does change the
> user experience, breaks ABI/API, or adds a bunch of new functionality,
> then please don't. 
>
> kevin
Off course.

I really did not want start again this flame war. Off course I also have
packages where branches does not synced. I only ask how I can accomplish
such task where it possible.


-- 
With best wishes, Pavel Alexeev aka Pahan-Hubbitus. For fast contact
with me you could use Jabber: hubbi...@jabber.ru
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Ubuntu 10.10's installer looks rather nice

[Gilboa Davara]

> 
> the other point of richards is what the whole fedora community and
> redhat should have to understand: "most users like ubuntu rather then
> fedora/redhat". why? because:
> -... better is what most user like. period.

Following your simplistic logic, we should mimic the Windows Vista/7 UAC
(Even if it's insecure by design) or even consider running as root by
default, why?
- Usage-wise, Windows XP is the leading OS in the world, and 99% of all
Windows XP users are running as administrator. (Most don't even bother
to use password protected administrator-capable user accounts)
- Windows 7 will most likely overtake Windows XP in 2-3 years and it's
using UAC by default.

I assume that I do really need point out -why- this logic is flawed...
Different operating system target different user bases and usage cases.
Different Linux distributions target different user bases and usage
cases.

At least the last time I checked, Fedora -didn't- target Joe-six-pack as
its primary target user base (Let alone RHEL, which shares the same
Anaconda code).

- Gilboa


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