Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
On Tue, 2017-07-25 at 04:34 +, Duncan wrote: > > Automating stabilization and automated keyword dropping on timeouts > seems > the only other practical choice, as unfortunately, "stale" is what > we > have today in practice, if not in name. Looking at https://repology.org/statistics stable isn't quite that stale compared to other distributions. We're not doing great either, so we should certainly try to improve. Hans signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
On Mon, 2017-07-24 at 23:22 +, Peter Stuge wrote: > > I hold a perhaps radical view: I would like to simply remove stable. > > [snip] > > I consider dev time a precious resource. If we were to drop stable I would have to start maintaining my own stable lists to determine what would be ready to into production for my company. In production "works most of the time" and "good enough" simply aren't good enough. I estimate that would at least equal the amount of time I'm currently spending on Gentoo work, and consequently my contributions to Gentoo would dwindle to a halt. Most likely I would start looking at other solutions altogether. > More troubleshooting and fixing "hard" problems, less routine work. Except that some of that routine work is actually what I enjoy doing in Gentoo. I already get plenty of the other two in my day job. Hans signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] vim-syntax USE flag
On Mon, 2017-07-24 at 12:10 +0200, Ulrich Mueller wrote: > > Similarly, if we get rid of the vim-syntax flag, should we phase out > the emacs USE flag, too? I would say no because in almost all cases the emacs code needs to be compiled and that requires emacs to be present. As far as I understand installing a vim syntax file does not require compilation and can therefore be done without having vim on the system. Hans signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
Rich Freeman posted on Mon, 24 Jul 2017 19:52:40 -0400 as excerpted: > On Mon, Jul 24, 2017 at 7:22 PM, Peter Stuge wrote: >> >> I hold a perhaps radical view: I would like to simply remove stable. >> >> I continue to feel that maintaining two worlds (stable+unstable) >> carries with it an unneccessary cost. >> >> > The question is whether devs would start being more conservative with > ~arch if it essentially turned into the new stable? > > If ~arch doesn't break then we're probably delaying updates too much. > If it does start breaking and we don't have any alternative, we'll > probably start losing users who just can't deal with their systems > breaking. > > Personally I'd rather see stable stick around. If it isn't updated > often that isn't a big deal (to me at least). Indeed, while along with Peter I have little personal use for stable (~arch is my stable, live-git my unstable, and stale arch, well, stale), I've come to realize over the years that there's enough gentooers, both users and devs, that do stable, that killing it isn't going to be the boon people only looking at all that "wasted" effort might believe it to be. Instead, were gentoo to lose stable, it'd ultimately shrink as both users and devs that previously found gentoo stable the most effective 'scratch' to their 'configurable stability itch', were forced to look elsewhere to scratch that itch. While there's a small chance it'd be an incremental gain for gentoo ~arch, there's a far larger chance it'd be the beginning of the end as without stable, the gentoo community could easily shrink into unsustainability -- too few people ever considering being users to produce enough incoming developers to maintain gentoo ~arch at anything close to the level we have now. OTOH, there may be a case to be made for the implications of Rich's suggestion... and mine above. Arguably just lose the pretense and simply rename stable -> stale, and let people that want/need it continue to deal with it on those terms. At least that way gentoo security advisories, etc could then be for "gentoo stale", and as such wouldn't look so dated when they come out half a year after the upstream public vulnerability and patch and/or unaffected release announcements, because that's what it took to stabilize the patched version on some platform or other that was holding up the glsa. Automating stabilization and automated keyword dropping on timeouts seems the only other practical choice, as unfortunately, "stale" is what we have today in practice, if not in name. So yes, I support the initiative. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
On Mon, Jul 24, 2017 at 7:22 PM, Peter Stuge wrote: > > I hold a perhaps radical view: I would like to simply remove stable. > > I continue to feel that maintaining two worlds (stable+unstable) > carries with it an unneccessary cost. > The question is whether devs would start being more conservative with ~arch if it essentially turned into the new stable? If ~arch doesn't break then we're probably delaying updates too much. If it does start breaking and we don't have any alternative, we'll probably start losing users who just can't deal with their systems breaking. Personally I'd rather see stable stick around. If it isn't updated often that isn't a big deal (to me at least). -- Rich
Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
Thank you for working on this. Sergei Trofimovich wrote: > Can this proposal make a difference and make gentoo better and > easier to work with? > > Does it try to attack the right thing? > > Does it completely miss the point? I hold a perhaps radical view: I would like to simply remove stable. I continue to feel that maintaining two worlds (stable+unstable) carries with it an unneccessary cost. Based solely on how excellently unstable (and similar approaches before using Gentoo) works for me in practice, I believe that skipping stable and instead focusing efforts on resolving problems reported in unstable a little quicker would yield a much better end result - and would net positive dev time. > Does it sound fun? Sorry, no, not to me. It sounds like "double" overhead. :\ I consider dev time a precious resource. Devs should need to do as few things as possible, to keep things going, and should be able to immediately reuse as much input from the wider community as possible. More troubleshooting and fixing "hard" problems, less routine work. //Peter
[gentoo-dev] Last rites: various gnustep-* packages
# Bernard Cafarelli (25 Jul 2017) # Dropped from upstream tarball for years, removal in a month (#626106) gnustep-apps/clipbook # Bernard Cafarelli (25 Jul 2017) # Dead upstream, last release 13 years ago, removal in a month (#626106) gnustep-apps/displaycalibrator # Bernard Cafarelli (25 Jul 2017) # Segfaults on diffs, last release 8 years ago, removal in a month (#626106) gnustep-apps/easydiff # Bernard Cafarelli (25 Jul 2017) # Dead upstream, last release 11 years ago, removal in a month (#626106) gnustep-apps/remotedesk # Bernard Cafarelli (25 Jul 2017) # Crashes on startup with current gnustep packages, removal in a month (#626106) gnustep-apps/sudoku # Bernard Cafarelli (25 Jul 2017) # Dead upstream, nothing in tree depends on it, removal in a month (#626106) gnustep-libs/camerakit # Bernard Cafarelli (25 Jul 2017) # Dead upstream, nothing in tree depends on it, removal in a month (#626106) gnustep-libs/iconkit # Bernard Cafarelli (25 Jul 2017) # Dead upstream, last code update 11 years ago, removal in a month (#626106) # Use gnustep-apps/systempreferences instead gnustep-apps/preferences gnustep-libs/prefsmodule -- Bernard Cafarelli (Voyageur) Gentoo developer
Re: [gentoo-dev] New eclass: opam.eclass
On 2017-07-24 17:20, Alexis Ballier wrote:
> Hey,
>
> Here is an eclass that would allow me to factor quite a bit of
> redundant code.
>
> …
> if [ -d "${ED}/usr/share/doc/${PF}/${PN}" ] ; then
It’s always been recommended to me that we should use the [[ … ]] form.
Otherwise, looks good to me.
signature.asc
Description: Digital signature
[gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
El lun, 24-07-2017 a las 22:22 +0100, Sergei Trofimovich escribió: > 4. Q: How to push more packages into STABLE? > > A: File automatic STABLEREQ bugs more aggressively if no known bugs > exist for a package version. The rough workflow is the following: > > - Grab a list of candidates for stabilization (will need > additional tooling) > - File STABLEREQ against maintainer only first. > - Maintainer will have a 2-week timeout to either proceed with > request: > - add "runtime testing required fields", CC relevant arches to > start stabilization > - or set blocking bugs against STABLEREQ to stop stabilization > - After 2-week timeout tooling automatically CCes arches and > stabilization happens (ideally with minimal manual work) > - Profit! I think the tools for this were already developed... but they were relying on some of us remembering to run them from time to time :/ https://gitweb.gentoo.org/proj/arch-tools.git/tree/file-stabilization-bugs.py https://gitweb.gentoo.org/proj/arch-tools.git/tree/maintainer-timeout.py https://gitweb.gentoo.org/proj/arch-tools.git/tree/stabilization-candidates.py Thanks specially for sharing https://wiki.gentoo.org/wiki/Package_testing#Tools link, it summarizes all the process really well :O Also, it seems that tatt- is able to do most of the work... then only thing that maybe has no official script to get it, for example, what would be the best way of getting the list of bug numbers that are pending to handle? For example, if I go to the list manually and pick 10 random bugs, it's ok to run tatt and copy&paste every bug number but, if the arch queue has 300 pending bugs. Do we have a way to simply get a plain text with all the bug numbers from bugzilla interface? Having links per arch pointing to that list of bugs with arches CCed and sanity-check=+ would be probably helpful ;) Thanks
[gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
TL;DR;TL;DR:
This email seeks for one step towards less toil tied to gentoo's
keywording/stabilization process. I've CCed a few groups who
might be interested in making this area better:
- gentoo-dev@ as it affects most devs (and non-devs!)
- wg-stable@ as it overlaps quite a bit with efforts staged on STABLEREQ
(should I join? :)
- arch-leads@ as it directly helps (or breaks everything for) arch teams
- all individual arches for wider visibility
TL;DR
-
I see the problem of lagging stable and unstable trees as:
1. lack of automation
2. lack of manpower
The PROPOSAL to solve the '1. automation' part is to draft
a new GLEP. If there is any interest (I assume there is!) I'll start one.
Let's call that fufure 'life of KEYWORDS'. It will cover:
- Update on GLEP-40 ("x86 stabilization can do only x86@ team")
to allow package maintainers to do ARCH=x86 stabilization.
It will be an arch-agnostic way: each arch will have minimal requirements
to setup environment suitable for stabilization and keywording:
CFLAGS to have, hardware required, whatever else is practical.
- Formalize list of stable arches as such (will be covered by
'arches.desc' GLEP)
- Formalize what is a "stable arch". In short:
- arch is marked as such in 'arches.desc'
- performs most of STABLEREQ/KEYWORDREQ or gives rationale
why progress can't be easily done before 90-days timeout
- Formalize and automate process of dropping keywords for timed out
STABLEREQ/KEYWORDREQ requests.
- Automate process of restoring dropped KEYWORDS due to bumps
adding new unkeyworded dependencies. repoman already complains
about those. What is left is to grab them in batches time to time
and handle those as if those were KEYWORDREQ.
- File more automated STABLEREQs to rely less on lazy maintainers
(I am example of lazy maintainer not siling STABLEREQs enough).
- Formalize which STABLEREQ/KEYWORDREQ can be done automatically
by arch teams (or maybe anyone else having the hardware!).
In short: anything not marked as "Runtime testing required"
on bugzilla and not having any blocker bugs.
The proposal to solve the '2. manpower' part is:
- Write more docs and make stabilisation process easier for everyone.
Important detail: the list is not in set in stone but rather a guideline
of things to cover.
Please feel free to propose other topics, questions, concerns, likes or
any other actionable feedback!
Story mode
--
Hi all!
As you might suspect arch testing (an important process part of
gentoo's health). Recently arch testing became a point of contentions
among gentoo developers.
The non-exhaustive list of complaints is:
- Minor (usually understaffed) arch ${A} is slow and does not process
STABLEREQ/KEYWORDREQ packages for many months. Lag forces maintainers
to keep more old versions in the tree prohibiting removal of not
really-maintained packages.
In theory policy allows dropping stable keywords from such packages
but in practice people frequently do not do it because it's a large
and tedious tree-wide change.
- Packages on major arch (amd64 or x86) are not stabilized frequently
enough. Packages fall through the cracks in bugzilla, STABLEREQs don't
get filed by maintainers.
-
What are the actual problems?
-
- Arch testing is complicated, repetitive and (somethat) unrewarding.
People only notice when things don't work.
- Arch testing is complicated: each architecture (or OS) has it's own
quirks.
It's hard for a developer to join empty arch team as documentation
on specifics is frequently lacking.
Some example questions could arise:
- When keywording for ARCH=ppc64 should we test on both powerpc64 and
powerpc64le or only one of them?
- Does -Wl,--as-needed work on ia64?
- There seem to be a little of coordination between arch teams which
tools to use to handle stabilization pipeline.
Some examples:
- Q: How to grab a list for keywording?
A: use 'getatoms.py' from https://wiki.gentoo.org/wiki/Package_testing#Tools
but there is a few caveats.
- Q: How to keyword a package before stabilization?
A: $ ekeyword ~ia64
Caveat: can easily drop a keyword from ia64 down to ~ia64 for a
package or two causing tree breakage.
- Q: How to mark a package as explicitly not working or an ${arch}?
A: Use KEYWORDS="-${arch}" but bots and ekeyword ignore it.
- Q: How to mark a single package version as broken for a particular
arch?
- Q: What is the format of commit message for arch commit? Should
package version be there? Should it be one commit per package?
Per bug? Per arch?
A: Everyone does it their own way.
What can we do about it?
The short answer is: we need more automation and more manpower.
Both are related: in an ideal world robots would do all package testing
for us. People would only need to add new packages into system.
More detailed p
Re: [gentoo-dev] vim-syntax USE flag
On Sun, Jul 23, 2017 at 11:46 AM, Ciaran McCreesh wrote: > On Sat, 22 Jul 2017 16:27:39 -0400 > Mike Gilbert wrote: >> Packages currently handle installation of vim syntax support files >> inconsistently. Some builds install the files if the "vim-syntax" USE >> flag is enabled, while others install them unconditionally. >> >> Do these files fall into the "small text files" category for >> unconditional installation? If so, we should probably phase out the >> vim-syntax USE flag. >> >> If we want to keep the USE flag, I would suggest documenting a global >> policy regarding its use. Should that live in the devmanual? Or maybe >> the Vim project page? > > One potential issue is help files: any Vim plugin that comes with > documentation needs a little script (which requires Vim to be installed) > to be run in pkg_postinst. Thanks for pointing that out. Sounds like we need some documentation on how to properly install vim-related files.
Re: [gentoo-dev] vim-syntax USE flag
> On Mon, 24 Jul 2017, Mike Gilbert wrote: >> The flag also pulls in additional dependencies for some ebuilds. >> So I wonder how it could be made unconditional? For example, >> app-admin/eselect[vim-syntax] depends on app-vim/eselect-syntax >> which in turn will pull in vim or gvim. Certainly not all users >> would want that? > I was unaware that the USE flag sometimes introduces additional > dependencies. That being the case, we should certainly keep it. A quick scan shows that about 100 ebuilds in the tree have such a USE-conditional dependency. >> Similarly, if we get rid of the vim-syntax flag, should we phase >> out the emacs USE flag, too? > Does this also pull in optional dependencies? Yes, most of the time it does. Also, last time I had a (non-Emacs) package unconditionally install Emacs support, there were complaints by "religious" users who wanted to keep their systems 100% Emacs free. ;-) Ulrich pgplS6G1tXxmX.pgp Description: PGP signature
[gentoo-dev] New eclass: opam.eclass
Hey,
Here is an eclass that would allow me to factor quite a bit of
redundant code.
Potential users:
https://qa-reports.gentoo.org/output/genrdeps/dindex/dev-ml/opam
Examples of conversion:
diff --git a/dev-ml/ocaml-cstruct/ocaml-cstruct-3.1.1.ebuild
b/dev-ml/ocaml-cstruct/ocaml-cstruct-3.1.1.ebuild index
0acf2607860..5e238f762db 100644 ---
a/dev-ml/ocaml-cstruct/ocaml-cstruct-3.1.1.ebuild +++
b/dev-ml/ocaml-cstruct/ocaml-cstruct-3.1.1.ebuild @@ -3,7 +3,7 @@
EAPI=5
-inherit findlib
+inherit findlib opam
DESCRIPTION="Map OCaml arrays onto C-like structs"
HOMEPAGE="https://github.com/mirage/ocaml-cstruct https://mirage.io";
@@ -57,18 +57,6 @@ src_test() {
jbuilder runtest -p $(get_targets) || die
}
-oinstall() {
- opam-installer -i \
- --prefix="${ED}/usr" \
- --libdir="${D}/$(ocamlc -where)" \
- --docdir="${ED}/usr/share/doc/${PF}" \
- ${1}.install || die
-}
-
src_install() {
- oinstall cstruct
- oinstall cstruct-unix
- use lwt && oinstall cstruct-lwt
- use async && oinstall cstruct-async
- use ppx && oinstall ppx_cstruct
+ opam-install $(get_targets | tr ',' ' ')
}
diff --git a/dev-ml/utop/utop-2.0.1.ebuild
b/dev-ml/utop/utop-2.0.1.ebuild index 90056da08e8..c3bec3b1f94 100644
--- a/dev-ml/utop/utop-2.0.1.ebuild
+++ b/dev-ml/utop/utop-2.0.1.ebuild
@@ -3,7 +3,7 @@
EAPI=5
-inherit findlib
+inherit findlib opam
DESCRIPTION="A new toplevel for OCaml with completion and colorization"
HOMEPAGE="https://github.com/diml/utop";
@@ -30,12 +30,3 @@ DEPEND="${DEPEND}
DOCS=( "CHANGES.md" "README.md" )
SITEFILE="50${PN}-gentoo.el"
-
-src_install() {
- opam-installer -i \
- --prefix="${ED}/usr" \
- --libdir="${D}/$(ocamlc -where)" \
- --docdir="${ED}/usr/share/doc/${PF}" \
- --mandir="${ED}/usr/share/man" \
- ${PN}.install || die
-}
Alexis.# Copyright 1999-2017 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: opam.eclass
# @MAINTAINER:
# Gentoo ML Project
# @AUTHOR:
# Alexis Ballier
# @BLURB: Provides functions for installing opam packages.
# @DESCRIPTION:
# Provides dependencies on opam and ocaml, opam-install and a default
# src_install for opam-based packages.
case ${EAPI:-0} in
0|1|2|3|4) die "You need at least EAPI-5 to use opam.eclass";;
*) ;;
esac
RDEPEND=">=dev-lang/ocaml-4:="
DEPEND="${RDEPEND}
dev-ml/opam"
# @FUNCTION: opam-install
# @USAGE:
# @DESCRIPTION:
# Installs the opam packages given as arguments. For each "${pkg}" element in
# that list, "${pkg}.install" must be readable from current working directory.
opam-install() {
for pkg ; do
opam-installer -i \
--prefix="${ED}/usr" \
--libdir="${D}/$(ocamlc -where)" \
--docdir="${ED}/usr/share/doc/${PF}" \
--mandir="${ED}/usr/share/man" \
"${pkg}.install" || die
done
}
opam_src_install() {
opam-install "${PN}"
# Handle opam putting doc in a subdir
if [ -d "${ED}/usr/share/doc/${PF}/${PN}" ] ; then
mv "${ED}/usr/share/doc/${PF}/${PN}/"*
"${ED}/usr/share/doc/${PF}/" || die
rmdir "${ED}/usr/share/doc/${PF}/${PN}" || die
fi
}
EXPORT_FUNCTIONS src_install
Re: [gentoo-dev] vim-syntax USE flag
On Mon, Jul 24, 2017 at 6:10 AM, Ulrich Mueller wrote: >> On Sat, 22 Jul 2017, Mike Gilbert wrote: > >> Packages currently handle installation of vim syntax support files >> inconsistently. Some builds install the files if the "vim-syntax" >> USE flag is enabled, while others install them unconditionally. > >> Do these files fall into the "small text files" category for >> unconditional installation? If so, we should probably phase out the >> vim-syntax USE flag. > > The flag also pulls in additional dependencies for some ebuilds. > So I wonder how it could be made unconditional? For example, > app-admin/eselect[vim-syntax] depends on app-vim/eselect-syntax > which in turn will pull in vim or gvim. Certainly not all users would > want that? I was unaware that the USE flag sometimes introduces additional dependencies. That being the case, we should certainly keep it. > Similarly, if we get rid of the vim-syntax flag, should we phase out > the emacs USE flag, too? Does this also pull in optional dependencies?
Re: [gentoo-dev] vim-syntax USE flag
> On Sat, 22 Jul 2017, Mike Gilbert wrote: > Packages currently handle installation of vim syntax support files > inconsistently. Some builds install the files if the "vim-syntax" > USE flag is enabled, while others install them unconditionally. > Do these files fall into the "small text files" category for > unconditional installation? If so, we should probably phase out the > vim-syntax USE flag. The flag also pulls in additional dependencies for some ebuilds. So I wonder how it could be made unconditional? For example, app-admin/eselect[vim-syntax] depends on app-vim/eselect-syntax which in turn will pull in vim or gvim. Certainly not all users would want that? Similarly, if we get rid of the vim-syntax flag, should we phase out the emacs USE flag, too? Ulrich pgpLAaW8dAPlN.pgp Description: PGP signature
