Re: orphaning Taskotron-related packages

On Wed, Nov 25, 2020 at 2:29 PM Josef Skladanka wrote: > > Orphaning python-mongoquery and retiring everything else makes sense to > > me. > > > > Tim > > +1 > OK, I'll make it happen. ___ qa-devel mailing list -- qa-devel@lists.fedoraproject.org To

Re: orphaning Taskotron-related packages

On Mon, Nov 16, 2020 at 8:27 AM František Zatloukal wrote: > The "correct" way to do this is to use orphaning procedure. This way, > anybody interested will have enough time to take over the to-be removed > packages. > "When Fedora maintainers do not want or are not able to maintain a package

Re: orphaning Taskotron-related packages

Note: The email subject should have said "retiring" instead of "orphaning". There is little reason to orphan them, retiring is the right approach here. Perhaps except for mongoquery, somebody else could be interested in maintaining that, so that one should be orphaned instead.

orphaning Taskotron-related packages

Hello, our Taskotron-related repositories (with exceptions like resultsdb) have been marked as EOL and archived more than half a year ago. I believe it's time to also tidy up our rpm packages in Fedora. Looking at our group ownership [1] I have identified the following rpms which could be

Re: current maintainer of lmbench3

On Sun, Nov 1, 2020 at 9:53 PM Ryan Kosta wrote: > Dear QA tool development, > > During this week's kernel testday, I encountered a few interesting > compilation errors with lmbench. Nothing to warrent major concern but > their was a variable or two that had the wrong types, enough to offer a >

Re: Poor first time experience for potential contributors interested in release validation

On Thu, Aug 6, 2020 at 5:16 AM Jonathan Watt wrote: > I originally reported this issue at > https://bugzilla.redhat.com/show_bug.cgi?id=1862703 but was asked to > re-report it here: > > I was using whatcanidoforfedora.org to see what areas I could contribute > to. I selected "Validate Releases"

Re: delete fedora-qa/qa-ansible project?

On Mon, May 4, 2020 at 12:10 PM Kamil Paral wrote: > Hello, > Fedora Infra Ansible is now available on Pagure [1], which means people > can finally submit and review pull requests. That means we no longer have a > use case for our own fedora-qa/qa-ansible mirror [2], which we

delete fedora-qa/qa-ansible project?

Hello, Fedora Infra Ansible is now available on Pagure [1], which means people can finally submit and review pull requests. That means we no longer have a use case for our own fedora-qa/qa-ansible mirror [2], which we created just for the purpose of easily reviewing our PRs to Fedora Infra

Re: seeing issues querying results by nvr/item in resultsdb

On Thu, Apr 9, 2020 at 12:46 AM Tim Flink wrote: > I'm working on something that looks for certain results in resultsdb > and I'm getting some strange results. I'm hoping someone here can point > out what I'm doing wrong. > > I'm hitting an issue where the data I'm getting back from resultsdb

Re: Git forge requirements discussion

On Wed, Feb 12, 2020 at 10:35 AM Kamil Paral wrote: > On Tue, Feb 11, 2020 at 10:42 PM Ben Cotton wrote: > >> On Tue, Feb 11, 2020 at 4:37 PM Matthew Miller >> wrote: >> > >> > Can you put the voting/polls idea in the form of a user story? >>

Re: Git forge requirements discussion

On Tue, Feb 11, 2020 at 10:42 PM Ben Cotton wrote: > On Tue, Feb 11, 2020 at 4:37 PM Matthew Miller > wrote: > > > > Can you put the voting/polls idea in the form of a user story? > > > I think #44 on the list I sent covers that: > As a Fedora team member, I can vote +1/abstain/-1 on issues so

Re: Git forge requirements discussion

On Wed, Jan 22, 2020 at 10:00 AM Adam Williamson wrote: > Hey folks! > > There's a post on the Community Blog: > > https://communityblog.fedoraproject.org/git-forge-requirements > > and a thread on devel@: > > >

