glibc policy chage?

[Michał Piotrowski]

Hi,

I noticed that F17 is based on the latest stable glibc realease.
Previously development Fedora version was based on development glibc.
Was there a change of some Fedora glibc policy? If it is no
coincidence, but the new policy - many thanks for the change :)

-- 
Best regards,
Michal

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

Re: glibc policy chage?

[Frank Murphy]

On 06/02/12 09:27, Michał Piotrowski wrote:

Hi,

I noticed that F17 is based on the latest stable glibc realease.
Previously development Fedora version was based on development glibc.



I'm guessing Branched in a couple of days, would need some stability.

--
Regards,

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

Re: glibc policy chage?

[Jared K. Smith]

2012/2/6 Michał Piotrowski :
> I noticed that F17 is based on the latest stable glibc realease.
> Previously development Fedora version was based on development glibc.
> Was there a change of some Fedora glibc policy? If it is no
> coincidence, but the new policy - many thanks for the change :)

Yes, we've worked with the glibc maintainers in Fedora to change the
way that glibc packages are produced.  Previously, each new updated
glibc package would sync in most (if not all) of the latest changes
from development, which made it difficult to release.  For example, in
the F16 development cycle, we had several instances of bug-fix
releases for glibc causing further regressions.

In the new scheme, glibc packages will be based on stable releases,
with bug-fixes back-ported as necessary.  I'll throw out a huge thank
you to Jeff Law for being willing to step up and take over maintenance
of the glibc packages in Fedora, and for building those packages in a
less chaotic way than was previously done.

--
Jared Smith
Fedora Project Leader
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Does anyone still need to create legacy HFS filesystems?

[Joel Rees]

On Sun, Feb 5, 2012 at 7:36 AM, Chris Murphy  wrote:
> On Feb 3, 2012, at 12:06 PM, John Reiser wrote:
>
>> Examining with gparted and Disk Utility, I see an Apple partition label
>> that designates partitions:
>>
>>  HFS (not plus)       1 MB  boot
>>  HFS+ journalled   25.6 GB  Machintosh HD
>>  ext3              10.6 GB  Fedora root
>>  swap               1.0 GB
>>
>> I believe that the plain HFS boot partition was created during
>> Fedora install.  It's now running MacOS 10.4.11 and Fedora 12,
>> which are both the latest applicable releases.
>
> I though you meant a user accessible volume being formatted as HFS.
>
> HFS+ and HFSX volumes must be greater than 32MB, where as HFS supports 
> smaller sizes. As for the purpose of the 1MB HFS volume, it may be a Fedora 
> PPC convention. I have a PowerPC machine dual booting two versions of Mac OS 
> X, and the disk does not have an HFS volume on it. They are jhfs+.

Sort of Fedora convention. Debian can use a larger disk to store the
boot files.

My impression is that the HFS volume made there is primarily for code
that no one wants to fix, and to hide from the user slightly hairy
boot incantations like "boot hd:3,ofwboot /bsd" (per the openbsd boot
incantation for ppc).

I personally would prefer to use ofwboot directly, because Fedora's
gparted doesn't seem to be able to make volumes as small a 1M on disks
larger than 120G or so, and every partition used by Linux for making
things easier on the user is one less that could be used for
multi-boot and such. But I haven't had success guessing which file to
name in the above incantation on Fedora.

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

Re: help with adding systemd support to a package.

[Michal Schmidt]

Itamar Reis Peixoto wrote:
> I need help adding systemd support into xrdp.
> 
> someone can take a look and tell me what is wrong ?

Are you seeing any actual problems with the service?

I have not tried to run the service, but here's what comes
to mind:
 - It is pointless to declare both
in A: After=B
in B: Before=A
   Once you declare the ordering in one of the services,
   the other is implied automatically.
 - Is it really necessary to have network.target?
   I.e. Can't the daemons start listening on their sockets
   regardless of whether a network connection is ready?
 - Other distributions may not like the usage of
   /etc/sysconfig/. In order to unify the configuration of
   the program among distributions it would be great if
   the program had its own native config file somewhere
   in /etc.

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

Re: Does anyone still need to create legacy HFS filesystems?

[Joel Rees]

Think MOL? I've never used it, but I would hate to block its use on
Fedora. I'm planning to use it someday.

On Sat, Feb 4, 2012 at 3:12 AM, Chris Murphy  wrote:
>
>
> On Feb 2, 2012, at 6:45 PM, John Reiser wrote:
>
>>> Does anyone object [to dropping support for HFS]?
>>
>> Plain HFS has no journal, so there are workloads where HFS is faster
>> than HFS+ which has a journal.
>
> Mac OS Extended or HFS+ or HFS Plus, does not inherently have a journal. 
> There is a separate variant called Journaled HFS+ (acronym appears as HFSJ or 
> jhfs+). There is yet another variant called HFSX which is case-sensitive, but 
> also has more feature potential than HFSJ.
>
> For nearly nine years Apple's tools have only created HFSJ/jhfs+ by default.

Most of the reason for supporting HFS at all lies in seriously old
legacy software. Much older than nine years.

>>  Is it economical to cater to such cases?
>> Probably not.

retro computing? Maintaining access to pre-historic data?

(I keep thinking I want to get MOL or an equivalent emulator running
on a Linus box so I can dump my ancient 68K macs like my wife wants me
to. There's a sentimental resistance to dumping those boxes, but I
haven't booted either in over a year, I think. Wait. I played around
with an old Codewarrior compiler on one last summer. Heh.)

>> [...]
> HFS is dead. I'm not even finding a partition type GUID for it, it was always 
> intended to be used with the APM partitioning scheme (not MDB or GPT).

Well, yeah, the partition type was a kind of half-baked attempt to
help DOS-world OSses ignore Mac disks. I don't remember the flag
number and I couldn't find it last time I looked, either. I think it
got re-used by something more meaningful in the DOS-world.

But, no, HFS isn't really dead. Old formats should not be allowed to
die. I do want to be able to read my old media under emulation
someday. Apple doesn't care, but I do.

Sentimental fool that I am. :-/

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

Re: glibc policy chage?

[Stephen Gallagher]

On Mon, 2012-02-06 at 06:11 -0500, Jared K. Smith wrote:
> 2012/2/6 Michał Piotrowski :
> > I noticed that F17 is based on the latest stable glibc realease.
> > Previously development Fedora version was based on development glibc.
> > Was there a change of some Fedora glibc policy? If it is no
> > coincidence, but the new policy - many thanks for the change :)
> 
> Yes, we've worked with the glibc maintainers in Fedora to change the
> way that glibc packages are produced.  Previously, each new updated
> glibc package would sync in most (if not all) of the latest changes
> from development, which made it difficult to release.  For example, in
> the F16 development cycle, we had several instances of bug-fix
> releases for glibc causing further regressions.
> 
> In the new scheme, glibc packages will be based on stable releases,
> with bug-fixes back-ported as necessary.  I'll throw out a huge thank
> you to Jeff Law for being willing to step up and take over maintenance
> of the glibc packages in Fedora, and for building those packages in a
> less chaotic way than was previously done.


I'd like to second that. Glibc forms the basic foundation of Fedora, and
it's nice to know that we'll have fewer earthquakes post-Alpha. Thanks
very much Jeff!


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

why is gurb-menu hidden as default?

[Reindl Harald]

hi

who decided that it is a good idea to hide the grub-menu?
most questions on mailing-lists and boards is "how can
i boot  a different kernel" and it makes really really tired
to see that no new user is realizing that Fedora has a boot
manager

this results a) in needless questions and b) new users does
learn nothing because they see nothing as default



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

Re: filesystem

[Jon Ciesla]

On Sat, Feb 4, 2012 at 12:53 PM, Jef Spaleta  wrote:
> On Fri, Feb 3, 2012 at 5:10 PM, darrell pfeifer  wrote:
>> If you continue to repeat the "eating babies" myth then it will become
>> self-fulfilling.
>
> I would humbly suggest that use of future tense is that sentence is
> overly optimistic and is misleading. I think that sentence above reads
> more accurately
> if reconstructed using present perfect continuous tense to indicate
> that the eating babies myth has been and continues to be
> self-fulfilling instead of suggesting it has yet reached that state.
>
> I however do not believe its a myth. I believe it is a tweetable
> catchphrase which tries to encapsulate the nature of rawhide as a
> collection of bits instead of having to point someone to a detailed
> 1000+ word essay that goes into details of the seasonal stability
> nature rawhide. I do not think it inaccurate, but it may be overly
> graphic and it always makes me hungry when I see it uttered.

I always thought it killed kittens, rather than ate babies.  This is
so confusing.  How are we to know which condiments to keep at the
ready?

-J

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



-- 
in your fear, seek only peace
in your fear, seek only love

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

Re: why is gurb-menu hidden as default?

[Tomasz Torcz]

On Mon, Feb 06, 2012 at 02:55:38PM +0100, Reindl Harald wrote:
> who decided that it is a good idea to hide the grub-menu?

  It was F10 feature: http://fedoraproject.org/wiki/Features/BetterStartup
I believe showing GRUB2 menu is a regression which will be
fixed before F17 release.

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

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

Re: rawhide report: 20120206 changes

[Richard W.M. Jones]

On Mon, Feb 06, 2012 at 01:22:14PM +, Rawhide Report wrote:
> [libguestfs]
[...]

This should be fixed by the current build going through Koji at the
moment.

> [ocaml-augeas]

Needs upstream attention still.

Rich.


-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: why is gurb-menu hidden as default?

[Reindl Harald]

Am 06.02.2012 15:07, schrieb Tomasz Torcz:
> On Mon, Feb 06, 2012 at 02:55:38PM +0100, Reindl Harald wrote:
>> who decided that it is a good idea to hide the grub-menu?
> 
> It was F10 feature: http://fedoraproject.org/wiki/Features/BetterStartup
> I believe showing GRUB2 menu is a regression which will be
> fixed before F17 release.

what regression?

i speak about that GENERALLY the boot-maanger should be VISIBLE
in Feodra as also in RHEL and not hidden, to hide the option
boot with the previous kernel for everybody since years
degrades the whole OS because if a new kernel does not boot
and a new user does not know how to get the boot menu while
he is owning only this machine prevents him to boot it

on the other hand if we display the boot menu even a totally
new user would see it and have a good chance to start his machine





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

Draft schedule for today's FESCO meeting (6th February 2012)

[Matthew Garrett]

Following is the list of topics that will be discussed in the FESCo
meeting tomorrow at 18:00UTC (1:00pm EST) in #fedora-meeting on
irc.freenode.net.

Links to all tickets below can be found at: 
https://fedorahosted.org/fesco/report/9

