This bug branches from the discussion in bug #498332. To ease in building mips stages with catalyst, it makes sense to maintain stable mips keywords for only @system packages. Reproducible: Always
Will the arch remain as a 'dev' profile even with the stable keywords in place?
Also your comment in https://bugs.gentoo.org/show_bug.cgi?id=498332#c19 does not really make much sense to me. What't the benefit of adding stable mips keywords to the latest @system packages compared to having them in ~arch? It seems the same to me.
(In reply to Markos Chandras from comment #2) > Also your comment in https://bugs.gentoo.org/show_bug.cgi?id=498332#c19 does > not really make much sense to me. What't the benefit of adding stable mips > keywords to the latest @system packages compared to having them in ~arch? It > seems the same to me. Because that is the *current* sitatuation. In the future, it may not be the case, in which case we may want to hold back a package from being marked stable so that our builds work. Otherwise, I have to do what I did in the past, ie, locally mask a package.
(In reply to Anthony Basile from comment #3) > (In reply to Markos Chandras from comment #2) > > Also your comment in https://bugs.gentoo.org/show_bug.cgi?id=498332#c19 does > > not really make much sense to me. What't the benefit of adding stable mips > > keywords to the latest @system packages compared to having them in ~arch? It > > seems the same to me. > > Because that is the *current* sitatuation. In the future, it may not be the > case, in which case we may want to hold back a package from being marked > stable so that our builds work. Otherwise, I have to do what I did in the > past, ie, locally mask a package. I see. Your proposal adds extra maintenance cost by having as to maintain a full ~arch and a stable @system tree. Can we really do that? Current ~testing tree mostly works for stage3 tarballs on MIPS and if it does not it's a nice way to push teams to fix their package for us. Sometimes a little bit of masking is necessary but not to the extent to justify adding stable keywords to @system
(In reply to Markos Chandras from comment #4) > (In reply to Anthony Basile from comment #3) > > (In reply to Markos Chandras from comment #2) > > > Also your comment in https://bugs.gentoo.org/show_bug.cgi?id=498332#c19 does > > > not really make much sense to me. What't the benefit of adding stable mips > > > keywords to the latest @system packages compared to having them in ~arch? It > > > seems the same to me. > > > > Because that is the *current* sitatuation. In the future, it may not be the > > case, in which case we may want to hold back a package from being marked > > stable so that our builds work. Otherwise, I have to do what I did in the > > past, ie, locally mask a package. > > I see. > Your proposal adds extra maintenance cost by having as to maintain a full > ~arch and a stable @system tree. Can we really do that? Current ~testing > tree mostly works for stage3 tarballs on MIPS and if it does not it's a nice > way to push teams to fix their package for us. write a script which maintains a list of current stable packages. i used to do this for sec-policy before Swift took over selinux. It was a list of about 240 packages. > Sometimes a little bit of masking is necessary but not to the extent to > justify adding stable keywords to @system this is the better point. it forces us to focus harder on ~arch. but, with stable keywords, it doesn't stop you from still building stages for ~arch.
(In reply to Anthony Basile from comment #5) > (In reply to Markos Chandras from comment #4) > > (In reply to Anthony Basile from comment #3) > > > (In reply to Markos Chandras from comment #2) > > > > Also your comment in https://bugs.gentoo.org/show_bug.cgi?id=498332#c19 does > > > > not really make much sense to me. What't the benefit of adding stable mips > > > > keywords to the latest @system packages compared to having them in ~arch? It > > > > seems the same to me. > > > > > > Because that is the *current* sitatuation. In the future, it may not be the > > > case, in which case we may want to hold back a package from being marked > > > stable so that our builds work. Otherwise, I have to do what I did in the > > > past, ie, locally mask a package. > > > > I see. > > Your proposal adds extra maintenance cost by having as to maintain a full > > ~arch and a stable @system tree. Can we really do that? Current ~testing > > tree mostly works for stage3 tarballs on MIPS and if it does not it's a nice > > way to push teams to fix their package for us. > > write a script which maintains a list of current stable packages. i used to > do this for sec-policy before Swift took over selinux. It was a list of > about 240 packages. Yeah but someone needs to test these packages. Manpower is my main concern... > > > Sometimes a little bit of masking is necessary but not to the extent to > > justify adding stable keywords to @system > > this is the better point. it forces us to focus harder on ~arch. but, with > stable keywords, it doesn't stop you from still building stages for ~arch. Yeah but catalyst will also need a little bit of tweaking to pull ~arch packages instead of stable by default. This may also have the exact opposite effect of us using a stable @system and never notice that the ~arch is broken. Don't get me wrong. I am fine with what the majority decides. I just want to avoid seeing a lower QA outcome for MIPS.
(In reply to Markos Chandras from comment #4) the maintenance cost is carried only by the mips team. and they already have a load with trying to keep their stages working using the very latest unstable when all other arches are using the latest stable. we aren't talking about package maintainers (not on the mips team) from keeping track of the mips arch themselves.
(In reply to Markos Chandras from comment #1) > Will the arch remain as a 'dev' profile even with the stable keywords in > place? According to what has been said on the list, the profile could remain exp with these stable keywords. That means the maintainers can ignore this arch when cleaning out old ebuilds and stabilizing things would be the sole responsibility of the arch team when they need something new stable.
Markos suggested moving this discussion to the list and I'm fine. But for the records, here's whats working on all mips uclibc and what I would hit up with a mass first stabilization. It does contain a little more than @stage, namely vim and gentoolkit plus their deps. I guess they could be removed but I'd keep them up: [IP-] [ ] app-admin/eselect-1.4:0 [IP-] [ ] app-admin/eselect-ctags-1.14:0 [IP-] [ ] app-admin/eselect-python-20140115:0 [IP-] [ ] app-admin/eselect-vi-1.1.7-r1:0 [IP-] [ ] app-admin/perl-cleaner-2.12:0 [IP-] [ ] app-admin/python-updater-0.11:0 [IP-] [ ] app-arch/bzip2-1.0.6-r6:0 [IP-] [ ] app-arch/gzip-1.6:0 [IP-] [ ] app-arch/tar-1.27.1-r1:0 [IP-] [ ] app-arch/unzip-6.0-r3:0 [IP-] [ ] app-arch/xz-utils-5.0.5-r1:0 [IP-] [ ] app-editors/nano-2.3.2-r1:0 [IP-] [ ] app-editors/vim-7.4.131:0 [IP-] [ ] app-editors/vim-core-7.4.131:0 [IP-] [ ] app-misc/ca-certificates-20130906:0 [IP-] [ ] app-misc/editor-wrapper-4:0 [IP-] [ ] app-misc/mime-types-9:0 [IP-] [ ] app-misc/pax-utils-0.7:0 [IP-] [ ] app-portage/gentoolkit-0.3.0.8-r2:0 [IP-] [ ] app-shells/bash-4.2_p45-r1:0 [IP-] [ ] app-text/build-docbook-catalog-1.20:0 [IP-] [ ] app-text/docbook-xml-dtd-4.1.2-r6:4.1.2 [IP-] [ ] app-text/docbook-xsl-stylesheets-1.78.0-r1:0 [IP-] [ ] app-text/sgml-common-0.6.3-r5:0 [IP-] [ ] app-vim/gentoo-syntax-20130619:0 [IP-] [ ] dev-lang/perl-5.16.3:0/5.16 [IP-] [ ] dev-lang/python-2.7.6:2.7 [IP-] [ ] dev-lang/python-3.2.5-r3:3.2 [IP-] [ ] dev-lang/python-3.3.3:3.3 [IP-] [ ] dev-lang/python-exec-0.3.1:0 [IP-] [ ] dev-lang/python-exec-2.0.1:2 [IP-] [ ] dev-libs/expat-2.1.0-r3:0 [IP-] [ ] dev-libs/glib-2.36.4-r1:2 [IP-] [ ] dev-libs/gmp-5.1.3-r1:0 [IP-] [ ] dev-libs/libelf-0.8.13-r2:0 [IP-] [ ] dev-libs/libffi-3.0.13-r1:0 [IP-] [ ] dev-libs/libgcrypt-1.6.0:0/20 [IP-] [ ] dev-libs/libgpg-error-1.12:0 [IP-] [ ] dev-libs/libiconv-1.14-r1:0 [IP-] [ ] dev-libs/libpcre-8.34:3 [IP-] [ ] dev-libs/libpipeline-1.2.5:0 [IP-] [ ] dev-libs/libxml2-2.9.1-r2:2 [IP-] [ ] dev-libs/libxslt-1.1.28-r1:0 [IP-] [ ] dev-libs/mpc-1.0.1:0 [IP-] [ ] dev-libs/mpfr-3.1.2-r1:0 [IP-] [ ] dev-libs/openssl-1.0.1f:0 [IP-] [ ] dev-libs/popt-1.16-r1:0 [IP-] [ ] dev-perl/Text-Unidecode-0.40.0:0 [IP-] [ ] dev-perl/Unicode-EastAsianWidth-1.330.0:0 [IP-] [ ] dev-perl/XML-Parser-2.410.0-r1:0 [IP-] [ ] dev-perl/libintl-perl-1.230.0:0 [IP-] [ ] dev-python/python-exec-10000.1:0 [IP-] [ ] dev-python/python-exec-10000.2:2 [IP-] [ ] dev-python/pyxattr-0.5.2:0 [IP-] [ ] dev-python/setuptools-1.1.6:0 [IP-] [ ] dev-util/ctags-5.8:0 [IP-] [ ] dev-util/gperf-3.0.4:0 [IP-] [ ] dev-util/gtk-doc-am-1.19:0 [IP-] [ ] dev-util/intltool-0.50.2-r1:0 [IP-] [ ] dev-util/pkgconfig-0.28:0 [IP-] [ ] net-misc/iputils-20121221-r1:0 [IP-] [ ] net-misc/netifrc-0.1:0 [IP-] [ ] net-misc/openssh-6.4_p1-r1:0 [IP-] [ ] net-misc/rsync-3.1.0:0 [IP-] [ ] net-misc/wget-1.14-r1:0 [IP-] [ ] perl-core/CPAN-Meta-2.132.510:0 [IP-] [ ] perl-core/CPAN-Meta-Requirements-2.125.0:0 [IP-] [ ] perl-core/CPAN-Meta-YAML-0.8.0:0 [IP-] [ ] perl-core/ExtUtils-Install-1.540.0:0 [IP-] [ ] perl-core/ExtUtils-MakeMaker-6.820.0:0 [IP-] [ ] perl-core/ExtUtils-Manifest-1.630.0:0 [IP-] [ ] perl-core/File-Spec-3.400.0:0 [IP-] [ ] perl-core/File-Temp-0.230.400:0 [IP-] [ ] perl-core/IO-1.25:0 [IP-] [ ] perl-core/JSON-PP-2.272.20:0 [IP-] [ ] perl-core/Parse-CPAN-Meta-1.440.900:0 [IP-] [ ] perl-core/Scalar-List-Utils-1.350.0:0 [IP-] [ ] perl-core/version-0.990.400:0 [IP-] [ ] sys-apps/attr-2.4.47-r1:0 [IP-] [ ] sys-apps/baselayout-2.2:0 [IP-] [ ] sys-apps/busybox-1.22.1:0 [IP-] [ ] sys-apps/coreutils-8.22:0 [IP-] [ ] sys-apps/debianutils-4.4:0 [IP-] [ ] sys-apps/diffutils-3.3:0 [IP-] [ ] sys-apps/file-5.16:0 [IP-] [ ] sys-apps/findutils-4.5.12:0 [IP-] [ ] sys-apps/gawk-4.1.0:0 [IP-] [ ] sys-apps/grep-2.16:0 [IP-] [ ] sys-apps/groff-1.22.2:0 [IP-] [ ] sys-apps/help2man-1.43.3:0 [IP-] [ ] sys-apps/hwids-20140103:0 [IP-] [ ] sys-apps/kbd-2.0.1:0 [IP-] [ ] sys-apps/kmod-16:0 [IP-] [ ] sys-apps/less-462:0 [IP-] [ ] sys-apps/man-db-2.6.5:0 [IP-] [ ] sys-apps/net-tools-1.60_p20130513023548:0 [IP-] [ ] sys-apps/openrc-0.12.4:0 [IP-] [ ] sys-apps/portage-2.2.8-r1:0 [IP-] [ ] sys-apps/sandbox-2.6-r1:0 [IP-] [ ] sys-apps/sed-4.2.2:0 [IP-] [ ] sys-apps/shadow-4.1.5.1-r1:0 [IP-] [ ] sys-apps/sysvinit-2.88-r6:0 [IP-] [ ] sys-apps/tcp-wrappers-7.6.22-r1:0 [IP-] [ ] sys-apps/texinfo-5.2:0 [IP-] [ ] sys-apps/util-linux-2.23.2-r2:0 [IP-] [ ] sys-apps/which-2.20-r1:0 [IP-] [ ] sys-devel/autoconf-2.69:2.5 [IP-] [ ] sys-devel/autoconf-wrapper-13:0 [IP-] [ ] sys-devel/automake-1.12.6:1.12 [IP-] [ ] sys-devel/automake-1.14.1:1.14 [IP-] [ ] sys-devel/automake-wrapper-9:0 [IP-] [ ] sys-devel/binutils-2.24-r2:0 [IP-] [ ] sys-devel/binutils-config-3-r3:0 [IP-] [ ] sys-devel/bison-2.7.1:0 [IP-] [ ] sys-devel/flex-2.5.37:0 [IP-] [ ] sys-devel/gcc-4.8.2:4.8 [IP-] [ ] sys-devel/gcc-config-1.8:0 [IP-] [ ] sys-devel/gettext-0.18.3.1-r1:0 [IP-] [ ] sys-devel/gnuconfig-20131128:0 [IP-] [ ] sys-devel/libtool-2.4.2:2 [IP-] [ ] sys-devel/m4-1.4.17:0 [IP-] [ ] sys-devel/make-4.0-r1:0 [IP-] [ ] sys-devel/patch-2.7.1-r3:0 [IP-] [ ] sys-fs/e2fsprogs-1.42.9:0 [IP-] [ ] sys-fs/eudev-1.4:0 [IP-] [ ] sys-fs/udev-init-scripts-26:0 [IP-] [ ] sys-kernel/linux-headers-3.12:0 [IP-] [ ] sys-libs/cracklib-2.9.1:0 [IP-] [ ] sys-libs/e2fsprogs-libs-1.42.9:0 [IP-] [ ] sys-libs/gdbm-1.11:0 [IP-] [ ] sys-libs/libcap-2.22-r2:0 [IP-] [ ] sys-libs/ncurses-5.9-r3:5 [IP-] [ ] sys-libs/readline-6.2_p5-r1:0 [IP-] [ ] sys-libs/uclibc-0.9.33.2-r9:0 [IP-] [ ] sys-libs/zlib-1.2.8-r1:0 [IP-] [ ] sys-process/procps-3.3.9:0 [IP-] [ ] sys-process/psmisc-22.21:0 [IP-] [ ] virtual/dev-manager-0:0 [IP-] [ ] virtual/editor-0:0 [IP-] [ ] virtual/libc-0:0 [IP-] [ ] virtual/libffi-3.0.13-r1:0 [IP-] [ ] virtual/libiconv-0-r1:0 [IP-] [ ] virtual/libintl-0:0 [IP-] [ ] virtual/man-0-r1:0 [IP-] [ ] virtual/modutils-0:0 [IP-] [ ] virtual/os-headers-0:0 [IP-] [ ] virtual/package-manager-0:0 [IP-] [ ] virtual/pager-0:0 [IP-] [ ] virtual/perl-CPAN-Meta-2.132.510:0 [IP-] [ ] virtual/perl-CPAN-Meta-Requirements-2.125.0:0 [IP-] [ ] virtual/perl-CPAN-Meta-YAML-0.8.0:0 [IP-] [ ] virtual/perl-ExtUtils-Command-1.180.0:0 [IP-] [ ] virtual/perl-ExtUtils-Install-1.540.0:0 [IP-] [ ] virtual/perl-ExtUtils-MakeMaker-6.820.0:0 [IP-] [ ] virtual/perl-ExtUtils-Manifest-1.630.0:0 [IP-] [ ] virtual/perl-File-Spec-3.400.0:0 [IP-] [ ] virtual/perl-File-Temp-0.230.400:0 [IP-] [ ] virtual/perl-IO-1.25:0 [IP-] [ ] virtual/perl-JSON-PP-2.272.20:0 [IP-] [ ] virtual/perl-Parse-CPAN-Meta-1.440.900:0 [IP-] [ ] virtual/perl-Scalar-List-Utils-1.350.0:0 [IP-] [ ] virtual/perl-Test-Simple-0.980.0-r2:0 [IP-] [ ] virtual/perl-version-0.990.400:0 [IP-] [ ] virtual/pkgconfig-0:0 [IP-] [ ] virtual/python-argparse-1:0 [IP-] [ ] virtual/service-manager-0:0 [IP-] [ ] virtual/shadow-0:0 [IP-] [ ] virtual/ssh-0:0 [IP-] [ ] virtual/udev-208:0 [IP-] [ ] virtual/yacc-0:0 [IP-] [ ] x11-misc/shared-mime-info-1.2-r1:0
(In reply to SpanKY from comment #7) > (In reply to Markos Chandras from comment #4) > > the maintenance cost is carried only by the mips team. and they already > have a load with trying to keep their stages working using the very latest > unstable when all other arches are using the latest stable. > > we aren't talking about package maintainers (not on the mips team) from > keeping track of the mips arch themselves. I think you misunderstood what I said. I was referring to the MIPS maintainers. We now only try to make sure the latest ~arch is working for us. But with a stable @system, we need to track both the latest ~arch and the latest stable for the @system packages. I am moving this to the list
Please move the discussion here http://gentoo.2317880.n4.nabble.com/Restore-stable-keywords-on-system-td275281.html I am closing this bug as NEEDINFO to avoid talking about the same thing in two different places. Once we agree on a solution, we will reopen it.