upgrade your libtaskotron virtualenv to python3

Hi taskotron developers, we've recently switched to using python3 by default in libtaskotron and all taskotron tasks. So if you have your local virtualenv to be used with libtaskotron, I suggest you re-create it with python3 [1] instead of python2, because that's how libtaskotron is going to get

Re: Please update rpmlint on taskotron

On Mon, Jul 9, 2018 at 2:40 PM, Miro Hrončok wrote: > All Python 3 packages now get bytceode related errors with Python 3.7. > > See for example https://taskotron.fedoraprojec > t.org/artifacts/all/7653ca56-8370-11e8-bbcf-525400fc9f92/ > tests.yml/python-libsass-0.14.5-1.fc29.log > > rpmlint was

Re: git clone ... Permission denied

On Tue, Apr 17, 2018 at 2:36 PM, Normand wrote: > Since today, I have a problem accessing the openqa git tree from pagure. > I do not understand what I am doing wrong. > > any suggestion ? > > === > $git clone -v

Re: qa-ansible - repo for PRs against fedora infra ansible

On Wed, Feb 21, 2018 at 7:49 PM, Kevin Fenzi <ke...@scrye.com> wrote: > On 02/21/2018 05:54 AM, Kamil Paral wrote: > > Hello, > > > > I've created a new project and cloned all Fedora Infra ansible into it: > > https://pagure.io/fedora-qa/qa-ansible > > >

qa-ansible - repo for PRs against fedora infra ansible

Hello, I've created a new project and cloned all Fedora Infra ansible into it: https://pagure.io/fedora-qa/qa-ansible The idea is to have a repo against which we can create a PR and review it comfortably. Once reviewed, the patch of course needs to go to the real infra ansible repo. But this

Re: Making ResultsDB dumps public?

On Mon, Jan 15, 2018 at 3:25 PM, Tim Flink <tfl...@redhat.com> wrote: > On Sun, 14 Jan 2018 14:19:54 -0800 > Kevin Fenzi <ke...@scrye.com> wrote: > > > On 01/11/2018 07:44 AM, Kamil Paral wrote: > > > On Wed, Nov 1, 2017 at 7:48 PM, Kevin Fenzi <ke...@

Re: 2017-10-16 @ 14:00 UTC - Fedora QA Devel Meeting

Dne 16. 10. 2017 6:36 napsal uživatel "Tim Flink" : # Fedora QA Devel Meeting # Date: 2017-10-16 # Time: 14:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting-1 on irc.freenode.net https://fedoraproject.org/wiki/QA:Qadevel-20171016 If

Re: Need help ?

On Fri, Sep 1, 2017 at 10:57 PM, Ellen OSullivan wrote: > I'm a newbie, would like to help out with something. I'm dev/qa > automation at work but fairly new to Linux. Willing to clean the floors, > make the coffee :-) > Hi Ellen, if you familiarize yourself with testing

Re: Upcoming changes for rpmgrill

On Thu, Aug 31, 2017 at 1:05 AM, Róman Joost wrote: > Heya, > > just wanted to give everyone a heads up for some of the upcoming changes > in a new rpmgrill release. > > The rpmgrill tool now exits with an exit code of 1 in case of test > failures, 0 if all tests ran

Re: Deprecating rpmgrill-fetch-build and rpmgrill-analyze-local

On Wed, Aug 23, 2017 at 9:00 AM, Róman Joost wrote: > Hi, > > The rpmgrill tool ships with two commands which I think can be > deprecated: > > rpmgrill-fetch-build in favour of `koji download-task` > rpmgrill-analyze-local in favour of rpmgrill-unpack; rpmgrill

Re: Outdated clamav database in Taskotron

> > > > So maybe the ClamAV definitions should be treated similarly? In > > > a separate package which gets updated on a regular interval to pull in > > > the latest data? > > > > > > > That would be the best solution here, yes. Could someone please file an > RFE > > against clamav? > Done: > >

