In yesterday's FESCo meeting I told you I'd make a list of specific issues
I have with the current proposal for ARM as a primary archictecture. There
are some places where I think the current proposal fails to deal with some
necessary aspects of becoming a primary architecture, and some places where
I don't think the approach is quite right. So without further ado:
1) mechanisms need to be in place to get package maintainers access to fix
arm-specific bugs in their packages
2) excludearch is not an option. This is fundamentally contrary to being
a primary arch. In fact this is one of the defining characteristics of
a secondary arch.
3) arm must be integrated to the formal release criteria
4) when milestones occur, arm needs to be just as testible as other
5) installation methods must be in place. I'm not saying it has to be
using the same model as x86, but when we get to beta, if it can't be
installed, it can't meet similar release criteria to existing or prior
primary arches. Where possible, we should be using anaconda for
installation, though I'd be open to looking at using it to build installed
images for machines with severe resource constraints.
6) supported platforms must be fully integrated into building and
installation. If you need a special build procedure to make this happen
for kernel, we need to have rel-eng signing off saying they've approved
of whatever method that is, and QE signing off that they think it'll
result in a something they can claim is tested enough to release as a
7) it can't be a serious maintenance burdon due to build related issues.
We need a couple of groups to sign off that builds are fast enough, not
just on a "full distro rebuild" (throughput) level, but also on a
"doesn't destroy my workflow due to waiting on it" (latency) level.
Obviously any feedback you guys have on this is welcome.
Old MacDonald had an agricultural real-estate tax abatement.
On 03/08/2012 04:18 AM, Pavel Alexeev wrote:
> 08.03.2012 01:16, Orion Poplawski wrote:
>> On 03/06/2012 01:29 PM, Pavel Alexeev wrote:
>>> 05.03.2012 21:47, Sérgio Basto wrote:
>>>> On Mon, 2012-03-05 at 21:11 +0400, Pavel Alexeev wrote:
>>>>> 05.03.2012 01:04, Sérgio Basto пишет:
>>>>>> On Sun, 2012-03-04 at 19:33 +0100, Mario Santagiuliana wrote:
>>>>>>> In data domenica 26 febbraio 2012 18:39:14, Pavel Alexeev ha scritto:
>>>>>>>> ImageMagick-6.7.6-5 will land to rawhide in short time. Soname change
>>>>>>>> happened (.so.5), so dependency rebuild needed.
>>>>>> Does it land on F17 ? , if not, why ?
>>>>> Do you think it have worth? I ready to do it.
>>>> yes , not in koji ?
>>> Ok, that's done.
>> If you're going to push this to F17, please submit a buildroot override and
>> we're going to need to rebuild everything that needs it in F17.
> Do you mean I should submit ticket for that? Unfortunately I'm not
> provenpackager and have no such capability to rebuild deps. But rуфвн вщdo
> that or anything to help.
Anyone can submit a buildroot override now here:
Then you should notify all relevant package owners that they need to do a rebuild.
>> Would be nice to have a single update for all if possible. I would suggest
>> unpushing from F17 testing until the rebuilds are done as well.
Technical Manager 303-415-9701 x222
NWRA, Boulder Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 http://www.nwra.com
-----BEGIN PGP SIGNED MESSAGE-----
I have some issues to build aplus-fsf via mock for the master branch.
Because I don't have any idea to selve the existing issues, I have uploaded
the build.log, the SPEC file and a patch to
It will be nice, if anyone can get a look on it to give me a hint to
solve the build errors.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
I'm trying to build a perl package which requires mod_perl in rawhide,
and I'm getting this error in root.log:
DEBUG util.py:257: httpd-mmn = 20120211
DEBUG util.py:257: Error: Package: mod_perl-2.0.5-8.fc18.x86_64 (build)
DEBUG util.py:257: Requires: httpd-mmn = 20051115-x86-64
DEBUG util.py:257: Available: httpd-2.4.1-6.fc18.x86_64 (build)
DEBUG util.py:257: httpd-mmn = 20120211-x86-64
DEBUG util.py:257: httpd-mmn = 20120211
DEBUG util.py:257: You could try using --skip-broken to work around the problem
DEBUG util.py:257: You could try running: rpm -Va --nofiles --nodigest
DEBUG util.py:347: Child returncode was: 1
for the full details).
I also started receiving rawhide (f18) depcheck error reports on another
package I own (mod_pubcookie) related to httpd-mmn. Is this a known
transient problem currently percolating through rawhide, or rather
something worthy of filing a bug ?
An idea found on the summer-coding list, please forward if you have
any idea, comment.
Thanks for the support !
Buddhike Kurera suggested me to write my idea and send it to this mailing list.
I am a functional programming advocate and would like to see Standard
ML projects in Fedora. Both a better infrastructure for the language
and actual projects that are implemented in SML.
For a short introduction why SML would be useful, check my blog entry:
I would add the following: as far as I know, daemons are written in
Python nowadays in Fedora, with a possible rewriting in C if speed and
memory footprint is critical. SML
could do both, as the sml/nj and the polyml compiler has an
interactive loop like
Python for creative programming, but the mlton whole-program
optimizing compiler generates executables with speed comparable to C
object files. It has a mathematical definition so it is easier to
argument about a program than in Python or C.
The first step could be proper packaging for various architectures and
platforms, and cross-compilation for these. mlton, polyml and mosml
has packaging but I did not find packaging for sml/nj.
The next step could be choosing a daemon task to write from scratch or
an existing one to rewrite.
I would appreciate your comments and questions on this.
Buddhike Chandradeepa Kurera(bckurera)
Fedora Ambassador - APAC region
Event Liaison - Design Team
Email: email@example.com | IRC: bckurera
Hello devel list,
a few months ago I expressed my interest in porting the Ubuntu
Software Center to Fedora, integrating the AppStream infrastructure
for application metadata in our repository system.
Unfortunately, for a variety of reasons, since have stalled ever since
and, although experimental Fedora support exists in upstream
software-center sources, no rpm package is available, and neither work
on yum / repodata / pkgdb integration was started.
What is more, I'm now forced to reconsider my occupations and
therefore I must say I'm not interested in working on this, short
term. This may change a few months in the future, but for the time
being I won't be doing any further development work. This means that
I'm not going to propose the feature for F18.
Of course, if any of you wants to volounteer, that would be great
(this feature is still needed, if we want to reach the "greater
public"). All my code is publicy available, and if you need any help
to reach the same point as me (this screenshot ), just contact me
Sorry for not being able to complete this, and thanks a lot for your
time and attention,