As a heads up, we're updating AutoQA to 0.7 today. I'm not expecting
any issues during the update process but no new jobs will be run while
we're updating the production systems. The update process shouldn't
take much more than an hour, maybe two if we hit problems.
If all goes well, you might notice a delay in results being posted to
bodhi. If all doesn't go well, you'll see another email from me.
test-announce mailing list
(Cross Posting both to the Developers and Users List, sent a copy to
Rex Dieter, who I believe is the maintainer for Kmess in the Fedora
Hi, as you might have noticed in the last few days (if you are a kmess user)
the kmess client that ships with Fedora 15 and Fedora 16 was affected by a
bug that won't let the user see it's contact list when connecting into Kmess
just after starting it's session.
I was really annoyed by this bug because I use kmess really often, so I've
looked in the Kmess forums for a patch, downloaded the lastest kmess source
from fedora's repositories and built new RPM's with the patch applied.
Here you can download the final results of my work, so we can update
the kmess delivered from the fedora's official repos:
I'm adding in one tarball the 32 and 64 bit RPM's and SRPMS for my recently
version and also the 32 and 64 bit RPM's and SRPMS for "LibISF-Qt",
a dependency required by the new patched version.
Thanks for your attention,
Have a Nice Day.
Linux User #509052
Twitter: @Jmlevick <http://twitter.com/Jmlevick>
Blogger: Blog Xenode <http://xenodesystems.blogspot.com/>
PGP/GnuPG: E2F5 12FA E1C3 FA58 CF15 8481 B77B 00CA C1E1 0FA7
Xenode Systems - xenodesystems.com <http://www.xenodesystems.com/> - "Conéctate
a Tu Mundo"
Hi, folks. I wanted to let everyone know that I've gone through all the
issues raised in the Fedora 16 QA Retrospective:
and taken action on each item where possible.
For most items I've added a recommendation to the Recommendations
so that section now lists the trac tickets (in most cases) and mailing
list threads relevant to each item. I've also brought forward some
still-outstanding action items from the F15 retrospective, listed under
'Brought forward from Fedora_15_QA_Retrospective' sub-sections within
Here's a list of the specific tasks that are now outstanding in QA trac
as a direct result of the Retrospective: it would be great if people
could volunteer to pick these up. Please, if you'd like to help out,
just assign one of the tickets to yourself and go do it! There are no
hoops to jump through. I'll try and add links in each ticket to the
relevant processes for creating test cases and so on.
"Add EFI data to installation / base results matrices"
"Create and maintain F17 install test plan"
"Create EC2 test cases and integrate into validation matrices"
"Review Fedora 17 feature list and co-ordinate with owners of
significant features to create test plans"
"Cover USB-written images better in installation validation testing"
"Revise upgrade test case set"
There were a couple of items where the action didn't really fit
comfortably into the 'Recommendations' section, so for the record, I'll
list those here:
"adamw - when there are showstoppers in anaconda early we tend to just
sit around and wait for them to get fixed, but without much urgency;
which means we're getting no idea of what bugs are lurking behind the
showstoppers, and we wind up trying to fix a lot of blockers in a small
amount of time once the showstoppers are finally fixed"
"adamw - when we hit an obvious showstopper we tend to focus in on it
exclusively until it's fixed, iterate, and then be surprised when there
are bugs hidden behind it; we should work harder to try and workaround
showstoppers in a way that has as small an impact as possible, and
continue testing, to avoid this problem. e.g. RHBZ #730863 hid behind
RHBZ #729563, but we could have exposed it by
editing /etc/selinux/config in the installed system prior to rebooting
from the installer"
"adamw - need to do more direct personal pinging of maintainers who seem
unresponsive to blockers; some respond when contacted directly but do
not appear to place a high priority on bug reports"
There isn't really any specific action to be taken on these right now,
they're more things to keep in mind while validating F17.
items 5-8 are just notes of what bugs blocked Alpha RC spins, no
specific action was really needed in relation to any of those
"adamw - it wasn't an A+ idea for both rpm maintainers to be on vacation
at the same time, with no cover in place, during a critical freeze
The action I took here was fairly RH-internal, as this is really an RH
staffing issue: I poked Tom Callaway to ask about putting a cover policy
in place for RH-employed maintainers of key Fedora components
"adamw - NFS testing instructions may need to be more precise to avoid
pilot errors, and may need to account for NFSv4 quirks"
This one's pretty much already taken care of, we did tweak the NFS test
cases somewhat during the f16 cycle
"tflink - Maybe it was due to the high number of TC/RC spins that we did
for F16 but it would be awesome to have some more automation around
image generation for testing. I'm not talking about any rel-eng
processes but it would be nice to be able to request generation of a
boot.iso made from custom packages and packages in koji in order to do
testing. I can see this being helpful for test day coordination as well
but there are issues with complexity and hosting so this is a bit of a
"pony list" item."
"tflink - Since qemu/kvm VMs are all legacy BIOS emulation, it would be
awesome to do EFI emulation. There are some projects out there on using
EFI in qemu VMs but it is unknown whether they actually work. Either
way, it might be good to look into them in order to evaluate whether
their use is practical"
These are sort of 'blue sky' ideas from tflink that don't lead to any
immediate action items that anyone could take care of: I'm relying on
him to keep thinking about them and turn them into more concrete
proposals. I don't really want to file open-ended tickets for rough
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
test-announce mailing list
I've got 15 daemons writen in python that run php tasks. When I start
all daemons I see a lot of segfaults in logs.
[137969.485410] php: segfault at 500000018 ip 00000000005910d9
sp 00007fff4160bd90 error 4 in php[400000+2ca000]
[138037.623654] php: segfault at bc072fa35 ip 00000000005910d9
sp 00007fffd0fda110 error 4 in php[400000+2ca000]
[138189.585367] php: segfault at 100007f73 ip 00000000005910d9
sp 00007fffbe262110 error 4 in php[400000+2ca000]
[138447.809834] php general protection ip:5bcc8d
sp:7fff0aeac680 error:0 in php[400000+2ca000]
[138526.771017] php general protection ip:5a1d94
sp:7fffe2e11850 error:0 in php[400000+2ca000]
[139180.948140] php general protection ip:5910d9
sp:7fffd9708f30 error:0 in php[400000+2ca000]
[139476.383179] php general protection ip:5910d9
sp:7fffd3cdd460 error:0 in php[400000+2ca000]
[139485.007395] php: segfault at bc0dcc21c ip 00000000005910d9
sp 00007fffcf113cb0 error 4 in php[400000+2ca000]
[139860.124330] php: segfault at 14 ip 00007f515ba0c7d8 sp
00007fff64d4a2d0 error 4 in ld-2.14.90.so[7f515b9f8000+22000]
[139911.992581] php: segfault at 0 ip 00007fc84670ac34 sp
00007fff40d61168 error 4 in libc-2.14.90.so[7fc84668a000+1aa000]
[140000.293107] php general protection ip:5a1d91
sp:7fff31d74e40 error:0 in php[400000+2ca000]
[140085.313565] php: segfault at 0 ip 00007fbc81bd5c34 sp
00007fffe711a248 error 4 in libc-2.14.90.so[7fbc81b55000+1aa000]
[140120.294446] php general protection ip:5910d9
sp:7ffff74b5020 error:0 in php[400000+2ca000]
[140270.083455] php: segfault at 0 ip 00000000005ac672 sp
00007fff4c80b1f0 error 4 in php[400000+2ca000]
[140274.462653] php: segfault at 4 ip 00000000005bd4e9 sp
00007fff71035ae0 error 4 in php[400000+2ca000]
[140305.552332] php: segfault at 416f6681 ip 00000000005cd749
sp 00007fffdb040c10 error 4 in php[400000+2ca000]
[140343.753005] php general protection ip:5910d9
sp:7fff22a9dc50 error:0 in php[400000+2ca000]
[140386.823934] php general protection ip:5a1d91
sp:7fff3f3b8cf0 error:0 in php[400000+2ca000]
[140396.070389] php: segfault at 69027d11e4 ip 00000000005911be
sp 00007fff2fc46b80 error 4 in php[400000+2ca000]
[140408.000815] php: segfault at 10 ip 00000000005a1d94 sp
00007fffaf578200 error 4 in php[400000+2ca000]
This problem occurs on glibc 2.14.90-19, after downgrade to 2.14.90-14
There is a package in review that allows one to simply run DNSSEC
on the endnode by dynamically reconfiguring the locally running
DNS server. This process is mostly invisible to the user.
What happens is basically the following:
- network manager connects to a new network
- dnssec-triggerd probes to see how clean it is:
- Can we use the DHCP listed DNS servers?
- If not, can we query authoritative servers directly?
- if not, can we use an open resolver on port 443?
- if not, can we use an open resolver on port 443 using
- if not, offer the user to go "insecure" or "cache only"
If the user needs some bogus DNS, eg for a hotspot redirect, it has a
"hotspot" mode where you can briefly allow insecure DNS without putting
it in your cache, then when you have accepted the terms (or paid) you
can reprobe and re-enable DNSSEC.
This works fairly well, though we can still do better on NM integration.
The real question I have is the port 443 resolver. It is surprising how
many hotspots still transparently take (and break) port 53, even after
signon, so the port 443 transport is quite regularly used (eg here in
Canada, with most coffee places like Starbucks and Second Cup). Currently,
there is an open resolver configured by upstream, but they are not able
to handle a "Fedora size" userbase on such a resolver.
Is there infrastructure within the Fedora Project to run some of these
resolvers? I am willing to take on maintenance for those if we do.
Is there infrastructure within the Fedora Community to run some of these
resolvers in an "ntp pool" like way? I can donate a few mbps in Europe,
but have no good resources in North America.
Can we send Fedora users to DNS(SEC) servers operated by third
parties? While security is not much of a concern (DNSSEC is in use for
those domains willing to protect themselves) there is a potential issue
of privacy on the DNS queries.
I would really like to get some feedback on this. Both the software and
the infrastructure questions.
is it possible to update rawhide's xcb-util to the current version which was
released earlier this year?
SONAMES changed so dependent packages will need (at least) a rebuild.
Apparently, when it was released there was some confusion regarding the
splitting of some parts into a seperate repo and the merging of -atom, -aux
and -event into a single library (libxcb-util). A clarifying mail can be found
It would be very nice to get this in in time for F17. As far as I see Mandriva
is packaging it in Cooker. Debian and Ubuntu are also shipping it.
Michal (Nowak), as you're the maintainer, is there any specific reason it
wasn't updated yet? Are there any issues with xcb-util 0.3.8 (or its
dependants) that prevent the new release from going into Fedora until they are
solved? Or is it just that there wasn't enough time yet?
Forwarding with permission for discussions
-------- Original Message --------
Received: by 10.180.100.134 with SMTP id ey6cs329326wib; Fri, 25
Nov 2011 14:22:04 -0800 (PST)
Received: by 10.231.62.75 with SMTP id w11mr547054ibh.6.1322259722787;
Fri, 25 Nov 2011 14:22:02 -0800 (PST)
Received: from bastion.fedoraproject.org (bastion02.fedoraproject.org.
[188.8.131.52]) by mx.google.com with ESMTP id
j8si12626451icn.24.2011.11.25.14.22.02; Fri, 25 Nov 2011 14:22:02
Received-SPF: neutral (google.com: 184.108.40.206 is neither permitted
nor denied by domain of stefano.palazzo(a)gmail.com) client-ip=220.127.116.11;
Authentication-Results: mx.google.com; spf=neutral (google.com:
18.104.22.168 is neither permitted nor denied by domain of
dkim=pass (test mode) header.i=(a)gmail.com
Received: by bastion02.phx2.fedoraproject.org (Postfix) id 0E537402D6;
Fri, 25 Nov 2011 22:22:02 +0000 (UTC)
Received: from mx1.redhat.com (ext-mx14.extmail.prod.ext.phx2.redhat.com
[10.5.110.19]) by bastion02.phx2.fedoraproject.org (Postfix) with ESMTP
id BF9AF4025F for <sundaram(a)fedoraproject.org>; Fri, 25 Nov 2011
22:22:01 +0000 (UTC)
Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com
[22.214.171.124]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id
pAPMM0t9022906 for <sundaram(a)fedoraproject.org>; Fri, 25 Nov 2011
Received: by vbbfa15 with SMTP id fa15so4031579vbb.41 for
<sundaram(a)fedoraproject.org>; Fri, 25 Nov 2011 14:22:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
Received: by 10.52.92.70 with SMTP id ck6mr12328803vdb.61.1322259720160;
Fri, 25 Nov 2011 14:22:00 -0800 (PST)
Received: by 10.220.184.67 with HTTP; Fri, 25 Nov 2011 14:21:39 -0800 (PST)
From: Stefano Palazzo <stefano-palazzo(a)ubuntu.com>
Date: Fri, 25 Nov 2011 23:21:39 +0100
Subject: Ask Fedora
Content-Type: multipart/alternative; boundary=20cf307f308aebc4cd04b296946c
X-Scanned-By: MIMEDefang 2.68 on 10.5.110.19
I'm a community moderator at Ask Ubuntu. And I was talking to some people
about what mistakes we think Ask Fedora and Ask Debian have made, so I
thought I'd give you some feedback.
You should take it for what it's worth. It's just my opinion, but it's
worked for us. I will also be blunt, excuse me if it sounds a bit preachy.
- First things first: elect moderators. This is essential if you're going
to have any rules at all. The vast majority of closed questions on Ask
Ubuntu required moderator intervention at some point.
We are quite busy, mostly doing things the community can't do.
- Set up a meta site. You're going to need it eventually, and it will
encourage a discussion among the community about how this site ought to be
run. Without that discussion, you have no idea whether people are happy or
not, and you'll miss a great deal of good ideas.
- Get rid of the country's flag next to the username. It's a distraction,
and there's no reason to have it. Some users *will* have prejudice, the
rest won't care.
- Be *very* strict about enforcing these rules:
- Close questions that are duplicates
- " off topic
- " not a good fit for the Q&A format (discussions)
- " overly broad (including anything starting with "Why..")
- " too localised (most of these will be bug reports)
And prominently include them in your FAQ.
- Encourage (even enforce) titles that are indeed questions, not 'forum
"ATI/INTEL Switchable Graphics issue" → "How can I
enable switchable graphics?"
- Be very strict about tags. Delete as many tags as you can. In particular:
- Delete tags that don't make sense if used alone
- Delete tags that are superfluous (such as "fedora", "error")
- Discourage tags that can be described in terms of other tags (grub2 →
grub → boot)
You have far too many different tags for the number of questions and
- Get the full fedora branding. It helps getting new users to stay on the
- Encourage users to vote (up *and* down). The Q&A format fails without
- Discourage use of signatures and taglines. It's needless clutter,
obfuscating the content. Posts are already signed with "user cards".
- Discourage (i.e. close) questions about the next, unreleased version of
Fedora. They are typically about issues that will be fixed within a week,
and they don't help to *build a resource on the internet*, even if they
help someone short term.
- Who is this site for?
Ideally, your site should be for people searching on Google. 95% of
readers will never create an account, and every decision should be made
with them in mind.
If you think I can help you in any way, just send an email. If you think
I'm just talking nonsense, send an email anyway. ;-) By the way: It's
fantastic to see a Q&A site for Fedora users. And long overdue.
PS: I understand you run Ask Fedora. I'm sending this email directly to you
because the feedback form seems to be broken. My apologies if you got three
of them. If somehow I've reached the wrong person altogether, please let me
know whom I should contact, or simply forward this email to them. Thank you.
PPS: I neither represent Canonical nor Stack Exchange.