Re: Outdated clamav database in Taskotron

On Wed, Aug 2, 2017 at 2:44 AM, Dan Callaghan <dcall...@redhat.com> wrote: > Excerpts from Róman Joost's message of 2017-08-02 10:18 +10:00: > > Dear Petr, > > > > On Tue, Aug 01, 2017 at 01:05:34PM +0200, Petr Pisar wrote: > > > On Tue, Aug 01, 2017 at

all projects moved to pagure

Hello, we've moved all our projects from bitbucket (and github, in case of testcloud) to pagure. You'll need to update the remote sources for (or re-clone) all projects that you have checked out and were hosted outside of pagure. You can find the new locations of our projects in this list:

Taskotron: depcheck task replaced by rpmdeplint

If you are a Fedora packager, you might be interested to know that in Taskotron we replaced the depcheck task with rpmdeplint task.

Re: 2017-04-24 @ 15:00 UTC - Fedora QA Devel Meeting

On Mon, Apr 24, 2017 at 7:06 AM, Tim Flink wrote: > # Fedora QA Devel Meeting > # Date: 2017-04-24 > # Time: 14:00 UTC > (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) > # Location: #fedora-meeting-1 on irc.freenode.net I won't be around today, sorry.

Re: Re-Scheduling Jobs for Taskotron as a User

On Tue, Apr 18, 2017 at 2:35 PM, Tim Flink wrote: > One of the things that seems like it is and will be a pain point for > folks writing package-specific tasks is how to work through the times > when there was an issue in the task and things didn't run well. At the > moment,

Re: per-arch tasks strategy in Taskotron

> Getting ppc64 or ppc64le machines should be only matter of filling a > ticket with fedora infra, these arches are part of the fedora cloud. > aarch64 is going to added soon. Thanks for info. The problem is not that much in having hardware (I think), but in preparing tailored disk images for

Re: per-arch tasks strategy in Taskotron

> Hello, > > I want to consult our current strategy regarding per-arch tasks. We currently > have no such tasks, all of them are generic (they can run on any host system > and test any single or multiple item arches). I want to convert > task-rpmdeplint [1] to arch-specific, to avoid a race

per-arch tasks strategy in Taskotron

Hello, I want to consult our current strategy regarding per-arch tasks. We currently have no such tasks, all of them are generic (they can run on any host system and test any single or multiple item arches). I want to convert task-rpmdeplint [1] to arch-specific, to avoid a race condition [2].

Re: New automated test coverage: openQA tests of critical path updates

> On Thu, 2017-03-02 at 04:31 -0500, Kamil Paral wrote: > > > The job can - and already does - log the exact packages it actually > > > got, but I don't think there's an easy way for it to take the > > > 'last_modified' date for the update at the time it does the d

Re: New automated test coverage: openQA tests of critical path updates

> > There's one important thing we need to do first, though. Bodhi ID > > doesn't identify the thing tested uniquely, because Bodhi updates are > > mutable (and the ID is kept). So Bodhi (or any gating tools) can't > > rely on just retrieving the latest result for a particular Bodhi ID > > and

Re: New automated test coverage: openQA tests of critical path updates

> Hi folks! > > I am currently rolling out some changes to the Fedora openQA deployment > which enable a new testing workflow. From now on, a subset of openQA > tests should be run automatically on every critpath update, both on > initial submission and on any edit of the update. > > For the

Re: Trigger changes - call for comments

> Hey, gang! > As with the ExecDB, I took some time to try and formalize what I think is to > be done with Trigger in the near-ish future. > Since it came to my attention, that the internal G-Docs can not be accessed > outside of RH, this time, it is shared from my personal account - hopefully >

Re: Taskotron CI in Taskotron

> So, the repo now has working PoC > https://pagure.io/taskotron/task-taskotron-ci > Readme contains example on how to run the task. > Works on my setup, and I'd be glad if somebody else tried. I tried, and it didn't eat my laptop. Also it worked. Good job. /me throws cookies at jskladan

