R.I.P Taskotron
On Thu, 30 Apr 2020 at 10:01, Kamil Paral wrote:
>
> As previously announced [1], Taskotron [2] will be shut down today. See the
> announcement and its discussion for more details and some background info.
>
> As a result, certain tests (beginning with “dist.“)
On 30. 04. 20 9:59, Kamil Paral wrote:
As previously announced [1], Taskotron [2] will be shut down today. See the
announcement and its discussion for more details and some background info.
As a result, certain tests (beginning with “dist.“) will no longer appear for
new updates in Bodhi (in
As previously announced [1], Taskotron [2] will be shut down today. See the
announcement and its discussion for more details and some background info.
As a result, certain tests (beginning with “dist.“) will no longer appear
for new updates in Bodhi (in Automated Tests tab). Some of those tests
On 10. 03. 20 19:16, Tim Flink wrote:
I was under the impression that the python-versions check wasn't needed
going forward. Did I misunderstand something?
Technically, it is not needed for Fedora 32+ unless people go and push serious
regressions. However we monitor rawhide pretty closely and
s this decision made (and
> where can I read about it)?
Much of it was an informal discussion between the Taskotron developers
where we came to the conclusion that Fedora CI was in a better place to
run these checks for Fedora.
> 2) Why are we removing something that arguably has a lot of va
On Fri, 6 Mar 2020 16:37:33 -0700
Jerry James wrote:
> On Fri, Mar 6, 2020 at 4:31 PM Tim Flink wrote:
> > In the short term, there is a Jenkins instance which is running
> > rpminspect. Rpminspect includes tests which are effectively the
> > same as rpmlint and rpmgrill which removes the need t
and miles of roads/trains/etc. While bundled carefully, you
can expect anywhere from 5 to 20% of the equipment to need warranty repairs
for broken drives/motherboards/etc after the move. The more stuff you move
the larger the percentage because the more likely things cascade. So we are
shipping th
> > It's not a direct response to your question, but one important fact is that
> > our beefy machines in Fedora Infrastructure are out of warranty now (and
> > replacing them would cost a lot of money, I assume). That's one of the
> > major reasons why they won't be migrated to the new datacenter
On Mon, Mar 09, 2020 at 03:04:20PM +0100, Kamil Paral wrote:
> On Sat, Mar 7, 2020 at 1:05 AM Miro Hrončok wrote:
>
> > On 07. 03. 20 0:29, Tim Flink wrote:
> > > If you have any questions about this, feel free to reply to this thread.
> >
> > Hello Tim.
> >
> > I have 3 questions.
> >
>
> I'll
sults that you
> currently see in Bodhi under the "Automated Tests" tab. At the moment,
> most of those results come from Taskotron.
To clarify, Taskotron results are those prefixed with "dist.". Depending on
the nature of the update, there can be a number of "upda
On Sat, Mar 7, 2020 at 12:38 AM Jerry James wrote:
> On Fri, Mar 6, 2020 at 4:31 PM Tim Flink wrote:
> > In the short term, there is a Jenkins instance which is running
> > rpminspect. Rpminspect includes tests which are effectively the same as
> > rpmlint and rpmgrill which removes the need to
27;s an example of a generic test support in tmt:
https://github.com/psss/tmt/pull/96/files
This just defines the environment and workflow. The actual command is
inside the "--script 'some command'" part (in your case something like
"--script 'python3 python_version
rrect?)
Thanks for running Taskotron so far. It helped us a lot in the past with the
Python 2 to 3 transition.
[1] https://github.com/fedora-python/taskotron-python-versions
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing
On Fri, Mar 6, 2020 at 4:31 PM Tim Flink wrote:
> In the short term, there is a Jenkins instance which is running
> rpminspect. Rpminspect includes tests which are effectively the same as
> rpmlint and rpmgrill which removes the need to run them.
For packages with a .rpmlintrc file in the git rep
This is something that has been coming for quite a while now
and while it was discussed among QA and Infra, there hasn't been
enough communication with the rest of Fedora. For that, I apologize.
Taskotron has been in maintenance-only mode for a couple of years now
pending a replacement of
Taskotron is back up but we're still having some issues with delays to
the incoming jobs.
We're still investigating but data should be flowing again, even if it
is a bit delayed.
Thanks,
Tim
On Thu, 27 Feb 2020 10:09:33 -0700
Tim Flink wrote:
> The subject says it all, really.
&
The subject says it all, really.
Taskotron is having some problems with an internal component, it can't
wait for a better time and we need some downtime to fix it.
If all goes well, it should be back up shortly. I'll send another email
to update once we're done.
Tim
pg
o or run:
>
> date -d '2019-11-26 19:00 UTC'
>
> Reason for outage:
>
> We will be upgrading the servers which host Taskotron and ResultsDB to
> newer versions of Fedora.
>
> Affected Services:
>
> Taskotron, ResultsDB and anything which uses ResultsDB as a
TC'
Reason for outage:
We will be upgrading the servers which host Taskotron and ResultsDB to
newer versions of Fedora.
Affected Services:
Taskotron, ResultsDB and anything which uses ResultsDB as a data source
(Bodhi, gating etc.)
Ticket Link:
https://pagure.io/fedora-infrastructure
tes started showing rpmlint errors
> > > for my packages again, where they were previously silent because
> > > I supply a $SRCNAME.rpmlintrc file in my dist-git repos.
> > >
> > > It looks like taskotron is broken and/or ignores this file again.
> > >
ause I supply
> > a $SRCNAME.rpmlintrc file in my dist-git repos.
> >
> > It looks like taskotron is broken and/or ignores this file again. Is
> > this a known issue?
> >
> > For example, this build from today shows rpmlint issues that are
> > explicitly wh
On Fri, 26 Apr 2019 16:42:30 +0200
Fabio Valentini wrote:
> Hi,
>
> I've noticed that my bodhi updates started showing rpmlint errors for
> my packages again, where they were previously silent because I supply
> a $SRCNAME.rpmlintrc file in my dist-git repos.
>
>
Hi,
I've noticed that my bodhi updates started showing rpmlint errors for
my packages again, where they were previously silent because I supply
a $SRCNAME.rpmlintrc file in my dist-git repos.
It looks like taskotron is broken and/or ignores this file again. Is
this a known issue?
For ex
There will be an outage starting at 2019-04-09 16:00 UTC, which will
last approximately 4 hours.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run:
date -d '2019-04-09 16:00UTC'
Reason for outage:
Major upgrade to Taskotron
Hi,
naive noob question: Is it possible to execute scripts with taskotron to
download 3rd-party dependencies e.g. with pip from PyPi? I tend to say that
it's not worth to package simple test libraries with all the dependency hell
behind. Those dependencies are not required for normal ru
ool, and adding a config file if present in distgit:
> > https://fedoraproject.org/wiki/Taskotron/Tasks/dist.rpmlint
>
> Using rpmlint-1.10-12.fc28 on the source rpm and e.g. all the x86_64 rpms I
> only get this warning:
> cmpfit-devel.x86_64: W: no-documentation
> 5 packages a
> "AP" == Alexander Ploumistos writes:
AP> /usr/bin/python: can't open file '/usr/lib/rpm/python-macro-helper':
AP> [Errno 2] No such file or directory
For the record, this happens because rpmlint does the equivalent of:
rpm -E %python_sitearch
by calling the expandMacro() function from th
ut-ldconfig-postin were a valid error, it
should appear on all arches.
> Running rpmlint locally should provide the same results. We're simply
running the tool, and adding a config file if present in distgit:
> https://fedoraproject.org/wiki/Taskotron/Tasks/dist.rpmlint
Using rpmlint
> for f28 and rawhide there were no errors or warnings.
>
Running rpmlint locally should provide the same results. We're simply
running the tool, and adding a config file if present in distgit:
https://fedoraproject.org/wiki/Taskotron/Tasks/dist.rpmlint
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Hello,
I've just submitted an update to cmpfit[0] for f28. The automated tests
show errors and warnings only on x86_64 and armv7hl[1] and the errors have
to do with the omission of ldconfig scriptlets. Aren't we supposed to get
rid of these for f28+?
The warnings are:
cmpfit-devel.armv7hl: W: no-
0 UTC'
Reason for outage:
We are upgrading the hosts which run the services required for
Taskotron. This will not affect resultsdb as this will be upgraded at a
later date.
Affected Services:
taskotron.fedoraproject.org
Contact Information:
Please join #fedora-admin or #fedora-noc on irc.fr
eason for outage:
>
> We are upgrading the hosts which run the services required for
> Taskotron.
>
> Affected Services:
>
> taskotron.fedoraproject.org
>
> Contact Information:
>
> Please join #fedora-admin or #fedora-n
/Infrastructure/UTCHowto
or run:
date -d '2017-08-15 16:00:00 UTC'
Reason for outage:
We are upgrading the hosts which run the services required for
Taskotron.
Affected Services:
taskotron.fedoraproject.org
Contact Information:
Please join #fedora-admin or #fedora-noc on irc.fr
On Mon, Jun 19, 2017 at 10:13 AM, Tomas Tomecek wrote:
> The way I envision this is that the test would be invoked via taskotron's
> API,
> something like:
>
> $ taskotron trigger --koji-build=
>
> The CLI tool would contact taskotron's API and would submit a ne
Quoting Jan Scotka (2017-06-16 17:27:48)
>
> > It would be awesome if I could execute a command locally which would
> > trigger
> > testing process inside taskotron. This way I could make sure the tests get
> > picked up correctly -- I definitely don't want to
Hi guys, I hope you don't mind me posting this to devel.
So I built nodejs module today (Friday) [1], went over to taskotron interface
to see if tests were executed [2]. Unfortunately, the tests [3] we have present
in the module dist-git were not triggered. Why?
It would be awesome if I
There there will be an outage starting at 2017-04-25 19:00 UTC, which
will last approximately 2 hours.
This is less notice than I would like but we're going to have some
downtime for Taskotron later today. I suspect that the actual outage
will be less than 2 hours but for the sake of s
; To convert UTC to your local time, take a look at
> https://fedoraproject.org/wiki/UTCHowto
> or run:
>
> date -d '2016-01-17 20:00 UTC'
>
> Reason for outage:
>
> We will be upgrading Taskotron to a new version which requires a
> migration that will take 8-1
There will be an outage starting at 2017-01-17 20:00 UTC, which will
last approximately 12 hours.
To convert UTC to your local time, take a look at
https://fedoraproject.org/wiki/UTCHowto
or run:
date -d '2016-01-17 20:00 UTC'
Reason for outage:
We will be upgrading Taskotron to a n
> 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 pu
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 agai
01-26 15:00 UTC'
Reason for outage:
We will be performing a major upgrade on the production Taskotron
instance which requires downtime while we rebuild and migrate the
backing machines.
Affected Services:
taskotron.fedoraproject.org
Services not listed are not affected by this outage
- Original Message -
> From: "Juan Orti Alcaine"
> To: "Development discussions related to Fedora"
>
> Sent: Thursday, December 3, 2015 8:54:21 AM
> Subject: Cannot open logs of Taskotron jobs
>
> Hi,
>
> I'm trying to open the logs
Hi,
I'm trying to open the logs of a couple of failed Taskotron jobs, but
I get a forbidden error.
These are the jobs:
https://taskotron.fedoraproject.org/resultsdb/results/5025942
https://taskotron.fedoraproject.org/resultsdb/results/5025972
https://bodhi.fedoraproject.org/updates/FEDORA
n the mean time, packagers will not receive
notifications if a package they're involved with fails a taskotron
check. You will still be able to see the results of the checks by
looking at the bodhi2 page for the update - taskotron checks status is
shown there.
We apologize for the inconvenien
Planned Outage: Taskotron - 2015-05-11 19:00:00 UTC
There will be an outage starting at 2015-05-11 19:00:00 UTC, which will
last about 15 minutes
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run:
date -d '2015-05-11 19:00:0
On Fri, 8 May 2015 16:59:22 +0300
Igor Gnatenko wrote:
> Hi,
>
> I pushed mesa update into F22, but actually testing failed at some
> packages.
>
> I think its not related to my update.
>
> https://taskotron.fedoraproject.org/taskmaster//builders/x86_64/builds/67288/steps/runtask/logs/stdio
>
Hi,
I pushed mesa update into F22, but actually testing failed at some packages.
I think its not related to my update.
https://taskotron.fedoraproject.org/taskmaster//builders/x86_64/builds/67288/steps/runtask/logs/stdio
Can you check what happened?
--
devel mailing list
devel@lists.fedoraproj
Planned Outage: Taskotron - 2015-04-23 18:00:00 UTC
There will be an outage starting at 2015-04-23 18:00:00 UTC, which will
last approximately 3 hours.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run:
date -d '2015-04-23 18:
a couple of things that need to be chased down (issues
> with sudo on taskotron-stg01.qa and some transient network issues that
> may have gone away) but everything appears to be up and running for
> now.
Turns out the old taskotron-stg VM wasn't removed and the issues I was
seeing last ni
> Updates seem to have been pushed out now, thanks!.
>
> But I see a different problem with my update. Taskotron failure which
> I don't understand:
>
> not ok - depcheck for Bodhi update systemd-216-20.fc21# FAIL
> ---
> arch: x86_64
> details
On Mon, Feb 16, 2015 at 08:45:12AM -0500, Kamil Paral wrote:
> > but yum install vtk\*.i686 appears to work fine for me (although I
> > didn't go through with the transaction).
> >
> > What's up?
>
> It is most probably a bug in depcheck (or down the stack), I'm sorry. We
> thought we fixed it a
> I got a complaint about this:
>
> not ok - depcheck for Bodhi update vtk-6.1.0-23.fc21 # FAIL
>---
>arch: x86_64
>details:
> output: |-
>Build vtk-6.1.0-23.fc21 failed depcheck
>package vtk-qt-python-6.1.0-23.fc21.i686 requires vtk(x86-32) =
> 6.1.0-23.fc21, but
Updates seem to have been pushed out now, thanks!.
But I see a different problem with my update. Taskotron failure which
I don't understand:
not ok - depcheck for Bodhi update systemd-216-20.fc21 # FAIL
---
arch: x86_64
details:
output: |-
Build systemd-216-20.fc21 f
I got a complaint about this:
not ok - depcheck for Bodhi update vtk-6.1.0-23.fc21# FAIL
---
arch: x86_64
details:
output: |-
Build vtk-6.1.0-23.fc21 failed depcheck
package vtk-qt-python-6.1.0-23.fc21.i686 requires vtk(x86-32) =
6.1.0-23.fc21, but none of the providers
On Wed, 21 Jan 2015 05:50:35 -0500 (EST), Kamil Paral wrote:
> > Taskotron doesn't notice if subpackages have been dropped and cause
> > unresolvable dependencies because they are not obsoleted anywhere.
>
> Yes, depcheck doesn't currently handle
On Wed, 21 Jan 2015 11:48:55 -0700, Tim Flink wrote:
> > Taskotron doesn't notice if subpackages have been dropped and cause
> > unresolvable dependencies because they are not obsoleted anywhere.
>
> This isn't so much something that taskotron's checks missed a
On Fri, 16 Jan 2015 11:00:00 +0100
Michael Schwendt wrote:
> Taskotron doesn't notice if subpackages have been dropped and cause
> unresolvable dependencies because they are not obsoleted anywhere.
This isn't so much something that taskotron's checks missed as it'
> Taskotron doesn't notice if subpackages have been dropped and cause
> unresolvable dependencies because they are not obsoleted anywhere.
Yes, depcheck doesn't currently handle that. I've created:
https://phab.qadevel.cloud.fedoraproject.org/T384
--
dev
Taskotron doesn't notice if subpackages have been dropped and cause
unresolvable dependencies because they are not obsoleted anywhere.
Examples: jogl2-javadoc, miglayout-examples, glusterfs-regression-tests
rubygem-json-doc, rubygem-rake-doc, and more
Yum is broken in the same way. A
Paulo César Pereira de Andrade wrote:
> Automatic push to stable based on karma has been
> disabled for this update due to failure of an AutoQA
> test
> ...
>
> But I cannot see the error:
This is a false positive.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https:
...
Automatic push to stable based on karma has been
disabled for this update due to failure of an AutoQA
test
...
But I cannot see the error:
---8<---
not ok - depcheck for Bodhi update sagemath-6.1.1-6.fc20 # FAIL
---
arch: x86_64
details:
output: |-
Build sagemath-6.1.1-6.fc20
Adam Williamson wrote:
> http://tirfa.com/current-state-of-depcheck-and-paths-forward.html
Sigh. This shows that once again a purported replacement for a working piece
of software was deployed before it was able to perform the allegedly
replaced tool's most important task, even though the proble
seen 2 instances where it didn't
> catch that, and this is the third). The old AutoQA got that right.
Another fun Taskotron depcheck bug, this time a false positive:
https://admin.fedoraproject.org/updates/FEDORA-2014-14865
https://taskotron.fedoraproject.org/taskmaster//builders/x86_64/b
rimary
reasons was to give our Quality Assurance team time to work on tooling
and infrastructure rather than just cycling through tests over and
over. This has borne fruit, and our new QA automation framework
Taskotron has gone live, replacing AutoQA] for checks on package
updates.
Right now, the effect
On Wed, Oct 15, 2014 at 09:21:10AM -0400, Kamil Paral wrote:
> > > """
> > > taskotron-dev.fedoraproject.org uses an invalid security certificate.
> > > The certificate is not trusted because no issuer chain was provided.
> > > The certificate is
gt; Sent: Tuesday, October 14, 2014 8:57:26 AM
> > > Subject: Re: [Test-Announce] Taskotron Has Replaced AutoQA
> > >
> > > You have not mentioned URL of Taskotron here nor the Wiki is
> > > updated to contain the link to the production version of
> > > Taskotron.
> > """
> > taskotron-dev.fedoraproject.org uses an invalid security certificate.
> > The certificate is not trusted because no issuer chain was provided.
> > The certificate is only valid for taskotron-dev01.qa.fedoraproject.org
> > """
gt; Sent: Tuesday, October 14, 2014 8:57:26 AM
> > > Subject: Re: [Test-Announce] Taskotron Has Replaced AutoQA
> > >
> > > You have not mentioned URL of Taskotron here nor the Wiki is updated to
> > > contain the link to the production version of Taskotron.
> >
On Tue, Oct 14, 2014 at 04:28:33AM -0400, Martin Krizek wrote:
> - Original Message -
> > From: "Vít Ondruch"
> > To: devel@lists.fedoraproject.org
> > Sent: Tuesday, October 14, 2014 8:57:26 AM
> > Subject: Re: [Test-Announce] Taskotron Has Replaced A
- Original Message -
> From: "Vít Ondruch"
> To: devel@lists.fedoraproject.org
> Sent: Tuesday, October 14, 2014 8:57:26 AM
> Subject: Re: [Test-Announce] Taskotron Has Replaced AutoQA
>
> You have not mentioned URL of Taskotron here nor the Wiki is updated
You have not mentioned URL of Taskotron here nor the Wiki is updated to
contain the link to the production version of Taskotron.
Vít
Dne 13.10.2014 v 19:08 Tim Flink napsal(a):
> This has been a long time coming, but AutoQA is no longer scheduling
> jobs and Taskotron is now running all
This has been a long time coming, but AutoQA is no longer scheduling
jobs and Taskotron is now running all of the automated checks on
packages/updates.
The changeover should be transparent to most people - the same checks
are being run in pretty much the same situations. Until Bodhi 2.0 is
This has been a long time coming but after running on smaller systems
for the last couple months to make sure that all the parts are running
smoothly, Taskotron is now running in staging:
https://taskotron.stg.fedoraproject.org/
What does this mean? It means that we are almost ready to turn on
On Fri, 2 May 2014 04:32:52 -0400 (EDT)
Kamil Paral wrote:
> > > > https://phab.qadevel.cloud.fedoraproject.org/w/taskotron-papercuts/
> > >
> > > Thanks, I was thinking about this. It's very unfortunate that
> > > Phabricator doesn't support arb
On Thu, Apr 17, 2014 at 02:25:03PM +0200, Vitaly Kuznetsov wrote:
> 2mattdm: Matt, I remember you telling me that someone is working on such
> uploader. Can you please shed some light on what's the status now and
> what can be done in before f21?
Yeah. Still manual process. It feels like a very lo
On Mon, 14 Apr 2014 17:01:49 +0200
Vitaly Kuznetsov wrote:
> Vitaly Kuznetsov writes:
>
> > Hi Tim & all,
> >
> > Yesterday I've tried setting up Taskotron (according to
> > http://roshi.fedorapeople.org/dexy-themed/) on 3 F20 VMs in EC2 and
> >
On Tue, 08 Apr 2014 13:51:10 +0200
Vitaly Kuznetsov wrote:
> Hi Tim & all,
>
> in Cloud WG we have 'Automatic Smoketests on Image Build' task:
> https://fedorahosted.org/cloud/ticket/38
> AFAIK you have somehting similar among future Taskotron goals. It
> wou
in naming, it helps
> > us and our users, that's all.
>
> Yeah, consistency is important. Personally, I'm ok with leaving stuff
> like libtaskotron.check for the moment - that's what we're working on.
> Do you think that changing things over to TaskDetail etc. wo
On Tue, 21 Jan 2014 10:23:40 -0500 (EST)
Martin Krizek wrote:
> >
> > As a general note, I'm not fully happy when the source code lives
> > somewhere else than the issues do. It confuses people. But if we
> > want to keep easy-to-browse-and-fork functionality (bitbucket) and
> > full-featured-
- Original Message -
> From: "Kamil Paral"
> To: "Fedora QA Development" , "Josef
> Skladanka"
> Sent: Tuesday, January 21, 2014 4:00:33 PM
> Subject: Re: Taskotron wiki page
>
> > I also updated
> >
> > https://fed
mkrizek claimed this task.
TASK DETAIL
https://phab.qadevel.cloud.fedoraproject.org/T52
To: mkrizek
Cc: kparal, qa-devel, tflink
___
qa-devel mailing list
qa-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/qa-devel
tflink added a dependency: T49: koji download tag directive
TASK DETAIL
https://phab.qadevel.cloud.fedoraproject.org/T41
To: tflink
Cc: qa-devel, tflink
___
qa-devel mailing list
qa-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman
tflink added a dependency: T48: createrepo directive
TASK DETAIL
https://phab.qadevel.cloud.fedoraproject.org/T41
To: tflink
Cc: qa-devel, tflink
___
qa-devel mailing list
qa-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listin
tflink added a dependency: T47: bodhi download
TASK DETAIL
https://phab.qadevel.cloud.fedoraproject.org/T41
To: tflink
Cc: qa-devel, tflink
___
qa-devel mailing list
qa-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/qa-
tflink added a dependency: T46: bodhi directive module
TASK DETAIL
https://phab.qadevel.cloud.fedoraproject.org/T41
To: tflink
Cc: qa-devel, tflink
___
qa-devel mailing list
qa-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/list
tflink added a dependency: T45: dynamically load modules for task directives
TASK DETAIL
https://phab.qadevel.cloud.fedoraproject.org/T41
To: tflink
Cc: qa-devel, tflink
___
qa-devel mailing list
qa-de...@lists.fedoraproject.org
https://admin.fedorapr
tflink added a dependency: T39: Investigate documentation systems for taskotron
and related sub-projects
TASK DETAIL
https://phab.qadevel.cloud.fedoraproject.org/T28
To: tflink
Cc: qa-devel, tflink
___
qa-devel mailing list
qa-de
On Wed, 8 Jan 2014 02:14:43 -0500
Rahul Sundaram wrote:
> Hi
>
> On Wed, Jan 8, 2014 at 1:58 AM, Adam Williamson wrote:
>
> >
> > Well, we'll want to do all sorts of tests that aren't obviously
> > tied to any specific package. The only kinds of tests it would make
> > sense to have in packages
Hi
On Wed, Jan 8, 2014 at 1:58 AM, Adam Williamson wrote:
>
> Well, we'll want to do all sorts of tests that aren't obviously tied to
> any specific package. The only kinds of tests it would make sense to
> have in packages would be tests that are very tightly associated with
> that package, but
On Tue, 2014-01-07 at 10:47 -0500, Matthew Miller wrote:
> On Mon, Jan 06, 2014 at 10:30:07PM -0800, Adam Williamson wrote:
> > The RPM spec file is a clearly defined thing that achieves a clearly
> > defined set of functions. Overloading it with something that's really
>
> Well, it's not so clear
I've finally read it as well :) Comments below.
> At the moment, that task yaml file for rpmlint [1] looks like:
>
> dependencies:
> - rpmlint
> - libtaskbot
>
> input:
> args: envr,arch
These arguments are provided by the event trigger, right? So, the event trigger
offer
On Mon, Jan 06, 2014 at 10:30:07PM -0800, Adam Williamson wrote:
> The RPM spec file is a clearly defined thing that achieves a clearly
> defined set of functions. Overloading it with something that's really
Well, it's not so clear as all that, but, sure. And I wasn't really
suggesting that RPM be
Dne 6.1.2014 19:47, Matthew Miller napsal(a):
On Mon, Jan 06, 2014 at 11:04:39AM -0700, Tim Flink wrote:
What about including them in the RPMs themselves, in a new section
similar to the existing %check -- or just in a standard file location
(so no changes to RPM itself are needed immediately)?
On Mon, 2014-01-06 at 13:47 -0500, Matthew Miller wrote:
> On Mon, Jan 06, 2014 at 11:04:39AM -0700, Tim Flink wrote:
> > > What about including them in the RPMs themselves, in a new section
> > > similar to the existing %check -- or just in a standard file location
> > > (so no changes to RPM itse
On Mon, Jan 06, 2014 at 11:04:39AM -0700, Tim Flink wrote:
> > What about including them in the RPMs themselves, in a new section
> > similar to the existing %check -- or just in a standard file location
> > (so no changes to RPM itself are needed immediately)?
> I'm not sure that I see how includi
sons for replacing AutoQA with taskotron
> > >> is to make it easier for folks to contribute checks. AutoQA's
> > >> implementation just isn't capable of doing that in a reasonable
> > >> fashion. We haven't gotten into the specifics of how
> >
On Mon, Jan 06, 2014 at 11:04:39AM -0700, Tim Flink wrote:
> I haven't given a whole lot of thought to how exactly we'll do package
> specific checks. Keeping the checks in the package's git repo is the
> first thing that comes to mind but I'm sure there other possible
> solutions. Either way, it f
On Mon, 6 Jan 2014 11:53:14 -0500
Matthew Miller wrote:
> On Mon, Jan 06, 2014 at 09:36:09AM -0700, Tim Flink wrote:
> > One of the primary reasons for replacing AutoQA with taskotron is to
> > make it easier for folks to contribute checks. AutoQA's
> > implementation j
On Mon, Jan 06, 2014 at 09:36:09AM -0700, Tim Flink wrote:
> Kamil already covered this a bit but I wanted to add a few more details.
>
> One of the primary reasons for replacing AutoQA with taskotron is to
> make it easier for folks to contribute checks. AutoQA's implementa
1 - 100 of 109 matches
Mail list logo
