I need to patch ntp for my uses. But I find that the src rpm will not build on
cd . && env
autogen -L ../include --writable -Tagman1.tpl -bntpd ntpd-opts.def
ice-9/psyntax.scm:1259:12: In procedure dobody:
ice-9/psyntax.scm:1259:12: Syntax error:
/usr/share/autogen/agman1.tpl:187:6: definition in expression context, where
definitions are not allowed, in form (define optname-from "_^")
Scheme evaluation error. AutoGen ABEND-ing in template
/usr/share/autogen/agman1.tpl on line 179
Failing Guile command: = = = = =
(define opt-arg "")
(define dis-name "")
(define opt-name "")
(define optname-from "A-Z_^")
(define optname-to "a-z--")
(if (exist? "preserve-case")
(define optname-from "_^")
(define optname-to "--")
(if (exist? "option-info")
(string-append "\n.PP\n" (get "option-info") "\n") )
Is this being worked on or should I report a bug? I'd appreciate know what
Below is a draft governance charter for the Workstation WG. I have
taken much of this from the Cloud WG draft charter (found here:
https://fedoraproject.org/wiki/Cloud_WG) to have some commonality
between groups. I left some of the sections from that off for now, as
I think that is their main landing page and we can fill in those
sections with our relevant details as we go.
Please read it over and provide any feedback or ask any questions you
may have. Thanks!
== Fedora Workstation WG Governance ==
This document describes the governing structure for the Fedora
Workstation Work Group.
=== Membership ===
The Fedora Workstation Work Group has nine voting members, with one
member selected by the Fedora Engineering Steering Committee as the
liaison to FESCo.
Members of the Working Group serve two year terms. At the end of the
two year period, FESCo will either renew the FESCo liaison or appoint
a new one. The other positions will be filled by general election
every two years. As a special exception, four seats will be filled in
one year, with those positions chosen at random (unless some number of
members decide to step down). Voting will follow the standard Fedora
election process and be open to all contributors in the CLA+1 group.
In the event that a current member relinquishes their seat, that seat
will be filled by the first runner up in the previous election. If
that person is not able or willing to fill the seat, it will go to
each successive runner up until the seat is filled. If there are no
candidates available or remaining from the previous election, the Work
Group will fill the seat by selecting a candidate and approving by
NOTE: Clearly all of the above is open for discussion. I've modelled
it after how FESCo current does their membership to a large degree.
If we want something else, please follow up with alternative
=== Current Members ===
* Josh Boyer (FESCo Liaison)
* Matthias Clasen
* Kalev Lember
* Ryan Lerch
* Jens Petersen
* Christian Schaller
* Owen Taylor
* Lukáš Tinkl
* Christoph Wickert
=== Making Decisions ===
Because Fedora is a global project, members of the working group may
be distributed across multiple timezones. It may be possible to have a
real-time IRC meetings, but in general we will conduct business on the
Many of our decisions can be made through "lazy consensus";. Under
this model, an intended action is announced on the mailing list,
discussed, and if there is no controversy or dissenting views with a
few days, simply done.
For bigger issues, where there may be disagreement, or where there is
long-term impact, or where an action may not easily be undone, we will
... Working group members can vote +1 to approve, -1 to disagree,
or 0 to abstain; five +1 votes are necessary for a measure to pass.
Non-members may comment on the item and (of course) discuss on the
mailing list, but are asked to refrain from putting votes.
 NOTE: for the workstation WG, we have the following option for
1) Use a trac ticketing system as the cloud WG is doing
2) Come up with an official proposal voting system on the mailing list
(specific "Subject: [Proposal for Vote] ..." or something).
3) Schedule an IRC meeting and do the vote live.
I'm fine with any of these, though I will point out that live meetings
across all of our relevant timezones are difficult. If we choose to
have a trac ticketing system (which can be used for votes and for
people to report issues), I can get that created.
=== Changing these Rules ===
This document will be approved by consensus of the initial Working
Group members and approved by FESCo. After initial ratification, any
substantive changes can be approved by majority vote and sent to FESCo
بسم الله الرّحمن الرّحيم
The result of updating Fedora by yum is fail !!
When any package have "proxy" word marked to (install or update) , error message will appear with http 403 error forbidden.
In my country Syria (maybe others) all URLs have "proxy" word are forbidden and couldn't open by default way.
In Fedora there are two common packages and have many updates:
libproxy - sssd-proxy .
Can to rename to :
libproxies - sssd-proxies
Or something else.
Then do new rule to write "proxies" instead of proxy, at Fedora packaging guidlines.
Senior of Linux Arab Community http://linuxac.org
Member of Ojuba Project http://ojuba.org
Member of Arab Eyes project http://arabeyes.org
Maintainer of Almasa project
Maintainer of Arabic Translations in : Wine - VLC - KDE .... etc
Also member of Fedora Arabic translations team
The bottom line question is, would it be useful to have an fsck_gpt run by systemd at either startup or shutdown time? This wasn't needed for MBR, so it seems kinda silly to suggest it, but there are some cases of one or the other GPT being stepped on in a way that probably never happened to MBR for the obvious reason that if it did, the computer would be busted.
A recent bug came up in QA that made me go down a bit of a rabbit hole, corrupting one or the other GPT to see how different things behave, starting with the various partition tools. This is a summary:
parted does the right thing, identifies which GPT is corrupt and says it's using the other one, and fixes the problem on the next write to disk.
gdisk does the right thing also.
fdisk sees a disk with corrupt primary GPT as being an MBR disk, RHBZ 1022217, fix now available although I haven't tested it yet.
anaconda sees such a disk as totally blank, RHBZ 1020974 is in progress.
grub2 only uses the primary GPT table, it doesn't check to see if it's valid, RHBZ 1022743. So a bit flip probably won't cause a computer to not boot. It'd have to be something that alters just the start LBA of /boot or / (or both), or stomps on the whole table data. In either case the result is an unbootable system. It's an open question if a bootloader should be able to determine the validity of the primary GPT since that means it needs CRC32 code. And then whether it should know to use the backup GPT. I've raised this on grub-devel@.
And just now, I found the kernel nose dives if the primary GPT table is altered by even one byte. kernel.org bug 63591.
Anyway, as rare as this is, it might be nice if the system can self-heal from such problems, because it's pretty much guaranteed the user will never know about it until the other GPT is toast. And the UEFI spec amusingly requires the user be asked for confirmation before restoring a primary GPT, which is probably not in either the kernel nor systemd's job description.
So that's why I ask if it makes sense to have an fsck for GPT disks.
It's taking a bit of time, but I plan to start packaging a couple of
packages that are not currently available for either Red Hat nor Fedora.
The main reason for it taking a bit longer really has to do with
personal infrastructure and setting up my build host, etc.
However, that doesn't really pertain to the question at hand. I come
from a Debian centric environment, and have "come back" to Red Hat and
Fedora after more than a decade. As such, I have quite a bit more
experience building my packages with fakeroot, than I do with mock, and
I'm wondering what the differences between the two packages/processes are.
Will using mock in this environment be more beneficial to using
fakeroot? Will it be "harder" for lack of a better word, to build from
within the build system using fakeroot , once I get to that point or, is
Koji flexible enough so that it really wouldn't matter from an
infrastructure point of view as to whether or not I use one or the other?
As I am more familiar with fakeroot, I'd like to keep using that, but
at the same time, I'd like to do it the "Red Hat way" to ensure that the
package conforms to both Red Hat and Fedora packaging standards.
Thanks in advance for your guidance.
I hope all is well.
I am writing in regards to something I had written about two months ago.
This in regards to the search engine.
I think we need to seriously fix this thing once and for all.
I am looking at designing a solution for us.
I however would like to start from the basics.
We will need to look at the solutions that are present at the current time.
This should allow us to critic and analyse them.
I will then take this issue into the meeting for voting and whatever is
decided is what I shall implement.
Kindly do advice if you have any pointers on this project.
I however must be honest and say it will take me about 2 months to complete
when i start because I have a day job elsewhere.
This does not mean I will not want assistance. As always assistance is
I hope this will be fruitful so we can close this once and for all. Or
should I say until we need a revision done.
Skype: Frankie Onuonga
irc #freenode: Frankie.onuonga
Based on discussions at and around Flock, the Fedora Project Board has
approved a proposal for a big change in the way we put Fedora together.
Rather than presenting one Fedora with multiple slightly-different
install options, future Fedora will be designed, developed, and promoted
as three separate products built around a common core.
To take that idea from talk to reality, we're making a corresponding
change to Fedora leadership. Each product will be guided by a Working
Group, which will function as an independent subcommittee of FESCo, (the
Fedora Engineering Steering Committee). FESCo will resolve issues which
impact multiple working groups, and the Fedora Board will continue to
set overall strategic direction, but the working groups will be largely
autonomous within their own areas.
We are creating a group for each of the three initial products the Board
* Fedora Workstation
* Fedora Server
* Fedora Cloud
The Board asks that the Working Groups determine their own target
audience definition and product description as a first task; the names
aren't set in stone.
We're also creating groups to focus on the common core, and to work on
policies and practices for software operating outside of Fedora's
traditional packaging model, alongside the existing (and continuing)
Fedora Packaging Committee.
* Base Design Working Group
* Environments & Software Stacks Working Group
The working groups' initial membership will be chosen by FESCo from
volunteers. This message is the request for those volunteers to
Each group will have at least one FESCo member, who will act as a
liaison to FESCo and as a representative of the group at FESCo meetings.
We would like each group to also have representation from other major
areas of Fedora - Quality Assurance, Infrastructure, Release
Engineering, Documentation, Design, Websites, Ambassadors, Feature
Wrangler, Marketing. We don't intend for this to be additional work to
current members of those teams; working group members should interact
with and augment the existing subprojects.
These working groups will be more formal than the existing SIGs, with a
documented governing structure and process of operation, voting members,
up-to-date and maintained project materials, and regular open
communication. All working group members will need to actively
The first responsibility will be to establish a governance charter,
followed by a product requirements document. We're obviously in the
middle of Fedora 20 development, and that's the priority for many of us
right now. For that reason, these deliverables won't be required until
after the F20 release, but we do want to start organizing as soon as
Interlude: Interested in Something Else?
Are the projects listed above not your interest? That's fine; you can
keep on working the way you are now. Or, perhaps you're interested in a
target product, but something different from the ones described above.
In that case, you may start a "secondary product" working group
following the same model; if that is successful the Fedora Board may
elect to promote that product to a primary target.
How to Self-Nominate
To volunteer to serve on one of the new Fedora working groups, simply
add yourself to the appropriate section in the wiki page below, along
with a brief description of your current involvement with Fedora and
plans for participation in this group.
The nomination period will be at least one month from this announcement.
FESCo will review the applications, appoint the initial members, and
assist with the development of each group's independent governance.
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
devel-announce mailing list