F20 System Wide Change: ARM as primary Architecture
by Jaroslav Reznik
= Proposed System Wide Change: ARM as primary Architecture =
https://fedoraproject.org/wiki/Changes/ARM_as_Primary
Change owner(s): Dennis Gilmore <dennis(a)ausil.us>, Peter Robinson
<pbrobinson(a)gmail.com>
Make ARM a primary architecture. Add armv7hl to the i686 and x86_64 as arches
that we build and support. This will mean that all packages supported by the
ARM architecture must build for ARM to be released. With the release of Fedora
19 we have deprecated support for software floating support (ARMv5tel sfp) so
the only proposed addition to primary architectures is currently ARMv7
hardware floating point 32 bit support (ARMv7 hfp 32bit).
== Detailed description ==
The Changing IT landscape has started to focus on greener technologies as well
as cheaper mass produced devices that allow for fully functional cheap devices
for lower socio-economic areas and other markets like education and "makers".
ARM SoCs have traditionally been the domain of embedded and mobile
applications but are now finding their way into more traditional computing
devices like desktop, notebook and server markets. Fedora ARM currently works
on many different devices with wider support coming with each new mainline
kernel release.
For this change we will enable armv7hl builds on primary koji, and compose arm
trees as with the other primary architectures. Fedora has in the Phoenix data
centre 96 quad core Calxeda EnergyCore server nodes. Some of these nodes will
remain allocated to the arm secondary architecture koji instance for building
updates for the current Fedora 18 and 19 releases. When Fedora 18 goes end of
life the ARMv5 softfp nodes will able to be be reallocated to other tasks.
Infrastructure has expressed an interest in testing and experimenting with
some of its workloads on ARM, some are allocated to QA and some for releng.
There is currently 24 nodes configured in primary koji ready to go as builders,
there is the capacity to add up to 24 more when ARM becomes primary if
desired.
The kernel is now a multi platform unified ARMv7 kernel supporting a number of
SoCs with support expanding with each new upstream release. We build a base
and LPAE variant similar to i686. There is an ARM specific (ARMv7 and aarch64)
kernel maintainer working in collaboration with the Fedora kernel team. The
releases are composed using the exact same tooling as used for the primary
architectures. Disk images for development boards are generated by appliance-
creator and the kickstarts live in spin-kickstarts, they take a similar format
as the livecds on primary but are shipped as an OEM disk image, and like
primary initial-setup is used to do final user configuration. Like primary pungi
is used to generate an install tree, PXE install trees are created but current
bootloaders don't support isofs so ISO images aren't currently created.
== Scope ==
Add armv7hl to list of arches for f20-build and future build tags in koji
compose armhfp trees with i386 and x86_64. Requisite build hardware already
exists in phx2 and is configured to work with mainline koji.
Proposal owners: change the arches in koji, import the matching ARMv7 rawhide
builds into koji. Update Release Engineering scripts to automatically build
armhfp trees along with i686 and x86_64.
Other developers: submit builds as normal, in the event of unexpected build
failures liaise with the ARM Team to help debug and fix issues.
Release engineering: Will need to add armhfp to the release processes and make
arm install trees and disk images with each milestone compose. Release
Engineering are part of the team of people proposing the Change.
Policies and guidelines: armv7hl builds will be required to complete for
builds to be successful in koji
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
10 years, 6 months
anaconda / initial-setup / gnome-initial-setup: can we do this better?
by Adam Williamson
So I'm writing a blog post on this topic ATM, and that really kinda
brought home how messy this design is at present.
Quick refresher for anyone who hasn't looked at it much yet: in F19,
anaconda can create user accounts, and 'firstboot' has been replaced
with two alternative tools, 'initial-setup' which is used in any
graphical install other than a GNOME install and just replicates
anaconda's 'root password', 'user creation' and 'date/time' spokes, and
gnome-initial-setup, which is used in GNOME installs and is its own
whole thing that can also do user creation.
I mapped out all the potential paths through this maze, and got this -
16(!!!) paths:
anaconda: root pw, no user - g-i-s: admin user
i-s: admin user
i-s: regular user
console: root
anaconda: root pw, regular user - g-i-s: user mode
i-s: edit root pw or user
i-s: leave intact
console: regular user + root
anaconda: root pw, admin user - g-i-s: user mode
i-s: edit root pw or user
i-s: leave intact
console: admin user + root
anaconda: no root pw, admin user - g-i-s: user mode
i-s: edit root pw or user
i-s: leave intact
console: admin user + root
Note the paths marked "i-s: edit root pw or user" are pretty messy and
open ended in themselves - initial-setup always runs if installed, no
matter what you set in anaconda, and at least theoretically lets you
change the settings you picked in anaconda.
This is...kinda nuts, and a QA nightmare. Can we maybe take a step back
and look if there's a more sensible way to design this, ideally with the
GNOME and anaconda teams working together?
If we imagined initial-setup didn't exist and we only had the
anaconda/g-i-s case, the proliferation of trees at least looks rather
better, because g-i-s can't set the root password or change what
anaconda did; if you create a user account during anaconda, g-i-s runs
only after you log in with that user account and just lets you configure
various settings for that user account, it doesn't let you create other
user accounts (this is what I've labelled as 'g-i-s: user mode' in the
tree). So the anaconda/g-i-s paths are broadly sane already. It's the
anaconda/i-s paths that are really complicating things. Still, it might
help to just take a step back and decide if we really need all this
flexibility. We could, for instance, simply force user creation during
anaconda, dump initial-setup entirely, and use only
gnome-initial-setup's "user mode" (desktops other than GNOME could
implement something like this "user mode" if they wanted to, or not).
That would be a hell of a lot simpler to code, test, support and
explain, with the minor(?) drawback that you couldn't install without a
user account and then create it on first boot any more. Xkcd Law tells
us that someone will not be happy about this:
https://xkcd.com/1172/
but still, it seems to be worth considering. Alternatively, we could
make i-s behave a lot more like g-i-s: it could dump its 'root password'
and 'date/time' spokes, and only run at all, and only to allow user
creation, if you didn't create a user during anaconda.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
10 years, 6 months
GPG verification in SPECs
by Till Maas
Hi,
upstream of pam_mount pointed me to OpenSUSE's gpg-offline RPM macros at
https://build.opensuse.org/package/show/Base:System/gpg-offline
They allow to use a keyring and detached signature as additional source
in SPECs to get both verified. Since gpg-offline's upstream is willing
to create a proper release to allow easy packaging for Fedora, I wonder
if I will find any obstacles when I package it. The packaging guidelines
allow packaging RPM macros, therefore this should be fine.
Also I am interested whether there are better options available.
Regards
Till
10 years, 6 months
F19 server install experience
by Samuel Sieb
I realize it's been a while since F19 was released but I finally got
around to do a server install. Since there have been a few negative
reviews here of the installation process I thought it might be nice to
have a mostly positive one. Here are my observations:
VLAN setup for installing! Yay! However, after rebooting,
NetworkManager wasn't able to bring it up, something about not knowing
the "virtual interface name". Turned out to be the ethernet interface
name changed from what it was at install time.
Didn't detect my timezone. Not a big deal, but I was hoping it would
since there's been some discussion here about it working.
I'm reinstalling an existing server, so used the custom partitioning.
The only problem I had here was that I clicked on the existing /home
partition to add it to the new install but then couldn't figure out what
to do. All I saw on the right was lots of disabled form items.
Eventually I read the instructions carefully and then looked at the
mount point entry again and saw that it wasn't disabled. I wonder if
there is some way to make it more obvious...
After starting the install, I went to enter the root password. As I was
doing so, the interface appeared to freeze. I switched through the
consoles and when I got back the interface was working again and the
keys that I had typed had shown up. One odd thing I noticed while
cycling through the consoles was that console 6 had a login prompt on
it. I didn't actually try logging in.
The progress bar is strange. All the package installing barely made it
past a quarter of the way.
Other than the ethernet interface naming issue, just minor cosmetic
issues. Thanks to everybody involved in getting the installer in such
nice shape.
10 years, 6 months
bodhi client question
by Joachim Backes
Dear bodhi/koji specialists,
perhaps, this is a dumb question:
sometimes after having filed a BZ, I get some email like
-----------------------------------------------------------
Package xxxxx-4.1.0.0-4.beta1.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing xxxxx-4.1.0.0-4.beta1.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-9971/xxxxx-4.1.0.0-4....
------------------------------------------------------------
*My question:* if xxxxx consists of a lot of packages, and I'm only
needing some few of them (libreoffice is a good example), how then can I
automatically download only those packages installed on my site?
The usage of "bodhi -D xxxxx....." will download *all* and not only the
locally installed pkgs.
Kind regards
Joachim Backes
--
Fedora release 19 (Schrödinger’s Cat): Kernel-3.9.4-302.fc19.x86_64
Joachim Backes <joachim.backes(a)rhrk.uni-kl.de>
https://www-user.rhrk.uni-kl.de/~backes
10 years, 6 months
Non-responsive maintainer: Dodji Seketeli
by Darryl L. Pierce
BZ#848774
This bug is nearly a year old, requesting that package offlineimap be
upgraded to what was then the latest release (6.5.4, now it is
6.5.5-rc2). There has been no response from the maintainer.
I posted a bug comment on 01 July asking for something from the package
maintainer and received no word.
I don't want to take over the package, but would like either the primary
or else a co-maintainer to upgrade the package as it has bugs that have
been fixed since 6.5.2 (the currently packaged release).
--
Darryl L. Pierce <mcpierce(a)gmail.com>
http://mcpierce.multiply.com/
"What do you care what people think, Mr. Feynman?"
10 years, 7 months
Suggestion: bmap files and bmaptool
by Artem Bityutskiy
Hi Fedora developers,
I would like suggest you to take a look at bmaptool, which you can use
for flashing Fedora ISO images to USB sticks (or other block devices).
Let me set the scene. In order to flash a Fedora ISO image, typically
first download the image and then use dd to copy it to the USB stick.
Bmaptool does this, but
a) a lot faster (several times faster if you have the bmap file)
b) simpler, because it can flash directly from an URL (decompress
on-the fly too)
c) simpler, because it verifies data checksum automatically (only
if bmap file is present)
d) safer, since it won't destroy your mounted partition if you specify
wrong block device (say, for example, /dev/sda being the rootfs)
So what I am trying to "sell" here is a tool which flashes several times
faster than dd, which is safe, and can flash from http/ftp/https/ssh
URLs directly, and decompress gz/bz2/xz/gzip/tgz/tar.{gz/bz2/zx} files
on-the-fly.
We are using this in Tizen IVI, and I'd like to see other distros
using/supporting it. Or at least checking it.
The key element for bmaptool is the bmap file, which Fedora does not
produce for the ISO images. So bmaptool is not so useful, but the
community could find the tool useful and start providing the bmap
files.
Anyway, those who are interested in all the details may read the docs,
the links will be at the end. Let me give a couple of examples. I the
example I flash a Fedora image to my USB stick, which is /dev/sdd.
1. First of all, I can flash directly from the URL, I use the Finland
mirror here:
$ bmaptool copy --nobmap ftp://ftp.funet.fi/pub/mirrors/fedora.redhat.com/pub/fedora/linux/release... /dev/sdd
Note, I use --nobmap because there is no bmap file. With bmap file
flashing would be _a lot_ faster.
2. Let's check how fast is dd. I downloaded and decompressed the image
prior to running the tests.
$ dd if=Fedora-x86_64-19-20130627-sda.raw of=/dev/sdd
4194304+0 records in
4194304+0 records out
2147483648 bytes (2.1 GB) copied, 799.487 s, 2.7 MB/s
13.3 minutes.
3. With bmaptool, no bmap file.
$ bmaptool copy --nobmap Fedora-x86_64-19-20130627-sda.raw /dev/sdd
bmaptool: info: no bmap given, copy entire image to '/dev/sdd'
bmaptool: info: 100% copied
bmaptool: info: synchronizing '/dev/sdd'
bmaptool: info: copying time: 7m 22.2s, copying speed 4.6 MiB/sec
Faster, but not too impressive. The speed is because bmaptool configures
the block device for optimal writing of large sequential files.
4. Now I've generated the bmap file myself. Note, the real, correct bmap
file can only be generated on the Fedora build server just after the
image is created, so this example is artificial, and not correct, do not
try to use it. And it will give better numbers than the real bmap file
would give, I can explain why if needed, or see the docs. Anyway, I've
made a sparse file out of the image, then generated the bmap file for
it, and flashed it:
# Make the image to be sparse
$ cp --sparse=always Fedora-x86_64-19-20130627-sda.raw Fedora-x86_64-19-20130627-sda.raw.sparse
# Generate the bmap file
$ bmaptool create Fedora-x86_64-19-20130627-sda.raw.sparse -o Fedora-x86_64-19-20130627-sda.raw.sparse.bmap
# Now flash with the bmap file
$ sudo ./bmaptool copy Fedora-x86_64-19-20130627-sda.raw.sparse /dev/sdd
bmaptool: info: discovered bmap file '/home/dedekind/tmp/Fedora-x86_64-19-20130627-sda.raw.sparse.bmap'
bmaptool: info: block map format version 1.3
bmaptool: info: 524288 blocks of size 4096 (2.0 GiB), mapped 176288 blocks (688.6 MiB or 33.6%)
bmaptool: info: copying image 'Fedora-x86_64-19-20130627-sda.raw.sparse' to block device '/dev/sdd' using bmap file 'Fedora-x86_64-19-20130627-sda.raw.sparse.bmap'
bmaptool: info: 100% copied
bmaptool: info: synchronizing '/dev/sdd'
bmaptool: info: copying time: 2m 36.2s, copying speed 4.4 MiB/sec
Several times faster than dd.
And yes, bmaptool can flash the .raw.xz file as well, you do not have to
decompress.
Please, fine the bmaptool documentation here:
https://source.tizen.org/documentation/articles/bmaptool
It is a bit out-of-date, but not much, will be updated soon.
The tool is generic, not tizen-specific.
Please, see the information about the project here as well:
http://git.infradead.org/users/dedekind/bmap-tools.git/blob/refs/heads/de...
Note, the .xz support is only available in v2.6, which I did not release
yet, so you need to take the sources, not the packages.
The project is a python project, and it provides APIs so that other
python projects could use the functionality.
Here is an example of a bmap file can be found here:
https://source.tizen.org/documentation/articles/bmaptool
And yes, I suggest that Fedora could also generate and publish bmap
files, if this is found to be useful. In Tizen IVI people are very happy
to use bmaptool versus pain dd.
Anyway, please, check the docs, give feed-back, ask questions.
Thanks, and sorry for a messy e-mail :-)
--
Best Regards,
Artem Bityutskiy
10 years, 7 months
Fwd: Broken dependencies: python-osmgpsmap
by Richard Shaw
Ok, I've been getting these messages for a while but I'm not the package
owner for I didn't worry about it, however, it's been a couple of weeks so
I decided to take a look to see how much work it would be.
Now I'm really confused... There are two separate packages in Fedora:
osm-gps-map
python-osmgpsmap
Both point to the same upstream URL. The description from upstream of
osm-gps-map says it includes python bindings but there is not currently a
separate sub-package generated...
So what's the deal? Do one of these packages need to be retired?
Richard
---------- Forwarded message ----------
From: <buildsys(a)fedoraproject.org>
Date: Sun, Aug 11, 2013 at 7:35 AM
Subject: Broken dependencies: python-osmgpsmap
To: python-osmgpsmap-owner(a)fedoraproject.org
python-osmgpsmap has broken dependencies in the rawhide tree:
On x86_64:
python-osmgpsmap-0.7.3-9.fc20.x86_64 requires
libosmgpsmap.so.2()(64bit)
On i386:
python-osmgpsmap-0.7.3-9.fc20.i686 requires libosmgpsmap.so.2
On armhfp:
python-osmgpsmap-0.7.3-9.fc20.armv7hl requires libosmgpsmap.so.2
Please resolve this as soon as possible.
10 years, 7 months
Mouse focus stealing bug
by Maros Zatko
Hello dear Fedora comunity,
I've hit very weird bug which happen to get very urgent now.
Something (very likely GTK{2,3} but not sure at all) is stealing my
mouse focus
so that I cannot click anymore. Symptoms are in range from being able to
click
once or several times AFTER switching desktop (tag), to being able to
click only
with left button (with right being totally unresponsive) to not being
able to click
at all anymore until I kill Xorg.
Killing Xorg was *the fix* -- for you to understand, after reboot I
*had* to kill Xorg
session three times, with spawning some GTK app in between runs so that
I hit
the issue and Xorg restart had the right effect.
What happens now is that Xorg restart are NOT helping any more, i.e.
after that
it "works" for about 5 minutes and then it get progressively more and more
wrong until I cannot click any more.
My nowadays combo is Xmonad with nm-applet and some other basics plus
firefox, xchat, pidgin and some gnome-terminals (and couple of other random
stuff). To hit the issue is enough to spawn xchat and firefox in a clean
session.
I've been hitting the very same issue before when I was using Awesome WM,
but I thought it was its issue so I've picked xmonad but after some time
the same
issues returned.
So, dear Fedora community, I beg you for help. I have no idea how can I
fix this,
nor how can I debug it. Any help would be really welcome.
Thank you,
Maros
10 years, 7 months
