The stable depgraph has been broken for over a day. https://qa-reports.gentoo.org/output/gentoo-ci/output.html Please fix this.
(In reply to Mike Gilbert from comment #0) > The stable depgraph has been broken for over a day. Yeah, I cannot be around 24h every day for Gentoo... > > https://qa-reports.gentoo.org/output/gentoo-ci/output.html > > Please fix this. pango-sharp was unmasked... but why the use.mask for zeitgeist-datasources[tomboy] is not working? :/
Ah, it was because of specific unmasks of the use on some arches, should be dropped in a few seconds
(In reply to Pacho Ramos from comment #1) > (In reply to Mike Gilbert from comment #0) > > The stable depgraph has been broken for over a day. > > Yeah, I cannot be around 24h every day for Gentoo... Next time, check reverse deps *before* pushing to gentoo.git.
Please post me the exact steps for getting that pull requests checked, because currently I need to check them manually
(In reply to Pacho Ramos from comment #4) > Please post me the exact steps for getting that pull requests checked, > because currently I need to check them manually This is how I do it: 1. Fork https://github.com/gentoo/gentoo on github. 2. Add this remote to your local gentoo repo: git remote add github ssh://git@github.com/floppym/gentoo.git 3. Create a branch. git checkout -b mybranch1 4. Commit some dangerous things. 5. Push the branch to github. git push -u github mybranch1 6. Create a pull request using the github UI. Shortcut: https://github.com/floppym/gentoo/pull/new/mybranch1 7. Wait 30 minutes to 1 hour for the gentoo ci bot to check your pull request.
Looks like we are all green now. Thanks!
Thanks to you for the tips... anyway I am unsure if that steps are too overkill to be used often... I mean, when you think a commit it's going to break, it's ok... but running all that steps more often will be a bit :/ But I guess it's a problem of github not allowing to avoid github UI and simply fully script the process. Also... in other cases maybe it would be easier to simply fix the issue if possible and mail me for reminding... well, I don't think I am breaking the tree so often... and this was obviously not done in purpose (I have being checking the reverse deps but manually grepping, that is the reason both failures were a bit "corner cases"... and that is the reason treecleaning takes so much time :P, if I would have being masking "blindly" it would have been far faster... and terrible too ;). Well... paradoxically part of all this dotnet work is to try to "unbreak" the completely broken state of our current mono stuff since mono-4 was stabilized without porting most reverse deps, causing them to even not build :|
(In reply to Pacho Ramos from comment #7) > Thanks to you for the tips... anyway I am unsure if that steps are too > overkill to be used often... I mean, when you think a commit it's going to > break, it's ok... but running all that steps more often will be a bit :/ It's only really necessary when making changes that might affect reverse dependencies. Masking or removing ebuilds mainly. For a treecleaner, I would say it should be standard operating procedure. This might be easier if you mask things in batches, and submit the batches as pull requests. > Also... in other cases maybe it would be easier to simply fix the issue if > possible and mail me for reminding... If I knew exactly what was intended, I would have fixed it. However, I could not make any sense of the dev-dotnet/gtk-sharp situation. Overall, the pull request / CI workflow is really not that burdensome once you are comfortable with the process. Steps 1 and 2 only need to be done once, ever. Steps 3 to 5 are a standard git workflow. Step 6 requires a web browser, but it only takes a few seconds to hit the "create pull request button". Step 7 requires some patience; but I think it is better to be patient than to unintentionally push broken changes.
Ah, nice, will try the next time until I get used ;)
