GoOSe Linux 6.0 Beta Release Candidate 5 (RC5) is now available for testing. Visit http://get.gooseproject.org/ to obtain the download.

Once you arrive at the above link, the downloads are under /releases/6.0/Beta-RC5/GoOSe/<arch>/.

The GoOSe Project is always interested in feedback around its project. Please feel free to drop us a line about this release.

Comments/Questions:

• Send us an email goose-linux@googlegroups.com
• Contact us on irc.freenode.net at #gooseproject
• Leave a comment on this blog post

Issues with GoOSe 6.0

If you find yourself having trouble installing, using or managing GoOSe Linux, please let us know. The best way is to file issues at our main project site on github, but we’re happy to have the information in any of the ways listed above.

Testing can be done by anyone. Please feel free to check our new testing wiki page for information on what tests need to be run and which have already passed. If you have interest in helping us test, thank you, thank you, thank you for the help!

GoOSe Beta-RC5 will be available for 1 week from today. At such time the GoOSe team will decide whether it will be the first Golden GoOSe release. This will be based upon feedback provided, so please do tell us what you think!

Cheers,

herlo

Once you arrive at the above link, the downloads are under /releases/6.0/Beta-RC4/GoOSe/<arch>/.

The GoOSe Project is always interested in feedback around its project. Please feel free to drop us a line about this release.

Comments/Questions:

• Send us an email goose-linux@googlegroups.com
• Contact us on irc.freenode.net at #gooseproject
• Leave a comment on this blog post

Issues with GoOSe 6.0

If you find yourself having trouble installing, using or managing GoOSe Linux, please let us know. The best way is to file issues at our main project site on github, but we’re happy to have the information in any of the ways listed above.

GoOSe Beta-RC4 will be available for 2 weeks from today. At such time the GoOSe team will decide whether it will be the first Golden GoOSe release. This will be based upon feedback provided, so please do tell us what you think!

Cheers,

herlo

Note: The links below are provided by the Fedora Project as a useful pointer to tests the GoOSe Project should be be performing. Please do not modify content on the links below, they are only for reference. It is expected that the GoOSe Project will build its own tests based upon the great tests provided below.

Installation:

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

Base:

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

Ideally, all Alpha, Beta, and Final priority test cases for
Installation [1], and Base [2] should pass in order to meet the Final Release Criteria [3]. Help is available on #gooseproject on irc.freenode.net.

[1] https://fedoraproject.org/wiki/QA:Installation_validation_testing
[2] https://fedoraproject.org/wiki/QA:Base_validation_testing
[3] https://fedoraproject.org/wiki/Fedora_17_Final_Release_Criteria

The GoOSe Project thanks the Fedora Project for providing such good testing information and allowing us to ‘stand upon shoulders of giants’ as we grow and learn.

When is this happening you ask? Well it’s very simple and very soon, in fact it’s happening July 27-28, 2012. Yes, that’s Tomorrow and Saturday. It’s a bit unexpected for some of you, to be sure, but if you can make it, we’d love to have you for any time possible. If you can’t make it, take some time this next week and work on the GoOSe. The goal is to get the Golden GoOSe 6.0 release out by the end of August, so we really need to start cranking!

What’s left, you ask? Quite a bit actually, but the biggest piece still remaining is our Quality Assurance testing and reporting components. We’re working on them in our qa repository on github, and you can most definitely fork it and get an idea of what we’re doing. We need some serious help with ABI compliance, validation of RPMS and overall validation that all packages have been built.

Wait! There’s more! We also need help with documentation, code and usability testing of the isos. The documentation is all based upon our
‘How to Cook a Goose’ wiki page on github, the skein code needs to be
updated to the new github v3 api and the Isos can be downloaded and
tested.

Some of this is more self-explanatory and some is just plain confusing. This is where we need your help! If you have ever wanted to define how things work, you can jump in now and help us identify things and help us solve problems. That’s the fun part about free and open source software! A good for instance, what is the usability testing requirements for our Isos? Well at the moment, we don’t really have a good handle on this, but you could step in and define some requirements. If you would prefer to help write code, you could clean up things that might look a bit messy. There’s plenty to do!

