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 A
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.
>
> Taskotron
On Mon, May 14, 2018 at 1:39 PM, Alexander Ploumistos <
alex.ploumis...@gmail.com> wrote:
>
> Well, rpmlint is the one that failed and only on two arches, that's why I
> wanted it to be run again, just in case something was off the first time. I
> thought that if library-without-ldconfig-postin we
> "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
On Mon, May 14, 2018 at 11:59 AM Kamil Paral wrote:
> On Sun, May 13, 2018 at 12:22 PM, Alexander Ploumistos <
alex.ploumis...@gmail.com> wrote:
>> 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
On Sun, May 13, 2018 at 12:22 PM, Alexander Ploumistos <
alex.ploumis...@gmail.com> wrote:
> 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 scriptl
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
>
On Mon, 30 Mar 2015 21:43:56 -0600
Tim Flink wrote:
> On Mon, 30 Mar 2015 16:02:42 -0600
> Tim Flink wrote:
>
> > I'm going to be taking taskotron.stg down for a bit to redeploy it
> > on F21 hosts before beta freeze starts tomorrow.
> >
> > I don't expect this will take more than a couple hou
> 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 system
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
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 that. I've created:
> https://phab.qadevel.cloud.f
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 as it's
> something we're not even ch
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's
something we're not even check
> 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
--
devel mailing list
devel@lists.fedoraproject.o
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:
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
I wrote:
> The Taskatron depcheck appears to be broken or incomplete: It might be
> effective at checking whether the new package has any broken dependencies,
> but it definitely does not appear to check whether the update breaks OTHER
> packages' dependencies (at least I've seen 2 instances where
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
> > actually I've failed (some ansible playbooks are
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
> would be nice if we can collaborate here
> > It's Task-o-tron, it suggests it's meant to execute _tasks_ :-) On
> > the other hand, check is more specific than task, it explains the
> > purpose better. I guess native speakers will need to deal with
> > language subtleties. I just want to be consistent in naming, it helps
> > us and our us
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
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
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
On Mon, 06 Jan 2014 12:36:08 -0500
Matthias Clasen wrote:
> On Mon, 2014-01-06 at 18:06 +0100, Vít Ondruch wrote:
> > Dne 6.1.2014 17:53, Matthew Miller napsal(a):
> > > On Mon, Jan 06, 2014 at 09:36:09AM -0700, Tim Flink wrote:
> > >> One of the primary reasons for replacing AutoQA with taskotro
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 just isn't capable of doing
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 implementation
> just isn't capab
On Mon, Jan 06, 2014 at 08:00:23AM -0500, Kamil Paral wrote:
> Thanks, Richard, for your feedback. That's exactly one of the
> problems in AutoQA that we want to improve in Taskotron. The package
> maintainers or test maintainers should have a direct and simple
> control over their tests.
Excellen
On Mon, 2014-01-06 at 18:06 +0100, Vít Ondruch wrote:
> Dne 6.1.2014 17:53, Matthew Miller napsal(a):
> > 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
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
> just isn't capable of doing that in a reasonable fashion. We haven't
> gotten into the specifi
Dne 6.1.2014 17:53, Matthew Miller napsal(a):
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
just isn't capable of doing that in a reasonable fa
On Sat, 28 Dec 2013 16:42:16 +
"Richard W.M. Jones" wrote:
> On Thu, Dec 26, 2013 at 07:52:04PM -0800, Adam Williamson wrote:
> > No. There's a bad one, which is AutoQA. The problem with it is it's
> > more or less considered obsolete now as far as new development
> > goes; the devs are worki
> On Thu, Dec 26, 2013 at 07:52:04PM -0800, Adam Williamson wrote:
> > No. There's a bad one, which is AutoQA. The problem with it is it's more
> > or less considered obsolete now as far as new development goes; the devs
> > are working on Taskotron to replace it, but I don't believe it's ready
> >
41 matches
Mail list logo
