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(a)chello.at> 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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org