= Followups =

#topic #690 F17 Feature: move all to /usr - 
https://fedoraproject.org/wiki/Features/UsrMove
.fesco 690

#topic #756 F17 Feature: English Typing Booster - 
https://fedoraproject.org/wiki/Features/english-typing-booster
.fesco 756

#topic #796 F17 Feature: Network Zones - 
https://fedoraproject.org/wiki/Features/network-zones
.fesco 796

#topic #797 F17 Feature: firewall-d - default firewall solution -- 
https://fedoraproject.org/wiki/Features/firewalld-default
.fesco 797

= Fedora Engineering Services tickets = 

https://fedorahosted.org/fedora-engineering-services/report/6

= Open Floor = 

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting. 

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Review Swap

[Nikos Roussos]

Hi Pavel,

Ok :-)
 On Feb 5, 2012 8:16 PM, "Pavel Alexeev"  wrote:

>  Hello, Nikos.
>
> I'm ready swap to httpd-itk package -
> https://bugzilla.redhat.com/show_bug.cgi?id=598860
>
> 04.02.2012 00:42, Nikos Roussos wrote:
>
> I'd like a review about sparkleshare package:
> https://bugzilla.redhat.com/show_bug.cgi?id=787293
>
> Does somebody like to swap reviews?
>
> Thanks in advance
>
> --
> Nikos Roussos
> about 
>
> --
> With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact
> with me use jabber: hubbi...@jabber.ru
>
>
> --
> 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

Heads up: Ruby 1.9.3 landed in Rawhide

[Bohuslav Kabrda]

Hi all,
Ruby 1.9.3 has finally made it into Rawhide, there are still few more packages 
that need to be built, but otherwise the transitions was successful.

Please note again, that soname has been bumped to 1.9.1 and license is changed 
from GPLv2 or Ruby to BSD or Ruby, as already announced.

-- 
Regards,
Bohuslav "Slavek" Kabrda.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Fedora 17 Feature Freeze is TOMORROW, February 7.

[Robyn Bergeron]

A friendly reminder as we move towards a miraculous, beefy release:

* Feature freeze is tomorrow, February 7, 2012.  At this point, all 
accepted features should be substantially complete, and testable. 
Additionally, if a feature is to be enabled by default, it must be so 
enabled at Feature Freeze.


https://fedoraproject.org/wiki/Feature_Freeze_Policy
https://fedoraproject.org/wiki/Features/Policy/Milestones#Feature_Freeze

If you are a FEATURE OWNER:

* The percentage of completion on your feature's wiki page should 
reflect your current progress.  Feature pages should be updated *at 
least* monthly.


https://fedoraproject.org/wiki/Features/Policy/Status

* Features which do not appear to be substantially complete will be sent 
to FESCo for review as to whether or not they should continue to be 
listed as a release feature.  Your feature's wiki page status and 
indication of progress is what determines whether or not it will be sent 
to FESCo.


Please, for the love of Beefy, UPDATE YOUR PAGES. There are 62 features 
() currently slated for F17. Updating your feature page's completion 
percentage, along with the date that you updated your page, prevents me 
from having to relentlessly beg you all individually via e-mail to do 
the same thing. :)


If you have questions, concerns, flames, or winning lottery tickets 
which will prevent you from completing your feature, please don't 
hesitate to contact me.


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

[Test-Announce] Announcing 389 Directory Server version 1.2.10 Release Candidate 1 Testing

[Rich Megginson]

The 389 Project team is pleased to announce the release of 
389-ds-base-1.2.10.rc1.  No new features were added between alpha 8 and 
rc1, just many bug fixes.  There are also 389-adminutil, 389-admin, and 
389-dsgw packages in Testing.


NEW: EL6 support

Beginning with RHEL 6.2, the 389-ds-base package is included in the base 
OS.  Therefore, the 389-ds-base package can no longer be provided via 
EPEL, due to RHEL/EPEL packaging restrictions.


However, the 389 Project will still make the full 389-ds-base package 
available via http://repos.fedorapeople.org/repos/rmeggins/389-ds-base. 
 See http://directory.fedoraproject.org/wiki/Download for more information.


NEW: Issue Tracking System

We have moved our ticket tracking system from the Red Hat Bugzilla 
https://bugzilla.redhat.com/enter_bug.cgi?product=389 to our Fedora 
Hosted Trac https://fedorahosted.org/389. All of the old 389 bugs have 
been copied to Trac. All new bugs, feature requests, and tasks should be 
entered in Trac


NEW: Plugin Authors

WARNING: Plugins should be made transaction aware so that they can be 
called from within a backend pre/post transaction plugin. Otherwise,
attempting to perform an internal operation will cause a deadlock. See 
http://directory.fedoraproject.org/wiki/Plugins


Installation

 yum install --enablerepo=updates-testing 389-ds
 # or for EPEL
 yum install --enablerepo=epel-testing 
[--enablerepo=epel-testing-389-ds-base] 389-ds

 setup-ds-admin.pl

Upgrade

 yum upgrade --enablerepo=updates-testing 389-ds-base 
idm-console-framework 389-admin 389-ds-console 389-admin-console 
389-dsgw 389-adminutil

 # or for EPEL
 yum upgrade --enablerepo=epel-testing 
[--enablerepo=epel-testing-389-ds-base] 389-ds-base 
idm-console-framework 389-admin 389-ds-console 389-admin-console 
389-dsgw 389-adminutil

 setup-ds-admin.pl -u

How to Give Feedback

The best way to provide feedback is via the Fedora Update system.

* Go to https://admin.fedoraproject.org/updates
* In the Search box in the upper right hand corner, type in the name of 
the package
* In the list, find the version and release you are using (if you're not 
sure, use rpm -qi  on your system) and click on the release
* On the page for the update, scroll down to "Add a comment" and provide 
your input


Or just send us an email to 389-us...@lists.fedoraproject.org

Reporting Issues

https://fedorahosted.org/389

More Information
* Release Notes - http://port389.org/wiki/Release_Notes
* Install_Guide - http://port389.org/wiki/Install_Guide
* Download - http://port389.org/wiki/Download


___
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: Draft schedule for today's FESCO meeting (6th February 2012)

[Josef Bacik]

On Mon, Feb 6, 2012 at 9:18 AM, Matthew Garrett  wrote:
> Following is the list of topics that will be discussed in the FESCo
> meeting tomorrow at 18:00UTC (1:00pm EST) in #fedora-meeting on
> irc.freenode.net.
>
> Links to all tickets below can be found at:
> https://fedorahosted.org/fesco/report/9
>
> = Followups =
>
> #topic #690     F17 Feature: move all to /usr - 
> https://fedoraproject.org/wiki/Features/UsrMove
> .fesco 690
>
> #topic #756     F17 Feature: English Typing Booster - 
> https://fedoraproject.org/wiki/Features/english-typing-booster
> .fesco 756
>
> #topic #796     F17 Feature: Network Zones - 
> https://fedoraproject.org/wiki/Features/network-zones
> .fesco 796
>
> #topic #797     F17 Feature: firewall-d - default firewall solution -- 
> https://fedoraproject.org/wiki/Features/firewalld-default
> .fesco 797
>
> = Fedora Engineering Services tickets =
>
> https://fedorahosted.org/fedora-engineering-services/report/6
>
> = Open Floor =
>
> For more complete details, please visit each individual ticket.  The
> report of the agenda items can be found at
> https://fedorahosted.org/fesco/report/9
>
> If you would like to add something to this agenda, you can reply to
> this e-mail, file a new ticket at https://fedorahosted.org/fesco,
> e-mail me directly, or bring it up at the end of the meeting, during
> the open floor topic. Note that added topics may be deferred until
> the following meeting.
>

We're running close to the wire on this but it looks like Chris will
have fsck out for btrfs tomorrow, so I'd like to get fesco's opinion
on the viability of moving forward with the Btrfs as default feature,
whether we actually want to make a push for it or leave it for F18.
Thanks,

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

Re: Draft schedule for today's FESCO meeting (6th February 2012)

[Matthew Garrett]

On Mon, Feb 06, 2012 at 10:51:37AM -0500, Josef Bacik wrote:

> We're running close to the wire on this but it looks like Chris will
> have fsck out for btrfs tomorrow, so I'd like to get fesco's opinion
> on the viability of moving forward with the Btrfs as default feature,
> whether we actually want to make a push for it or leave it for F18.

There's been a couple of concerns raised about btrfs's resiliance 
against local attacks (forced hash collisions and the like) - is local 
hardening something that's been on the test plan so far?

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: why is gurb-menu hidden as default?

[Tomasz Torcz]

On Mon, Feb 06, 2012 at 03:16:40PM +0100, Reindl Harald wrote:
> 
> 
> Am 06.02.2012 15:07, schrieb Tomasz Torcz:
> > On Mon, Feb 06, 2012 at 02:55:38PM +0100, Reindl Harald wrote:
> >> who decided that it is a good idea to hide the grub-menu?
> > 
> > It was F10 feature: http://fedoraproject.org/wiki/Features/BetterStartup
> > I believe showing GRUB2 menu is a regression which will be
> > fixed before F17 release.
> 
> what regression?

  GRUB2 menu is shown in F16. This is a regression compared to F10÷15.
See https://bugzilla.redhat.com/show_bug.cgi?id=757487 and linked
bugs #737339 and #727831.

-- 
Tomasz Torcz  ,,If you try to upissue this patchset I shall be 
seeking
xmpp: zdzich...@chrome.pl   an IP-routable hand grenade.'' -- Andrew Morton 
(LKML)

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

Re: why is gurb-menu hidden as default?

[drago01]

On Mon, Feb 6, 2012 at 3:16 PM, Reindl Harald  wrote:
>
>
> Am 06.02.2012 15:07, schrieb Tomasz Torcz:
>> On Mon, Feb 06, 2012 at 02:55:38PM +0100, Reindl Harald wrote:
>>> who decided that it is a good idea to hide the grub-menu?
>>
>> It was F10 feature: http://fedoraproject.org/wiki/Features/BetterStartup
>> I believe showing GRUB2 menu is a regression which will be
>> fixed before F17 release.
>
> what regression?
>
> i speak about that GENERALLY the boot-maanger should be VISIBLE
> in Feodra as also in RHEL and not hidden, to hide the option
> boot with the previous kernel for everybody since years

No unless you dual boot another OS the bootloader should not be
visible as the user does not have to care about it.
Other OSs also don't do that for a reason.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: why is gurb-menu hidden as default?

[Reindl Harald]

