Re: Copr Build System - review of 2019 and vote for features in 2020

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> For what it's worth, I never got the promised notification for my Coprs.
> The legacy chroots are just gone forever with no warning whatsoever.

I am truly sorry to hear that. I am afraid, that there is no way to recover
those data. Thank you for reporting it though, I have investigated the
issue and did as much as I could to prevent it from happening in the future.

I wrote some unit tests for the feature and more importantly
added a constraint, so we won't remove any chroot, that we haven't sent
a notification email about. I have also found a possible cause of the issue,
so I temporarily disabled the feature.

Tests, fix, and explanation in https://pagure.io/copr/copr/pull-request/1229


Jakub

On Mon, Jan 20, 2020 at 1:09 PM Kevin Kofler <kevin.kofler@xxxxxxxxx> wrote:
>
> Neal Gompa wrote:
> > * building containers, ISOs, disk images
>
> +1 (at least installable live ISOs).
>
> > using kiwi and/or appliance-tools+livecd-tools/lorax
>
> I vote for livecd-creator from livecd-tools, it is the easiest to use
> (and in particular, livecd-creator accepts kickstarts from livemedia-creator
> with little to no changes, whereas the opposite requires many more changes),
> the easiest to do local testing with (because it supports caching
> packages without complicated workarounds), and probably also the easiest to
> integrate into the Copr setup (because it has less stringent setup
> requirements).
>
> (Neal, I know I don't have to explain the rationale to YOU, but the
> other readers should know the rationale. :-) )
>
> > * automatic rebuilds of packages when dependencies change
>
> I am not sure about that one. I would at least like it to be optional
> if implemented (because I would probably not enable it for most of my
> Coprs), and I am concerned about the resource usage.
>
> > The second item would make Rawhide builds so much more useful since
> > they won't just silently remain broken.
>
> Most likely they'll just fail to build instead of silently failing
> to install. ;-) (And then they'll still fail to install because there was
> no successful rebuild.)
>
> Sure, there are cases where a straight rebuild (for a new dependency
> soname) will help, but judging from my experience with Rawhide FTBFSes,
> often, a rebuild with no changes won't even succeed where no soname was
> bumped (and soname bumps typically indicate some API change that makes it
> more likely that the rebuild will fail).
>
>         Kevin Kofler
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux