Re: CI projects in Copr
On Thursday, August 31, 2017 8:43:38 AM CEST Pavel Raiskup wrote: > On Wednesday, August 30, 2017 5:18:39 PM CEST Michal Novotny wrote: > > We are considering the options here and so far the most convenient method > > (at > > least from the implementation point of view) seems to be to automatically > > call > > `make srpm` command in the source git repo if user selects `make srpm` as a > > srpm generator method > > I'm curious why you insist on 'make srpm'; that sounds like you try to push > the > copr users somewhere, to "standardize something". > > Please allow specifying custom script, relatively placed in the git > repository. > That's exactly the same thing, but users don't have to create Makefile > "because > copr ..." -- users just can use what they already have. Ok, even better -> allow specifying custom command, like: Git Repo: something.somewhere.git/project/foo Command to get sources: cd packaging/rpm/fedora ; SOMEVAR=something ./generate-rpm.sh --some-arg Packages needed to obtain sources: help2man, gettext-devel, wget, git-lfs SRPM pattern: packaging/rpm/fedora/xyz*.src.rpm The pattern is important; plus we should declare that only the first matched srpm is going to be built. > > We will probably also add a field to differentiate between srpm buildroot > > packages and rpm buildroot packages and also make this setting available > > across all project chroots. > > Thanks for this! Btw., copr builds three (or four?) SRPMs. First it generates (or it is planned to generate) the SRPM from upstream source, then builder goes and generates the SRPM from dist-git, and last time it generates SRPM during the RPM build (this used to have one additional SRPM build I guess in mock). It should be clear that you specify "build deps" only for **the first** SRPM preparation, before it is even imported into copr dist-git. Pavel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: CI projects in Copr
Hello,
I'm using Jenkins for pOCCI testsuite tool [1] (COPR repository is
[2]).
I'm building everything in Jenkins using my own scripts for several OS
(Fedora/EPEL, Debian), but I've added also COPR as optional step in the
build workflow.
Source rpms are generated locally by Jenkins and then is launched on
pre-configured machine:
copr-cli build --nowait ${COPR_PROJECT} ${BUILD_URL}artifact/${1}
($COPR_PROJECT is "indigo", $BUILD_URL is preset by Jenkins, $1 is the
srpm)
There is just rebuild on each commit on master.
Cheers,
Frantisek
[1] https://pypi.python.org/pypi/pOCCI/
[2] https://copr.fedorainfracloud.org/coprs/valtri/indigo/
Miroslav Suchý píše v St 23. 08. 2017 v 13:46 +0200:
> Hi,
> I am gathering informations about various use of CI with Copr. Do you
> use Copr for building packages for nightlies? For
> building packages before pull request is merged? Do you have your set
> up described somewhere? What is the name of your
> project?
>
> Please let me know. Either here or via private reply.
> It will help me to understand your use of Copr and to make Copr
> better.
>
> Thanks in advance.
>
> Miroslav Suchy
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: OCaml / aarch64 / binutils / coq mess
On Wed, Aug 30, 2017 at 07:23:04PM -0600, Jerry James wrote: > BTW, most of the packages that sit on top of coq have new versions > available, so when this is fixed, I will want to update the other > packages anyway. If you could let me know when a fix for this issue > is available, I will take care of building everything else. Sure. > >> (3) Disable the problematic coq modules. I'm not clear if they are > >> necessary however, since I've only used Coq as an end user, I've never > >> delved into how it works. > > Which ones are problematic? All of them? It could be all of them. The first failure is: rm -f theories/Init/Datatypes.glob bin/coqtop -boot -native-compiler -compile theories/Init/Datatypes.v -noinit -R theories Coq File "./theories/Init/Datatypes.v", line 13, characters 0-38: Error: while loading /home/rjones/d/coq/plugins/syntax/nat_syntax_plugin.cmxs: error loading shared library: /home/rjones/d/coq/plugins/syntax/nat_syntax_plugin.cmxs: undefined symbol: camlLoc__3 (‘make -k’ doesn't get past this point) The problem specifically is that we're carrying this patch: https://github.com/ocaml/ocaml/pull/1268 which marks most global symbols that need to be loaded into registers as ‘.hidden’. However this "over-hides", in this case hiding camlLoc__3 (some anon function in the Loc module) which does actually need to be public. We need this patch to get OCaml to compile at all on aarch64, so the answer is not to remove this patch, but to fix it in some other way. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: CI projects in Copr
On Thu, Aug 31, 2017 at 8:43 AM, Pavel Raiskup wrote: > On Wednesday, August 30, 2017 5:18:39 PM CEST Michal Novotny wrote: > > We are considering the options here and so far the most convenient > method (at > > least from the implementation point of view) seems to be to > automatically call > > `make srpm` command in the source git repo if user selects `make srpm` > as a > > srpm generator method > > I'm curious why you insist on 'make srpm'; that sounds like you try to > push the > copr users somewhere, to "standardize something". > > It's easier on implementation. That's the main reason. I generally believe that what's easier on implementation is better. > Please allow specifying custom script, relatively placed in the git > repository. > That's exactly the same thing, but users don't have to create Makefile > "because > copr ..." -- users just can use what they already have. > > > for his (or her) SCM project (this will be a select > > field in UI and also it will be a build parameter available in our future > > API). That means it would be a custom script > > placed inside a Makefile under srpm goal. Custom packages needed for this > > operation could be > > specified in minimal buildroot of the given chroot (in chroot settings). > > > > We will probably also add a field to differentiate between srpm buildroot > > packages and rpm buildroot packages and also make this setting available > > across all project chroots. > > Thanks for this! > > Pavel > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Module Stream "Expansion"
On 30 August 2017 at 21:56, Matthew Miller wrote: > On Wed, Aug 30, 2017 at 07:43:21PM +1000, Nick Coghlan wrote: >> As a concrete example, the upstream Python 3.7 alpha & beta cycle will >> be running in parallel with the F28 development cycle. It would be >> beneficial to be able to create the corresponding module stream once >> the first alpha release is available, but we don't really want anyone >> else to implicitly start building against that stream until it hits >> the release candidate phase (as upstream's typical API and ABI >> stability guarantees don't apply until after the last beta release). > > I'm missing how this relates to the multiple targets problem here. > Wouldn't you want that alpha (and eventually final) to be available > across the different various bases? Yes, but our concern isn't with the Python module's dependencies on the Platform module, it's with *other* components that depend on the Python module: if stream expansion were to pick up all non-EOL branches as being "active", then it would be difficult to safely bootstrap the streams for new feature releases (since other modules would then start implicitly trying to build against them before they were ready). > I'd think the solution is simply to mark your module with "Service > Level: alpha" (and then we'd want some tooling where SL-alpha and > SL-beta modules only show up for those who ask for them.) If the definition of active stream (for stream expansion purposes) were to exclude SL-alpha (and maybe SL-beta) streams in addition to EOL ones, then yes, I think that would handle my/our concerns, as then there would be a way to indicate that a *new* streams should be considered inactive without needing to set a misleading EOL date. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Non-responsive maintainer process for caillon, and retiring xchat
On Mon, Jun 26, 2017 at 11:06:16AM +, Debarshi Ray wrote: > On Wed, Jun 14, 2017 at 03:19:52PM +, Debarshi Ray wrote: > > I would like to initiate the non-responsive maintainer process [1] for > > Christopher Aillon [2]. A long time ago, he used to be part of the > > Fedora and Red Hat desktop teams. He is no longer around. He left > > software development and was last seen living off the grid in Hawaii > > [3]. Therefore I have jumped straight to the fourth step in the > > aforementioned process. > > > > Here is a list of his packages: > > https://admin.fedoraproject.org/pkgdb/packager/caillon/ > > > > I am particularly interested in xchat, which I want to retire right > > after removing Chris as the point of contact for his packages. > > Filed: https://pagure.io/fesco/issue/1721 This is done - caillon has been removed as the point-of-contact for his packages, and xchat has been retired from the f27 and master branches. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: CI projects in Copr
On Thursday, August 31, 2017 11:43:08 AM CEST Michal Novotny wrote: > On Thu, Aug 31, 2017 at 8:43 AM, Pavel Raiskup wrote: > > I'm curious why you insist on 'make srpm'; that sounds like you try to push > > the copr users somewhere, to "standardize something". > > It's easier on implementation. That's the main reason. I generally believe > that what's easier on implementation is better. This is not first time we talk about this... (a) can you elaborate what's "easier" to implement on the 'make srpm' way? (b) shouldn't you make a life easier to your users? Even when I really like make, what's easier on "enforcing" Makefile existence to be able to enable CI in copr? (c) Wrong general belief, please, forget about that. Doing it wrong (== an "easier" way) in the beginning is much more expensive in the end (try to grep for "refactor" word...). The proposal is to have "one method" which suits everybody; and never touch it again. But yeah, no-thanks for not listening. Again. Pavel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Module Stream "Expansion"
On Thu, Aug 31, 2017 at 08:11:56PM +1000, Nick Coghlan wrote: > Yes, but our concern isn't with the Python module's dependencies on > the Platform module, it's with *other* components that depend on the > Python module: if stream expansion were to pick up all non-EOL > branches as being "active", then it would be difficult to safely > bootstrap the streams for new feature releases (since other modules > would then start implicitly trying to build against them before they > were ready). From the presentation I saw yesterday, right now, there isn't an "alpha" service level tag; "rawhide" is probably the closest. But if we added one, or even assuming just "rawhide", those SLs should be inhereted into the downstream modules (and then presumably filtered out for users who don't want that kind of thing). > > I'd think the solution is simply to mark your module with "Service > > Level: alpha" (and then we'd want some tooling where SL-alpha and > > SL-beta modules only show up for those who ask for them.) > If the definition of active stream (for stream expansion purposes) > were to exclude SL-alpha (and maybe SL-beta) streams in addition to > EOL ones, then yes, I think that would handle my/our concerns, as then > there would be a way to indicate that a *new* streams should be > considered inactive without needing to set a misleading EOL date. I think we'd probably _still_ want it active, because even if it fails, it's nice to know that sooner rather than later. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: CI projects in Copr
On Thu, Aug 31, 2017 at 1:47 PM, Pavel Raiskup wrote:
> On Thursday, August 31, 2017 11:43:08 AM CEST Michal Novotny wrote:
> > On Thu, Aug 31, 2017 at 8:43 AM, Pavel Raiskup
> wrote:
> > > I'm curious why you insist on 'make srpm'; that sounds like you try
> to push
> > > the copr users somewhere, to "standardize something".
> >
> > It's easier on implementation. That's the main reason. I generally
> believe
> > that what's easier on implementation is better.
>
> This is not first time we talk about this...
>
> (a) can you elaborate what's "easier" to implement on the 'make srpm' way?
>
> (b) shouldn't you make a life easier to your users? Even when I really
> like
> make, what's easier on "enforcing" Makefile existence to be able to
> enable CI in copr?
>
> (c) Wrong general belief, please, forget about that. Doing it wrong (== an
> "easier" way) in the beginning is much more expensive in the end (try
> to
> grep for "refactor" word...). The proposal is to have "one method"
> which suits everybody; and never touch it again. But yeah, no-thanks
> for
> not listening. Again.
>
a) you need an additional db field. you need to have more inputs in SCM
tabs when
one has a meaning only if 'custom' is selected in the srpm_generator select
(which
means you should hide/unhide that by js in frontend to have nice user
experience),
then on API, you need to have one selector (const argument) for
srpm_generator
and then another field (name of the script) that has meaning only if
'custom' has
been selected (that will occur on more places in the code). And having the
selector
in the first place is good because you can supply a default value and you
can implicitly point
users to the well-established tools where people can get more info about
them
and finally pick the tool most suitable for them. Additionally `make srpm`
carries the message
so user knows what's expected. There also needs to be some kind of
uniformity
because we need to put the output srpm into the predefined place (git repo
directory)
and also such scripts would usually tend to have similar names
(gen_srpm.py, make_srpm.pl),
so automatically it is good to have a predefined choice, I mean...why not.
You can call
your any_script.xyz from the Makefile. Everyone is familar with Makefiles
and likes them
(for simple things at least). It's a nice tradition. And the approach is
the same thing as defining a
callback method that is being called from a certain lib that goes back to
your code.
b) I like Makefiles for simple things, I think it's a neat choice. Also I
hope that the default
choice ('rpkg') will serve pretty well.
c) Note that you can cover your use-case (of any-name script) by simply
calling
that script by name from the Makefile if you want. So there is nothing to
be refactored.
>Ok, even better -> allow specifying custom command, like:
>Git Repo:
>something.somewhere.git/project/foo
>Command to get sources:
cd packaging/rpm/fedora ; SOMEVAR=something ./generate-rpm.sh --some-arg
>Packages needed to obtain sources:
help2man, gettext-devel, wget, git-lfs
>SRPM pattern:
packaging/rpm/fedora/xyz*.src.rpm
>The pattern is important; plus we should declare that only the first
matched
>srpm is going to be built.
This is already _very_ complicated at least for new users that we would
also like
to attract (in addition to satisfying power users).
So these are my reasons. I am willing to discuss this but at the same time
I don't
want to spend too much time on this because it really is an implementation
detail.
| Pavel
On Thu, Aug 31, 2017 at 1:47 PM, Pavel Raiskup wrote:
> On Thursday, August 31, 2017 11:43:08 AM CEST Michal Novotny wrote:
> > On Thu, Aug 31, 2017 at 8:43 AM, Pavel Raiskup
> wrote:
> > > I'm curious why you insist on 'make srpm'; that sounds like you try
> to push
> > > the copr users somewhere, to "standardize something".
> >
> > It's easier on implementation. That's the main reason. I generally
> believe
> > that what's easier on implementation is better.
>
> This is not first time we talk about this...
>
> (a) can you elaborate what's "easier" to implement on the 'make srpm' way?
>
> (b) shouldn't you make a life easier to your users? Even when I really
> like
> make, what's easier on "enforcing" Makefile existence to be able to
> enable CI in copr?
>
> (c) Wrong general belief, please, forget about that. Doing it wrong (== an
> "easier" way) in the beginning is much more expensive in the end (try
> to
> grep for "refactor" word...). The proposal is to have "one method"
> which suits everybody; and never touch it again. But yeah, no-thanks
> for
> not listening. Again.
>
> Pavel
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: CI projects in Copr
On Thursday, August 31, 2017 3:48:21 PM CEST Michal Novotny wrote:
> a) you need an additional db field. you need to have more inputs in SCM tabs
> when one has a meaning only if 'custom' is selected in the srpm_generator
> select (which means you should hide/unhide that by js in frontend to have nice
> user experience), then on API, you need to have one selector (const argument)
> for srpm_generator and then another field (name of the script) that has
> meaning only if 'custom' has been selected (that will occur on more places in
> the code).
False. With 'make srpm' you still want to specify where the Makefile is.
I hope you don't expect that the only-for-copr Makefiles will be added to
the root of all the project in the wild...
Anyway, I did not expected that you will complain about *one argument* in
API or anywhere else, that's nitpick. How expensive is that? :) I can
help you with this additional work, sure.
> And having the selector in the first place is good because you can supply a
> default value and you can implicitly point users to the well-established tools
> where people can get more info about them and finally pick the tool most
> suitable for them.
Off-topic, selector picks among tito/mock-scm/py2rpm/... or
arbitrary_script. Each method has an arguments.
> Additionally `make srpm` carries the message so user knows what's expected.
Why do you care how the end-user names the script? :)
> There also needs to be some kind of uniformity because we need to put the
> output srpm into the predefined place (git repo directory) and also such
> scripts would usually tend to have similar names (gen_srpm.py, make_srpm.pl),
> so automatically it is good to have a predefined choice, I mean...why not.
How the "name of the generating tool" reflects where the result SRPM is
put, and how "copr is going to import that"?
> You can call your any_script.xyz from the Makefile.
No, I __have to__, and that's the difference :) What's the benefit on
enforcing it?
> Everyone is familar with Makefiles and likes them (for simple things at
> least).
(rofl) I wish this was truth.
> It's a nice tradition. And the approach is the same thing as defining a
> callback method that is being called from a certain lib that goes back to your
> code.
>
> b) I like Makefiles for simple things, I think it's a neat choice. Also I
> hope that the default choice ('rpkg') will serve pretty well.
I like Makefiles too, but that's not about my/your preferences.
Yes, let's have rpkg/tito/mock-scm/xxx2rpm/.. methods to obtain sources, but
let's have also a fall-back option which matches everybody else. After
some time, we'll see how the fall-back is useful (and whether anybody
still uses other declarative and not-flexible methods...).
> c) Note that you can cover your use-case (of any-name script) by simply
> calling that script by name from the Makefile if you want. So there is nothing
> to be refactored.
Will ninja people install some Makefile only because of CI in Copr? So
you either will be adding ninja support (mistake), or you replace the
"make srpm" build option with general one (api change that annoys users).
That's the refactoring I'm talking about.
Thanks,
Pavel
> >Ok, even better -> allow specifying custom command, like:
>
> >Git Repo:
> >something.somewhere.git/project/foo
> >Command to get sources:
> cd packaging/rpm/fedora ; SOMEVAR=something ./generate-rpm.sh --some-arg
> >Packages needed to obtain sources:
> help2man, gettext-devel, wget, git-lfs
> >SRPM pattern:
> packaging/rpm/fedora/xyz*.src.rpm
>
> >The pattern is important; plus we should declare that only the first
> matched
> >srpm is going to be built.
>
> This is already _very_ complicated at least for new users that we would
> also like
> to attract (in addition to satisfying power users).
>
> So these are my reasons. I am willing to discuss this but at the same time
> I don't
> want to spend too much time on this because it really is an implementation
> detail.
>
> | Pavel
>
> On Thu, Aug 31, 2017 at 1:47 PM, Pavel Raiskup wrote:
>
> > On Thursday, August 31, 2017 11:43:08 AM CEST Michal Novotny wrote:
> > > On Thu, Aug 31, 2017 at 8:43 AM, Pavel Raiskup
> > wrote:
> > > > I'm curious why you insist on 'make srpm'; that sounds like you try
> > to push
> > > > the copr users somewhere, to "standardize something".
> > >
> > > It's easier on implementation. That's the main reason. I generally
> > believe
> > > that what's easier on implementation is better.
> >
> > This is not first time we talk about this...
> >
> > (a) can you elaborate what's "easier" to implement on the 'make srpm' way?
> >
> > (b) shouldn't you make a life easier to your users? Even when I really
> > like
> > make, what's easier on "enforcing" Makefile existence to be able to
> > enable CI in copr?
> >
> > (c) Wrong general belief, please, forget about that. Doing it wrong (== an
> > "easier" way) in the beginning is much more expen
Re: CI projects in Copr
Hello Pavel,
On Thu, Aug 31, 2017 at 4:37 PM, Pavel Raiskup wrote:
> On Thursday, August 31, 2017 3:48:21 PM CEST Michal Novotny wrote:
> > a) you need an additional db field. you need to have more inputs in SCM
> tabs
> > when one has a meaning only if 'custom' is selected in the srpm_generator
> > select (which means you should hide/unhide that by js in frontend to
> have nice
> > user experience), then on API, you need to have one selector (const
> argument)
> > for srpm_generator and then another field (name of the script) that has
> > meaning only if 'custom' has been selected (that will occur on more
> places in
> > the code).
>
> False. With 'make srpm' you still want to specify where the Makefile is.
> I hope you don't expect that the only-for-copr Makefiles will be added to
> the root of all the project in the wild...
>
> Anyway, I did not expected that you will complain about *one argument* in
> API or anywhere else, that's nitpick. How expensive is that? :) I can
> help you with this additional work, sure.
>
> > And having the selector in the first place is good because you can
> supply a
> > default value and you can implicitly point users to the well-established
> tools
> > where people can get more info about them and finally pick the tool most
> > suitable for them.
>
> Off-topic, selector picks among tito/mock-scm/py2rpm/... or
> arbitrary_script. Each method has an arguments.
>
> > Additionally `make srpm` carries the message so user knows what's
> expected.
>
> Why do you care how the end-user names the script? :)
>
> > There also needs to be some kind of uniformity because we need to put the
> > output srpm into the predefined place (git repo directory) and also such
> > scripts would usually tend to have similar names (gen_srpm.py,
> make_srpm.pl),
> > so automatically it is good to have a predefined choice, I mean...why
> not.
>
> How the "name of the generating tool" reflects where the result SRPM is
> put, and how "copr is going to import that"?
>
> > You can call your any_script.xyz from the Makefile.
>
> No, I __have to__, and that's the difference :) What's the benefit on
> enforcing it?
>
> > Everyone is familar with Makefiles and likes them (for simple things at
> > least).
>
> (rofl) I wish this was truth.
>
> > It's a nice tradition. And the approach is the same thing as defining a
> > callback method that is being called from a certain lib that goes back
> to your
> > code.
> >
> > b) I like Makefiles for simple things, I think it's a neat choice. Also I
> > hope that the default choice ('rpkg') will serve pretty well.
>
> I like Makefiles too, but that's not about my/your preferences.
>
> Yes, let's have rpkg/tito/mock-scm/xxx2rpm/.. methods to obtain sources,
> but
> let's have also a fall-back option which matches everybody else. After
> some time, we'll see how the fall-back is useful (and whether anybody
> still uses other declarative and not-flexible methods...).
>
> > c) Note that you can cover your use-case (of any-name script) by simply
> > calling that script by name from the Makefile if you want. So there is
> nothing
> > to be refactored.
>
> Will ninja people install some Makefile only because of CI in Copr? So
> you either will be adding ninja support (mistake), or you replace the
> "make srpm" build option with general one (api change that annoys users).
> That's the refactoring I'm talking about.
>
> Thanks,
> Pavel
>
Please, let's have an off-line talk. I think I can better clarify why I
think `make srpm`
is the best. It's mostly about where we are now and where we need to get.
Or if there is a concrete use-case that you know that will break, please
tell, so that
we can find a solution immediately.
But I think an off-line talk might be the best. Depends on you.
>
> > >Ok, even better -> allow specifying custom command, like:
> >
> > >Git Repo:
> > >something.somewhere.git/project/foo
> > >Command to get sources:
> > cd packaging/rpm/fedora ; SOMEVAR=something ./generate-rpm.sh
> --some-arg
> > >Packages needed to obtain sources:
> > help2man, gettext-devel, wget, git-lfs
> > >SRPM pattern:
> > packaging/rpm/fedora/xyz*.src.rpm
> >
> > >The pattern is important; plus we should declare that only the first
> > matched
> > >srpm is going to be built.
> >
> > This is already _very_ complicated at least for new users that we would
> > also like
> > to attract (in addition to satisfying power users).
> >
> > So these are my reasons. I am willing to discuss this but at the same
> time
> > I don't
> > want to spend too much time on this because it really is an
> implementation
> > detail.
> >
> > | Pavel
> >
> > On Thu, Aug 31, 2017 at 1:47 PM, Pavel Raiskup
> wrote:
> >
> > > On Thursday, August 31, 2017 11:43:08 AM CEST Michal Novotny wrote:
> > > > On Thu, Aug 31, 2017 at 8:43 AM, Pavel Raiskup
> > > wrote:
> > > > > I'm curious why you insist on 'make srpm'; that sounds like you
> try
> > > to push
> > > > > the copr users some
Fedora Rawhide-20170830.n.1 compose check report
Missing expected images: Workstation live i386 Server boot i386 Kde live i386 Failed openQA tests: 81/126 (x86_64), 18/18 (i386), 1/2 (arm) New failures (same test did not fail in Rawhide-20170828.n.0): ID: 135993 Test: x86_64 Workstation-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/135993 ID: 135997 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/135997 ID: 136001 Test: x86_64 Workstation-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/136001 ID: 136003 Test: x86_64 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/136003 ID: 136010 Test: x86_64 KDE-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/136010 ID: 136014 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/136014 ID: 136018 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/136018 ID: 136037 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/136037 ID: 136038 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/136038 ID: 136039 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/136039 ID: 136042 Test: x86_64 universal install_repository_http_variation URL: https://openqa.fedoraproject.org/tests/136042 ID: 136043 Test: x86_64 universal install_repository_http_graphical URL: https://openqa.fedoraproject.org/tests/136043 ID: 136078 Test: x86_64 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/136078 ID: 136097 Test: i386 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/136097 ID: 136099 Test: i386 universal install_repository_http_graphical URL: https://openqa.fedoraproject.org/tests/136099 Old failures (same test failed in Rawhide-20170828.n.0): ID: 135965 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/135965 ID: 135966 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/135966 ID: 135967 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/135967 ID: 135974 Test: x86_64 Server-dvd-iso install_repository_nfs_variation URL: https://openqa.fedoraproject.org/tests/135974 ID: 135975 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/135975 ID: 135984 Test: x86_64 Server-dvd-iso install_updates_nfs URL: https://openqa.fedoraproject.org/tests/135984 ID: 135986 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/135986 ID: 135988 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/135988 ID: 135990 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/135990 ID: 135991 Test: x86_64 Workstation-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/135991 ID: 136004 Test: x86_64 Workstation-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/136004 ID: 136005 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/136005 ID: 136007 Test: x86_64 KDE-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/136007 ID: 136019 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/136019 ID: 136021 Test: x86_64 universal install_package_set_minimal URL: https://openqa.fedoraproject.org/tests/136021 ID: 136022 Test: x86_64 universal install_anaconda_text URL: https://openqa.fedoraproject.org/tests/136022 ID: 136023 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/136023 ID: 136024 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/136024 ID: 136025 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/136025 ID: 136027 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/136027 ID: 136028 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/136028 ID: 136029 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/136029 ID: 136030 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/136030 ID: 136031 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/136031 ID: 136032 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/13603
FAILED: BuildError: package ... not in list for tag f28-pending
It's been several hours since this entirely new package repo has been created, but the koji build still fails. How long does it take for koji to learn about this new package? $ fedpkg build Building ampache_browser-1.0.0-1.fc28 for rawhide Created task: 21592583 Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=21592583 Watching tasks (this may be safely interrupted)... 21592583 build (rawhide, /rpms/ampache_browser:d7627e20f2a306bb1f53d39c182280c3c991fe15): open (buildhw-08.phx2.fedoraproject.org) 21592584 buildSRPMFromSCM (/rpms/ampache_browser:d7627e20f2a306bb1f53d39c182280c3c991fe15): free 21592584 buildSRPMFromSCM (/rpms/ampache_browser:d7627e20f2a306bb1f53d39c182280c3c991fe15): free -> open (buildvm-s390x-13.s390.fedoraproject.org) 21592584 buildSRPMFromSCM (/rpms/ampache_browser:d7627e20f2a306bb1f53d39c182280c3c991fe15): open (buildvm-s390x-13.s390.fedoraproject.org) -> closed 0 free 1 open 1 done 0 failed 21592583 build (rawhide, /rpms/ampache_browser:d7627e20f2a306bb1f53d39c182280c3c991fe15): open (buildhw-08.phx2.fedoraproject.org) -> FAILED: BuildError: package ampache_browser not in list for tag f28-pending 0 free 0 open 1 done 1 failed 21592583 build (rawhide, /rpms/ampache_browser:d7627e20f2a306bb1f53d39c182280c3c991fe15) failed ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: FAILED: BuildError: package ... not in list for tag f28-pending
Am 31.08.2017 um 21:36 schrieb Michael Schwendt: It's been several hours since this entirely new package repo has been created, but the koji build still fails. How long does it take for koji to learn about this new package? $ fedpkg build Building ampache_browser-1.0.0-1.fc28 for rawhide Created task: 21592583 Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=21592583 Watching tasks (this may be safely interrupted)... 21592583 build (rawhide, /rpms/ampache_browser:d7627e20f2a306bb1f53d39c182280c3c991fe15): open (buildhw-08.phx2.fedoraproject.org) 21592584 buildSRPMFromSCM (/rpms/ampache_browser:d7627e20f2a306bb1f53d39c182280c3c991fe15): free 21592584 buildSRPMFromSCM (/rpms/ampache_browser:d7627e20f2a306bb1f53d39c182280c3c991fe15): free -> open (buildvm-s390x-13.s390.fedoraproject.org) 21592584 buildSRPMFromSCM (/rpms/ampache_browser:d7627e20f2a306bb1f53d39c182280c3c991fe15): open (buildvm-s390x-13.s390.fedoraproject.org) -> closed 0 free 1 open 1 done 0 failed 21592583 build (rawhide, /rpms/ampache_browser:d7627e20f2a306bb1f53d39c182280c3c991fe15): open (buildhw-08.phx2.fedoraproject.org) -> FAILED: BuildError: package ampache_browser not in list for tag f28-pending 0 free 0 open 1 done 1 failed 21592583 build (rawhide, /rpms/ampache_browser:d7627e20f2a306bb1f53d39c182280c3c991fe15) failed Hello Michael, it takes as long someone from releng tells Koji manually about it… It can take up to one day. Cheers, Björn ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: CI projects in Copr
Quack, On 09/01/2017 01:28 AM, Michal Novotny wrote: > But I think an off-line talk might be the best. Depends on you. I can understand you don't want this thread to end-up in flames, and yes sometimes it helps to have a live direct talk, but this also means the rest of this list is kept out. I think it would be best to improve on collaborative talks together. Also being asked for rational may seem boring but is really necessary to understand each-other and is in no way a provocative behavior, even if Pavel seems to like teasing you :-). I'm really new in here, I'm only using Copr/mock-scm and besides a few bugs it really suit my simple needs, so I don't have any good suggestion myself because I don't have a clear view on the need. Nevertheless I was following the thread so far so I'd like to be able to continue doing so if I like. So if you persist on having private talks, then at least please post a sum-up here for the rest of the world. Thanks. \_o< signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