Am 06.02.2012 17:10, schrieb Tomasz Torcz:
> On Mon, Feb 06, 2012 at 03:16:40PM +0100, Reindl Harald wrote:
>>
>>
>> Am 06.02.2012 15:07, schrieb Tomasz Torcz:
>>> On Mon, Feb 06, 2012 at 02:55:38PM +0100, Reindl Harald wrote:
 who decided that it is a good idea to hide the grub-menu?
>>>
>>> It was F10 feature: http://fedoraproject.org/wiki/Features/BetterStartup
>>> I believe showing GRUB2 menu is a regression which will be
>>> fixed before F17 release.
>>
>> what regression?
> 
> GRUB2 menu is shown in F16. This is a regression compared to F10÷15.
> See https://bugzilla.redhat.com/show_bug.cgi?id=757487 and linked
> bugs #737339 and #727831.

this is a behavior that should never been changed!



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

PIDA, pygtkhelpers, medit

[Jon Ciesla]

PIDA, in f16 and beyond, has broken deps:
https://bugzilla.redhat.com/show_bug.cgi?id=754673

So to fix this, I need to update to the latest upstream:
https://bugzilla.redhat.com/show_bug.cgi?id=651853

But this release need python-flatland and pygtkhelpers.  I got
python-flatland into Fedora.

pygtkhelpers is going to be a problem, as it bundles code from medit,
which in turn bundles gtksourceview:
https://bugzilla.redhat.com/show_bug.cgi?id=767185

The new pida release also apparently bundles code from medit.

I've torn out enough hair trying to unbundle gtksourceview from medit,
so I'm retiring PIDA and closing the pygtkhelpers review.

I anyone cares sufficiently about PIDA to see this through, you are
welcome to do so. :)

-J

-- 
in your fear, seek only peace
in your fear, seek only love

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

evoltuion-data-server 3.3.5 libcamel soname bump in rawhide

[Milan Crha]

Hi,
with evolution-data-server 3.3.5 release is also bumped soname version
for libcamel. I realized just now, when building eds for rawhide.
Bye,
Milan

___
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

[Guidelines Change] Changes to the Packaging Guidelines

[Tom Callaway]

There have been quite a few approved changes to the Fedora Packaging
Guidelines since the previous announcement, but this is mostly because I
have not had time to actually apply the approved updates to the wiki
until recently. These updates actually were approved over a period of
several months. I will try harder to get updates written up and
announced in a more timely fashion going forward.

---

The Eclipse Plugin Packaging Guidelines were updated. The most major
change is the addition of a section discussing how to run the
reconciler. For the full updated guidelines see:
https://fedoraproject.org/wiki/Packaging:EclipsePlugins

---

t4k_common contains a forked copy of an older version of liblinebreak. A
temporary bundling exception has been granted until the t4k_common
upstream is able to port their code to use the newer system copy of
liblinebreak. The t4k_common package must include Provides:
bundled(liblinebreak) until the issue is resolved.

This exception has been added to the list here:
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_granted_exceptions

---

Spring RTS includes a forked and bundled copy of Lua which has Spring
RTS specific patches applied, must link to streflop, and is configured
differently from stock Lua (most importantly it needs lua_Number to be a
float and not a double). Lua is particularly important because parts of
the game code may be written in it, which must yield exactly identical
results (also floating point operations!) on all platforms.

As a result, it has been granted a bundling exception for lua. The
Spring RTS package must include Provides: bundled(lua) = X.Y.Z (where
X.Y.Z is the base lua version), until the bundling issue is resolved (if
ever).

This exception has been added to the list here:
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_granted_exceptions

---

A section has been added to the Guidelines that limits which package
manager repositories are allowed to be configured in Fedora. Additional
repository configuration files are allowed as documentation provided
that they are legally allowable by Fedora.

https://fedoraproject.org/wiki/Packaging:Guidelines#Configuration_of_Package_Managers

---

The MPI Guidelines have been clarified by adding this additional statement:

If the maintainer wishes for the environment module to load
automatically by use of a scriptlet in /etc/profile.d or by some other
mechanism, this MUST be done in a subpackage.

https://fedoraproject.org/wiki/Packaging:MPI

---

The Devel Packages section of the Packaging Guidelines has been
rewritten to be more comprehensive and clear:

https://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages

In addition, the ReviewGuidelines have been simplified to state simply
that Development files must be in a -devel package.

---

An exception was granted which permits the bundling of binutils
libraries, (most notably, libbfd, libcpu, libopcodes, and libdecnumber)
but only to packages which share the same upstream as binutils
(sourceware.org). This is because the libraries are developed by the
application authors as common functionality shared between several
applications. Being developers of both, they'll be intimately aware of
both issues that arise in the libraries and know how to port to newer
versions of the library as needed. Note that, at the moment, all of
these applications and libraries come from sourceware.org but not all of
them are used in binutils.

Packages leveraging this exception must add: Provides: bundled(binutils)
= %{snap}, where %{snap} is defined in the package as the date that the
binutils checkout was made, until the bundling issue is resolved (if ever).

This exception has been added to the list here:
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_granted_exceptions

---

The Packaging Guidelines section on Architecture Support has been
amended to clarify that all Fedora packages must successfully compile
and build into binary rpms on at least one supported primary
architecture, except where the package is useful only on a secondary
architecture (such as an architecture-specific boot utility, microcode
loader, or hardware configuration tool).

https://fedoraproject.org/wiki/Packaging:Guidelines#Architecture_Support

---

The "okjson" software has reluctantly been granted a bundling exception.
Packages which bundle okjson.rb must add: Provides: bundled(okjson),
until the bundling issue is resolved (if ever).

https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_granted_exceptions

---

The section of the Packaging Guidelines covering /srv was amended to
include /opt and /usr/local. Specifically, the following sentence was added:

  In addition, no Fedora package can have any files or directories
  under /opt or /usr/local, as these directories are not permitted to
  be used by Distributions in the FHS.

https://fedoraproject.org/wiki/Packaging:Guidelines#No_Files_or_Director

Re: why is gurb-menu hidden as default?

[Reindl Harald]

Am 06.02.2012 17:16, schrieb drago01:
> On Mon, Feb 6, 2012 at 3:16 PM, Reindl Harald  wrote:
>>
>>
>> Am 06.02.2012 15:07, schrieb Tomasz Torcz:
>>> On Mon, Feb 06, 2012 at 02:55:38PM +0100, Reindl Harald wrote:
 who decided that it is a good idea to hide the grub-menu?
>>>
>>> It was F10 feature: http://fedoraproject.org/wiki/Features/BetterStartup
>>> I believe showing GRUB2 menu is a regression which will be
>>> fixed before F17 release.
>>
>> what regression?
>>
>> i speak about that GENERALLY the boot-maanger should be VISIBLE
>> in Feodra as also in RHEL and not hidden, to hide the option
>> boot with the previous kernel for everybody since years
> 
> No unless you dual boot another OS the bootloader should not be
> visible as the user does not have to care about it.
> Other OSs also don't do that for a reason.

and why are there so many noobs with questions like "after a kernel
update my machine does no longer boot" if this decision would
be smart?

it si idiotic having a fallback after kernel updates and hide it
from the users - what do you think how many do not know this, have
no other computer to post any question because no longer inernet
access resulting in delete the whole linux-os and how many of them
never install it again after "killed with standard update"



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

Re: why is gurb-menu hidden as default?

[Bruno Wolff III]

On Mon, Feb 06, 2012 at 17:22:52 +0100,
  Reindl Harald  wrote:
> 
> > GRUB2 menu is shown in F16. This is a regression compared to F10÷15.
> > See https://bugzilla.redhat.com/show_bug.cgi?id=757487 and linked
> > bugs #737339 and #727831.
> 
> this is a behavior that should never been changed!

Some of us think so, but that battle was lost a long time ago and we really
don't need to keep rehashing it. If you are intersted you can go look for
long threads about this in the past. There was at least one, but maybe
a few.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: why is gurb-menu hidden as default?

[Reindl Harald]

Am 06.02.2012 17:25, schrieb Bruno Wolff III:
> On Mon, Feb 06, 2012 at 17:22:52 +0100,
>   Reindl Harald  wrote:
>>
>>> GRUB2 menu is shown in F16. This is a regression compared to F10÷15.
>>> See https://bugzilla.redhat.com/show_bug.cgi?id=757487 and linked
>>> bugs #737339 and #727831.
>>
>> this is a behavior that should never been changed!
> 
> Some of us think so, but that battle was lost a long time ago and we really
> don't need to keep rehashing it. If you are intersted you can go look for
> long threads about this in the past. There was at least one, but maybe
> a few.

it was refreshed for me with the question below
without such idiotic changes this sort of problems
would simply not exist and people would learn to
use their OS instead obfuscate all options from
the users like windows

what does this user if he has no other computer
for his question?

 Original-Nachricht 
Betreff: [CentOS] How to boot into a different kernel

CentOS Community,

Is there a command to boot into a different version of the kernel? I
believe this is setup via grub.conf but unsure. There are a few
different kernels loaded into /boot but I want to see if there is a
command to boot into a different kernel as a single instance or
permanent if needed. Please advise

[root@titanium boot]# ls -ltr
total 62768
-rw-r--r--. 1 root root  2312369 Dec  6 15:35
System.map-2.6.32-220.el6.x86_64
-rw-r--r--. 1 root root   100943 Dec  6 15:35 config-2.6.32-220.el6.x86_64
-rwxr-xr-x. 1 root root  3938288 Dec  6 15:35 vmlinuz-2.6.32-220.el6.x86_64
-rw-r--r--. 1 root root   171087 Dec  6 15:36
symvers-2.6.32-220.el6.x86_64.gz
-rw-r--r--. 1 root root  2313220 Dec 23 04:14
System.map-2.6.32-220.2.1.el6.x86_64
-rw-r--r--. 1 root root   100947 Dec 23 04:14
config-2.6.32-220.2.1.el6.x86_64
-rwxr-xr-x. 1 root root  3940752 Dec 23 04:14
vmlinuz-2.6.32-220.2.1.el6.x86_64
-rw-r--r--. 1 root root   171175 Dec 23 04:17
symvers-2.6.32-220.2.1.el6.x86_64.gz
drwx--. 2 root root12288 Jan 18 10:36 lost+found
drwxr-xr-x. 3 root root 1024 Jan 18 10:45 efi
-rw-r--r--. 1 root root 14888469 Jan 18 10:45
initramfs-2.6.32-220.el6.x86_64.img
-rw-r--r--. 1 root root 14885287 Jan 18 11:23
initramfs-2.6.32-220.2.1.el6.x86_64.img
-rwxr-xr-x. 1 root root  3940016 Jan 23 22:02
vmlinuz-2.6.32-220.4.1.el6.x86_64
-rw-r--r--. 1 root root  2313117 Jan 23 22:02
System.map-2.6.32-220.4.1.el6.x86_64
-rw-r--r--. 1 root root   100947 Jan 23 22:02
config-2.6.32-220.4.1.el6.x86_64
-rw-r--r--. 1 root root   171175 Jan 23 22:02
symvers-2.6.32-220.4.1.el6.x86_64.gz
-rw-r--r--. 1 root root 14885301 Jan 26 08:13
initramfs-2.6.32-220.4.1.el6.x86_64.img
drwxr-xr-x. 2 root root 1024 Feb  6 01:06 grub
[root@titanium boot]#



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

