You are not logged in.
Pages: 1
Just a thought.
In https://buildmaster.archlinux32.org it would be nice to see how many packages are currently black-listed.
Also the 'blacklist' file just contains the package name. It would be nice to see the reason why a certain package
is black-listed (could also be extracted from the git log, if the naming there is strictly followed).
Sorry, for not having written something on my own (yet). :-)
Offline
good idea with the blacklist file, I'd propose comment lines starting with '#' which explain the reason
you do not need to excuse for not writing build scripts - you hvae been debugging quite some package builds (which I am unable to do)
Offline
ok, it's implemented.
I also removed (commented) a large bunch of packages in the blacklist - I think, I accidentally blacklisted some of them. Let's see, which packages will compile :-)
Offline
very nice. :-)
Offline
Now of course I come with some other ideas.. ;-)
Is it necessary to provide an email command llike 'blacklist: xxxx.xxx reason'?
Or is this done completly via git pull requests?
Should https://buildmaster.archlinux32.org/ show 'number of blacklisted packages'
also in the graph?
Offline
An email frontend for blacklisting packages is not (easy) possible, because the build master cannot commit into the packages repository. However, each maintainer should get write access to that repository.
And since I currently count only three maintainers (including you), I would just give you access to the repository.
The reason for the difference between blocking and blacklisting is, that we want version control for blacklisting, but not for blocking.
'number of blacklisted packages' is rather boring - I'd show 'number of not-buildable packages' (e.g. the count of lines of deletion-list) - this way, we'd immediately notice when the build master wants to delete a huge amount of packages.
On the other hand, this number scales different from the others (e.g. it accumulates and probably stays large), so I'm hesitating.
Offline
I agree here, the value would be boring. The blacklist as shown now is enough.
Thanks for the github access. :-)
Offline
What do you think about a graph showing all packages on the deletion-list with their dependencies up to packages which are on the blacklist?
It could/would look similar to this one which shows all pending package builds with the broken packages.
Offline
The dependency graph could be useful to see the impact of a blacklist action onto the tree..
Offline
Here are some statistics.
We have currently
250 deletion-list packages
238 deletion-list packages matching lib32-*
=> 12 non-multilib deletion-list packages
8 blacklist packages
I'm not sure how to handle lib32-* packages in such a graph - they're rather boring, but might get interesting if they block another package.
Offline
Pages: 1
