Re: automated packaging

[Randy Barlow]

On Mon, 2017-03-27 at 12:26 +, Petr Pisar wrote:
> Or are these test failures expected to be delivered through FMN only?

This is currently how they are handled. I have my FMN settings
configured to send these to me over IRC and that works well for me.
However, I don't believe that is the default setting.

> I remember I read about a planned change in taskotron failure
> reporting,
> but I'm not sure this is the same thing.

I'm not sure what the plans are around notification. I do believe there
are plans to have automated tests be able to block updates from going
out, so that might happen in the future.

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: automated packaging

[Petr Pisar]

On 2017-03-24, Randy Barlow  wrote:
> The JavaScript that loads the taskotron results from resultsdb is in
> Bodhi, not taskotron:
>
You are right. It looks like NoScript Firefox extensions blocks AJAX
requests too. Maybe because the response contains a javascript code
(JSONP). That was why I thought it's a third-party code.

> However, Ryan Lerch has also recently done a redesign of the update
> page layout that moves the test results into a nice tab so they don't
> push the comments down like they do today. You can see the new design
> on staging but I'm not sure if any staging updates have taskotron
> results to display. For example:
>
> https://bodhi.stg.fedoraproject.org/updates/FEDORA-2017-e8e717e2b7

Nice. But I do not use the Bodhi web page very often. And besides some
sporadic upgrade-path breakage e-mails, I did not see any message about
failed tests.

Now when I enabled the javascript from taskotron, I can see a failure at
. If
these failures weren't sent actively to update submitters, they could
be ignored.

Or are these test failures expected to be delivered through FMN only?
I remember I read about a planned change in taskotron failure reporting,
but I'm not sure this is the same thing.

-- Petr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: automated packaging

[Randy Barlow]

On Fri, 2017-03-24 at 13:38 +, Petr Pisar wrote:
> third-party == from different host (bodhi.fedoraproject.org. !=
> taskotron.fedoraproject.org.).

The JavaScript that loads the taskotron results from resultsdb is in
Bodhi, not taskotron:

https://github.com/fedora-infra/bodhi/blob/2.4.0/bodhi/server/templates/update.html#L40-L241

There is also an open pull request from the talented Ryan Lerch which
significantly improved the performance of this code:

https://github.com/fedora-infra/bodhi/pull/1379

> Nevertheless I'd rather see taskotron to send a comment to the update
> with a list of failed tests.

The comments could be very large. Some updates have 1800 tests in them,
and I believe the QA group is adding more tests as time goes on.
However, Ryan Lerch has also recently done a redesign of the update
page layout that moves the test results into a nice tab so they don't
push the comments down like they do today. You can see the new design
on staging but I'm not sure if any staging updates have taskotron
results to display. For example:

https://bodhi.stg.fedoraproject.org/updates/FEDORA-2017-e8e717e2b7

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: automated packaging

[Petr Pisar]

On 2017-03-24, Matthew Miller  wrote:
> On Fri, Mar 24, 2017 at 09:11:22AM +, Petr Pisar wrote:
>> > It would be under the "Automated Test Results",
>> 
>> So this the stuff loaded by a third-party javascript code that I have
>> disabled. That explains why I wasn't able to see it anywhere.
>
> I don't think we use any "third-party" javascript.
>
third-party == from different host (bodhi.fedoraproject.org. !=
taskotron.fedoraproject.org.).

Nevertheless I'd rather see taskotron to send a comment to the update
with a list of failed tests.

-- Petr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: automated packaging

[Matthew Miller]

On Fri, Mar 24, 2017 at 09:11:22AM +, Petr Pisar wrote:
> > It would be under the "Automated Test Results",
> 
> So this the stuff loaded by a third-party javascript code that I have
> disabled. That explains why I wasn't able to see it anywhere.

I don't think we use any "third-party" javascript.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: automated packaging

[Petr Pisar]

On 2017-03-24, Dan Horák  wrote:
> On Fri, 24 Mar 2017 07:10:47 + (UTC)
> Petr Pisar  wrote:
>
>> On 2017-03-23, Michael Catanzaro  wrote:
>> > On Thu, 2017-03-23 at 06:32 -0500, Michael Catanzaro wrote:
>> >> That's not true, there are ABI checks in the sidebar on koji.
>> >
>> > Sorry, in the sidebar in *Bodhi*.
>> 
>> Could you be more specific (URL or so)? I cannot find it on Bodhi web
>> site.
>
> It would be under the "Automated Test Results",

So this the stuff loaded by a third-party javascript code that I have
disabled. That explains why I wasn't able to see it anywhere.

-- Petr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: automated packaging

[Nikos Mavrogiannopoulos]