Re: why is gurb-menu hidden as default?

[Rahul Sundaram]

On 02/06/2012 10:01 PM, Reindl Harald wrote:

> 
> it was refreshed for me with the question below
> without such idiotic changes this sort of problems
> would simply not exist and people would learn to
> use their OS instead obfuscate all options from
> the users like windows
> 
> what does this user if he has no other computer
> for his question?

You should ask the CentOS user that question instead of asking people
who cannot possibly know that and it is off topic here.  Let's limit
discussions to Fedora development in this list.  If you have a GRUB
specific concern, file a bug report.

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

Re: why is gurb-menu hidden as default?

[Matthew Garrett]

On Mon, Feb 06, 2012 at 05:25:08PM +0100, Reindl Harald wrote:

> and why are there so many noobs with questions like "after a kernel
> update my machine does no longer boot" if this decision would
> be smart?

The solution to "My kernel update doesn't boot" should be "Automatically 
detect that that happened, give the user that information and fall back 
to the old kernel", not "Always show the user a menu that they almost 
always don't care about". Solve the actual problem.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: why is gurb-menu hidden as default?

[Michael Cronenworth]

Reindl Harald wrote:

it was refreshed for me with the question below
without such idiotic changes this sort of problems
would simply not exist and people would learn to
use their OS instead obfuscate all options from
the users like windows

what does this user if he has no other computer
for his question?


Instead of forcing down your opinion down everyone's throats, there are 
nicer alternatives that need attention instead. How about you create a 
patch set (instead of threatening emails) that adds the ability to 
detect a bad boot and have grub prompt the user for an action the next 
time the system boots?


Examples:
"Boot into older kernel?", "Boot with safe graphics mode?", etc.

Then grub can remain hidden by default to provide a nice end-user 
experience and if booting fails a, less technically inclined, user gets 
shown some alternative boot methods.

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

Re: Draft schedule for today's FESCO meeting (6th February 2012)

[Rahul Sundaram]

On 02/06/2012 09:25 PM, Matthew Garrett wrote:
> On Mon, Feb 06, 2012 at 10:51:37AM -0500, Josef Bacik wrote:
> 
>> We're running close to the wire on this but it looks like Chris will
>> have fsck out for btrfs tomorrow, so I'd like to get fesco's opinion
>> on the viability of moving forward with the Btrfs as default feature,
>> whether we actually want to make a push for it or leave it for F18.
> 
> There's been a couple of concerns raised about btrfs's resiliance 
> against local attacks (forced hash collisions and the like) - is local 
> hardening something that's been on the test plan so far?

Would be useful to know the status of important Btrfs issues
(https://bugzilla.redhat.com/show_bug.cgi?id=689509) as well

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

Re: Draft schedule for today's FESCO meeting (6th February 2012)

[Josef Bacik]

On Mon, Feb 6, 2012 at 10:55 AM, Matthew Garrett  wrote:
> On Mon, Feb 06, 2012 at 10:51:37AM -0500, Josef Bacik wrote:
>
>> We're running close to the wire on this but it looks like Chris will
>> have fsck out for btrfs tomorrow, so I'd like to get fesco's opinion
>> on the viability of moving forward with the Btrfs as default feature,
>> whether we actually want to make a push for it or leave it for F18.
>
> There's been a couple of concerns raised about btrfs's resiliance
> against local attacks (forced hash collisions and the like) - is local
> hardening something that's been on the test plan so far?
>

We've fixed the recent one and audited everything else, it seems like
we're in pretty good shape.  Thanks,

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

Re: why is gurb-menu hidden as default?

[Reindl Harald]

Am 06.02.2012 17:35, schrieb Rahul Sundaram:
> On 02/06/2012 10:01 PM, Reindl Harald wrote:
> 
>>
>> it was refreshed for me with the question below
>> without such idiotic changes this sort of problems
>> would simply not exist and people would learn to
>> use their OS instead obfuscate all options from
>> the users like windows
>>
>> what does this user if he has no other computer
>> for his question?
> 
> You should ask the CentOS user that question instead of asking people
> who cannot possibly know that and it is off topic here.  Let's limit
> discussions to Fedora development in this list.  If you have a GRUB
> specific concern, file a bug report.

it is a "Fedora development" discussion and no there is not
a bugreport the right answer because it is a WRONG desicion
made in Fedora some releases ago to hide the boot-menu




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

Re: why is gurb-menu hidden as default?

[Josh Boyer]

On Mon, Feb 6, 2012 at 11:36 AM, Matthew Garrett  wrote:
> On Mon, Feb 06, 2012 at 05:25:08PM +0100, Reindl Harald wrote:
>
>> and why are there so many noobs with questions like "after a kernel
>> update my machine does no longer boot" if this decision would
>> be smart?
>
> The solution to "My kernel update doesn't boot" should be "Automatically
> detect that that happened, give the user that information and fall back
> to the old kernel", not "Always show the user a menu that they almost
> always don't care about". Solve the actual problem.

Agreed.  Having a simple one-shot boot facility would be awesome.  If anyone
has ideas on how to accomplish this, please let me know.  I'd be willing to
look at implementing this.

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

Re: why is gurb-menu hidden as default?

[Reindl Harald]

Am 06.02.2012 17:37, schrieb Michael Cronenworth:
> Reindl Harald wrote:
>> it was refreshed for me with the question below
>> without such idiotic changes this sort of problems
>> would simply not exist and people would learn to
>> use their OS instead obfuscate all options from
>> the users like windows
>>
>> what does this user if he has no other computer
>> for his question?
> 
> Instead of forcing down your opinion down everyone's throats, there are nicer 
> alternatives that need attention
> instead. How about you create a patch set (instead of threatening emails) 
> that adds the ability to detect a bad
> boot and have grub prompt the user for an action the next time the system 
> boots?

if it ain't broken do not fix it

why should any magical patch be needed if a working for long time
behavior was changed for dying in beauty? i did even not know that
it was changed sooo bad because the first thing i do is disable quiet
and the whole graphical boot

but it was not clear to me that in the meantime the whole menu
was hidden from the users who do not know about this

"adds the ability to detect a bad boot and have grub prompt the user for an 
action
the next time the system boots" -> if boot fails you want to write to
a disk without knowing what happens what wozld be needed to know that
it failed the last time -> very bad idea!



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

Re: why is gurb-menu hidden as default?

[Rahul Sundaram]

On 02/06/2012 10:08 PM, Reindl Harald wrote:

> it is a "Fedora development" discussion and no there is not
> a bugreport the right answer because it is a WRONG desicion
> made in Fedora some releases ago to hide the boot-menu

why a CentOS user wants to boot into a alternative kernel is not a
Fedora development discussion and the GRUB maintainer does not believe
it is wrong to hide the GRUB menu by default.  So be persuasive (that
doesn't involve screaming or yelling) in your arguments if you have any.

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

Re: why is gurb-menu hidden as default?

[Petr Šabata]

On Mon, Feb 06, 2012 at 05:38:51PM +0100, Reindl Harald wrote:
> 
> 
> Am 06.02.2012 17:35, schrieb Rahul Sundaram:
> > On 02/06/2012 10:01 PM, Reindl Harald wrote:
> > 
> >>
> >> it was refreshed for me with the question below
> >> without such idiotic changes this sort of problems
> >> would simply not exist and people would learn to
> >> use their OS instead obfuscate all options from
> >> the users like windows
> >>
> >> what does this user if he has no other computer
> >> for his question?
> > 
> > You should ask the CentOS user that question instead of asking people
> > who cannot possibly know that and it is off topic here.  Let's limit
> > discussions to Fedora development in this list.  If you have a GRUB
> > specific concern, file a bug report.
> 
> it is a "Fedora development" discussion and no there is not
> a bugreport the right answer because it is a WRONG desicion
> made in Fedora some releases ago to hide the boot-menu

I am completely happy with a hidden menu and if it wasn't like that by default,
I'd just change my grub settings.  That's my opinion and taste, different from
yours.  Ha.

Teach them how to display the menu if needed or reconfigure the software to
suit their needs.

Oh, and could stop posting hate emails with insulting tone all the time?

-P


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



pgpXyCTI54yUq.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: why is gurb-menu hidden as default?

[Reindl Harald]

Am 06.02.2012 17:44, schrieb Petr Šabata:
> I am completely happy with a hidden menu and if it wasn't like that by 
> default,
> I'd just change my grub settings.  That's my opinion and taste, different from
> yours.  Ha.

no problem, configure it
the new user does know nothing about it!

> Teach them how to display the menu if needed or reconfigure the software to
> suit their needs.

if you have permanently to teach people about the same default
problem the default is wrong and how will you teach anybody
no longer able to boot his only computer?

> Oh, and could stop posting hate emails with insulting tone all the time?

jesus if THIS is a "hate email" you never saw hate in your life



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

Re: why is gurb-menu hidden as default?

[Reindl Harald]

Am 06.02.2012 17:42, schrieb Rahul Sundaram:
> On 02/06/2012 10:08 PM, Reindl Harald wrote:
> 
>> it is a "Fedora development" discussion and no there is not
>> a bugreport the right answer because it is a WRONG desicion
>> made in Fedora some releases ago to hide the boot-menu
> 
> why a CentOS user wants to boot into a alternative kernel is not a
> Fedora development discussion 

it is a GENERAL discussion affecting fedora too and was
introduced in CentOS from fedora

> and the GRUB maintainer does not believe
> it is wrong to hide the GRUB menu by default.  

and if this is a well thought decision i wanted to point out again

> in your arguments if you have any.

why do you not read the arguments?

* a new user does not know anything about the menu
* a new user fall into a boot problem after update
* the user has only one computer
* the user possibly has no LiveCD
* the user can not go to any documentation because his machine refuses to boot
* you can not educate the user after lost this game

so what is the glory of hide well thought features from users?




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

Re: why is gurb-menu hidden as default?

[Matthew Garrett]

On Mon, Feb 06, 2012 at 11:40:28AM -0500, Josh Boyer wrote:
> On Mon, Feb 6, 2012 at 11:36 AM, Matthew Garrett  wrote:
> > The solution to "My kernel update doesn't boot" should be "Automatically
> > detect that that happened, give the user that information and fall back
> > to the old kernel", not "Always show the user a menu that they almost
> > always don't care about". Solve the actual problem.
> 
> Agreed.  Having a simple one-shot boot facility would be awesome.  If anyone
> has ideas on how to accomplish this, please let me know.  I'd be willing to
> look at implementing this.

Add a byte to the grub config block (wherever setdefault gets written) 
indicating whether a boot was clean or not. Have grub set clear that at 
kernel load, and then have a userspace app that sets it at the 
completion of boot. Check whether it's set or not on next boot and use 
that to run a different config stanza.

In theory I think you could do something with the BIOS simple boot flag, 
but that could get confusing in a dual boot scenario.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: why is gurb-menu hidden as default?

[Petr Šabata]

On Mon, Feb 06, 2012 at 05:50:59PM +0100, Reindl Harald wrote:
> 
> 
> Am 06.02.2012 17:44, schrieb Petr Šabata:
> > I am completely happy with a hidden menu and if it wasn't like that by 
> > default,
> > I'd just change my grub settings.  That's my opinion and taste, different 
> > from
> > yours.  Ha.
> 
> no problem, configure it
> the new user does know nothing about it!
> 
> > Teach them how to display the menu if needed or reconfigure the software to
> > suit their needs.
> 
> if you have permanently to teach people about the same default
> problem the default is wrong and how will you teach anybody
> no longer able to boot his only computer?

Maybe those users should read that and understand "Press ESC
to show the menu..." which is displayed for several seconds,
if I'm not mistaken.  If they can't do that, I wouldn't trust
them with selecting the right kernel or anything...

> 
> > Oh, and could stop posting hate emails with insulting tone all the time?
> 
> jesus if THIS is a "hate email" you never saw hate in your life

I live such a happy life, wheee!

-P


pgp5N69tYW1B0.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: why is gurb-menu hidden as default?

[Peter Jones]

On 02/06/2012 11:40 AM, Josh Boyer wrote:

On Mon, Feb 6, 2012 at 11:36 AM, Matthew Garrett  wrote:

On Mon, Feb 06, 2012 at 05:25:08PM +0100, Reindl Harald wrote:


and why are there so many noobs with questions like "after a kernel
update my machine does no longer boot" if this decision would
be smart?


The solution to "My kernel update doesn't boot" should be "Automatically
detect that that happened, give the user that information and fall back
to the old kernel", not "Always show the user a menu that they almost
always don't care about". Solve the actual problem.


Agreed.  Having a simple one-shot boot facility would be awesome.  If anyone
has ideas on how to accomplish this, please let me know.  I'd be willing to
look at implementing this.


So, this is something we could probably do with what we've got now.  It'd
require some changes to kernel's .spec, and probably a few minor changes in
grubby, and something would have to provide a systemd service.  Here's the
basic algorithm:

1) kernel's %post/%posttrans adds the new stanza using new-kernel-package/
   grubby, but doesn't make the new kernel default.
2) kernel's %post saves new kernel version someplace (/etc/sysconfig/newkernel
   for the purpose of this text, we can decide if there's a more appropraite
   place)
