Well, the title says it all. Fedora Tour, which we recently decided
to make a web application needs web developers. Ironic eh? The thing is:
none of the current Fedora Tour team members have ever done web
development before. We’re learning, but the changes with HTML5, CSS3 and
time, we’d like an established web developer to come in and help us
reduce the learning time and get down to the implementation as soon as
- Are you a web developer?
- Do you have some free cycles?
- Do you want to work on a brand new, *awesome* project?
** Give us a shout today!!
You can either catch us on #fedora-tour on Freenode, or you can ping us
on the mailing list. I’m around on quite a few fedora IRC channels,
so you can also catch me personally if you want. My nick is
The wiki page for fedora tour contains all the info you’d need.
Note: This is only an announcement mail. Please do not reply to it.
Contact us instead!
Some update appears to have broken the operation of ypbind recently.
I have a F14 sever that serves /home and implements NIS services (ypserv)
and has been running fine for over a year.
The F16 clients use NetworkManager with wired Ethernet set to automatic/system
connection. Everything comes up fine except for ypbind that fails. This
has worked fine until a week or so ago (fails on multiple clients).
The boot.log is enclosed, any ideas ?
This was forwarded to the related maintainers earlier, but an ABI bump
is required for the matio update in F-18.
I don't plan to update it in F-17.
There is a license change involved from LGPL2+ to BSD (2 clauses).
I've tested the rebuilt for vips and it went fine.
---------- Forwarded message ----------
From: Nicolas Chauvet <kwizart(a)gmail.com>
Subject: matio ABI bump
To: nip2-owner(a)fedoraproject.org, scilab-owner(a)fedoraproject.org,
I'm preparing a matio update to 1.5.0. This involve an ABI change.
I've made a scratch build targeting f17 from the current master git
(not yet in f18 target)
# repoquery --whatrequires "libmatio.so.0()(64bit)"
I plan to update in devel first in the next days. I guess it might be
of interest for f17.
Unless someone disagree, I will make the update on wednesday for f17
with a builroot override.
Please rebuild your package then.
-------- Original Message --------
Subject: [fedora-arm] Weekly ARM status call - TOMORROW (Wed 2012/04/25)
Date: Tue, 24 Apr 2012 12:27:23 -0400
From: Jon Masters <jcm(a)redhat.com>
Organization: Red Hat, Inc.
Let's have one of our "weekly" status calls tomorrow pm. I aim to send
these reminders out more regularly so that we can get in the habit. If
the times no longer work for those involved in the Fedora ARM project,
please do let us know asap. Sadly, not every time will always work :)
Meeting is on #fedora-meeting for a (trial) change. I am also going to
suggest we do not have the phone component this week, and see how it
goes. If folks are more comfortable, the phone bridge is easy to setup.
As to the venue, I think it's appropriate to give it a trial and see
what happens - if #fedora-meeting turns into an opportunity for the
peanut gallery to take potshots, we'll reconsider that approach.
Times in various timezones:
Also join #fedora-arm on Freenode for general ARM discussion
before/after the weekly syncup.
0). Current build status
- Gnarly bugs and build failures
- Atomics on older processors (v5)
1). Secondary Architecture Promotion
- discuss outcome of FESCo meeting
2). Happy Birthday ARM
- ARM turns 27 on Thursday, how are we celebrating?
- Where do we stand with the F17 release.
3). Your topic here
arm mailing list
On 04/24/2012 12:27 PM, Jon Masters wrote:
> Let's have one of our "weekly" status calls tomorrow pm. I aim to send
> these reminders out more regularly so that we can get in the habit. If
> the times no longer work for those involved in the Fedora ARM project,
> please do let us know asap. Sadly, not every time will always work :)
> Meeting is on #fedora-meeting for a (trial) change.
Link to the meeting minutes:
I've occasionally wanted to test a packages built for another release
of Fedora and didn't really care to setup a bare metal or VM to do it.
I've found I can use mock (or probably any other chroot
program/helper) and Xnest to do this.
Is there any interest in putting this in the Fedora wiki somewhere? Am
I late to the party and everyone already knows how to do this?
$ mock -r fedora-rawhide-x86_64 --init
$ mock -r fedora-rawhide-x86_64 --install xclock
$ Xnest :1 -ac &
$ mock -r fedora-rawhide-x86_64 --shell
[mock] $ xclock -display :1
I also sometimes do this (without the Xnest part) for new library
packages in order to run rpmlint against the installed package. This
catches things like "undefined-non-weak-symbols" or something like
that and a few others that it can't catch from the package alone.