On Thu, 2017-03-23 at 09:54 -0700, Adam Williamson wrote:
> On Thu, 2017-03-23 at 09:20 +0100, Nikos Mavrogiannopoulos wrote:
> > 
> > > FWIW, I would be *extremely* reluctant to use something that big
> > > that's
> > > a) written in shell script (ugh) and b) has no tests.
> > 
> > How did you figure the (b) part? The package itself has extensive
> > tests.
> 
> I meant that, so far as I can see in
> https://github.com/cockpit-project/cockpituous/ , there are no tests
> for the 'release' scripts. If there are, can you point me to them?

You are right. There are none on the cockpituous package.

regards,
Nikos
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: automated packaging

[Nikos Mavrogiannopoulos]

On Fri, 2017-03-24 at 08:27 +0100, Dan Horák wrote:
> On Fri, 24 Mar 2017 07:10:47 + (UTC)
> Petr Pisar  wrote:
> 
> > On 2017-03-23, Michael Catanzaro  wrote:
> > > On Thu, 2017-03-23 at 06:32 -0500, Michael Catanzaro wrote:
> > > > That's not true, there are ABI checks in the sidebar on koji.
> > > 
> > > Sorry, in the sidebar in *Bodhi*.
> > 
> > Could you be more specific (URL or so)? I cannot find it on Bodhi
> > web
> > site.
> 
> It would be under the "Automated Test Results", but the libabigail
> tests are enabled now only for critical path packages. But it should
> be
> really enabled for all and made to require a manual waiver if an
> incompatible result is detected.

I do not see that in gnutls [0] so it may be selectively enabled even
for critical path packages. I agree that it should be there for all
with a manual waiver.

regards,
Nikos


[0]. https://bodhi.fedoraproject.org/updates/FEDORA-2017-5a55b061cb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: automated packaging

[Dan Horák]

On Fri, 24 Mar 2017 07:10:47 + (UTC)
Petr Pisar  wrote:

> On 2017-03-23, Michael Catanzaro  wrote:
> > On Thu, 2017-03-23 at 06:32 -0500, Michael Catanzaro wrote:
> >> That's not true, there are ABI checks in the sidebar on koji.
> >
> > Sorry, in the sidebar in *Bodhi*.
> 
> Could you be more specific (URL or so)? I cannot find it on Bodhi web
> site.

It would be under the "Automated Test Results", but the libabigail
tests are enabled now only for critical path packages. But it should be
really enabled for all and made to require a manual waiver if an
incompatible result is detected.


Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: automated packaging

[Petr Pisar]

On 2017-03-23, Michael Catanzaro  wrote:
> On Thu, 2017-03-23 at 06:32 -0500, Michael Catanzaro wrote:
>> That's not true, there are ABI checks in the sidebar on koji.
>
> Sorry, in the sidebar in *Bodhi*.

Could you be more specific (URL or so)? I cannot find it on Bodhi web
site.

-- Petr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: automated packaging

[Adam Williamson]

On Thu, 2017-03-23 at 09:20 +0100, Nikos Mavrogiannopoulos wrote:
> 
> > FWIW, I would be *extremely* reluctant to use something that big
> > that's
> > a) written in shell script (ugh) and b) has no tests.
> 
> How did you figure the (b) part? The package itself has extensive
> tests.

I meant that, so far as I can see in
https://github.com/cockpit-project/cockpituous/ , there are no tests
for the 'release' scripts. If there are, can you point me to them?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: automated packaging

[Michael Catanzaro]

On Thu, 2017-03-23 at 06:32 -0500, Michael Catanzaro wrote:
> That's not true, there are ABI checks in the sidebar on koji.

Sorry, in the sidebar in *Bodhi*.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: automated packaging

[Michael Catanzaro]

On Thu, 2017-03-23 at 09:20 +0100, Nikos Mavrogiannopoulos wrote:
> Unless you mean about fedora testing in general. It is true fedora
> provides no practical infrastructure for testing. Even basic checks
> like ABI checks for libraries are missing on updates; that's sad but
> shouldn't stop packagers from improving their life.

That's not true, there are ABI checks in the sidebar on koji. But I
always ignore them, because they are easy to ignore. Clearly, as you
didn't even realize it was there :)

Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: automated packaging

[Richard W.M. Jones]

On Wed, Mar 22, 2017 at 11:02:28AM -0400, Colin Walters wrote:
> 
> 
> On Wed, Mar 22, 2017, at 06:00 AM, Nikos Mavrogiannopoulos wrote:
> > Hi,
> >  For several packages it is possible to automate build, test and
> > package updating on multiple fedora releases (+epel) in a single
> > keypress using the cockpituous (sic) tools [0]. These tools hide quirks
> > and requirements of the fedora tooling, and allow a very efficient
> > orchestration of package releases (see [1] for a script which releases
> > gnutls  for example).
> 
> I started a list of these here a while ago:
> 
> https://fedoraproject.org/wiki/Layered_build_scripts_for_package_maintainers

