Current state of the tree is a complete mess with some packages requiring the old splitted gtk-sharp and others this one. What is blocking this stabilization? The idea would be to try to stabilize this and port all to this monolithic one
I can maybe prepare a big list to stabilize for all dotnet maintained packages, try to fix it (for the case more deps are needed) and go ahead, what do you think?
dev-dotnet/gtk-sharp-2.12.21: amd64 ppc x86 dev-libs/gmime-2.6.20-r3: alpha amd64 arm hppa ia64 ppc ppc64 sparc x86 dev-dotnet/gnome-sharp-2.24.2-r1: amd64 ppc x86 dev-dotnet/mono-addins-1.0-r1: amd64 ppc x86
Stable on alpha.
There seems to be a bug in the addins ebuild: >>> Source compiled. >>> Test phase: dev-dotnet/mono-addins-1.0-r1 >>> Working in BUILD_DIR: "/var/tmp/portage/dev-dotnet/mono-addins-1.0-r1/work/mono-addins-1.0_build" /var/tmp/portage/dev-dotnet/mono-addins-1.0-r1/temp/environment: line 631: pushd: /var/tmp/portage/dev-dotnet/mono-addins-1.0-r1/work/mono-addins-1.0_build: No such file or directory
arm stable
Dear Maintainer (or who is mainly involved in this stable request), This is an auto-generated message that will move the current component to the new component Stabilization. To ensure that the stabilization will proceed correctly, please fill the fields "Atoms to stabilize" and "Runtime testing required" as described here: https://archives.gentoo.org/gentoo-dev/message/4b2ef0e9aa7588224b8ae799c5fe31fa
An automated check of this bug failed - the following atoms are unknown: dev-dotnet/gnome-sharp-2.24.2-r1: dev-dotnet/gtk-sharp-2.12.21: dev-dotnet/mono-addins-1.0-r1: dev-libs/gmime-2.6.20-r3: Please verify the atom list.
kensington, I think the script is getting confused with the ":"... I am not sure if maybe that ":" could simply be ignore :/ Thanks
(In reply to Pacho Ramos from comment #8) > kensington, I think the script is getting confused with the ":"... I am not > sure if maybe that ":" could simply be ignore :/ > > Thanks I do my best to be forgiving with what input is accepted but it's difficult to anticipate every possible type of invalid data. The main purpose of the field is to have a well-defined format (described in the tooltip) that's easy to access using scripts.
Sure, no problem. I only wanted to warn you for the case you get similar issues like this in the future ;) I have no problems with dropping it from the list
amd64 stable
ppc stable
x86 stable
ppc64 stable
sparc stable
Stable for HPPA.
ia64 stable. Closing.