You are not logged in.

#1 2017-10-06 09:35:44

andreas_baumann
Administrator
From: Zurich, Switzerland
Registered: 2017-08-10
Posts: 591
Website

blacklist file

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

#2 2017-10-06 09:53:37

deep42thought
Administrator
From: Jena, Germany
Registered: 2017-06-17
Posts: 365

Re: blacklist file

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

#3 2017-10-06 11:36:54

deep42thought
Administrator
From: Jena, Germany
Registered: 2017-06-17
Posts: 365

Re: blacklist file

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

#4 2017-10-06 12:14:26

andreas_baumann
Administrator
From: Zurich, Switzerland
Registered: 2017-08-10
Posts: 591
Website

Re: blacklist file

very nice. :-)

Offline

#5 2017-10-07 07:14:09

andreas_baumann
Administrator
From: Zurich, Switzerland
Registered: 2017-08-10
Posts: 591
Website

Re: blacklist file

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

#6 2017-10-07 14:12:38

deep42thought
Administrator
From: Jena, Germany
Registered: 2017-06-17
Posts: 365

Re: blacklist file

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

#7 2017-10-07 16:09:04

andreas_baumann
Administrator
From: Zurich, Switzerland
Registered: 2017-08-10
Posts: 591
Website

Re: blacklist file

I agree here, the value would be boring. The blacklist as shown now is enough.
Thanks for the github access. :-)

Offline

#8 2017-10-07 16:55:44

deep42thought
Administrator
From: Jena, Germany
Registered: 2017-06-17
Posts: 365

Re: blacklist file

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

#9 2017-10-07 17:22:52

andreas_baumann
Administrator
From: Zurich, Switzerland
Registered: 2017-08-10
Posts: 591
Website

Re: blacklist file

The dependency graph could be useful to see the impact of a blacklist action onto the tree..

Offline

#10 2017-10-07 17:51:08

deep42thought
Administrator
From: Jena, Germany
Registered: 2017-06-17
Posts: 365

Re: blacklist file

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

Board footer

Powered by FluxBB