Should this list include the various `X2spec' tools out there?
For example cpanspec:

  https://fedoraproject.org/wiki/Perl/cpanspec

I also have a tool I wrote to manage the Fedora OCaml rebuilds:

  https://people.redhat.com/rjones/goaljobs/
  http://git.annexia.org/?p=goals.git;a=blob;f=fedora_ocaml_rebuild.ml

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: automated packaging

[Nikos Mavrogiannopoulos]

On Thu, 2017-03-23 at 09:35 +0100, Miroslav Suchý wrote:
> Dne 23.3.2017 v 09:23 Nikos Mavrogiannopoulos napsal(a):
> > What I was
> > interested is whether there is plan or intention of improving the
> > fedora infrastructure for packagers by making these part of our
> > daily
> > work-flow.
> 
> It depends. :)
> I use Tito daily and it saves me a lot of time. However some people
> find it too complicate/less powerfull/hard to
> understand/not enough powerfull... so they use some other tool.
> People are different and they like different tools. And I'm afraid
> that fedpkg is biggest common denominator.
> 
> So I would say: go ahead, write blogposts about your tool, continue
> to enhance it or join your effort with some other
> tool from the list Colin compiled. But there is 0% chance that it
> will be wide enforced tool for all Fedora contributors.

Note that this is not my tool, and my post is not about imposing any
specific tool. What I'm trying to suggest here is to move to automated
packaging, not talk about using a tool.

That is, being able to tie certain packages to certain upstream streams
per release using the fedora infrastructure. That is, set package xyz,
tied to upstream 1.2.x branch, and update as needed (maybe with manual
confirmation/review from maintainer, maybe not).

It is the monkey work I would like to eliminate.

regards,
Nikos
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: automated packaging

[Miroslav Suchý]

Dne 23.3.2017 v 09:23 Nikos Mavrogiannopoulos napsal(a):
> What I was
> interested is whether there is plan or intention of improving the
> fedora infrastructure for packagers by making these part of our daily
> work-flow.

It depends. :)
I use Tito daily and it saves me a lot of time. However some people find it too 
complicate/less powerfull/hard to
understand/not enough powerfull... so they use some other tool.
People are different and they like different tools. And I'm afraid that fedpkg 
is biggest common denominator.

So I would say: go ahead, write blogposts about your tool, continue to enhance 
it or join your effort with some other
tool from the list Colin compiled. But there is 0% chance that it will be wide 
enforced tool for all Fedora contributors.

-- 
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: automated packaging

[Nikos Mavrogiannopoulos]

On Wed, 2017-03-22 at 11:36 +0100, Miroslav Suchý wrote:
> Dne 22.3.2017 v 11:00 Nikos Mavrogiannopoulos napsal(a):
> > Hi,
> >  For several packages it is possible to automate build, test and
> > package updating on multiple fedora releases (+epel) in a single
> > keypress using the cockpituous (sic) tools [0]. These tools hide
> > quirks
> > and requirements of the fedora tooling, and allow a very efficient
> > orchestration of package releases (see [1] for a script which
> > releases
> > gnutls  for example).
> 
> 
> Few comments from my quick review:
> + it can release to Debian and Docker
> - user have to put quite a lot of logic and repetitive configuration
> in `make-release` (for every project)
> - not really well documented
> 
> There already exist much olders and IMO betters tools which can
> release from upstream directly to Fedora:
>   https://github.com/dgoodwin/tito/
>   https://github.com/openstack-packages/rdopkg
>   https://github.com/ignatenkobrain/rpm-gitoverlay

The look fine too. I am not tied to a particular tool. What I was
interested is whether there is plan or intention of improving the
fedora infrastructure for packagers by making these part of our daily
work-flow.

regards,
Nikos
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: automated packaging

[Nikos Mavrogiannopoulos]

On Wed, 2017-03-22 at 08:51 -0700, Adam Williamson wrote:
> On Wed, 2017-03-22 at 11:00 +0100, Nikos Mavrogiannopoulos wrote:
> > Hi,
> >  For several packages it is possible to automate build, test and
> > package updating on multiple fedora releases (+epel) in a single
> > keypress using the cockpituous (sic) tools [0]. These tools hide
> > quirks
> > and requirements of the fedora tooling, and allow a very efficient
> > orchestration of package releases (see [1] for a script which
> > releases
> > gnutls  for example).
> > 
> > I'm transforming more of the packages I maintain to that form,
> > however,
> > there is much more value if that is done once for all the Fedora
> > maintainers. While obviously the maintainers who are also involved
> > in
> > upstream developing would benefit most, the majority of the
> > maintainers
> > which have packages which follow good practices will benefit from
> > such
> > a simple automated rebase, spending their time only for reviewing
> > changes. Is that something that is already being worked on?
> 
> FWIW, I would be *extremely* reluctant to use something that big
> that's
> a) written in shell script (ugh) and b) has no tests.

How did you figure the (b) part? The package itself has extensive
tests.

Unless you mean about fedora testing in general. It is true fedora
provides no practical infrastructure for testing. Even basic checks
like ABI checks for libraries are missing on updates; that's sad but
shouldn't stop packagers from improving their life.

regards,
Nikos
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: automated packaging

[Patrick Laimbock]

On 22-03-17 19:18, Matthew Miller wrote:

On Wed, Mar 22, 2017 at 04:22:08PM +0100, Patrick Laimbock wrote:

Thanks for compiling that list. The Tito link gave a 404 so I edited
it to point to https://github.com/dgoodwin/tito and also added
centpkg which is used by CentOS.


Does centpkg fit in this category? Isn't it basically just the same as
fedpkg, but for CentOS?


I thought that centpkg was based on/inspired by rdopkg but that doesn't 
seem to be the case. Went back to the wiki page to remove centpkg but my 
changes are not visible so moot.


HTH,
Patrick
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: automated packaging

[Matthew Miller]

On Wed, Mar 22, 2017 at 04:22:08PM +0100, Patrick Laimbock wrote:
> Thanks for compiling that list. The Tito link gave a 404 so I edited
> it to point to https://github.com/dgoodwin/tito and also added
> centpkg which is used by CentOS.

Does centpkg fit in this category? Isn't it basically just the same as
fedpkg, but for CentOS?

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: automated packaging

[Adam Williamson]

On Wed, 2017-03-22 at 11:00 +0100, Nikos Mavrogiannopoulos wrote:
> Hi,
>  For several packages it is possible to automate build, test and
> package updating on multiple fedora releases (+epel) in a single
> keypress using the cockpituous (sic) tools [0]. These tools hide quirks
> and requirements of the fedora tooling, and allow a very efficient
> orchestration of package releases (see [1] for a script which releases
> gnutls  for example).
> 
> I'm transforming more of the packages I maintain to that form, however,
> there is much more value if that is done once for all the Fedora
> maintainers. While obviously the maintainers who are also involved in
> upstream developing would benefit most, the majority of the maintainers
> which have packages which follow good practices will benefit from such
> a simple automated rebase, spending their time only for reviewing
> changes. Is that something that is already being worked on?

FWIW, I would be *extremely* reluctant to use something that big that's
a) written in shell script (ugh) and b) has no tests.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: automated packaging

[Patrick Laimbock]

On 22-03-17 16:02, Colin Walters wrote:



On Wed, Mar 22, 2017, at 06:00 AM, Nikos Mavrogiannopoulos wrote:

Hi,
 For several packages it is possible to automate build, test and
package updating on multiple fedora releases (+epel) in a single
keypress using the cockpituous (sic) tools [0]. These tools hide quirks
and requirements of the fedora tooling, and allow a very efficient
orchestration of package releases (see [1] for a script which releases
gnutls  for example).


I started a list of these here a while ago:

https://fedoraproject.org/wiki/Layered_build_scripts_for_package_maintainers


Thanks for compiling that list. The Tito link gave a 404 so I edited it 
to point to https://github.com/dgoodwin/tito and also added centpkg 
which is used by CentOS.


HTH,
Patrick
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: automated packaging

[Colin Walters]

On Wed, Mar 22, 2017, at 06:00 AM, Nikos Mavrogiannopoulos wrote:
> Hi,
>  For several packages it is possible to automate build, test and
> package updating on multiple fedora releases (+epel) in a single
> keypress using the cockpituous (sic) tools [0]. These tools hide quirks
> and requirements of the fedora tooling, and allow a very efficient
> orchestration of package releases (see [1] for a script which releases
> gnutls  for example).

I started a list of these here a while ago:

https://fedoraproject.org/wiki/Layered_build_scripts_for_package_maintainers
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: automated packaging

[Miroslav Suchý]

Dne 22.3.2017 v 11:00 Nikos Mavrogiannopoulos napsal(a):
> Hi,
>  For several packages it is possible to automate build, test and
> package updating on multiple fedora releases (+epel) in a single
> keypress using the cockpituous (sic) tools [0]. These tools hide quirks
> and requirements of the fedora tooling, and allow a very efficient
> orchestration of package releases (see [1] for a script which releases
> gnutls  for example).


Few comments from my quick review:
+ it can release to Debian and Docker
- user have to put quite a lot of logic and repetitive configuration in 
`make-release` (for every project)
- not really well documented

There already exist much olders and IMO betters tools which can release from 
upstream directly to Fedora:
  https://github.com/dgoodwin/tito/
  https://github.com/openstack-packages/rdopkg
  https://github.com/ignatenkobrain/rpm-gitoverlay

-- 
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org