Re: Taskotron CI in Taskotron

> On Tue, 2017-02-14 at 14:46 -0500, Kamil Paral wrote: > > > The only problem with this kind of testing is, that we still don't really > > > have a good way to test trigger, as it is tied to external events. My > > > idea > > > here was that I coul

Re: Taskotron CI in Taskotron

> The only problem with this kind of testing is, that we still don't really > have a good way to test trigger, as it is tied to external events. My idea > here was that I could add something like wiki edit consumer, and trigger > tasks off of that, making that one "triggering" edit from inside the

Re: Libtaskotron - allow non-cli data input

> On Wed, Feb 8, 2017 at 2:26 PM, Kamil Paral < kpa...@redhat.com > wrote: > > > This is what I meant - keeping item as is, but being able to pass another > > > structure to the formula, which can then be used from it. I'd still like > > > to > > >

Re: making test suites work the same way

> Well, after more discussions with kparal, we are still unsure about the > "right" way to tackle this. > Our current call would be: > 1) sync requirements.txt versions with fedora (mostly done) > 2) allow --system-site-packages in the test_env > 3) do `pip install -r requirements.txt` (with

welcome Fedora Quality Planet

Hello, I've set up a Quality sub-planet for Fedora Planet, available here: http://fedoraplanet.org/quality/ The purpose is to have a single place where people can read and subscribe to quality-related news and information. Here's an introductory blogpost with more details and instructions how

Re: Proposal: Migrating More Git Projects to Pagure

> This came up in the qadevel meeting today and I wanted to put a bit > more detail out. > > Bitbucket was never intended to be the long-term home for our git > projects - I think we're about the only folks in Fedora using it and > it's not free software. As fedorahosted is closed down, we need

Re: Enabling running Taskotron tasks on Koji scratch builds

> Couldn't we use the task ID as the primary identifier but use the srpm > for readability sake since there is no "build" NVR for scratch builds? Systems like new hotness will need to query according to the task ID, though (to get reliable results). So we're talking about hacking just resultsdb

Re: Please Test Staging Phabricator

> > For a start Ipsilon tells me it's some entirely foreign third-party > > domain - 'monikra.me' - that wants access to all my personal > > information, which is a bit unsettling. I went ahead and let it have > > it (For Science!) and got: > > FWIW, monikra.me is a service that puiterwijk made

autoqa migrated to pagure

I moved autoqa (yes, autoqa) from fedorahosted to pagure: https://pagure.io/fedora-qa/autoqa Wiki pages are exported in wiki/ directory. Just in case somebody would need it some day :-) Cheers, Kamil ___ qa-devel mailing list --

Re: stats-bodhi license

> On Thu, 2016-11-03 at 14:41 -0700, Adam Williamson wrote: > > I'm back working on moving fedora-qa to Pagure. I'm now dealing with > > the 'stats' scripts, and there's a problem: it appears that stats-bodhi > > has never actually been properly licensed. It has no license header or > > license

Re: Proposal to move things from fedora-qa.git to Pagure

> OK, this is all done now, and fedora-qa.git is a mere empty shell with > a MOVED.md text file. End of an era! Thanks, Adam. ___ qa-devel mailing list -- qa-devel@lists.fedoraproject.org To unsubscribe send an email to

Re: New ExecDB

> On Tue, Oct 11, 2016 at 1:14 PM, Kamil Paral < kpa...@redhat.com > wrote: > > > Proposal looks good to me, I don't have any strong objections. > > > > > > 1. If you don't like blame: UNIVERSE, why not use blame: TESTBENCH? > > > > > >

Re: New ExecDB

> Proposal looks good to me, I don't have any strong objections. > 1. If you don't like blame: UNIVERSE, why not use blame: TESTBENCH? > 2. I think that having enum values in details in crash structure would be > better, but I don't have strong opinion either way. For consistency checking, yes.

Re: New ExecDB

> With ResultsDB and Trigger rewrite done, I'd like to get started on ExecDB. > The current ExecDB is more of a tech-preview, that was to show that it's > possible to consume the push notifications from Buildbot. The thing is, that > the code doing it is quite a mess (mostly because the

Re: Resultsdb v2.0 - API docs

> On Tue, Sep 27, 2016 at 6:06 PM, Kamil Paral < kpa...@redhat.com > wrote: > > ... > > > What are the use cases? I can think of one - yesterday Adam mentioned he > > would like to save manual test results into resultsdb (using a frontend). > > That

Re: What to do with fedora-qa (fedorahosted is dying)

> > Phabricator works well with remote repos, and I don't think there's > > any strong advantage in using local Phab repos. On Pagure we will get > > more visibility for the projects, easy forking, etc. Also certain > > simple repos (like the one above) can be completely fine with Pagure > > issue

Re: What to do with fedora-qa (fedorahosted is dying)

> We still have a few miscellaneous things hosted in: > > https://git.fedorahosted.org/cgit/fedora-qa.git > > since fedorahosted is dying next February, what should we do with them? Move to Pagure. I can do it right away if nobody objects, I've already set up a group:

Re: RFC: URLs for docs and released bits from CI

> > I submitted a revision today which makes some slight modification to > > how the doit.py script is building docs, rpms and tarballs. > > > > https://phab.qadevel.cloud.fedoraproject.org/D1012 > > > > My intention is to get this deployed to a non-staging setup soon but I > > wanted to reach

Re: 2016-09-14 @ 14:00 UTC - QA Tools Video "Standup" Meeting

> # QA Tools Video "Standup" Meeting > # Date: 2016-09-14 > # Time: 14:00 UTC > (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) > # Location: https://bluejeans.com/2509415264 > > One discussion that came up after Flock was that doing a video meeting > would be worth trying to see how it

Re: "500 Internal Server Error" when trying to submit a new blocker bug

> > Whenever I'm trying to submit a new blocker bug¹, I'm getting a HTTP 500 > > status code error page. I've tried these browsers: > > * one recent release of Firefox (heavily configured) > > * one vanilla Fedora Firefox release > > * one Firefox LTS based release > > > > With all of these I'm

Re: "500 Internal Server Error" when trying to submit a new blocker bug

> Whenever I'm trying to submit a new blocker bug¹, I'm getting a HTTP 500 > status code error page. I've tried these browsers: > * one recent release of Firefox (heavily configured) > * one vanilla Fedora Firefox release > * one Firefox LTS based release > > With all of these I'm getting the

libtaskotron: new mock needed to run the test suite

Please note I've bumped the requirements for mock in libtaskotron and removed some workarounds we had for bugs in the older version. Please make sure to run $ git pull $ pip install -r requirements.txt otherwise the test suite might not pass for you the next time you run it and the errors are

Re: rpmgrill in taskotron

> Hey Ralph (ccing qa-devel), > > just to let you know, I added some code to Koji directive to download build > logs. The patch is posted here: > https://phab.qadevel.cloud.fedoraproject.org/D916 > (you can use 'arch patch D916' to apply the diff in your libtaskotron > checkout) > > The

rpmgrill in taskotron

Hey Ralph (ccing qa-devel), just to let you know, I added some code to Koji directive to download build logs. The patch is posted here: https://phab.qadevel.cloud.fedoraproject.org/D916 (you can use 'arch patch D916' to apply the diff in your libtaskotron checkout) The corresponding changes for

Re: Task Result Namespaces

> > > Now, since we maintain task-dockerautotest, it should go into > > > qa.*, > > > > Agreed. Once we have dist-git checks implemented, we can ask docker > > maintainers to keep it and maintain it in their repo. If they don't > > want, we can keep it in our domain (same as anyone will be able

Re: Task Result Namespaces

> Hi, > > we have deployed task result namespaces support a while ago and put > our checks (depcheck, upgradepath, rpmlint) into the 'qa' namespace. > With newly added tasks like task-abicheck and task-dockerautotest, > we weren't sure where to put them and so we used the scratch > namespace

Re: Automatic ABI checks for new package updates in bodhi using taskotron

> > Speaking of lists, you and Tim were mentioning white/blacklists, also > > critpath set. So what is the ideal set of packages we should run on > > initially? All packages? Only critpath packages? Only libraries included > > in critpath? In case we should run just on libraries, any good > >

Re: Automatic ABI checks for new package updates in bodhi using taskotron

> Hello Kamil, > > Sorry for replying late. I subscribed to this list, but for a reason the > emails are still not being delivered to me. I clicked on some more buttons > in the interface right now, so we'll see. In the mean time, I am using the > web interface to reply, so please forgive the

Re: Automatic ABI checks for new package updates in bodhi using taskotron

> Thanks for the quick review. I have addressed review comments and added new > diff at https://phab.qadevel.cloud.fedoraproject.org/D817?id=2081 . Thanks, looks good. I have no further concerns regarding the task code. > I am not > sure if I updated diff in right way but this is what I ended

Re: Automatic ABI checks for new package updates in bodhi using taskotron

Hi Sinny, I have created a review here: https://phab.qadevel.cloud.fedoraproject.org/D813 I used our Phabricator, because it makes it easy to comment on particular lines. You can log in using your FAS email [1] and reply there, or here in the mailing list, it doesn't matter. I'm pleasantly

Re: Automatic ABI checks for new package updates in bodhi using taskotron

> Hi all, > Last year, discussion happened around "Checking the ABI of packages submitted > to the updates-testing Fedora repository" on Fedora devel ML [1]. > We felt that taskotron[2] will be the best place to run automatic ABI checks > for a new package update pushed in bodhi for testing

Re: Workboards and Sprints

> On Tue, 23 Feb 2016 14:44:14 -0700 > Tim Flink wrote: > > After the qadevel meeting today and trying it out in staging, I'm > moving forward with a plan that nobody has rejected and I'm choosing to > believe that means folks are OK with it :) > > This means that I'm going

Re: 2016-02-29 @ 15:00 UTC - Fedora QA Devel Meeting

The same applies to me today, sorry, can't make it. Top posting for consistency, as Josef says :) - Original Message - > Sorry, but I have some errands today (again) and I won't be able to attend. > 2016-02-29 6:52 GMT+01:00 Tim Flink < tfl...@redhat.com > : > > # Fedora QA Devel

Re: 2016-02-22 @ 15:00 UTC - Fedora QA Devel Meeting

> # Fedora QA Devel Meeting > # Date: 2016-02-22 > # Time: 15:00 UTC > (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) > # Location: #fedora-meeting-1 on irc.freenode.net Sorry, I won't attend the meeting today, I have an important errand in the city.

Re: Example Suggestions for Automation Workshop

> I'm preparing for an automation workshop at DevConf in February and I'm > trying to think of good example cases to show off what Taskotron can do. > > At the moment, I figure that I'll do at least 1 easy task and 1 not so > easy but not crazy task. > > Rpmlint is usually my go-to for a

Re: Building Images for Taskotron Disposable Clients

> As we get closer to putting disposable clients into production, we need > a way to have updated images for those clients. I don't think this is > news to anyone since the topic has come up several times before but now > there's a bit more urgency :) > > In my mind, we have the following