3) set next boot kernel to the new kernel with grub2-reboot
4) during boot up, a systemd service compares uname to /etc/sysconfig/newkernel
 a) if they match, it worked - use grubby to make it the default
 b) if they don't match, it failed - do whatever it is you guys want to do.

The only problem here is that when we get to 4b, we don't *really* know
that we've attempted to boot the new kernel - the user could have manually
intervened and booted the old (or some other) kernel.  Dunno how to avoid that.

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

Re: why is gurb-menu hidden as default?

[Jarosław Górny]

Hi,

Wiadomość napisana w dniu 2012-02-06, o godz. 17:55, przez Reindl  
Harald:

in your arguments if you have any.


why do you not read the arguments?

* a new user does not know anything about the menu
* a new user fall into a boot problem after update



If we are considering such a newbie user as you describe, I bet this  
user does not know if system update installed a new kernel or not.  
(S)he probably does not know what the kernel is.
So, why do you assume, such a user, having grub menu *not* hidden,  
will guess, that in case of boot problem (s)he should try to boot  
another kernel?


Another thing is:
I like breaking things. A lot. But since a *long*  time (read: couple  
of years) I didn't have kernel crash after reboot on *stock* kernel  
provided by *stable* Fedora release. And with CentOS, this statement  
is even more true, due to the nature of this distribution.

Only problems I had, were with custom made kernels.

So, really, I don't see any problem here. And based on comments of  
other users, I'm not alone here.


regards,

--
Jarosław Górny
RHCE: 805008212834187



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

Re: why is gurb-menu hidden as default?

[Rahul Sundaram]

On 02/06/2012 10:25 PM, Reindl Harald wrote:

> it is a GENERAL discussion affecting fedora too and was
> introduced in CentOS from fedora

If Fedora users are affected, . be more direct.  CentOS or RHEL
discussions here are not appropriate.

> why do you not read the arguments?

Because it was mixed with all the yelling which is a consistent strategy
of yours which you need to drop. It is not effective.
> 
> * a new user does not know anything about the menu
> * a new user fall into a boot problem after update

Then let's address this boot problem.

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

Re: why is gurb-menu hidden as default?

[Reindl Harald]

Am 06.02.2012 18:02, schrieb Jarosław Górny:
> Hi,
> 
> Wiadomość napisana w dniu 2012-02-06, o godz. 17:55, przez Reindl Harald:
>>> in your arguments if you have any.
>>
>> why do you not read the arguments?
>>
>> * a new user does not know anything about the menu
>> * a new user fall into a boot problem after update
> 
> 
> If we are considering such a newbie user as you describe, I bet this user 
> does not know if system update installed
> a new kernel or not. (S)he probably does not know what the kernel is.
> So, why do you assume, such a user, having grub menu *not* hidden, will 
> guess, that in case of boot problem (s)he
> should try to boot another kernel?

because i learned it exactly this way long time ago
with FC3 after a machine did not boot and it was
absolutely logical for me what this boot-menu means
and even if not totally - if my machine does not boot
without interaction and i have a menu at startup i
would simply try the other option

and having this example from the centos-list does make it
very clear - this users question was explictly how to
boot with another kernel, so he found out somehow that
there is more than once and even then needed help!



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

[389-devel] please review ticket #175 - logconv.pl improvements (2)

[Mark Reynolds]

https://fedorahosted.org/389/attachment/ticket/175

https://fedorahosted.org/389/attachment/ticket/175/0001-Ticket-175-logconv.pl-improvements.patch

There might be another duplicate email coming through.  Having mail server 
issues(again)...

Thanks,
Mark
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

[389-devel] please review ticket #175 - logconv.pl improvements

[Mark Reynolds]

https://fedorahosted.org/389/attachment/ticket/175

https://fedorahosted.org/389/attachment/ticket/175/0001-Ticket-175-logconv.pl-improvements.patch

Thanks,
Mark
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

Re: why is gurb-menu hidden as default?

[Przemek Klosowski]

On 02/06/2012 11:58 AM, Peter Jones wrote:


grubby, and something would have to provide a systemd service.  Here's the
basic algorithm:

1) kernel's %post/%posttrans adds the new stanza using new-kernel-package/
 grubby, but doesn't make the new kernel default.
2) kernel's %post saves new kernel version someplace (/etc/sysconfig/newkernel
 for the purpose of this text, we can decide if there's a more appropraite
 place)
3) set next boot kernel to the new kernel with grub2-reboot
4) during boot up, a systemd service compares uname to /etc/sysconfig/newkernel
   a) if they match, it worked - use grubby to make it the default
   b) if they don't match, it failed - do whatever it is you guys want to do.

The only problem here is that when we get to 4b, we don't *really* know
that we've attempted to boot the new kernel - the user could have manually
intervened and booted the old (or some other) kernel.  Dunno how to avoid that.



Would this be solved by writing down the version (output of 'uname -r' 
and/or 'cat /proc/cmdline' ) of the kernel after it successfully boots? 
if it worked last time, it should work again.

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

Summary/Minutes for today's FESCo meeting (6th February 2012)

[Matthew Garrett]

===
#fedora-meeting: FESCO (2012-02-06)
===


Meeting started by mjg59 at 18:00:24 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2012-02-06/fesco.2012-02-06-18.00.log.html
.



Meeting summary
---
* init process  (mjg59, 18:00:25)

* #690 F17 Feature: move all to /usr -
  https://fedoraproject.org/wiki/Features/UsrMove  (mjg59, 18:02:21)
  * AGREED: close it out again  (mjg59, 18:05:07)

* #756 F17 Feature: English Typing Booster -
  https://fedoraproject.org/wiki/Features/english-typing-booster
  (mjg59, 18:05:33)
  * AGREED: feature is accepted  (mjg59, 18:06:29)

* #797 F17 Feature: firewall-d - default firewall solution --
  https://fedoraproject.org/wiki/Features/firewalld-default  (mjg59,
  18:07:13)
  * AGREED: feature is accepted  (mjg59, 18:14:48)

* #796 F17 Feature: Network Zones -
  https://fedoraproject.org/wiki/Features/network-zones  (mjg59,
  18:14:59)
  * AGREED: feature accepted  (mjg59, 18:17:27)

* #704 F17 Feature: BTRFS default file system
  https://fedoraproject.org/wiki/Features/F17BtrfsDefaultFs  (mjg59,
  18:17:37)
  * AGREED: We'll try btrfs by default as long as it lands in alpha - if
not, push to F18  (mjg59, 18:34:52)

* #798 ibus makes Ctrl+Space a global shortcut  (mjg59, 18:35:35)
  * AGREED: defer to next week, gather more information  (mjg59,
18:46:11)
* Next week's chair  (mjg59, 18:47:10)
  * AGREED: sgallagh to chair next meeting  (mjg59, 18:47:51)

* Open Floor  (mjg59, 18:47:57)

Meeting ended at 19:04:37 UTC.




Action Items






Action Items, by person
---
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* mjg59 (102)
* sgallagh (67)
* nirik (37)
* josef (34)
* pjones (31)
* mitr (30)
* limburgher (24)
* notting (18)
* t8m (16)
* twoerner (14)
* mmaslano (12)
* drago01 (12)
* zodbot (10)
* MarkDude (1)


-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: why is gurb-menu hidden as default?

[Miloslav Trmač]

