So it’s meteorological spring, at least in the Northern Hemisphere, and I’m preparing to move house for the first time in almost a decade so of course it’s time to procrastinate and have a spring clean of the packages I maintain!
A number of these I’ve maintained longer than I’ve been in my current flat and like a lot of the contents of my flat I’m not sure why I still have them! A bunch of them I packaged when MeeGo was the coolest thing to run on your Netbook and before GNOME-3 was stable and packaged and I wanted to run MeeGo on Fedora on my ASUS EeePC 901! Then a bunch I’ve acquired over the years because various things I was interested in depended on them. There’s others I actually have no idea why I own them! Anyway, with my day job doing “Device Edge” or “IoT” and with less spare non work time (why yes, apparently I do have a life outside of Fedora, who knew!) I decided it’s high time I relinquished the maintainership of these packages and let someone else love them or allow them to sail off into the sunset of their, probably long overdue, retirement!
So without further ado the list of packages I relinquishing is as follows…. Please reply to the list message or message me on IRC/email (if you know the Fedora packaging process) to (co)maintain something in this list:
* GNOME related:
* A UPnP stack, used (or at least used to be) by GNOME and others:
* Ancient gnome related (please retire or move the deps to copr already):
* GTK VoIP client. Mostly dead upstream. Has explicit deps/tightly coupled with opal/ptlib:
* iOS/iMobiledevice - Apple iDevice support:
* Random / no idea TBH:
A list of packages that I still have an interest in but would appreciate a co-maintainer:
When ever we branch for a new release of Fedora I, and others, end up spending a non trivial amount of time ensuring that there’s a clean upgrade path for packages. From the moment we branch you need to build new versions and bug fixes of packages for rawhide (currently what will become Fedora 26), for the current stabilising release (what will become Fedora 25) as well as what ever stable releases you need to push the fix for. For rawhide you don’t need to submit it as an update but for the current release that’s stabilising you do need to submit it as an update as it won’t just automagically get tagged into the release.
As a packager you should know this, it’s been like it for a VERY LONG TIME! Yet each cycle from the moment of branching right through to when a new release goes GA I still end up having to fix packages that “get downgraded” when people upgrade between releases!!
So far this cycle I’ve fixed about 20 odd with the latest being bash-completion (built but not submitted as an update for F-25) and certmonger (numerous fixes missing from F-25 and master branch).
The other silly packaging bug I end up having to fix quite a bit is NVR downgrades where even though it’s a newer package the way the NVR is handled makes rpm/dnf/yum think the newer package is a lesser version than the current version and hence you’re new shiny fix won’t actually make it to end users. I see this a lot where people push a beta/RC package to a devel (F-25/rawhide) release. Just something to be aware of, there’s lots of good docs around the way rpm/dnf/yum handles eNVR upgrades.
Allwinner ARM Systems on a Chip is a cheap SoC producing some cheap and interesting devices. The SoCs themselves are made in China by a company that licensed the Cortex-A8 reference design from ARM, it was one of the earlier ARMv7 chips so isn’t bleeding edge but it is ARMv7 so fully hardfp compatible. They currently produce two widely available chips the Allwinner A10 and A13.
The Allwinner chips are something I’ve been interested in supporting in some form or another on Fedora ARM for a while as they simply have a lot of cheap hardware available that is of reasonable specs. There’s a few things that have stopped me to date. Firstly it doesn’t appear that all their kernel code is upstream as yet so we’d be in a similar situation as we are with the Raspberry Pi. I’ve also not had a lot of time of late (as can be seen by my lack of blog posts recently!) as I’ve had other more pressing things non Fedora ARM things on my plate. Lastly I’ve been concentrating on ensuring Fedora 18 and rawhide remains in reasonable shape, the kernels of the devices we support keep moving forward and I’ve also got some other boards that have upstream kernel support I would like to see being usable on Fedora. Simply put… there’s just not enough hours in the day.
The other day I noticed that the company behind the Allwinner SoC (or some other company) had decided the create a cheap development board similar to that of the Pi, BeagleBoard or some of the other devices on the market. It’s called the CubieBoard.
It’s an interesting board. It’s some what higher speced than the Pi being an 1Ghz ARMv7 Cortex-A8 processor with 1Gb of RAM (or 512Mb), 4Gb of NAND Flash, 100Mb ethernet, most of the usual peripherals and interestingly a onboard SATA port. All for $49.
I contacted the CubieBoard team to see what their plans were for Fedora support and offered my assistance. I’ve since got an email back saying they’ll send me a board to enable us to get it working with Fedora. So once I’m back from holidays I should have a Allwinner A10 board waiting for me which I can start investigating what is required to support the Allwinner devices in Fedora. It seems they’re moving to get the kernel support upstream, there’s also a project to write an open source X driver for the MALI 200 and 400 GPUs. So with luck before long we might have another class of cheap ARM devices for people to play with Fedora on.
Having done two complete OS builds of Fedora on ARM. First with Fedora 14 and now with Fedora 17 on both hardfp and softfp flavours of ARM is never ceases to amaze me how many packages won’t build on mainline Fedora. Now days if I get a build failure on ARM the very first thing I do is a scratch build on mainline so I can be sure whether the problem is ARM specific or a general failure, in a lot of cases sadly it’s the later.
What’s more it’s surprising to see how many packages are FTBFS post mass rebuilds even though it’s advertised that packagers need to fix their build failures post mass rebuild. In fact post F-17 mass rebuild there’s still nearly 300 packages that are FTBFS in F-17 and that’s just doing a basic grep against the latest f-17 tagged packages so it doesn’t take into account packages that were built in the f17-build prior to gcc 4.7 landing but are FBTFS with gcc 4.7.0, ruby or some of the other F-17 features.
I know of the last 3-4 months I’ve personally fixed into the 100s of broken packages, and I know spot fixes a lot too but it still amazes me that maintainers don’t fix the build failures for their packages. A lot of fixes, especially for the older build packages, are basic things like patch fuzz so shouldn’t be hard to fix!
A list of the current < f17 packages currently tagged into F-17 stable (sorry if there's already a fix in the works via updates-testing):
I would like to remind people to check if their package is in the failure list for packages that have failed to compile since the Fedora GCC 4.7 mass rebuild. There’s still well over 550 packages that have failed to build! I’ve fixed well over 50 of them myself as they packages were holding up the Fedora 17 ARM building but frankly I’m getting somewhat sick of fixing things that the package maintainers should be actively dealing with. So check the failure list and if a package is yours or you can fix it please do so 🙂
I suspect this won’t be my last post like this. I use to just package them up myself but I’m finding that the amount of packages I maintain is increasing and the time I have to actually maintain them is decreasing and I know there’s people that are likely better suited to some of these packages than I am.
PinPoint – a tool for making hackers do excellent presentations
What more do I need to say! PinPoint is a clutter based tool for making cool presentations without death by bullet point.
Media Explorer – a media centre application for Linux
Media Explorer is another clutter/Mx based project for playing various types of media. It leverages existing libraries (GUPnP, Grilo, Tracker, GStreamer) to find, index and play local and remote media. It comes from the original Moblin team and looks very cool.
SqueezeBox server is a music server for Logitech’s excellent SqueezeBox devices but it works with other devices. There’s upstream rpms but its unfortunately broken with Fedora 15. The server is written in perl and I believe the code is all open source including a number of clients.
There’s a couple of utils that are part of the libiMobileDevice project that some people might find useful that aren’t yet packaged. ideviceinstaller for app management is one, nautilus-ideviceinfo for extended information in Nautilus is the other.