Re: Building Images for Taskotron Disposable Clients

> My vote would be for imagefactory. In my mind, it comes down to the blob > vs. from-scratch thing, using the same tools that releng does and the > fact that imagefactory is completely written in python. > > Whether we use the API or not is a different question, though :) I think both tools are

Re: Building Images for Taskotron Disposable Clients

> > > - may not run well in a VM (would need nested virt) > > > > This is the same as in virt-builder, it also needs virt support. > > Originally I thought it doesn't, but it does. It can still be used > > without hw virt support (unlike anaconda, that would just be > > impossible

Re: openQA in infra

> so we can run openQA in Ze Cloud, with KVM, and it can work and > complete a test. What's Ze Cloud? Is it using nested virt? We might also want to use nested virt in Taskotron, I'm very interested in any issues related to it you run into. ___

Re: openQA in infra

> > so we can run openQA in Ze Cloud, with KVM, and it can work and > > complete a test. > > What's Ze Cloud? Now I know, you fake French! ___ qa-devel mailing list qa-devel@lists.fedoraproject.org

Re: 2015-07-22 @ 21:00 - Taskotron Outage and qadevel Migration

It took significantly longer than I was hoping but Taskotron dev/stg/prod has been updated and qadevel has been migrated to a new machine. There should be no big changes here, everything user-facing should be business as usual. Please let me know if you notice something not quite working