About a year ago Harald had a talk about a "smart initrd" /
"integrated rescue mode" along similar lines. Is this still under
development?
   Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: why is gurb-menu hidden as default?

[Peter Jones]

On 02/06/2012 02:01 PM, Przemek Klosowski wrote:

On 02/06/2012 11:58 AM, Peter Jones wrote:


grubby, and something would have to provide a systemd service. Here's the
basic algorithm:

1) kernel's %post/%posttrans adds the new stanza using new-kernel-package/
grubby, but doesn't make the new kernel default.
2) kernel's %post saves new kernel version someplace (/etc/sysconfig/newkernel
for the purpose of this text, we can decide if there's a more appropraite
place)
3) set next boot kernel to the new kernel with grub2-reboot
4) during boot up, a systemd service compares uname to /etc/sysconfig/newkernel
a) if they match, it worked - use grubby to make it the default
b) if they don't match, it failed - do whatever it is you guys want to do.

The only problem here is that when we get to 4b, we don't *really* know
that we've attempted to boot the new kernel - the user could have manually
intervened and booted the old (or some other) kernel. Dunno how to avoid that.



Would this be solved by writing down the version (output of 'uname -r' and/or
'cat /proc/cmdline' ) of the kernel after it successfully boots? if it worked
last time, it should work again.


No - the problem isn't that we can't spot success, the problem is that we can't
actually detect failure.  But Matthew's suggestion effectively solves that.

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

[ACTION NO LONGER REQUIRED] Retired packages for F-17

[Bill Nottingham]

As stated eariler, the following packages have been retired in F-17 (and
therefore rawhide), due to either failing to build, or not having maintainers.

adaptx
ario
asa
autodafe
avant-window-navigator
avl
awn-extras-applets
bit
blam
camstream
ccsm
compiz
compiz-bcop
compizconfig-backend-gconf
compizconfig-backend-kconfig4
compizconfig-python
compiz-fusion-extras
compiz-fusion-unsupported
compiz-manager
conexus
dbus-cxx
eazykeyboard
eclipse-setools
eclipse-slide
erlang-erlzmq2
expatmm
gestikk
gget
gimpfx-foundry
gkrellm-volume
gnome-paint
gnubversion
gpx-viewer
higlayout
intellij-idea
intuitively
invulgotracker
itaka
itools
iwak
iwidgets
jps
junit4
kcirbshooter
libcompizconfig
libdesktop-agnostic
libmetalink
libnoise
libspe2
libsx
lifeograph
log4c
lush
maradns
mathmap
maxr
mediawiki-rss
memchan
metalink
mingw32-OpenSceneGraph
mingw32-plib
mod_perlite
monsoon
mtkbabel
mulk
nanoxml
ndoutils
netbeans
netstiff
openbios
papyrus
phpTodo
picocontainer
pinot
plpa
podcatcher
puritan
pyactivemq
pyevent
pymssql
pypar2
python-assets
python-elixir
python-text_table
python-wehjit
python-ZSI
quadkonsole
quotatool
rainbow
rudecgi
rudeconfig
snacc
specspo
spr
spu-binutils
stgit
systemtapguiserver
tbcload
tclchecker
tclcompiler
tcldebugger
tclhttpd
tclparser
tclpro
tclsoap
tcl-thread
tkcon
tktable
tomcat5
transbot
ugene
vim-perl-tt2
wordtrans
xcftools
xmldb-api
xmlrpc-epi

Have a nice day.

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

Re: why is gurb-menu hidden as default?

[Adam Williamson]

On Mon, 2012-02-06 at 18:02 +0100, Jarosław Górny wrote:
> Hi,
> 
> Wiadomość napisana w dniu 2012-02-06, o godz. 17:55, przez Reindl  
> Harald:
> >> in your arguments if you have any.
> >
> > why do you not read the arguments?
> >
> > * a new user does not know anything about the menu
> > * a new user fall into a boot problem after update
> 
> 
> If we are considering such a newbie user as you describe, I bet this  
> user does not know if system update installed a new kernel or not.  
> (S)he probably does not know what the kernel is.
> So, why do you assume, such a user, having grub menu *not* hidden,  
> will guess, that in case of boot problem (s)he should try to boot  
> another kernel?

Well, they do. Generally what people do when something is broken and
they don't really know what or how to fix it is twiddle: they look for
something they can poke, and poke it. A boot menu is an excellent
example of a twiddle-able interface, if you always show it: it's right
there, on boot. It's actually just about the only thing the user CAN
twiddle, if booting the default kernel doesn't work - the only bit where
they feel they can influence the process. So, in my experience, that's
what they do: they try a different menu entry. They don't actually
_need_ the knowledge of what the hell they're doing. All they need is
the knowledge that 'this is a menu with different entries and choosing
one of the other ones might make something different happen'.

Obviously this tweaking reflex can lead to disaster in _some_ cases, but
in the case of recovering from a bad kernel, it actually serves people
rather well.

I agree with the kernel team that a better option would be some kind of
smart recovery from failed boot, though.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

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

[389-devel] New Support Tool: dseconv.pl (dse.ldif file parser)

[Mark Reynolds]

Hi All,

This was a side project of mine for some time, and I just ported it to 
DS 389.  It basically parses the dse.ldif into a readable format.  It 
groups all the backend info together.  So each backend lists its own 
indexes, config, replication info, etc.  It checks for non default 
config settings as well.


It's basically a great way to take a quick look at a customers config:

Here is some sample output:

Reading 
/tmp/dse.ldif



--
 Config File Processing Statistics
--

Total Entries:  164
Skipped Entries:19

Processed Entries:  145


--
 Cache Sizes
--

Total DB Cache: 9,765 Kb  (1000 bytes)
Total Entry Cache:  10,240 Kb  (10485760 bytes)
--
Total Cache Size:   19 Mb,  20,005 Kb,  (20485760 bytes)



--
 Main Configuration
--

 -> errorlog-level: 65536
accesslog-logging-enabled: on
accesslog-logrotationsync-enabled: off
accesslog-logrotationsynchour: 0
accesslog-logrotationsyncmin: 0
accesslog-logrotationtime: 1
accesslog-logrotationtimeunit: day
accesslog-maxlogsize: 100
accesslog-maxlogsperdir: 10
accesslog-mode: 600
accesslog: /var/log/dirsrv/slapd-localhost/access
allow-anonymous-access: on
allow-unauthenticated-binds: off
auditlog-logging-enabled: on
auditlog-logrotationtime: 1
auditlog-logrotationtimeunit: day
auditlog-maxlogsize: 100
auditlog-mode: 600
auditlog: /var/log/dirsrv/slapd-localhost/audit
bakdir: /var/lib/dirsrv/slapd-localhost/bak
certdir: /etc/dirsrv/slapd-localhost
dn-validate-strict: off
enquote-sup-oc: off
errorlog-logging-enabled: on
errorlog-logrotationsync-enabled: off
errorlog-logrotationsynchour: 0
errorlog-logrotationsyncmin: 0
errorlog-logrotationtime: 1
errorlog-logrotationtimeunit: week
errorlog-maxlogsize: 100
errorlog-maxlogsperdir: 2
errorlog-mode: 600
errorlog: /var/log/dirsrv/slapd-localhost/errors
instancedir: /usr/lib64/dirsrv/slapd-localhost
ldapifilepath: /var/run/slapd-localhost.socket
ldapilisten: off
ldifdir: /var/lib/dirsrv/slapd-localhost/ldif
localhost: localhost.localdomain
localssf: 71
localuser: nobody
lockdir: /var/lock/dirsrv/slapd-localhost
max-filter-nest-level: 40
maxdescriptors: 1024
minssf: 0
port: 389
require-secure-binds: off
return-exact-case: on
rewrite-rfc1274: off
rootdn: cn=dm
rootpw: {SSHA}VBmupFhRJ90LC3YxnnD+rGTl8xYSPWqumGATiw==
rundir: /var/run/dirsrv
schemacheck: on
schemadir: /etc/dirsrv/slapd-localhost/schema
ssl-check-hostname: on
syntaxcheck: on
tmpdir: /tmp
validate-cert: warn




--
 LDBM Database Configuration
--

lookthroughlimit: 5000
mode: 600
idlistscanlimit: 4000
directory: /var/lib/dirsrv/slapd-localhost/db
dbcachesize: 1000
db-logdirectory: /var/lib/dirsrv/slapd-localhost/db
db-durable-transaction: on
db-checkpoint-interval: 60
db-transaction-batch-val: 0
db-logbuf-size: 0
db-private-import-mem: on
import-cache-autosize: -1
import-cachesize: 2000
idl-switch: new
search-bypass-filter-test: on
search-use-vlv-index: on
exclude-from-export: entrydn entryid dncomp parentid 
numSubordinates tombstonenumsubordinates entryusn

serial-lock: on
subtree-rename-switch: on
pagedlookthroughlimit: 0
pagedidlistscanlimit: 0




--
 Backends (1)
--


[1] "cn=userRoot"
-

suffix: dc=example,dc=com
cachesize: -1
cachememsize: 10485760
readonly: off
require-index: off
directory: /var/lib/dirsrv/slapd-localhost/db/userRoot
dncachememsize: 10485760

Indexes:
 cn:  eq
 givenName:  pres eq sub
 mail:  pres eq sub
 mailAlternateAddress:  eq
 mailHost:  eq
 member:  eq
 memberOf:  eq
 ntUniqueId:  eq
 ntUserDomainId:  eq
 owner:  eq
 seeAlso:  eq
 sn:  pres eq sub
 telephoneNumber:  pres eq sub
 uid:  eq
 uniquemember:  eq
   * aci:  pres
   * entrydn:  subtree
   * entryrdn:  subtree
   * entryusn:  eq
   - nsMatchingRule: integerOrderingMatch

   * nscpE

Re: Does anyone still need to create legacy HFS filesystems?

[Chris Murphy]

On Feb 6, 2012, at 5:30 AM, Joel Rees wrote:
> 
> retro computing? Maintaining access to pre-historic data?

The only suggestion is dropping the ability to *create* HFS volumes using 
hfsplus-tools. Not dropping read support for existing HFS volumes.


> But, no, HFS isn't really dead. Old formats should not be allowed to
> die. I do want to be able to read my old media under emulation
> someday. Apple doesn't care, but I do.

HFS is about as dead as Espiranto. Those who really want to keep it alive need 
to put the effort into keeping it alive. As a long time Mac user, I don't 
expect someone else in the open source community to do this for me, so that I 
can have access to weird ancient junk. Migrating the data forward to new media 
and contemporary volume formats is the only sure way to have access to your 
data. That old media is oxidizing and eventually won't be readable even if you 
have something that understands HFS. I'd migrate it before it's too late.


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