Please come and help us out this weekend or anytime next week! We’ll be in #gooseproject on irc.freenode.net, or you can work by email, github or ESP. We’re excited to be moving forward and look for your help making the the ‘Quest for the Golden GoOSe’ 6.0 release a reality!

Cheers,

Clint

The Fedora project will be putting on a Beefy Miracle lunch across the street from SELF on Saturday (I think it’s at noon) so come by and get a Beefy Miracle in honor of Fedora 17.

Also, stop by the Fedora booth sometime during the weekend with your canned goods we’ll be collecting this weekend for the Loaves and Fishes food pantry in Charlotte, NC. Their priority list includes canned meats, canned pasta (such as spaghetti’os, ravioli, etc.), cereal, canned fruit, and 100% fruit juice. Nothing in glass, please!

Plus, you’ll get a little surprise in return. I won’t give it away, but as you might have guessed it’s something that is definitely beefy. Hope to see you there!

There are quite a few other goodies on the schedule, so please feel free to peruse. It should be a great weekend!

Cheers,

herlo

Just released today is the second Release Candidate (Beta-RC2) for GoOSe 6.0 – You can find it here. In addition to the DVD, netinstall and CD installation images, you will now find a Live Desktop ISO.

Please help us by downloading and using the ISO images. File any bugs you find. It’s incredibly easy to become a contributor!! (If you are not a contributor yet, please email bugs to the goose-linux mailing list.)

Cheers,

herlo

The first will be on my latest project, GoOSe Linux – Rebuilding Enterprise Linux the ‘Community’ Way at 11:15am on Thursday, May 3.. If you ever wondered why CentOS took so long to rebuild Enterprise Linux, wondered what other options are out there, or even were just curious how Linux is built, come by and listen. It will be entertaining and enlightening.

The second talk will be Koji – A Reliable, Repeatable Build Environment, 4pm on Thursday, May 3. If you aren’t aware of what Koji does, it builds and manages RPMs. While we use it for the GoOSe project, many folks need a simple and clean way to build packages in a repeatable and reliable way.  Koji can also build LiveCD/LiveDVD images, manages repositories, tags builds and much, much more.

The last presentation I will be giving is ‘The State of Open Source‘, it’s a keynote presentation at 1:30pm on Friday, May 4. Expect this talk to be light and fun! I hope everyone comes out and enjoys this talk as well.

Additionally, it looks like Victor and the gang have created badges for you to put on your blog, Facebook, Google+, etc. so get them out there and come hang out at UTOSC 2012!

Cheers,

herlo

GoOSe Linux – Rebuilding Enterprise Linux the Community Way

Yes, GoOSe Linux is almost here and we’re ready to discuss the process and the goals of our little community. If you have been hearing me rant about GoOSe on the Utah Open Source Planet, Google Plus or Facebook and want to hear more. Or if you are just plain bored tomorrow night with nothing better to do, come down to the Provo Linux User Group. Learn more about how the Enterprise Linux Rebuild community is working together to make a better ecosystem.

If you can’t make it, or want to preview the slides, you can get them on my speakerdeck.com page. I look forward to seeing you all there.

For more information, check out the PLUG announcement.

Cheers,

herlo

Last night, Mike (shalkie) and I had a nice discussion about the process we are now using to build / import packages. This is in preparation for now and the future. A lot of this discussion is thanks to Mathieu Bridon (bochecha).

I have inserted a few notes in the process below for clarification.

02:03 < herlo> k, so you should know that you first ‘skein request’ a package
02:03 < herlo> it can be done with either the –path or –name option, but one must be provided
02:04 < herlo> normally, one shouldn’t grant their own package. I should be around some tomorrow to grant packages in bulk for you as needed
02:04 < herlo> but
02:04 < herlo> if you do need to grant a package
02:04 < herlo> it should be something like
02:05 < herlo> skein grant -k <koji owner> -g <github owner> issue_number name