Weak dependencies come to Fedora

Not sure if you noticed, but this can possibly affect some of our tools or workflows, so I wanted to highlight it - it seems that weak dependencies are now approved in Fedora: http://fedoramagazine.org/5tftw-2015-07-09/ https://fedoraproject.org/wiki/Packaging:WeakDependencies We now have 4

Re: openQA vs. Rawhide

There's a neat GTK+ debugging thing called the GtkInspector which you can launch from any GTK+ 3 app with shift+ctrl+D. From that you can Or Ctrl+Shift+I, if you find that easier to remember (I as inspector) :-) look at Properties then GtkSettings, and look at the gtk-xft-* settings. I

Re: Coding Style

After the meeting earlier today, I wanted to make a slightly different proposal. - if flake8 config in arcanist can be so configured, set max line width to 120 instead of 79 On my 1920px monitor, two windows with 100 columns fit perfectly next to each other (11px font). Is there a

Re: Coding Style

First of all I'd suggest to move our codebase to strict PEP8 (or as-strict-as-possible), so we can have see how our code looks like, when PEP8 compliant. For starters, we could just plain use autopep8 - https://pypi.python.org/pypi/autopep8/ How about that? For the record, Josef put up the

Re: Coding Style

Back to everyone's favorite topic - coding style and enforcement of that style. And I thought we were doing so great by leaving it behind... I'm not picking on Josef here - I'm sure I've submitted code recently with lint errors, this was just the review I was looking at which