GPT and Fedora 17

[Brian C. Lane]

In Fedora 16 we changed to using GPT as the default disklabel for new
installs. In a few cases, mostly limited to Lenovo hardware, we found
that some BIOS's would not boot from GPT. We blacklisted Lenovo, falling
back to msdos labels in order to solve this.

Thanks to Matthew Garrett we found that switching on the boot flag of
the GPT's protective MBR these BIOS's would then boot from GPT. Matthew
wrote a patch for parted to allow controlling this flag using the
disk_set pmbr_boot command in parted. This is in parted-3.0-7

In anaconda-17.6 I have reverted the Lenovo blacklist and changed things
so that pmbr_boot is always set on GPT labeled installs. This should
ensure that thing boot correctly.

If this still causes problems the symptom will be that grub never starts
and the bios may complain about not being able to find an OS. If you
have problems with this please open a bug with the output from dmidecode

You can still force usage of msdos partitions by passing nogpt on the
kernel cmdline.

-- 
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)


pgpFx8Vynj3RH.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Self Introduction

[Jamie Nguyen]

Hello,

My name is Jamie Nguyen. I'm a student in the UK and part-time Linux
system administrator.

I am an active contributer to the TOMOYO Linux security project [1]
and provide a binary repository containing RPMS/SRPMS for TOMOYO Linux
kernels for Enterprise Linux 6 and Fedora 16 [2]. I also have
experience in tech documentation; I have edited the "How to create an
RPM" page in the Fedora wiki and have so far revamped the first half
[3] with a view to doing a more complete revamp soon.

I have one pending review request [4] for bashmount. I happen to be
the author of this command-line tool :-)

I would also be glad in the near future to co-maintain some or all of
the MPD stack of applications (e.g. libmpdclient, mpc, ncmpc, ncmpcpp,
sonata etc.). I have already posted a package review on the RPMFusion
bugzilla [5] for a very heavily revised mpd.spec that includes a
systemd service file (the mpd.spec file is much more complex than
bashmount.spec, so it may interest you to take a look).

Thanks everyone.

[1] http://tomoyo.sourceforge.jp/
[2] http://repo.tomoyolinux.co.uk/
[3] https://fedoraproject.org/wiki/Special:Contributions/Jamielinux
[4] https://bugzilla.redhat.com/show_bug.cgi?id=787858
[5] https://bugzilla.rpmfusion.org/show_bug.cgi?id=1944
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: new comps group proposal: Virtualization Host

[Alan Pevec]

On Fri, Feb 3, 2012 at 8:29 PM, Bill Nottingham  wrote:
>> Renaming current "Virtualization" to "Virtualization Client" makes sense.
>> I would put new Boxes into both Virt.Client and GNOME groups, list of
>> packages are not exclusive.
>
> Got a patch for this?

v2 attached, it renames just name, id is kept to avoid breaking
kickstarts which might use @virtualization in the package list. I
didn't add gnome-boxes, since it's not in gnome-desktop yet.

New group is @virtualization-hypervisor with just libvirt and qemu-kvm for now.

How can I push this change to comps.git ?

Alan
From 56d295c07996349c2b1e28847ec6bd4edebf674d Mon Sep 17 00:00:00 2001
From: Alan Pevec 
Date: Mon, 23 Jan 2012 17:04:36 +0100
Subject: [PATCH v2] add Virtualization Hypervisor group

Smallest possible virtualization host installation
for headless nodes, without any graphical interface.
Installs on top of @core group.

Also rename existing Virtualization to Virtualization Client
to avoid confusion
(group id stays @virtualization to avoid breaking existing kickstarts)
---
 comps-f17.xml.in |   14 +-
 1 files changed, 13 insertions(+), 1 deletions(-)

diff --git a/comps-f17.xml.in b/comps-f17.xml.in
index 04376cf..46297fc 100644
--- a/comps-f17.xml.in
+++ b/comps-f17.xml.in
@@ -6068,7 +6068,7 @@
   
   
 virtualization
-<_name>Virtualization
+<_name>Virtualization Client
 <_description>These packages provide a virtualization environment.
 false
 true
@@ -6086,6 +6086,17 @@
 
   
   
+virtualization-hypervisor
+<_name>Virtualization Hypervisor
+<_description>Smallest possible virtualization host installation
+false
+false
+
+  libvirt
+  qemu-kvm
+
+  
+  
 walloon-support
 <_name>Walloon Support
 <_description/>
@@ -6687,6 +6698,7 @@
   legacy-software-support
   system-tools
   virtualization
+  virtualization-hypervisor
 
   
   
-- 
1.7.7.6

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

Re: GPT and Fedora 17

[Chris Murphy]

On Feb 6, 2012, at 3:40 PM, Brian C. Lane wrote:
> 
> In anaconda-17.6 I have reverted the Lenovo blacklist and changed things
> so that pmbr_boot is always set on GPT labeled installs. This should
> ensure that thing boot correctly.

Is this happening only for Lenovo hardware? Or all hardware? I ask because my 
Apple hardware fails to boot any OS including pre-existing Mac OS, if the 
protective MBR (MBR entry 1) has an active (boot) flag set.

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

Re: GPT and Fedora 17

[Pádraig Brady]

On 02/06/2012 10:40 PM, Brian C. Lane wrote:
> In Fedora 16 we changed to using GPT as the default disklabel for new
> installs. In a few cases, mostly limited to Lenovo hardware, we found
> that some BIOS's would not boot from GPT. We blacklisted Lenovo, falling
> back to msdos labels in order to solve this.
> 
> Thanks to Matthew Garrett we found that switching on the boot flag of
> the GPT's protective MBR these BIOS's would then boot from GPT. Matthew
> wrote a patch for parted to allow controlling this flag using the
> disk_set pmbr_boot command in parted. This is in parted-3.0-7
> 
> In anaconda-17.6 I have reverted the Lenovo blacklist and changed things
> so that pmbr_boot is always set on GPT labeled installs. This should
> ensure that thing boot correctly.
> 
> If this still causes problems the symptom will be that grub never starts
> and the bios may complain about not being able to find an OS. If you
> have problems with this please open a bug with the output from dmidecode
> 
> You can still force usage of msdos partitions by passing nogpt on the
> kernel cmdline.

Hmm, I tried that workaround I think on my Lenovo T520 with BIOS 1.29,
and it didn't help.  I.E. point (1.) from the link referenced here:
https://bugzilla.redhat.com/show_bug.cgi?id=735733#c31

Fingers crossed I just missed something at the time.
I'll try out again tomorrow maybe.

cheers,
Pádraig.

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

Re: glibc policy chage?

[Rahul Sundaram]

On 02/06/2012 04:41 PM, Jared K. Smith wrote:

> 
> In the new scheme, glibc packages will be based on stable releases,
> with bug-fixes back-ported as necessary.  I'll throw out a huge thank
> you to Jeff Law for being willing to step up and take over maintenance
> of the glibc packages in Fedora, and for building those packages in a
> less chaotic way than was previously done.

Thanks to Jeff Law and also to you for coordinating this.

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

Re: GPT and Fedora 17

[Adam Williamson]

On Mon, 2012-02-06 at 23:19 +, Pádraig Brady wrote:
> On 02/06/2012 10:40 PM, Brian C. Lane wrote:
> > In Fedora 16 we changed to using GPT as the default disklabel for new
> > installs. In a few cases, mostly limited to Lenovo hardware, we found
> > that some BIOS's would not boot from GPT. We blacklisted Lenovo, falling
> > back to msdos labels in order to solve this.
> > 
> > Thanks to Matthew Garrett we found that switching on the boot flag of
> > the GPT's protective MBR these BIOS's would then boot from GPT. Matthew
> > wrote a patch for parted to allow controlling this flag using the
> > disk_set pmbr_boot command in parted. This is in parted-3.0-7
> > 
> > In anaconda-17.6 I have reverted the Lenovo blacklist and changed things
> > so that pmbr_boot is always set on GPT labeled installs. This should
> > ensure that thing boot correctly.
> > 
> > If this still causes problems the symptom will be that grub never starts
> > and the bios may complain about not being able to find an OS. If you
> > have problems with this please open a bug with the output from dmidecode
> > 
> > You can still force usage of msdos partitions by passing nogpt on the
> > kernel cmdline.
> 
> Hmm, I tried that workaround I think on my Lenovo T520 with BIOS 1.29,
> and it didn't help.  I.E. point (1.) from the link referenced here:
> https://bugzilla.redhat.com/show_bug.cgi?id=735733#c31
> 
> Fingers crossed I just missed something at the time.
> I'll try out again tomorrow maybe.

Yes, I remember that. Please do test the change out and let us know the
results, we'd definitely like to know.

Brian, this change takes effect from Alpha TC2 (whenever we spin it),
it's not in Alpha TC1, correct?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

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

Re: GPT and Fedora 17

[Brian C. Lane]

On Mon, Feb 06, 2012 at 04:54:01PM -0800, Adam Williamson wrote:
> On Mon, 2012-02-06 at 23:19 +, Pádraig Brady wrote:
> > On 02/06/2012 10:40 PM, Brian C. Lane wrote:
> > > In Fedora 16 we changed to using GPT as the default disklabel for new
> > > installs. In a few cases, mostly limited to Lenovo hardware, we found
> > > that some BIOS's would not boot from GPT. We blacklisted Lenovo, falling
> > > back to msdos labels in order to solve this.
> > > 
> > > Thanks to Matthew Garrett we found that switching on the boot flag of
> > > the GPT's protective MBR these BIOS's would then boot from GPT. Matthew
> > > wrote a patch for parted to allow controlling this flag using the
> > > disk_set pmbr_boot command in parted. This is in parted-3.0-7
> > > 
> > > In anaconda-17.6 I have reverted the Lenovo blacklist and changed things
> > > so that pmbr_boot is always set on GPT labeled installs. This should
> > > ensure that thing boot correctly.
> > > 
> > > If this still causes problems the symptom will be that grub never starts
> > > and the bios may complain about not being able to find an OS. If you
> > > have problems with this please open a bug with the output from dmidecode
> > > 
> > > You can still force usage of msdos partitions by passing nogpt on the
> > > kernel cmdline.
> > 
> > Hmm, I tried that workaround I think on my Lenovo T520 with BIOS 1.29,
> > and it didn't help.  I.E. point (1.) from the link referenced here:
> > https://bugzilla.redhat.com/show_bug.cgi?id=735733#c31
> > 
> > Fingers crossed I just missed something at the time.
> > I'll try out again tomorrow maybe.
> 
> Yes, I remember that. Please do test the change out and let us know the
> results, we'd definitely like to know.
> 
> Brian, this change takes effect from Alpha TC2 (whenever we spin it),
> it's not in Alpha TC1, correct?

