Fedora 18 for IBM System z 64bit official release
by Dan Horák
Hello everyone,
Fedora 18 GA release for the IBM System z is here. This time only one
week (8 days to be correct) later than the primary and again more closer
to primary when we count the number of available packages.
Worth noting also here is that Anaconda, the Fedora installation
program, has been extensively redesigned since Fedora 17. Documentation
is available in the Installation Guide
(http://docs.fedoraproject.org/en-US/Fedora/18/html/Installation_Guide/ch-...)
and is generally applicable to Fedora for System z.
The links to the actual release are here:
http://secondary.fedoraproject.org/pub/fedora-secondary/releases/18/Fedor...
http://secondary.fedoraproject.org/pub/fedora-secondary/releases/18/Every...
and obviously on all sites that mirror the secondary arch content and we
still have few :-)
The first directory contains the normal installation trees as well as
one DVD ISO with the complete release.
Everything as usual contains, well, everything. :)
Additional information about known issues, the current progress and
state for future release, where and how the team can be reached and just
anything else Fedora on IBM System z related can be found here:
http://fedoraproject.org/wiki/Architectures/s390x/18
For architecture specific release notes, please read it as there are
changes in the interactive installation process. It's a wiki so don't
hesitate to add your knowledge there.
More information about Fedora on IBM System z can be found at
http://fedoraproject.org/wiki/Architectures/s390x
Thanks go out to everyone involved in making this happen!
Your Fedora/s390x Maintainers
--
Dan Horák, RHCE
Senior Software Engineer, BaseOS
Red Hat Czech s.r.o., Purkyňova 99, 612 45 Brno
11 years, 3 months
Self introduction
by Juerg Haefliger
Hi everyboy,
My name is Juerg Haefliger and I'm a software engineer with
Hewlett-Packard based in Switzerland. Part of my responsibilities is
building guest images for the HP cloud that runs OpenStack. Although
we use Ubuntu on bare metal, thanks to my imaging work I'm exposed to
different distro flavors and the pain and joy that come with it :-)
In terms of open source contributions, I'm a developer and maintainer
of two hardware monitoring kernel drivers which are part of the
lm-sensors project and I've also contributed to cloud-init which is a
customization tool for cloud images.
My main interest at the moment is to bring some new packages to Fedora
and RHEL to support cloud images, so be on the lookout for a sponsor
request shortly :-)
Best
...Juerg
11 years, 3 months
'Nice to have' process is now 'Freeze exception' process, improvements to blocker / freeze exception tracker aliases
by Adam Williamson
Hey folks!
At FUDCon Lawrence, Tim Flink presented on the Fedora blocker bug and
'NTH' processes, and we got some interesting and useful feedback. People
felt that the 'nice to have' / 'accepted' name used in that process was
confusing and difficult to understand, and that the aliases used for the
tracker bugs were inconsistent.
We developed a proposal to rename the aliases and the 'nice to have'
process. This was refined over the period of a few days' discussion on
the test@ mailing list: see
https://lists.fedoraproject.org/pipermail/test/2013-January/113363.html
for the thread.
There was a very solid consensus that the old scheme sucked and the
final form of the new proposal was miles better, and this is not the
first time the topic has come up (there are various proposals in the
list archives). So I decided to go ahead and Just Do It, putting the
proposal into 'production' today. I have adjusted the tracker bugs
themselves,
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Trackers ,
https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process ,
https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting , and renamed
https://fedoraproject.org/wiki/QA:SOP_nth_bug_process to
https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process and
adjusted it. I have also made the obvious changes to the relatively
large number of other wiki pages that link to and talk about the 'nth' /
'freeze exception' process: see my Wiki edit history for those changes.
Here are the practical changes:
The 'nice to have' / 'NTH' process is now the 'freeze exception'
process: thanks to Jared Smith for the name (though I believe it's
actually a resurrection from the old 'freeze exception request' process,
which was a better name but a much worse process). This name, very much
unlike the other one, 'does what it says on the tin': the freeze
exception process is how you request freeze exceptions. Seems pretty
simple. 'Freeze exception' is kind of jargon, but it's pretty standard
terminology in the tech world, doing a web search for it gives you
useful results that explain what it is, as noted it is terminology
Fedora has used in the past, and we could not think of a way of
concisely expressing the concept in non-jargon English.
The 'new style' tracker bug aliases are as follows:
AlphaBlocker
AlphaFreezeException
BetaBlocker
BetaFreezeException
FinalBlocker
FinalFreezeException
These names are consistent and, again, 'do what they say on the tin'. We
were using aliases ending with "-accepted" for NTH bugs before, which
was a really terrible idea (not least because it meant we used the word
'accepted' in two entirely different ways in one process), and the Final
aliases did not follow the same pattern as the Alpha and Beta ones.
These primary aliases do not need to be versioned, as Kamil Paral
perceptively pointed out: as they are only aliases and can be
transferred from bug to bug, we can file a new set of tracker bugs for
each release, but transfer these unversioned aliases at the time of each
release. So right now these aliases are applied to the F19 trackers: at
the time of F19 release, they will be transferred to the F20 trackers.
This basically means that, at any point in time, you can simply mark a
bug as blocking 'AlphaBlocker' and it will be nominated as blocking the
next Alpha release.
Versioned aliases will still be applied to all the tracker bugs, so that
we can find older ones when we need to and so that a consistent naming
scheme is always available for all releases. This format will be used:
F18AlphaBlocker
F18AlphaFreezeExcept
F18BetaBlocker
F18BetaFreezeExcept
F18FinalBlocker
F18FinalFreezeExcept
The shortening of 'Exception' to 'Except' is unfortunately forced upon
us by a Bugzilla limit of 20 characters for alias names. I have
submitted a bug requesting this limit be raised: if this is done, the
versioned aliases will be changed to follow the format of the
unversioned (FreezeException instead of FreezeExcept). I have not yet
filed the Fedora 20 tracker bugs as the text in the tracker bug
descriptions refers to these aliases and cannot easily be changed after
the bug is filed, so I am waiting to see the resolution of this issue
before I file those bugs to ensure accurate text can be included.
As our Bugzilla allows for multiple aliases to be applied to bugs, bugs
can have both the dynamic aliases and their static aliases applied at
once, we can maintain 'backwards compatibility', and old trackers can
have the new-style aliases applied to them so you can always use the
same naming scheme to find the trackers for any release, even old ones.
The Fedora 19 tracker bugs consequently have three aliases each at
present: the 'dynamic' alias, the new-style versioned alias, and the
old-style alias, so people and tools which are used to searching for the
old names can still succeed. For example, the F19 Beta freeze exception
bug has the aliases 'BetaFreezeException', 'F19BetaFreezeExcept', and
'F19Beta-accepted'. However, we will endeavour to use the new style in
all F19 discussion and blocker/FE review meetings.
As well as updating the F19 tracker bugs, I have added the 'new style'
aliases to the tracker bugs for all previous releases, so they all now
have two aliases: their original one, and one that follows the new
convention. You can now find the Fedora 10 Beta blocker tracking bug,
for instance, by using the alias 'F10BetaBlocker' as well as 'F10Beta'.
No need to remember both formats - just always use the new one.
The whiteboard fields used to indicate 'accepted' or 'rejected' status
for blocker and freeze exception bugs will be
AcceptedBlocker/RejectedBlocker (this has not changed) and
AcceptedFreezeException/RejectedFreezeException . Abbreviating to
AcceptedFE/RejectedFE was considered but rejected on the grounds the
abbreviation may be confusing to a maintainer who is not aware of this
process: the long version is more understandable.
There is, as always, a full list of tracker bugs for future, current and
past releases, with all their aliases, at
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Trackers .
I can think of a couple of potential issues with the 'dynamic' tracker
names (I'm not sure whether nominations will 'transfer' from one release
to the next when we change where the alias points, and if so, whether we
want that, especially for closed bugs), but we can burn that bridge when
we get to it: if that part of the plan causes a problem we can simply
get rid of those aliases and fall back to using the versioned ones for
all purposes. As we are preserving the old aliases, I can see no case
where this change will affect any existing usage of anything. All QA
tools, processes and documentation either already are or should soon be
updated to use the new names.
We hope this adjustment will make the process somewhat more convenient
for project members who are not accustomed to it as we are, and more
understandable for maintainers who find their bugs a part of the
blocker/FE process if they do not already understand it. We are aware
this process is still something of a 'duct tape job', but this is an
achievable improvement, and we are also working on more radical
adjustments like using flags or even tracking blocker/FE status outside
of Bugzilla itself.
Please let us know if you have any concerns or reservations about this
adjustment: all the changes involved in it are (as far as I'm aware)
non-invasive and reversible, so no panic. Thanks everyone!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
11 years, 3 months
Why do we have a kernel with version number - 20X?
by Joshua C.
Some days ago the version number for the f18-kernels was changed to
20x as in kernel-3.7.3-205.fc18. Is there a special reason for this?
Are the first 200 numbers reserved for something?
--joshua
11 years, 3 months
Install from ISO file supported
by Sergio Belkin
Hi Fedora community,
AFAIK fedup only works with DVD iso files not with LiveCD iso files:
I was reading the thread at
http://lists.fedoraproject.org/pipermail/users/2013-January/429113.htmlso...
interesting about it
ISO files are still useful, for example to test in a quicky way on a
Virtual machine, but I don't know you, but I'm sick of burning CDs....
I think that the best and more confortable method to upgrade the OS should
be:
1. Download a LiveCD Fedora.iso (it takes less time than download the DVD
iso file)
2. Launch fedup --iso Fedora-LiveCD.iso, that make the job of adjusting
GRUB2 i.a.
3. Reboot the system
3. Choose LiveCD entry from GRUB2) Perform the installation as you wish
And forget about of burning optical discs....
Of course this does not cover all cases, for example, you should preserve
the partition where ISO image file is.
What do you think?
Greetings
--
--
Sergio Belkin http://www.sergiobelkin.com
Watch More TV http://sebelk.blogspot.com
LPIC-2 Certified - http://www.lpi.org
11 years, 3 months
Re: [fedora-arm] FUDCon ARM related followup
by Jon Masters
Always was done with yaboot. Do we know if OLPC will move to UEFI?
--
Sent from my phone. Please excuse formatting and brevity.
Peter Robinson <pbrobinson(a)gmail.com> wrote:
> ----- Original Message -----
>> From: Peter Robinson <pbrobinson(a)gmail.com>
>> To: Development discussions related to Fedora <devel(a)lists.fedoraproject.org>
>> Cc: arm(a)lists.fedoraproject.org
>> Sent: Monday, January 21, 2013 6:28 PM
>> Subject: Re: [fedora-arm] FUDCon ARM related followup
>>
>> On Mon, Jan 21, 2013 at 1:57 PM, Bruno Wolff III <bruno(a)wolff.to> wrote:
>>> On Sun, Jan 20, 2013 at 23:56:49 -0500,
>>> Jonathan Masters <jcm(a)redhat.com> wrote:
>>>>
>>>>
>>>> We had a number of conversations about how to involve more people in
>>>> Fedora on ARM. We also had many other conversations that are being
>> minuted
>>>> on the wiki, with more notes and links to follow. Now is a great time
>> to
>>>> join arm@ and add your input.
>>>
>>>
>>> Since a number of Fedora developers where given XO 1.75s last summer,
>>> getting Fedora builds for those people might be a way to get more testing.
>>> (Yeah, they mostly use Fedora stuff now, but they don't use a Fedora
>>> kernel.)
>>>
>>> I have been testing OLPC builds, but that wipes my customizations, and
>> I'd
>>> rather do more normal Fedora testing with it.
>>
>> Fedora kernels don't support them because they're not all up stream
>> and we don't have support for OFW even where their kernels are
>> upstream. That being said you can use Fedora relatively easily while
>> still doing an initial install with the XO image and getting XO kernel
>> updates but still receiving standard Fedora updates and installing all
>> the other standard Fedora stuff using yum. I documented it here:
>>
>> http://nullr0ute.com/2012/09/using-fedora-on-your-shiny-new-olpc-xo/
>
> It doesn't seem like OF would be that hard to support, given PPC and sparc both use it, and it isn't -that- different then uBoot.
Probably not too hard to support but I believe PPC support is via
yaboot (or maybe now grub2) layered on top of OFW rather than directly
supporting OFW.
Peter
_______________________________________________
arm mailing list
arm(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
11 years, 3 months
Coordinating libffi upgrade
by Anthony Green
Several months ago I attempted to upgrade libffi 3.0.10 to 3.0.11. The change was reverted because the soname change in this version of the library broke the build environment. I would still like to get 3.0.11 in Fedora. I don't anticipate any future ABI-breaking changes, and 3.0.12 will include additional ports like Aarch64, which is likely of interest to some Fedora developers. How do we coordinate a rebuild for dependent packages? Also, I assume this will have to wait 'til F18 is out (fine by me), but I'd like to deal with it early in the F19 cycle.
Thanks,
Anthony Green
11 years, 3 months
