#436: SSH access to systems in Beaker lab
--------------------------------------+---------------------
Reporter: atodorov | Owner: tflink
Type: defect | Status: new
Priority: major | Milestone:
Component: Blocker bug tracker page | Version:
Keywords: | Blocked By:
Blocking: |
--------------------------------------+---------------------
= bug description =
Currently systems in Beaker lab can be accessed only through bastion.fp.o
which is not as convenient as direct SSH into the system.
There's also the question whether or not to open the systems directly to
the Internet.
This needs to be discussed with infra. Filing here so it doesn't get lost.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/436>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
#443: Better format for test compose (TC) and release candidate (RC) requests
----------------------------------------+------------------------
Reporter: jreznik | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: Fedora 21
Component: Blocker/NTH review process | Version:
Keywords: | Blocked By:
Blocking: |
----------------------------------------+------------------------
= problem =
With Dennis (in CC), we discussed how to make release process, with
Fedora.next in mind, more transparent and bullet proof. One issue is that
releng request can become pretty messy, with full text included and
sometimes it leads to errors (omission of packages in compose etc).
= enhancement recommendation =
One possibility is to visibly separate full text description (with bug
numbers, reasons - it's good to have history) and the list of exact nvrs
(maybe in code block?), try to avoid "qt bundle" etc. so it's easier to
pick up the right list (for blockers, FEs + exceptional tools requests).
Another thing is better coordination between requester/releng - to mark
when/which list was picked up etc, in similar way how Go/No-Go decision is
stated in the ticket.
Now I'll let more space to Dennis, maybe example of how the request should
look like to make it easy to parse would help.
Long term (and preferred) solution would be to have automation in place,
Blocker app talking to releng interface, compose database, web dashboard
etc...
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/443>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
#437: Need to import daily Fedora snapshots into Beaker
--------------------------------------+---------------------
Reporter: atodorov | Owner: tflink
Type: task | Status: new
Priority: major | Milestone:
Component: Blocker bug tracker page | Version:
Keywords: | Blocked By:
Blocking: |
--------------------------------------+---------------------
= bug description =
In order to perform any meaningfull testing Beaker needs to import more
recent Fedora trees. It could be daily(nightly) snapshots or less often
depending on available resources.
The tree directory structure needs to be a copy/snapshot of the current
state at the time of import. The reason is b/c devel trees utilize one URL
but the contents under this URL are updated in a rolling fashion. We need
tree URLs where content is not changing in order to produce consistent
test results.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/437>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
#433: blocker proposal form forgets everything after login timeout
--------------------------------------+---------------------
Reporter: kvolny | Owner: tflink
Type: defect | Status: new
Priority: major | Milestone:
Component: Blocker bug tracker page | Version:
Keywords: | Blocked By:
Blocking: |
--------------------------------------+---------------------
= bug description =
I was trying to propose a F20 blocker. I needed to gather information from
multiple bugs, so it took me longer to write the justification. After
finishing and submitting that, I was presented with a login screen. After
logging in again, I was redirected to the proposal form again, but it was
completely empty, all the text that took me so long to write was gone.
(Okay, I'm a smart guy and I had it in clipboard for such case, but if I
had forgotten ... booh.)
= bug analysis =
Seems the login code doesn't care about other variables in the http
request ...
= fix recommendation =
1) If there is such a short login timeout, the user should be warned about
it (e.g. countdown timer on the page) and the page should allow refresh
without submitting the data.
2) Once the login expires, the submitted data should be caried over all
the redirects back to the submission form.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/433>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
Hi there,
I used the blockerbugs application at https://qa.fedoraproject.org/blockerbugs/propose_bug but found that this is restricted to the primary arch releases.
Could it be possible to have it improved to support secondary arch releases (ppc64, s390, ...) ?
--
Michel Normand
On Tue, Nov 18, 2014 at 08:23:38PM -0500, Scott Talbert wrote:
> On Thu, 6 Nov 2014, Petr Pisar wrote:
>
> >>>As far as I know alternative-architecture multi-lib packages are
> >>>distributed in the same repository as packages for the main
> >>>architectue. E.g. glibc-devel.i686 is in x86_64 repository, hence
> >>>glibc-devel is mutlilib. glibc-headers.i686 is not in the the x86_64,
> >>>hence glibc-headers is not multi-lib.
> >>
> >>Yeah, but the thing that's bugging me about this now that I'm digging
> >>into it more is that miniz-devel.i686 is installable on f20 via dnf and
> >>yum.
> >>
> >I sent a question why miniz is flagged as multi-lib to the
> ><rel-eng(a)lists.fedoraproject.org> and it's waiting on the moderator now. Once
> >it propagates, I will take down a pointer here.
>
> Did you ever find out why miniz was flagged as multi-lib?
>
No. I sent on November 6th an e-mail to rel-eng mailing list, got a message it
waits for a moderator and then no reply. Obviously the Fedora's one-man
rel-eng team does not manage the mailing list.
However I got similar QA check report
<https://taskotron.fedoraproject.org/taskmaster//builders/x86_64/builds/1327…>
for pcre
<https://admin.fedoraproject.org/updates/FEDORA-2014-14639/pcre-8.35-7.fc21>
which never happened before.
I remember from talks with RHEL rel-engs that they mark all '*-devel' packages
as multi-lib just based on the package name. And then they have a lot of
exception hard-coded into the mashing script. So I guess similar situation is
in the Fedora too and that the script is just erroneous in same cases. And
that it's not in line the packaging guidelines which explicitly require that
any *-devel package must require specific architecture.
If the QA check bothers you I would recommend to raise this issue to FESCo.
-- Petr
Hi,
Can someone please help me with a depcheck question? See this log file
for the package 'miniz':
https://taskotron.fedoraproject.org/taskmaster//builders/x86_64/builds/6954…
As best I as I can tell, the depcheck is failing because there is no
32-bit glibc-headers package in the x86_64 repository. But do we care
because miniz 32-bit package won't be in the x86_64 repository either?
Thanks,
Scott
# Fedora QA Devel Meeting
# Date: 2014-11-03
# Time: 15:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting-1 on irc.freenode.net
It's been a while since we've done this and even though it looks like
F21 final testing is going to start right up this week, it'll be good
to at least sync up on what's going on even though I suspect that most
folks will be back on the validation treadmill.
If you have agenda items to add, feel free to respond to this thread
or bring them up during open floor.
Tim
Proposed Agenda
===============
Status Updates
--------------
- Disposable Clients
- Remote Logging
- ExecDB
- Depcheck
Upcoming Potential Stuff
------------------------
- Bodhi2
- Gating builds/updates on automated results
- Blockerbugs Enhancements?
- Project Ideas
* Better Metrics
* Upstream Contributions?
Iteration 7
-----------
- https://phab.qadevel.cloud.fedoraproject.org/w/taskotron-7/
Open Floor