fedora-review 0.7.3 supports RPMFusion configs again !!
Hi, fedora-review 0.7.3 was push to updates-stable yesterday (in Fedora repos) and seems that is working with RPMfusion and bugzila again [1] Best regards, [1] fedora-review --other-bz https://bugzilla.rpmfusion.org -b 5163 -m fedora-rawhide-x86_64-rpmfusion_free report.txt Generated by fedora-review 0.7.3 (44b83c7) last change: 2019-09-18 -- Sérgio M. B. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Testing upgrade to F31: qt5-qtwebengine-freeworld errors
Leigh Scott wrote: > If you don't do it your package will sit in update-testing forever, I > don't have time to monitor bodhi for shit I don't use! Either that or it's > get pushed whenever regardless or the matching fedora package. I don't > give a damn if it breaks, It's your job to coordinate not mine! I appreciate the work you are doing on RPM Fusion, but could you please be less aggressive? It is quite rude to call any package you don't use yourself "shit". That you don't have time to monitor Bodhi for the Fedora updates is one thing (and Nicolas is right that the solution would ultimately be to script this somehow, if somebody finds the time to implement that), but your rude reaction to the explicit request to move the F29 package (which would have been a one-line command) was already unnecessary. I was simply not aware that I can run the command myself and could have been told so politely. I have never actually asked you to watch Bodhi, just to move the package on my explicit request. Now, the reason I think the self-service approach is not ideal is because there are necessarily some restrictions (e.g., random packagers should not be allowed to mess with the GA repos for already released versions), so handling prereleases like currently F31 leaves room for mistakes. I hope that we can continue working with each other rather than against each other. Hopefully, we can get the infrastructure warts that make this painful for you and/or for us individual packagers sorted out. I realize that we are all very busy. I am, too (which is why I am not yet promising to look into the infrastructure scripts). That said, thanks for moving the F31 package on to the proper tag! Kind regards, Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Testing upgrade to F31: qt5-qtwebengine-freeworld errors
Nicolas Chauvet wrote: > There is a need to adapt the koji policy in this case. Or do you > managed to move it to updates once the package was moved back to > testing ? The Koji policy allows moving from updates-testing to updates, but not from updates to f31-free (GA) nor from updates back to updates-testing. In this case, Leigh moved it from f31-free-updates to f31-free, so it should be where it belongs now, thanks! Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Testing upgrade to F31: qt5-qtwebengine-freeworld errors
Le ven. 20 sept. 2019 à 00:25, Kevin Kofler a écrit : > > Kevin Kofler wrote: > > I have submitted http://koji.rpmfusion.org/koji/taskinfo?taskID=358046 . > > The build succeeded on Tuesday: > http://koji.rpmfusion.org/koji/buildinfo?buildID=12008 > and went out to the updates-testing repo. > > Now, I accidentally moved it to f31-free-updates, which was not a good idea > because it should really be in f31-free GA, I think. I only realized this > when I had already run the tag move. But now I can't move it to f31-free nor > even back to f31-free-updates-testing, so I need an admin to move it to the > proper tag. There is a need to adapt the koji policy in this case. Or do you managed to move it to updates once the package was moved back to testing ? > (I think it would be better if you did not tell non-admins to mess with > koji-rpmfusion move-tag at all and just let the admins do all the moves as > in the past.) The aim to have an infra is to be able to delegate. That's the very key point. The best way to avoid that is to somehow "script" and detect the need for move. In others words, either poll the fedora koji tags to detect that the package has moved in fedora or trigger an event on fedmsg. I've filled this infra bug to track this. (but anyone can implement). https://bugzilla.rpmfusion.org/show_bug.cgi?id=5389 -- - Nicolas (kwizart) ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
