Hi, I want to highlight https://bugzilla.redhat.com/show_bug.cgi?id=1381790
Right now we have rawhide target and when new chroot (e.g. F26) we copy everything from rawhide to F26.
This RFE as for the reverse. I.e. there is no rawhide at all. Rawhide is named F26 and when there is branching of F26 we add new chroot named F27.
I would love to hear your comments.
On 10/06/2016 08:55 AM, Miroslav Suchý wrote:
Hi, I want to highlight https://bugzilla.redhat.com/show_bug.cgi?id=1381790
Right now we have rawhide target and when new chroot (e.g. F26) we copy everything from rawhide to F26.
This RFE as for the reverse. I.e. there is no rawhide at all. Rawhide is named F26 and when there is branching of F26 we add new chroot named F27.
I would love to hear your comments.
I have a strong opinion against that proposal. IMHO rawhide chroot in Copr should have fixed name, repo URLs etc. Builds done years ago should still be available. Other services in Fedora use a similar approach: PkgDB has "Fedora devel" collection, dist-git has "master" branch, Koji has "rawhide" repo and build target and so on. Developers who focus their development work on rawhide don't even need to know or care about branching.
Personally, I mostly care about rawhide. Some of my Copr projects that I still use were created about 2.5 years ago, but they are still rawhide-only. It seems like with this proposal I would have to remember to switch chroots in Copr and fix repo URLs in all the places where I use them.
What would happen with builds? For me the idea of re-running them, in correct order, re-bootstrapping, fixing FTBFS etc. sounds a lot like asking users to move away from Copr to something else (or switch to using custom-1 chroot with rawhide repos).
The current state is that 'rawhide' is going to be renamed to f26. I'll additionally setup aliases (or redirects) from
/results/*/*/fedora-rawhide-$basearch/ *to* /results/*/*/fedora-26-$basearch/
so that no links are lost.
There will be no need to rebuild any existing builds.
On Thu, Oct 6, 2016 at 9:44 AM, Mikolaj Izdebski mizdebsk@redhat.com wrote:
On 10/06/2016 08:55 AM, Miroslav Suchý wrote:
Hi, I want to highlight https://bugzilla.redhat.com/show_bug.cgi?id=1381790
Right now we have rawhide target and when new chroot (e.g. F26) we copy
everything from rawhide to F26.
This RFE as for the reverse. I.e. there is no rawhide at all. Rawhide is
named F26 and when there is branching of F26 we
add new chroot named F27.
I would love to hear your comments.
I have a strong opinion against that proposal. IMHO rawhide chroot in Copr should have fixed name, repo URLs etc. Builds done years ago should still be available. Other services in Fedora use a similar approach: PkgDB has "Fedora devel" collection, dist-git has "master" branch, Koji has "rawhide" repo and build target and so on. Developers who focus their development work on rawhide don't even need to know or care about branching.
Personally, I mostly care about rawhide. Some of my Copr projects that I still use were created about 2.5 years ago, but they are still rawhide-only. It seems like with this proposal I would have to remember to switch chroots in Copr and fix repo URLs in all the places where I use them.
What would happen with builds? For me the idea of re-running them, in correct order, re-bootstrapping, fixing FTBFS etc. sounds a lot like asking users to move away from Copr to something else (or switch to using custom-1 chroot with rawhide repos).
-- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk _______________________________________________ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-leave@lists.fedorahosted.org
Hi Michal,
On Monday, October 10, 2016 4:39:11 PM CEST Michal Novotny wrote:
The current state is that 'rawhide' is going to be renamed to f26.
I'll additionally setup aliases (or redirects) from
/results/*/*/fedora-rawhide-$basearch/ *to* /results/*/*/fedora-26-$basearch/
so that no links are lost.
There will be no need to rebuild any existing builds.
How exactly users will use the aliases links? Should I think about those aliases too in internal Copr?
Pavel
The lighttpd aliases/redirects will be good to keep copr project's baseurls with *rawhide* in it working. You might want to use those.
On Mon, Oct 10, 2016 at 5:10 PM, Pavel Raiskup praiskup@redhat.com wrote:
Hi Michal,
On Monday, October 10, 2016 4:39:11 PM CEST Michal Novotny wrote:
The current state is that 'rawhide' is going to be renamed to f26.
I'll additionally setup aliases (or redirects) from
/results/*/*/fedora-rawhide-$basearch/ *to* /results/*/*/fedora-26-$
basearch/
so that no links are lost.
There will be no need to rebuild any existing builds.
How exactly users will use the aliases links? Should I think about those aliases too in internal Copr?
Pavel
On Monday, October 10, 2016 11:55:48 PM CEST Michal Novotny wrote:
The lighttpd aliases/redirects will be good to keep copr project's baseurls with *rawhide* in it working. You might want to use those.
I still don't get it, even the resolution of the bugzilla from this thread...
The question is: Who is going to consume `fedora-26-x86_64` fedora repo *now*, at the time when f26 == fawhide. I'm not against creating the aliases, I'm just asking who is the consumer.
What happens with `--chroot fedora-rawhide-x86_64` after https://github.com/fedora-copr/copr/commit/9ef053b3 ..? There's no longer fedora-rawhide-* chroot, even though from discussion it looks like this is not what most of us want? What's going to happen with `dnf copr enable USER/COPR` on rawhide?
Pavel
Could we have copr for F25 ? and in the future for other branched repos ? Please .
Thanks !
On Seg, 2016-10-10 at 16:39 +0200, Michal Novotny wrote:
The current state is that 'rawhide' is going to be renamed to f26. I'll additionally setup aliases (or redirects) from /results/*/*/fedora-rawhide-$basearch/ to /results/*/*/fedora-26- $basearch/ so that no links are lost. There will be no need to rebuild any existing builds.
On Thu, Oct 6, 2016 at 9:44 AM, Mikolaj Izdebski <mizdebsk@redhat.com
wrote: On 10/06/2016 08:55 AM, Miroslav Suchý wrote:
Hi, I want to highlight https://bugzilla.redhat.com/show_bug.cgi?id=1381790
Right now we have rawhide target and when new chroot (e.g. F26)
we copy everything from rawhide to F26.
This RFE as for the reverse. I.e. there is no rawhide at all.
Rawhide is named F26 and when there is branching of F26 we
add new chroot named F27.
I would love to hear your comments.
I have a strong opinion against that proposal. IMHO rawhide chroot in Copr should have fixed name, repo URLs etc. Builds done years ago should still be available. Other services in Fedora use a similar approach: PkgDB has "Fedora devel" collection, dist-git has "master" branch, Koji has "rawhide" repo and build target and so on. Developers who focus their development work on rawhide don't even need to know or care about branching.
Personally, I mostly care about rawhide. Some of my Copr projects that I still use were created about 2.5 years ago, but they are still rawhide-only. It seems like with this proposal I would have to remember to switch chroots in Copr and fix repo URLs in all the places where I use them.
What would happen with builds? For me the idea of re-running them, in correct order, re-bootstrapping, fixing FTBFS etc. sounds a lot like asking users to move away from Copr to something else (or switch to using custom-1 chroot with rawhide repos).
-- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk _______________________________________________ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-leave@lists.fedorahosted .org
copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-leave@lists.fedorahosted.o rg
Hi Sérgio,
On Monday, October 10, 2016 5:45:02 PM CEST Sérgio Basto wrote:
Could we have copr for F25 ? and in the future for other branched repos ? Please .
Thanks !
What is wrong with F25 at this point?
Pavel
On Seg, 2016-10-10 at 16:39 +0200, Michal Novotny wrote:
The current state is that 'rawhide' is going to be renamed to f26. I'll additionally setup aliases (or redirects) from /results/*/*/fedora-rawhide-$basearch/ to /results/*/*/fedora-26- $basearch/ so that no links are lost. There will be no need to rebuild any existing builds.
On Thu, Oct 6, 2016 at 9:44 AM, Mikolaj Izdebski <mizdebsk@redhat.com
wrote: On 10/06/2016 08:55 AM, Miroslav Suchý wrote:
Hi, I want to highlight https://bugzilla.redhat.com/show_bug.cgi?id=1381790
Right now we have rawhide target and when new chroot (e.g. F26)
we copy everything from rawhide to F26.
This RFE as for the reverse. I.e. there is no rawhide at all.
Rawhide is named F26 and when there is branching of F26 we
add new chroot named F27.
I would love to hear your comments.
I have a strong opinion against that proposal. IMHO rawhide chroot in Copr should have fixed name, repo URLs etc. Builds done years ago should still be available. Other services in Fedora use a similar approach: PkgDB has "Fedora devel" collection, dist-git has "master" branch, Koji has "rawhide" repo and build target and so on. Developers who focus their development work on rawhide don't even need to know or care about branching.
Personally, I mostly care about rawhide. Some of my Copr projects that I still use were created about 2.5 years ago, but they are still rawhide-only. It seems like with this proposal I would have to remember to switch chroots in Copr and fix repo URLs in all the places where I use them.
What would happen with builds? For me the idea of re-running them, in correct order, re-bootstrapping, fixing FTBFS etc. sounds a lot like asking users to move away from Copr to something else (or switch to using custom-1 chroot with rawhide repos).
-- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk _______________________________________________ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-leave@lists.fedorahosted .org
copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-leave@lists.fedorahosted.o rg
Dne 10.10.2016 v 18:45 Sérgio Basto napsal(a):
Could we have copr for F25 ? and in the future for other branched repos ? Please .
There is fedora-25-* in Copr for more than month already.
On Tuesday, October 11, 2016 8:21:15 AM CEST Miroslav Suchý wrote:
Dne 10.10.2016 v 18:45 Sérgio Basto napsal(a):
Could we have copr for F25 ? and in the future for other branched repos ? Please .
There is fedora-25-* in Copr for more than month already.
I guess I understand; Sérgio asks to have e.g. fedora-25-x86_64 repository automatically created from fedora-rawhide-x86_64.
Pavel
On Ter, 2016-10-11 at 08:25 +0200, Pavel Raiskup wrote:
On Tuesday, October 11, 2016 8:21:15 AM CEST Miroslav Suchý wrote:
Dne 10.10.2016 v 18:45 Sérgio Basto napsal(a):
Could we have copr for F25 ? and in the future for other branched repos ? Please .
There is fedora-25-* in Copr for more than month already.
I guess I understand; Sérgio asks to have e.g. fedora-25-x86_64 repository automatically created from fedora-rawhide-x86_64.
I'm checking now , yes, none of my project have f25 buildroots enabled, when f25 was created, projects should (IMHO) inherited same configuration of rawhide .
So yes ," Sérgio asks to have e.g. fedora-25-x86_64 repository automatically created from fedora-rawhide-x86_64 ".
Thanks.
On Ter, 2016-10-11 at 13:02 +0100, Sérgio Basto wrote:
On Ter, 2016-10-11 at 08:25 +0200, Pavel Raiskup wrote:
On Tuesday, October 11, 2016 8:21:15 AM CEST Miroslav Suchý wrote:
Dne 10.10.2016 v 18:45 Sérgio Basto napsal(a):
Could we have copr for F25 ? and in the future for other branched repos ? Please .
There is fedora-25-* in Copr for more than month already.
I guess I understand; Sérgio asks to have e.g. fedora-25-x86_64 repository automatically created from fedora-rawhide-x86_64.
I'm checking now , yes, none of my project have f25 buildroots enabled, when f25 was created, projects should (IMHO) inherited same configuration of rawhide .
So yes ," Sérgio asks to have e.g. fedora-25-x86_64 repository automatically created from fedora-rawhide-x86_64 ".
And checking other projects in copr , all projects that I checked also don't have f25 buildroots enabled , so maybe it not a bad idea apply the rule right now .
Thanks.
On Tuesday, October 11, 2016 1:13:55 PM CEST Sérgio Basto wrote:
On Ter, 2016-10-11 at 13:02 +0100, Sérgio Basto wrote:
On Ter, 2016-10-11 at 08:25 +0200, Pavel Raiskup wrote:
On Tuesday, October 11, 2016 8:21:15 AM CEST Miroslav Suchý wrote:
Dne 10.10.2016 v 18:45 Sérgio Basto napsal(a):
Could we have copr for F25 ? and in the future for other branched repos ? Please .
There is fedora-25-* in Copr for more than month already.
I guess I understand; Sérgio asks to have e.g. fedora-25-x86_64 repository automatically created from fedora-rawhide-x86_64.
I'm checking now , yes, none of my project have f25 buildroots enabled, when f25 was created, projects should (IMHO) inherited same configuration of rawhide .
So yes ," Sérgio asks to have e.g. fedora-25-x86_64 repository automatically created from fedora-rawhide-x86_64 ".
And checking other projects in copr , all projects that I checked also don't have f25 buildroots enabled , so maybe it not a bad idea apply the rule right now .
Thanks, isn't _this_ exactly what the bug https://bugzilla.redhat.com/show_bug.cgi?id=1381790 is about? Which would mean (in case we made what Sérgio suggests) _no change_ in rawhide policy is actually needed in copr?
Thanks for clarification, Pavel
On Tuesday, October 11, 2016 1:13:55 PM CEST Sérgio Basto wrote:
On Ter, 2016-10-11 at 13:02 +0100, Sérgio Basto wrote:
On Ter, 2016-10-11 at 08:25 +0200, Pavel Raiskup wrote:
On Tuesday, October 11, 2016 8:21:15 AM CEST Miroslav Suchý wrote:
Dne 10.10.2016 v 18:45 Sérgio Basto napsal(a):
Could we have copr for F25 ? and in the future for other branched repos ? Please .
There is fedora-25-* in Copr for more than month already.
I guess I understand; Sérgio asks to have e.g. fedora-25-x86_64 repository automatically created from fedora-rawhide-x86_64.
I'm checking now , yes, none of my project have f25 buildroots enabled, when f25 was created, projects should (IMHO) inherited same configuration of rawhide .
So yes ," Sérgio asks to have e.g. fedora-25-x86_64 repository automatically created from fedora-rawhide-x86_64 ".
And checking other projects in copr , all projects that I checked also don't have f25 buildroots enabled , so maybe it not a bad idea apply the rule right now .
After off-list discussion with Copr admins, this is already implemented, should be simple as `./manage.py rawhide_to_release A B` run by copr administractor, though I haven't had a chance to experiment with it yet.
Pavel
On Qui, 2016-10-13 at 10:56 +0200, Pavel Raiskup wrote:
On Tuesday, October 11, 2016 1:13:55 PM CEST Sérgio Basto wrote:
On Ter, 2016-10-11 at 13:02 +0100, Sérgio Basto wrote:
On Ter, 2016-10-11 at 08:25 +0200, Pavel Raiskup wrote:
On Tuesday, October 11, 2016 8:21:15 AM CEST Miroslav Suchý wrote:
Dne 10.10.2016 v 18:45 Sérgio Basto napsal(a):
Could we have copr for F25 ? and in the future for other branched repos ? Please .
There is fedora-25-* in Copr for more than month already.
I guess I understand; Sérgio asks to have e.g. fedora-25- x86_64 repository automatically created from fedora-rawhide-x86_64.
I'm checking now , yes, none of my project have f25 buildroots enabled, when f25 was created, projects should (IMHO) inherited same configuration of rawhide .
So yes ," Sérgio asks to have e.g. fedora-25-x86_64 repository automatically created from fedora-rawhide-x86_64 ".
And checking other projects in copr , all projects that I checked also don't have f25 buildroots enabled , so maybe it not a bad idea apply the rule right now .
After off-list discussion with Copr admins, this is already implemented, should be simple as `./manage.py rawhide_to_release A B` run by copr administractor, though I haven't had a chance to experiment with it yet.
(Now also to the list)
yes , I remember that [1] , now that we have one disynchronization , may be we should have this as a tool for each user :) (joking). but if user/project don't have any F25 buildroot maybe can be applied , I don't know , as have to decided how do that or if do that .
[1] https://lists.fedoraproject.org/archives/list/copr-devel@lists.fedorahosted....
Pavel
On 10/10/2016 04:39 PM, Michal Novotny wrote:
The current state is that 'rawhide' is going to be renamed to f26. I'll additionally setup aliases (or redirects) from
/results/*/*/fedora-rawhide-$basearch/ *to* /results/*/*/fedora-26-$basearch/
What happens when f27 chroot is created? Will these rawhide aliases suddenly start pointing f27, or will they keep pointing to f26 forever?
No aliases in API? Will users need to update all their scripts, and repeat this step after every branching event? Which in Copr is not even aligned with Fedora schedule...
There will be no need to rebuild any existing builds.
Do you mean that builds from f26 chroot be imported to f27 when it gets created, and so on?
On Thursday, October 6, 2016 8:55:29 AM CEST Miroslav Suchý wrote:
Hi, I want to highlight https://bugzilla.redhat.com/show_bug.cgi?id=1381790
Right now we have rawhide target and when new chroot (e.g. F26) we copy everything from rawhide to F26.
This is really good approach, IMO; I mean if that worked, but I reported in separate thread some time ago that one of my repositories was not fixed this way.
RFE1: It is definitely worth publishing logs from relevant script so users can themselves debug and report bugs.
RFE2: It would be nice to have a possibility (opt-in) to do package rebuilds at (before?) branching time. IOW mass-rebuild alternative .. and notify owners that his package doesn't build anymore.
This RFE as for the reverse. I.e. there is no rawhide at all. Rawhide is named F26 and when there is branching of F26 we add new chroot named F27.
I always thought about Rawhide as about "almost rolling updates distro", and if that is correct understanding, supplemental COPR repos should comply.
Pavel
On 10/06/2016 06:30 PM, Pavel Raiskup wrote:
On Thursday, October 6, 2016 8:55:29 AM CEST Miroslav Suchý wrote: RFE2: It would be nice to have a possibility (opt-in) to do package rebuilds at (before?) branching time. IOW mass-rebuild alternative .. and notify owners that his package doesn't build anymore.
Sounds like you are asking for Koschei for Copr. We are working on first bits of integration right now. See: https://github.com/msimacek/koschei/issues/113
On Thursday, October 6, 2016 6:34:02 PM CEST Mikolaj Izdebski wrote:
On 10/06/2016 06:30 PM, Pavel Raiskup wrote:
On Thursday, October 6, 2016 8:55:29 AM CEST Miroslav Suchý wrote: RFE2: It would be nice to have a possibility (opt-in) to do package rebuilds at (before?) branching time. IOW mass-rebuild alternative .. and notify owners that his package doesn't build anymore.
Sounds like you are asking for Koschei for Copr. We are working on first bits of integration right now. See: https://github.com/msimacek/koschei/issues/113
Maybe. I'm not sure, there are good reasons to rebuild packages periodically.
I.e. I would appreciate "production" builds done automatically and be informed only when something goes wrong. It could be done by Koschei, it would be fine.
Do we plan to replace mass-rebulids in Fedora Koschei, too? Or maybe mass rebuilds are planned to be less frequent now?
Pavel
Re-citing Mikolaj's comment: | Sounds like you are asking for Koschei for Copr. | We are working on first bits of integration right now. | See: https://github.com/msimacek/koschei/issues/113
On Friday, October 7, 2016 5:29:21 PM CEST clime@redhat.com wrote:
I am very much asking for that. Thanks!
I'm all for Koschei for Copr too. Just wanted to say that the original RFE I menteioned is not exactly the same. At least if I understand Koschei purpose (trigger a testing build if some dependency changed).
Pavel
On 10/11/2016 07:05 AM, Pavel Raiskup wrote:
Re-citing Mikolaj's comment: | Sounds like you are asking for Koschei for Copr. | We are working on first bits of integration right now. | See: https://github.com/msimacek/koschei/issues/113
On Friday, October 7, 2016 5:29:21 PM CEST clime@redhat.com wrote:
I am very much asking for that. Thanks!
I'm all for Koschei for Copr too. Just wanted to say that the original RFE I menteioned is not exactly the same. At least if I understand Koschei purpose (trigger a testing build if some dependency changed).
Since there are no scratch builds in Copr, "testing builds" need to be simulated by building in separate Copr project, with appropriate repos added and createrepo disabled. Doing "real builds" is almost the same thing.
On Tuesday, October 11, 2016 8:11:16 AM CEST Mikolaj Izdebski wrote:
Since there are no scratch builds in Copr, "testing builds" need to be simulated by building in separate Copr project, with appropriate repos added and createrepo disabled. Doing "real builds" is almost the same thing.
So? :) Is Koschei going to do the "real builds" in Copr?
Pavel
On 10/11/2016 08:17 AM, Pavel Raiskup wrote:
On Tuesday, October 11, 2016 8:11:16 AM CEST Mikolaj Izdebski wrote:
Since there are no scratch builds in Copr, "testing builds" need to be simulated by building in separate Copr project, with appropriate repos added and createrepo disabled. Doing "real builds" is almost the same thing.
So? :) Is Koschei going to do the "real builds" in Copr?
Yes.
The current plan is that Koschei will create separate project in Copr, add your project as external repo and run builds. Then if you want, you can import them into your Copr by "forking" Koschei-created Copr.
On Tuesday, October 11, 2016 8:21:46 AM CEST Mikolaj Izdebski wrote:
On 10/11/2016 08:17 AM, Pavel Raiskup wrote:
On Tuesday, October 11, 2016 8:11:16 AM CEST Mikolaj Izdebski wrote:
Since there are no scratch builds in Copr, "testing builds" need to be simulated by building in separate Copr project, with appropriate repos added and createrepo disabled. Doing "real builds" is almost the same thing.
So? :) Is Koschei going to do the "real builds" in Copr?
Yes.
The current plan is that Koschei will create separate project in Copr, add your project as external repo and run builds. Then if you want, you can import them into your Copr by "forking" Koschei-created Copr.
Sounds good, thanks.
On Qui, 2016-10-06 at 08:55 +0200, Miroslav Suchý wrote:
Hi, I want to highlight https://bugzilla.redhat.com/show_bug.cgi?id=1381790
Right now we have rawhide target and when new chroot (e.g. F26) we copy everything from rawhide to F26.
This RFE as for the reverse. I.e. there is no rawhide at all. Rawhide is named F26 and when there is branching of F26 we add new chroot named F27.
I would love to hear your comments.
IMHO , should have same rules of Fedora it self i.e. , when Fedora declare F22 EOL. and branched F25, Copr should do the same remove F22 buildroot and add F25 buildroot, which IMO could be done at same time. I also missed F25 branch in copr, i.e. dnf repoquery --releasever=25 result in "Failed to synchronize cache" for every copr repo that I had enabled ... branch F25 , means do a branch named F25 with one copy of rawhide.
Best regards,
copr-devel@lists.fedorahosted.org
-
Michal Novotny -
Mikolaj Izdebski -
Miroslav Suchý -
Pavel Raiskup -
Sérgio Basto