Package repos and koji tags are what get created with skein grant. However *only* an admin can grant a new package into our build environment. This is to make sure we are not putting packages into the process that are not part of the upstream and/or for a good review
process. In the future, I suspect quite a few people will be admins and this will be less problematic.

02:05 < herlo> once granted, the package can be imported with
02:05 < herlo> skein import /path/to/srpm
02:06 < herlo> usually though, I do take one extra manual step.
02:06 < herlo> I visit the repo page on github and add a service hook
02:06 < herlo> if you look at this page: https://github.com/gooselinux/libgnomecanvasmm26/admin/hooks
02:07 < herlo> you can see the ‘Post-Receive URLs (1)’
02:07 < herlo> if you click on it, you’ll see the url you should add for any new repo
02:07 < herlo> this post receive hook will automatically launch builds upon a commit

If you have admin access to a repository (and if a package has been ‘granted’ to you, then you do), add the following in the Post-Receive
URLs if it’s not already there:

http://roman.gooselinux.org:8080/add

02:08 < herlo> once you have that in place, run the import command described above
02:08 < herlo> at that point, everything should be pretty automatic.
02:08 < shalkie> k
02:08 < herlo> within 10 minutes, the build should automatically launch
02:08 < herlo> shalkie: seem pretty straightforward?
02:09 < shalkie> Yeah it does.
02:09 < herlo> k, so now it should also be clear that you may (and probably already do) have failed builds
02:09 < shalkie> The stack of email certainly suggests that.
02:09 < herlo> lol
02:10 < herlo> shalkie: a good portion of those can be run through again, though I have been working on fixing a few of mine
02:10 < herlo> shalkie: as you look through the failed builds, you may just need to run them again
02:11 < herlo> to do that, you can use
02:11 < herlo> skein build
02:11 < herlo> the way I usually do that is ‘skein build –nowait dist-gl6 <pkg_name>’
02:11 < herlo> only an admin can perform this task (you are an admin)
02:12 < herlo> you can watch the tasks at http://koji.gooselinux.org/koji as you always have, or go out for a
few hours and check the build statuses when you return

02:13 < herlo> BUT WAIT! There’s more!
02:13 < herlo> If for some reason, you determine something has to change in the spec file, like another dependency or something
02:13 < herlo> you’ll need to do two things
02:14 < herlo> first, clone the branch if not already there and then create a vanilla branch
02:16 < herlo> git checkout –track -b  <local branch> <remote>/<tracked branch>
02:16 < herlo> eg git checkout –track -b vanilla origin/vanilla
02:16 < herlo> then push that vanilla branch
02:16 < herlo> git push origin vanilla
02:17 < herlo> this is so we can keep the original state of the package before we make any changes. I’ll be working on  automating this later
02:17 < herlo> when vanilla is pushed, we’ll go back to master and make our changes
02:17 < herlo> git checkout master
02:17 < herlo> <make changes>
02:17 < herlo> git add <files changed>
02:17 < herlo> git commit -m “message regarding changes”
02:18 < herlo> git push origin master
02:18 < herlo> again, when you push to master, a build will be launched within 10 minutes
02:18 < herlo> sit back, enjoy coffee and wait for the build to return

At the moment, the ‘master’ branch is currently what is getting built. Vanilla never gets built, but serves as a reference point to what the upstream did at certain points along the way. The vanilla branch also provides a way to merge in upstream changes with our changes. Git will
make this easy for us, because merge conflicts will be much easier to resolve across branches.

I hope this little conversation is a bit clearer on the process we’re trying to use. Look for further improvements coming to skein 2.1 (I already have quite the feature list) in the next few months.

Cheers,

Clint

PS – I likely won’t be online when this post is published as I’ll literally be enjoying some GoOSe, prepared by my lovely wife. She is an amazing cook / chef and is attempting this for the first time ever!

As of this morning, it appears we only have around 40 failed builds! We’re getting very close! I think we could make an alpha by the end of next week with a good bit of sprinting! As I understand it, one is planned for next week, maybe we should sit down and figure out those details?

Cheers,

Clint