repos.fedorapeople.org
by Mike McGrath
I'm happy to announce the availability of repos.fedorapeople.org.
Intended for non-transient package hosting, it's a good central location
to store packages that users might find interesting.
It's still a bit manual (but coprs should fix that). When the time comes
we'll be able to properly mirror or move this if we need to (I do still
have some performance questions) but since we've never done anything like
this before it's hard to determine demand.
Enjoy:
http://fedoraproject.org/wiki/Fedorapeople_Repos
-Mike
12 years, 10 months
Fedora 14 has been branched!
by Jesse Keating
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
https://fedoraproject.org/wiki/Branch_Freeze_Policy
I know it's been a rough couple of days here, python-2.7 and boost
rebuilds creating build havoc, systemd creating some interesting
confusion, and dist-git to top it all off. But we'll work through it as
best as we can, as we always do. Onward into the future!
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkxSTyUACgkQ4v2HLvE71NUOrACgh9lVjA6Seo8P8XVWKp9/G2Kv
AqgAn34YI89nUBWRHlkoiqkGNLcL0RXt
=ieir
-----END PGP SIGNATURE-----
12 years, 10 months
The move to git!
by Jesse Keating
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This evening we opened up dist-git for business. Dist-git is our git
based replacement for dist-cvs, the source control system we were using
for our package specs, patches, and source files. This has been a long
time coming and a massive effort. I want to take a little time here to
outline what we've done and where we are going.
First a brief outline of how our CVS system worked. CVS is a daemon of
sorts, and all repos typically live within a single CVSROOT. Within
this CVSROOT we had an 'avail' system to make use of, that we could
populate with data from Fedora Account System and dump into this file.
Avail worked on path names, relative to the CVSROOT. Since we used
directories for each Fedora release as pseudo branches we could set
avail info on each release "branch". CVS also used some filesystem
symlink tricks to create a "common" subdir for every package module, and
this is where we stuffed common scripts and Makefile content. Pretty
clever on one hand, we can make updates to the make system without
touching every single package, but it is pretty hackish and we had
constant issues where somebody would attempt an action using old common
content and stuff would fall over.
Now we look at git. Git is for the most part a daemonless system. Each
repository is completely stand alone and generally does not require any
other infrastructure to be useful. You can interact with a repository
directly on the filesystem using /usr/bin/git or you can interact with
it through say ssh, again using /usr/bin/git (your local /usr/bin/git
will call a remote /usr/bin/git). Generally there is no running daemon
to connect to and authenticate with. Basic authentication of who can
check out what and commit where with git happens at the filesystem
permissions level. One twist with this is that with git, we wanted to
use real branches within a package repo to reflect the different
Fedora/EPEL releases. In repo branches are not reflected with path
names that we could set filesystem ACLs upon, so this posed a problem
for our conversion.
Enter gitolite. Gitolite ( http://github.com/sitaramc/gitolite )is an
addon system to git that provides ACL functionality including different
rights for different branches within a given repository, and more! By
using gitolite as a replacement for /usr/bin/git when a user connects to
our git server we can again utilize the information we have within the
Fedora Package Database and properly allow / restrict changes on
specific branches for specific developers. The gitolite upstream (
Sitaram Chamarty, sitaram(a)atc.tcs.com ) has been fantastically
responsive to our needs, which are admittedly a little unique. We have
a very large set of repositories (over 10.5K) and a largish number of
contributors (1050). The combination of the two leads to a very very
large and complex ACL structure that at first broke the system quite
badly. Upstream was very quick to create a "bigconfig" method of
compiling the ACLs without crashing the box. Our other unique needs
involve having individual accounts for each committer instead of a
shared account with a large list of allowed SSH keys. Add to that some
of our accounts need to be able to ssh shell into the git server for
administrative duties. Throughout our trials and testing with gitolite
every time we've ran into some issue that just didn't fit the mold,
Sitaram has been there with a smile and a fix. At this point our
production server is a whopping one line different from current gitolite
upstream. This is a fantastic win for us, for our sustainability, and
for the next large group that wants to make use of gitolite.
Once we had a plan for ACLs and for branches, we had to decide if we
were going to replace the Make system and with what. I had never been a
fan of Make, it was entirely too difficult to modify and innovate with.
Since I was the one pushing this transition forward, I decided to write
a new tool in my favorite language, python. The fedpkg tool was born
and took off. fedpkg was born around January 4th, 2010 and has since
grown into 1,523 (via sloccount) lines of code. While far from
complete, it is a great start (if I do say so myself!) at replacing the
make system. Because it is written in python (or maybe just !Make) it
seems to be easier to contribute to, and I've already gotten a number of
contributions. More will come as it starts to be more widely used. The
biggest challenge with fedpkg is removing the need to update something
on the end user's system every single time we added a new Fedora release
and changed what happens when you build for rawhide. I'll spare you the
details but I'm fairly happy with what we have. The end result should
be far fewer misfires and end user confusion.
The last major piece of the puzzle was how to actually convert the
existing CVS repositories, including the fun pseudo branches, into git
repositories. I tried a number of options over the years (I've been
working on this off and on for nearly 4 years!) ranging from the built
in git cvsimport to git-svn to parsecvs and a few others. In the end,
we took a page from the gnome project and used parsecvs (
http://cgit.freedesktop.org/~krh/parsecvs/ ) for the vast majority of
our repositories. There were a few that gave parsecvs fits and recent
versions of git cvsimport were able to handle them. The git system is
fantastic enough that we were able to merge our pseudo cvs branches into
actual git branches complete with a real shared history, but again I'll
spare you the details of the scripting to do this. All but the kernel
repo seems to have converted successfully which is a pretty good
success rate in my book. We may yet get the kernel converted, but in
the interest of time we opted to start fresh with dist-git for now.
Without the help of many others, this project would never have gotten
done. Folks helped out with Koji modifications, with fedpkg
contributions, with repeated testing of attempted conversions, with
logic checking of my plans, of helping me understand more of git
internals and deciphering error output, and most of all with being
patient while we worked through the transition and very positive along
the way. Things will be bumpy over the next few weeks as we really
start putting distgit to the test. No amount of staging and testing can
really replace production use. There will be many more updates to
fedpkg as bugs are found and fixed and features are contributed. Wiki
pages will get filled out as knowledge of how to interact with dist-git
starts to spread ( https://fedoraproject.org/wiki/Using_Fedora_GIT is a
good start ).
Once again I want to thank everybody who helped out and for all the
(continued) patience! I'll be available via email and IRC as much as
possible the next few days to help anybody with dist-git issues. Look
for Oxf13 on freenode. Happy gitting!
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkxSTR0ACgkQ4v2HLvE71NXEswCeOAu+EG/porsvkjMVq+4lAchy
VMgAn1DNwqyYcSSC3bwX/MQ/cfwx7qjs
=fBGf
-----END PGP SIGNATURE-----
12 years, 10 months
Outage: Build System - 2010-07-28 07:15 UTC
by Jesse Keating
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
There will be an outage starting at 2010-07-28 07:15 UTC, which will
last approximately 48 hours.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:
date -d '2010-07-28 07:15 UTC'
Reason for outage: dist-git migration and Fedora 14 branching
Affected Services:
Buildsystem - http://koji.fedoraproject.org/
CVS / Source Control
Unaffected Services: All others
Ticket Link: N/A
Contact Information: Jesse Keating <jkeating(a)redhat.com> or Oxf13 on IRC
Please join #fedora-admin in irc.freenode.net or respond to this email
to track the status of this outage.
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkxP1rcACgkQ4v2HLvE71NVOpwCgiXd2yra19vxTqo2qK6sDIHXL
AFUAoK9/j53MDD3BWsKDhpMBL2qCMB0E
=r/Hd
-----END PGP SIGNATURE-----
12 years, 10 months
Testing Fedora? Please enable SELinux if you can
by Adam Williamson
I've been asked by FESCo to post this public service announcement :)
We'd just like to remind those who test Fedora, in whatever
way...running a stable release with updates-testing, running Rawhide,
being a proven tester (especially)...that it's best if you test with
SELinux enabled and enforcing. This is the default configuration of
Fedora, so we need testers to be running with this configuration so we
don't miss problems that show up when SELinux is running.
For proven testers, I actually added a section about this to the
instructions recently -
https://fedoraproject.org/wiki/Proven_tester#Testing_process .
We recognize there may be situations when SELinux causes problems and
you need to make it permissive or turn it off temporarily, but please
try and keep it turned on if you possibly can, and if you're in a
situation where you need to disable it, please let the developers know
by filing a bug, so they can fix it and you can turn it back on. Thanks
a lot!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
12 years, 10 months
f14 boost-1.44.0 upgrade: pushed
by Benjamin De Kosnik
The boost maintainers have updated the boost package to the current
release (1.44.0) in rawhide for F14. More info here:
https://fedoraproject.org/wiki/Features/F14Boost144
Rebuilds for devel packages that require boost are mandatory, as SONAME
was bumped. Help from package maintainers with rebuilding packages with
boost dependencies is appreciated.
-benjamin
12 years, 10 months
Fedora 14 branching and dist-git roll out
by Jesse Keating
Hey all! It's that time again, we're gearing up to branch for Fedora 14
this coming Tuesday! There is a major twist this time around, we're
going to attempt a roll out of dist-git!
Dist-git is our replacement for the CVS system we are currently using.
This is a pretty big deal, but we're going to try to make it as smooth
as possible. In the next few days I'll be finalizing our git server
setup and polishing up the user interface tool you all will be using to
interact with the source control and build system.
The conversion will take a couple days, which means our normal short
outage for branching will be a bit extended. I wish there was another
way, but converting over 9K cvs repos into git repos does take some
time. I really feel that this move is worth the extended outage.
The tool you all will use to interact with git and the buildsystem is
called "fedpkg". It comes from the fedora-packager package. There is a
version of it available now in all active Fedora and EPEL releases,
although it is built to work against our staging environment where we
have been testing the setup for a while. This setup is slightly
different than the final version, but you can install it and poke around
the help system to get a feel for what's going on. Most of the make
targets have made it over and are named the same; build, sources, srpm,
etc... Many of the targets can take arguments and options. Where the
make system used shell variables, fedpkg uses options and arguments.
Each target takes a --help argument that will show any available
options. Fedpkg does not yet have a man page, that may be coming soon.
We're also going to be working on wiki pages to document the new stuff
and archive the old stuff. We're going to need help on this too, so if
you want to pitch in, by all means!
As I mentioned above, this is an attempt. We are trying this pretty
early, which I wouldn't normally do. However we have a good roll back
plan. We are going to keep the CVS server as is, although turned
read-only during and after the dist-git rollout. If something fails
beyond reasonable repair with the dist-git attempt we will re-enable
write access to the CVS server (after we branch it for Fedora 14).
Otherwise we will keep it around, in some capacity, as a read-only
reference point.
I'm certain we will run into some bumps along the way, and some wrinkles
to iron out. I ask that you are patient with us as we work through
these, and as we either get updates pushed out of fedpkg or make
adjustments to the git repos on the git server. This transition has
been a long time coming, and I'm really happy to be the one to make it
happen. Keep in mind that this will be the first iteration of our
transition, and it will operate mostly the same as dist-cvs did with a
few improvements. Later on we will start to explore more interesting
advancements such as automatic patch management with exploded sources,
linking to upstream source repositories, automatic %changelog generation
from git changelogs, or things I haven't even thought about. Most of
all, we won't be using CVS any more and that feels really good to me.
If you're curious about how the new system will work or have concerns,
or want to help, you can reply to this email thread or find me on IRC as
"Oxf13" (that's an o, not a zero). If you run across bugs in fedpkg,
you can file them in the fedora-packager hosted trac space
https://fedorahosted.org/fedora-packager/ or just find me on IRC as well.
Thanks again for your patience, both in waiting so long for us to make
this move, and for bearing with us during the transition.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
12 years, 10 months
[ANNOUNCEMENT] Red Hat Bugzilla 3.6 Upgrade Public Beta
by James Laska
I am sending this on behalf of Dave Lawrence and the bugzilla team at
Red Hat. Please forward this on to any appropriate lists that were
missed.
> Greetings,
>
> The Red Hat Bugzilla team is happy to announce the first public beta
> release of the next version of Red Hat Bugzilla based on the
> upstream 3.6 code base.
>
> Please test drive at:
>
> https://partner-bugzilla.redhat.com
>
> Over the years Red Hat has made substantial customizations to Bugzilla
> to fit into the Engineering tool chain. Over time the
> upstream has incorporated some of these customizations or solved them
> in different ways. Upgrading reduces our customization
> footprint (and thus maintenance) while bringing many bug fixes &
> enhancements.
>
> The main area of focus for our public betas is stability.
> Functionality that currently works in our 3.4 code base should
> continue to
> work as expected in the new 3.6 release. These include various ajax
> optimizations, needinfo actor support, frontpage.cgi, product
> browser, several various UI enhancements, and of course the XMLRPC
> API.
>
> Please feel free to point your various scripts and third party
> applications that use the XMLRPC API at the test server to make sure
> they continue to function properly.
>
> There are numerous other changes behind the scenes that we haven't
> listed. The goal is to make sure that functionality that people
> have come to expect in 3.4 is possible in the new system.
>
> There are also numerous new features/fixes that are part of the
> upstream 3.6 release. For more detailed information on what has
> changed since the last release, check out the release notes page at
> https://partner-bugzilla.redhat.com/page.cgi?id=release-notes.html .
>
> The database is a recent snapshot of the live database so should be
> useful for testing to make sure the information is displayed
> properly and changeable. Also with a full snapshot it is possible to
> test for any performance related issues. Email has been
> disabled so that unnecessary spam is not sent out. So feel free to
> make changes to bugs to verify proper working order.
>
> We are asking for everyone to get involved as much as possible with
> testing and feedback on the beta releases to help us make this
> the most robust and stable release possible.
>
> Please file any enhancement requests or bug reports in our current
> Bugzilla system at https://bugzilla.redhat.com . File them under
> the Bugzilla product and relevant component with the version 3.6. With
> everyone's help we can make this a great release.
>
> Thanks The Red Hat Bugzilla Team
12 years, 10 months