Re: Fedmsg Emitting

We talked with Martin about this in length some time ago, and I raised the question of different consumers. I see two groups here - machines and humans. If I understand you correctly, what you propose up there is to hardcode the system to fit human preferences. If I misunderstood it,

Re: Fedmsg Emitting

Before we start sending fedmsgs we need to discuss a few things. We don't have to find solutions to all these problems, just keep them in mind when designing the solution we're going to start with: 1. How often do we send fedmsg a) per-task b) per-update c) per-build ... That

watching projects in Phabricator, Herald rules simplified

Hello everyone, in the last week I've spent a bit of time investigating the possibilities of how to watch for ticket/revision updates in Phabricator, and found out that some new features in Phab greatly simplify this. I have updated our Phab wiki page and included most common use cases:

Re: To RHEL or Not to RHEL?

* Will need to be more diligent about keeping dev/stg on updates-testing so that we don't get any nasty surprises in production I don't have much advice about the other points, but this one caught my attention. Do we really need to use updates-testing for dev/stg? That might be quite

Re: CI for Taskotron and Related Projects

I've just re-started the CI on qadevel (the future one, not cloud) that mkrizek set up a while back. It was destroyed when I started working on replacing qadevel.cloud but never finished it. The link is: https://qadevel.fedoraproject.org/buildmaster/waterfall Great. Just to refresh my

Re: new project: taskotron-vmbuilder