Correct.

-- 
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)


pgpabuhMJpSxx.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Bug 787888] CVE-2012-0839 ocaml: hash table collisions CPU usage DoS (oCERT-2011-003)

[bugzilla]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=787888

Kurt Seifried  changed:

   What|Removed |Added

 CC||c.davi...@gmail.com,
   ||fedora-ocaml-l...@redhat.co
   ||m, rjo...@redhat.com

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
ocaml-devel mailing list
ocaml-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel

[Bug 787888] CVE-2012-0839 ocaml: hash table collisions CPU usage DoS (oCERT-2011-003)

[bugzilla]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=787888

Kurt Seifried  changed:

   What|Removed |Added

 Blocks||770929(hashdos,oCERT-2011-0
   ||03)

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
ocaml-devel mailing list
ocaml-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel

[Bug 787888] CVE-2012-0839 ocaml: hash table collisions CPU usage DoS (oCERT-2011-003)

[bugzilla]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=787888

Kurt Seifried  changed:

   What|Removed |Added

 Blocks||787889

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
ocaml-devel mailing list
ocaml-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel

Re: [ACTION NO LONGER REQUIRED] Retired packages for F-17

[Andy Grimm]

On Mon, Feb 6, 2012 at 3:09 PM, Bill Nottingham  wrote:
> As stated eariler, the following packages have been retired in F-17 (and
> therefore rawhide), due to either failing to build, or not having maintainers.
>
> ...
> junit4
> ...

Whoa there.. .this one wasn't in any of the previous emails... perhaps
it was orphaned very recently?  It's a BuildReq for most of the java
universe, so probably best to give people one more shot at claiming
it, if possible.

--Andy

>
> Have a nice day.
>
> Bill
> --
> 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: [ACTION NO LONGER REQUIRED] Retired packages for F-17

[Orion Poplawski]

On 02/06/2012 08:44 PM, Andy Grimm wrote:

On Mon, Feb 6, 2012 at 3:09 PM, Bill Nottingham  wrote:

As stated eariler, the following packages have been retired in F-17 (and
therefore rawhide), due to either failing to build, or not having maintainers.

...
junit4
...


Whoa there.. .this one wasn't in any of the previous emails... perhaps
it was orphaned very recently?  It's a BuildReq for most of the java
universe, so probably best to give people one more shot at claiming
it, if possible.


It appears that "junit" is now at version 4.


--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Request for testers of dnssec-trigger (now in rawhide)

[Paul Wouters]

Hi,

In our efforts to push DNSSEC to the enduser, we have packaged our
initial DNSSEC reconfiguration utility.

Basically, this makes it possible to use DNSSEC on your laptop, while
moving between networks of which some are "friendly" man in the middle
attacks on DNS via hotspots and sign-ons. Some steps are still awaiting
further network-manager integration. We hope to be able to hide almost
everything from the user, but the network manager integration is not yet
complete. But we would really like get more feedback on how well it
works in various alien and broken networks out there (especially wifi
and 3G/LTE)


First, to get some feedback on whether or not you are using DNSSEC and a
site is protected by DNSSEC, you should install the nic.cz Firefox
plugin that show DNSSEC information in the address bar:

http://www.dnssec-validator.cz/

Next, install dnssec-trigger (currently only in rawhide) but you can
grab a source rpm from here:

http://koji.fedoraproject.org/koji/taskinfo?taskID=3767834

Either reboot or start some services manually:

sudo systemctl start unbound-keygen.service
sudo systemctl start unbound.service
sudo systemctl start dnssec-triggerd-keygen.service
sudo systemctl start dnssec-triggerd.service

Then start the dnssec-trigger-applet from the Applications menu. A
(trust) anchor applet icon will now appear.

Now reconnect to your network so that NetworkManager receives DNS
servers via DHCP.

Browse to http://fedoraproject.org/  with firefox

If everything went well, you should see the green lock on the left
meaning that DNSSEC was used and proved that the DNS lookup for
fedopraproject.org was DNSSEC signed and used. There are other domains
you can use to test, perhaps most importantly at this point, paypal.com.
You can also run a manual test (dig +dnssec fedoraproject.org) and test
if the "ad" flag was set in the dig output.

If your icon is orange, it means your DHCP supplied DNS servers did not
perform DNSSEC. This should never happen in this setup, but would happen
if you only installed the firefox plugin and did not install and start
the unbound/dnssec-triggerd services.

When joining a new network,  right-click the anchor and select
"re-probe". After a few seconds you can get some debug output by
right-clicking and selecting "show results".

What this does:

1) Perform various probes to see if the DHCP supplied DNS servers and
the network are DNSSEC capable. If so, reconfigure the system to use
these. We do not want applications to query these directly, as we do not
trust oursourcing DNSSEC validation to anyone but our own locally
running DNS server (unbound) as the connection between you and the ISP
DNS servers is not trusted, and attackers could rewrite DNS answers
unless your laptop itself confirms this with validation (it comes with
the DNS ROOT key preinstalled)

2) If these servers are broken, it will attempt to query authoritative
servers directly, bypassing the caching DNS servers from the ISP. We do
not do this per default because we do not want to destroy the internet's
DNS caching hierarchy.

3) If using authoritative servers directly fails (eg there is a bad
transparent port 53 proxy or firewall rule forcing use of the DHCP
offered (broken) DNS servers, there is an option to attempt DNS over TLS
and raw DNS over port 80. This is a method of last resort and works
surprisingly well (though slow). This is currently not yet enabled but
you can enable it manually in /etc/dnssec-trigger.conf. Once the nice
people of Fedora Hosted have added a few of these servers, we will
enable this fallback option via a package update.

4) if all of this fails, the user is prompted with a choice. Either go
into "cache only mode" where you cannot do any insecure lookups and are
only using the cached DNS answers you already had before you joined this
network, or you can go "insecure" in which case the local DNS server is
pulled aside (so it does not get poisoned with unvalidated results) and
you're all on your own in your very hostile network without DNSSEC (kind
of what you are likely using right now :)  Exponential back-off attempts
run in the background to see if we can go back to a secure mode.

The Hot spot issue

Sometimes, you need to accept some "fake DNS" to get past the hotspot
portal. For this, the anchor also has an option. It will go into
"insecure" mode, and you can authenticate, pay or click "I acecpt your
terms". When you are done, you select "re-probe". (We cannot do this
automatically without risking to break your spoofed login portal page).
We are working on giving networkmanager a way to detect hotspots for you.

VPN and split DNS

If you connect to a VPN and you need a special DNS server to resolve
internal domains, you need to add an exception to
/etc/unbound/unbound.conf for now. The syntax is:

forward-zone:
name: "example.com"
forward-addr: 10.1.2.3



Future

Planned for the near future:
- Less user interaction, more network manager integration
- automatic ho

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Bohuslav Kabrda]

Hi Tom,

- Original Message -
> ---
> 
> The section of the Packaging Guidelines covering /srv was amended to
> include /opt and /usr/local. Specifically, the following sentence was
> added:
> 
>   In addition, no Fedora package can have any files or directories
>   under /opt or /usr/local, as these directories are not permitted to
>   be used by Distributions in the FHS.
> 
> https://fedoraproject.org/wiki/Packaging:Guidelines#No_Files_or_Directories_under_.2Fsrv.2C_.2Fopt.2C_or_.2Fusr.2Flocal
> 
> ---

Can I ask you where specifically you found the statement, that distributions 
cannot place their data under /opt?

Citing FHS [1]:
"Programs to be invoked by users must be located in the directory 
/opt//bin or under the /opt/ hierarchy. If the package 
includes UNIX manual pages, they must be located in /opt//share/man or 
under the /opt/ hierarchy, and the same substructure as 
/usr/share/man must be used."

And more importantly:
"Distributions may install software in /opt, but must not modify or delete 
software installed by the local system administrator without the assent of the 
local system administrator."

-- 
Regards,
Bohuslav "Slavek" Kabrda.

[1] 
http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Ralf Corsepius]

On 02/07/2012 07:38 AM, Bohuslav Kabrda wrote:

Hi Tom,

- Original Message -

---

The section of the Packaging Guidelines covering /srv was amended to
include /opt and /usr/local. Specifically, the following sentence was
added:

   In addition, no Fedora package can have any files or directories
   under /opt or /usr/local, as these directories are not permitted to
   be used by Distributions in the FHS.

https://fedoraproject.org/wiki/Packaging:Guidelines#No_Files_or_Directories_under_.2Fsrv.2C_.2Fopt.2C_or_.2Fusr.2Flocal

---


Can I ask you where specifically you found the statement, that distributions 
cannot place their data under /opt?


"/opt is reserved for the installation of add-on application software 
packages."


In this context, "add-on application software packages" are meant to be 
interpreted as "non-OS vendor supplied" packages.


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

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Bohuslav Kabrda]

- Original Message -
> On 02/07/2012 07:38 AM, Bohuslav Kabrda wrote:
> > Hi Tom,
> >
> > - Original Message -
> >> ---
> >>
> >> The section of the Packaging Guidelines covering /srv was amended
> >> to
> >> include /opt and /usr/local. Specifically, the following sentence
> >> was
> >> added:
> >>
> >>In addition, no Fedora package can have any files or
> >>directories
> >>under /opt or /usr/local, as these directories are not
> >>permitted to
> >>be used by Distributions in the FHS.
> >>
> >> https://fedoraproject.org/wiki/Packaging:Guidelines#No_Files_or_Directories_under_.2Fsrv.2C_.2Fopt.2C_or_.2Fusr.2Flocal
> >>
> >> ---
> >
> > Can I ask you where specifically you found the statement, that
> > distributions cannot place their data under /opt?
> 
> "/opt is reserved for the installation of add-on application software
> packages."
> 
> In this context, "add-on application software packages" are meant to
> be
> interpreted as "non-OS vendor supplied" packages.
> 
> Ralf

Again, citing FHS:
"Distributions may install software in /opt, but must not modify or delete 
software installed by the local system administrator without the assent of the 
local system administrator."

How can this be interpreted as "non-OS vendor supplied"?

-- 
Regards,
Bohuslav "Slavek" Kabrda.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

rubygem-open4 license change

[Bohuslav Kabrda]

Hi all,
due to license change in Ruby, I have updated the license of rubygem-open4 
after clarification with its author.
Previous license was GPLv2+ or Ruby, current license is BSD or Ruby.

-- 
Regards,
Bohuslav "Slavek" Kabrda.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel