Hi,
the current xine-lib maintainer speaking. :-)
The Xine project:
http://www.xine-project.org/home
has recently released a new major version, version 1.2.0.
Unfortunately, among the list of changes:
http://sourceforge.net/projects/xine/files/xine-lib/1.2.0/README.txt.asc/...
there are these new "features":
* Use libavutil-provided implementations for CRC, SHA1 and BASE64 algorithms,
this makes use of libavutil even outside the FFmpeg decoding plugin,
but avoid duplication of algorithms between different plugins.
* Use av_mallocz() when xine_xmalloc_aligned() wouldn't be needed.
* FFmpeg is now required as an external dependency; if you want to build
xine-lib from source, please download a copy of FFmpeg from their SVN
server.
which basically mean that xine-lib now has a global, non-optional dependency
on FFmpeg's libavutil library.
So there are 4 possible ways forward:
(a) Stick with 1.1.x forever. I don't think that's a good idea in the long
run, upstream won't be providing security fixes for the old branch forever.
(b) Package libavutil (and only libavutil) from FFmpeg in Fedora. (I don't
think libavutil, as opposed to libavcodec, is actually patent-encumbered,
though that'd also have to be checked.) The issue there is that FFmpeg
upstream obviously doesn't support this. It would need some more black
packaging magic of the kind already done in xine-lib, and more legal
auditing. I don't think I want to investigate going down that road.
(c) Bundle parts or all of libavutil with xine-lib. Yuck!!!
(d) Move the whole thing (back) to RPM Fusion (where it originally was, before
we started needing xine-lib for Amarok and Phonon, which both no longer
use it). It would go to the Free section, of course.
My proposal is to go with (d).
The following packages currently depend on xine-lib:
* gxine
* (k9copy – already in RPM Fusion, not affected)
* kaffeine (my package, the reason why I maintain xine-lib in the first place)
* oxine
* xine-plugin
* xine-ui
These packages would have to move to RPM Fusion along with xine-lib.
In Kaffeine's case, upstream is switching from xine-lib to MPlayer in their git
repository, so it will likely have to move to RPM Fusion sooner or later
anyway. This means the affected packages are basically *xine*.
So my plan is to retire (for my packages, resp. have the respective maintainer
retire) the listed packages in Fedora for Fedora ≥ 17 and get (or have the
respective maintainer get) them into RPM Fusion Free instead. (I'd take care
of xine-lib and kaffeine myself, I hope the maintainers of the other packages
will take care of them.)
Comments? Objections?
Kevin Kofler

i get somehow tired to report bugs for several packages,
refresh them at each release because maintainers
ignore guidelines all the time
some of them responded and fixed their packages
some insist to ignore them
https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelin...
If your package meets any of the following criteria you
MUST enable the PIE compiler flags:
* Your package is long running
* Your package runs as root
____________________________________________
since there is nobody logged in these are *all* long
running processes and enough of them even running as
root and so match *two* reasons for harden them
[root@srv-rhsoft:~]$ checksec --proc-all | grep "No PIE"
X 21342 Partial RELRO Canary found NX enabled No PIE
login 26045 Partial RELRO Canary found NX enabled No PIE
alsactl 642 Partial RELRO Canary found NX enabled No PIE
mdadm 651 Partial RELRO Canary found NX enabled No PIE
upowerd 704 Partial RELRO Canary found NX enabled No PIE
avahi-daemon 705 Partial RELRO Canary found NX enabled No PIE
rtkit-daemon 718 Partial RELRO Canary found NX enabled No PIE
pulseaudio 869 Full RELRO Canary found NX enabled No PIE

I just noticed that the boost141 package had been previously available in
Fedora, but it has since been removed (
https://fedorahosted.org/rel-eng/ticket/5291 ). I'm not familiar with the
recent changes in Boost, but is the API stable enough to support a package
to build on EL 5/6 and Fedora?
Thanks,
Dave

= 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

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

If two packages 'provide' the same dependency, isn't yum supposed to
pick the one with the shortest name?
Anyway, 'BuildRequires: kernel' in Rawhide (on koji) picks
'kernel-debug' instead of 'kernel'. Is there a way to make it pick
'kernel' instead?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
I want to become a co-maintener of freemedforms and freediams with Ankur
Sinha, under the SIG medical. I'm not a sponsored fedora packager, so I
need a sponsor. I know a little bit how make and build package,but I
need some other instructions;)
Thank you in advance,
- --
Nobrakal, Fedora User and Ambassador
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJSKuKnAAoJEM9emWXFxNGCVMcH/Ay2v5alDyKaKagg+7UxJ8af
ocWqV4l7AnAe3bMANpfQDd1ybB5Wi+XD+S+wW76i/UWxMYupZDq7AJ7JSz+cYVo1
r/0zX3mOeGZx/3jl/dOlS59IWwFRIeemH2ZHsrP/XcfwunGXydWb8bVFBT7WVDhH
tRNnez//D7r+MPx+chsf/m36BWadC8HFFOkb6Qht1dOJCnZAA6hveuLhzGQOHynp
nwkPeLQgWVVcG9P6rLaQWNhdQ5ln/Z6FiA8gq6U2dloN1lwjvpP7hvMm+vQ5vw1J
2vEGcmj6Au5ZUGULEZdlugy71Ha9r2Qiety9yreBvuKbxxwUh22eGY6LQ04Qe/w=
=f2wr
-----END PGP SIGNATURE-----

Hi All,
I'm very happy to announce the second release (r2) of my Fedora 19 ARM
remix images for Allwinner A10, A10s, A13 and A20 based devices. This
release is based on the official Fedora 19 Final for ARM images,
with u-boot and kernel(s) from the linux-sunxi project:
http://linux-sunxi.org/
Here is what is new in r2:
New features:
-Added support for the buttons on various olinuxino boards
-Added support for using 7" or 10" lcd module with various olinuxino boards
-Added spi support (except on A20)
-Added pwm support
-Added support for power buttons connected to an AXP152 pmic
-Improved A20 support, adding kernel support for the following pheriphals:
-usbc0 / otg usb controller
-nand
-mali (*)
-g2d (*)
-cedar (*)
-resistive touchscreen (sun4i-ts)
-gpio
-ir receiver
-leds
*) kernel driver only, needs userspace blobs
New boards:
-Marsboard A10
-Sanei N90
Bug fixes:
-Fixed USB-1 device support (OHCI) controller on A10s / A13
-Fixed reboot being unreliable on A10s / A13
-Fixed the power button on AXP209 + A20 not working
-Fixed 6 second bootup delay when going from uboot to kernel on A20
-Fixed invalid reporting of high load on some boards
You can download it here:
http://scotland.proximity.on.ca/contrib-images/hansg/Fedora-19-a10-armhfp...
sha1sum: 2c633c84d5b0c9d0f6118e9a8217395d45978d8
It is important to read the README, the image standard comes without
u-boot pre-loaded since u-boot is board specific. The image includes
a user-friendly simple script to install the right u-boot for
your board, but if you simply xzcat the image to an sdcard, and then
boot your device with the sdcard, things will *not* work.
See the README for a list of currently supported boards.
Known Issues:
-Many boards don't have an rtc (A10 and A20 have a builtin one),
or at least no battery backup for it, resulting in the date
+ time being wrong.
-If the date is of by more then a couple of months, "yum update"
won't work because certificate validation fails for the https
connection yum tries to make. So if yum fails to get its repodata
first check (and fix) your date
-The wifi chip on the Auxtek-T004 hdmi-stick is unsupported atm
Enjoy,
Hans
And to make sure everyone reads the README, let me print it here
in full:
Fedora 19 ARM for Allwinner A10, A10s, A13 and A20 devices README
-----------------------------------------------------------------
Quickstart guide
----------------
1) Insert an sdcard, note any data on the card will be destroyed!
2) Make sure the card is not mounted, run "mount" and if the card shows
up in the output umount its partitions
3) Write the img file to the card, ie as root do:
xzcat Fedora-19-a10-armhfp-r2.img.xz > /dev/mmcblk0
sync
4) The card is not yet ready for use! Since the A10 u-boot is board
specific, the image comes without any uboot install, follow the next
steps to install the right u-boot for your board
5) Remove the card, and re-insert it. The uboot partition should get
automatically mounted, if not mount it manually,
6) As root (or through sudo) run: <uboot-part-mount>/select-board.sh, ie:
sudo /run/media/hans/uboot/select-board.sh
If you've dialog installed the select-board.sh script will prompt for
your board. If you don't have dialog installed, it will print the list
of supported boards. Lookup your board and re-run the script with the
shortname for your board as argument, ie:
sudo sh /run/media/hans/uboot/select-board.sh mk802
7) umount the uboot and rootfs partitions, ie:
umount /run/media/hans/uboot
umount /run/media/hans/rootfs
8) Your sdcard is now ready for use
9) *Before* powering up your A10 device connect it to an hdmi or dvi monitor
10) When first booting from the sdcard inserted Fedora will automatically
reboot once, this is part of the process to resize the root partition to
fill the entire sdcard and is normal behavior.
11) After the automatic reboot Fedora will start with the initial-setup wizard:
11a) Configure networking, note:
* If you've an A10 board with wired ethernet and you want to use dhcp
you don't need to do anything.
* If you've an A20 board, your ethernet may have a random mac-address,
so if you want to configure a static ip-address and want it to stick
across reboots, go to the ethernet-tab, select the mac-address field
and delete its contents, so that the static ip address you're
configuring does not get tied to the random mac-address.
11b) Setup the time zone
11c) Set a root password
11d) Create a user
12) Log in as the just created user
13) Enjoy Fedora on your A10 device
Supported Devices:
------------------
Fedora 19 ARM for Allwinner A10 has been tested with the following devices:
* A10s-OLinuXino-MICRO (Olimex)
* A13-OLinuXino (Olimex)
* A13-OLinuXino-MICRO (Olimex)
* A20-OLinuXino-MICRO (Olimex)
* Auxtek T003 hdmi tv stick
* Auxtek T004 hdmi tv stick
* BA10 TV Box
* Cubieboard development board 1024 MB RAM
* Cubieboard2 (A20) development board
* Gooseberry development board
* Mele A1000G/A2000G 1024 MB RAM
* Mini-X 1024 MB RAM
* mk802 (with female mini hdmi) 512 MB RAM
* mk802 with A10s (s with a circle around it on the barcode label)
* mk802ii (with male normal hdmi) 1024 MB RAM
* r7 hdmi tv stick
* UHost U1A hdmi tv stick
* Wobo i5 TV Box
Fedora 19 ARM should also work on the following devices:
* A10 tablet sold under various names (whitelabel)
* A13 tablet sold under various names (whitelabel)
* Coby MID7042 tablet
* Coby MID8042 tablet
* Coby MID9742 tablet
* Cubieboard development board 512 MB RAM
* DNS AirTab M82 tablet
* EOMA68 A10 CPU card
* H6 netbook
* Hackberry development board
* Hyundai a7hd tablet
* iNet-97F Rev.2 (and clones) tablet
* Marsboard A10
* Mele A1000/A2000 512 MB RAM
* Mele A3700
* Mini-X 512 MB RAM
* mk802 (with female mini hdmi) 1024 MB RAM
* pcDuino development board
* Point of View ProTab 2 IPS 9" tablet
* Point of View ProTab 2 IPS tablet with 3g
* Sanei N90
* XZPAD700 7" tablet
Configuring the display output
------------------------------
Multiple video outputs at the same time are not supported. By default
hdmi output with EDID is used for all devices, except for tablets/netbooks
where the default output is the lcd.
The default hdmi output with EDID will get the native resolution of your
TV / monitor and use that. Note that in order for this to work your TV /
monitor must be connected *and turned on*, before booting your device.
The output resolution can be configured with the disp.screen0_output_mode
kernel cmdline value, which can be found in the extrargs part of uEnv.txt in
the uboot partition. The default uEnv.txt contains the following value:
disp.screen0_output_mode=EDID:1280x720p60
This means try to use EDID and if no valid EDID info is found fallback to
1280x720p60.
The used output can be changed by adding disp.screen0_output_type=X to the
extraargs in uEnv.txt. With X being one of: 0:none; 1:lcd; 2:tv; 3:hdmi; 4:vga
Some per display type notes:
-lcd outputs: Hardcoded to the native mode, disp.screen0_output_mode is ignored
-tv: For the cvbs output disp.screen0_output_mode must be set to one of the
following: pal, pal-svideo, ntsc, ntsc-svideo, pal-m, pal-m-svideo, pal-nc,
pal-nc-svideo. Note the -svideo variants should only be used on boards with
an svideo connector, for composite out use the regular variants, ie:
disp.screen0_output_type=2 disp.screen0_output_mode=pal
-hdmi: To override the EDID detected mode, drop the "EDID:" from the
disp.screen0_output_mode value and set it to the desired mode, ie:
disp.screen0_output_type=3 disp.screen0_output_mode=1360x768p60
-vga: Does not support EDID, "EDID:" must be removed from the
disp.screen0_output_mode value otherwise it will be ignored. interlaced
progressive and refreshrate settings specified are ignored, each resolution
has hardcoded values for these. Example usage:
disp.screen0_output_type=4 disp.screen0_output_mode=1024x768
USB controller caveats
----------------------
The OTG USB controller in host mode only supports a limited number of
devices, plugging in a hub + mouse + keyboard typically will make either
the mouse or keyboard not work. This is a hardware limitation which we
will likely not be able to work around.
On tv-sticks and top-set boxes, simply avoid the otg connector, instead
use a hub in a regular host usb connector. Note on the mini-x the otg / host
marking is not always correct. If things don't work try using the OTG
connector instead!
On tablets and the gooseberry unfortunately only the otg connector is
available. One solution there is using a single usb-device which is
both a keyboard and a mouse at the same time. IE the receiver for logitech
wireless desktop sets.
Supported hardware components / features:
-----------------------------------------
Fedora 19 ARM for Allwinner A10 supports the following components:
* CPU + PMU + RAM
* Serial ports
* MMC cards
* Internal NAND storage
* Framebuffer on lcd / vga / hdmi / composite video
* Sound both analog out and over hdmi
* OTG USB controller
* Both standard USB host controllers
* Wifi
* Wired Ethernet
* SATA
* IR (untested at this time)
* SPI (as module, not supported on A20)
* "tablet" keys on olinuxino boards
* 7 and 10 inch lcd displays on olinuxino boards (requires selecting the
right config in select-board.sh
Unsupported hardware components:
--------------------------------
The following components require various proprietary blobs to be used, and
as such are not supported in the Fedora images. The kernel drivers for them
are present (usually as modules), so if you add the necessary blobs you might
get these to work:
* Mali 400 GPU
* Cedar hardware video & audio decoding and encoding engine
* G2D 2d engine
Differences from stock Fedora
-----------------------------
* Since the A10 is not a very powerful soc some services which are enabled by
default on Fedora are disabled in the image, see build-image.sh for a list.
* No plymouth: we log to a serial console for debugging so no pretty splash.
Also we don't use an initrd, so removing the console=ttyS0,115200 from
the extraargs in uEnv.txt will give plymouth, but so late it hardly matters.
Rebuilding the Fedora 19 ARM for Allwinner A10 disk image
---------------------------------------------------------
Building the Fedora 19 ARM for Allwinner A10 disk image consists of 2 steps
1) Building a uboot.tar.gz and rootfs.tar.gz "overlays", this is done
bu the build-boot-root-sh script
2) Combining uboot.tar.gz and rootfs.tar.gz with an official Fedora 19 arm img,
this combining is done by the build-image.sh script
The a10 image you downloaded is based on Fedora-XFCE-armhfp-19-1-sda.raw
These scripts are hosted here:
https://github.com/jwrdegoede/sunxi-fedora-scripts.git
A copy of the exact versions of these scripts used to build this Fedora A10
image can be found in the scripts directory of the uboot partition, the
kernel config used during the build can be found here too.
If you want to exactly reproduce this image it is important to use the
scripts from the scripts dir of the uboot partition, as the scripts contain
GIT tags used during the build to checkout the exact versions to build.
The pre-conditions these scripts expect to be met, and the exact usage of
them is documented in comments in the top of each script.