On Wed, 2015-04-29 at 11:21 -0400, Kamil Paral wrote: I still haven't created project and repo in Phab, but if you approve this as a way forward, I will. Just one thought - this could probably be rather useful for openQA too. We already have one case where we want to begin a test

Re: new project: taskotron-vmbuilder

I still haven't created project and repo in Phab, but if you approve this as a way forward, I will. I vote for creating the project and repo in phabricator. Done. PS: I also noticed that our projects were editable by anyone (all users), which didn't seem to me as a great idea, so I

Re: 22 Final TC1 live fail: timeout due to SMP performance bug?

https://bugzilla.redhat.com/show_bug.cgi?id=1210857 , but I see you've found it already. For the time being, it seems that there's no benefit in giving the VMs more than one CPU? Yeah, I think it'd make sense to change the config to one CPU. That's what I use on

Re: Freeze Break Request: Increase execution timeouts in taskotron's buildbot

I'd argue that we do need to get the increased timeout working but that doesn't negate your point about python-yamlish. However, there are two problems: 1. there's no newer python-yamlish package to update to - that's something that I wrote the specfile for and isn't in the fedora

Fwd: Freeze Break Request: Increase execution timeouts in taskotron's buildbot

Just a note - we don't need an increased timeout, if we deploy newer python-yamlish. That could have been done a long time ago, but we forgot to update the spec file, so nobody found out. That's why I tried to fix it in https://phab.qadevel.cloud.fedoraproject.org/D337 . Once that is accepted,

Re: Could we disable AutoQA until it can produce usable results?

Witness (a): https://admin.fedoraproject.org/updates/libguestfs-1.29.31-1.fc22 The log file in this case is 3452 lines long. Witness (b): https://admin.fedoraproject.org/updates/ocaml-camlp4-4.02.0-0.9.git87c6a6b0.fc22 The log file in this case is 3452 lines long (not coincidentally

Re: Exit status for runtask should be 1 if task outcome is FAILED?

That's exactly why I thought about runtask. To be more precise, we're currently working on rpmgrill. It ships it's own fetch-build script which is currently tied to Fedoras Koji. Just a note, IIRC you don't need just all the rpms, but also the build log for certain subtests. That's currently

Re: Exit status for runtask should be 1 if task outcome is FAILED?

Hi, I'd like to enquire if it's desired to let runtask exit with '1' if the task in question has a 'FAILED' outcome. Maybe there was a conscious decision of not providing this feature and I'd like to hear about it. I've joined Taskotron on phabricator. If there are no obvious

libtaskotron: /var/cache/taskotron dir added

Hello, those of you who use libtaskotron from git, please note that libtaskotron now requires one more directory (/var/cache/taskotron) to exist [1]. From now on, you should be notified if you're missing any of the important directories right at 'runtask' execution start (the execution will

Re: testdays is down again

... it's down :( Seems to be working for me. Could you describe down a bit more? :) I've found the issue. It's this: http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security testdays.qa.fedoraproject.org runs only on http, not https. But if you have visited

[dev machines] script for cleaning up temporary taskotron files

Hello, if you use libtaskotron in a developer environment (running some taskotron tasks locally from time to time), there is a new script that will make sure taskotron temporary files will get cleaned up regularly. Look into conf/tmpfiles.d/ in libtaskotron checkout. This will probably get

Re: Coconut failures: use dl.fp.o not download.fp.o?

Please note, though, that we think that the mirror issue is a legitimate bug, either caused by dnf stack, or anaconda. Jan reported it yesterday here: https://bugzilla.redhat.com/show_bug.cgi?id=1196164 If this turns out to be true, it would also mean that OpenQA helped us uncover

Re: Coconut failure for TC5

Hey folks! Anyone paying attention to the Project Coconut box logs might've noticed it failed when it tried to run against Alpha TC5. The problem is to do with the download URLs. I wrote fedfind to always use https://download.fedoraproject.org/ URLs for mirror HTTP downloads, but this turns

  1   2   >