Re: [gentoo-dev] De-stabilizing and re-stabilizing (on amd64 only)
On Fri, 2020-05-08 at 13:33 +0300, Andreas K. Hüttel wrote: > > Background, I tried to locally emulate www.g.o using jekyll, and ran > into > troubles because lots of dev-ruby/* lost stable keywords. Newest > ~arch didn't > do the job, so I needed to figure out the config of www.g.o > (corresponding to > former stable) first... I'm not aware of amd64 stable keywords being lost in dev-ruby, other than dev-ruby/rails a long time ago. Which packages did you get in trouble with? And you can always file a stable bug for the maintainers :-) Hans signature.asc Description: This is a digitally signed message part
[gentoo-dev] gcc-10 is in ~arch
gcc-10 was released yesterday and was pushed to ::gentoo's ~arch as: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=32258c6414a31898ff5592893678a3910d2c5c75 Most of packages should Just Work. But we expect some amount of build- and runtime breakage. Non-exhaustive list of things to watch for: - missing includes in users' code Example build failure would be: "error: 'size_t' was not declared in this scope; did you mean 'std::size_t'?" where missing for used size_t types. - extra '-fcommon->-fno-common' linker failures for packages that ignore users' CFLAGS and thus missed Toralf's tinderbox runs. https://wiki.gentoo.org/wiki/Gcc_10_porting_notes/fno_common - "9" -> "10" version change also managed to break many assumptions of how gcc versions are parsed by shell scripts and ebuilds. This causes all sorts of bizarre bugs: https://trofi.github.io/posts/213-gcc-10-in-gentoo.html - overhauled gcc-10 inliner heuristics will cause some amount of build/runtime breakage in existing fragile code. As an extreme example your stack-protected kernel might not boot: https://lkml.org/lkml/2020/3/14/186 Tracker of common breakages: https://bugs.gentoo.org/show_bug.cgi?id=gcc-10 Landing page to steal-fixes-from/add-fixes-to: https://wiki.gentoo.org/wiki/Project:Toolchain#gcc-10 If you can't figure out non-trivial breakage feel free to add toolchain@ to the bug and we'll try to sort it out together. -- Sergei
[gentoo-dev] De-stabilizing and re-stabilizing (on amd64 only)
Hi all, quite some packages were un-stabilized across the tree recently. In general that is in my opinion a good thing if it helps us keep up, in particular where many arches are involved. What's the general opinion on re-stabilizing things on *amd64* only? I would say that maintaining a larger stable tree is comparatively easy there, since everyone of us devs is running (I guess) an amd64 machine and can stabilize own packages. Background, I tried to locally emulate www.g.o using jekyll, and ran into troubles because lots of dev-ruby/* lost stable keywords. Newest ~arch didn't do the job, so I needed to figure out the config of www.g.o (corresponding to former stable) first... Cheers, Andreas -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [gentoostats continued] Collected data and justification for it
Hi, On 2020/05/08 08:17, Hans de Graaff wrote: > On Thu, 2020-05-07 at 09:29 +0200, Michał Górny wrote: >> >> 1) list of selected packages (@world) >> >> We would use this to determine the popularity of individual packages, >> plus by scanning their dependencies we would be able to make combined >> statistics for direct usage + dependencies of other selected >> packages. >> This would allow us to judge which packages need more of our >> attention. > At work we install a lot of dependencies through a few company-specific > virtual packages, e.g. company/developer for all stuff useful for our > developers. These packages would then be missed in the statistics. I'm > not sure how prevalent this is and to what extend it wills skew the > statistics. You raise a valid point. The company/developer package itself I don't think is relevant. The fact that some/package::gentoo is installed as a dependency of company/developer may carry some relevance. So we do need the full list of packages installed, filtered to ::gentoo, but there needs to be an indicated whether it's installed because it's in @world, as a dep of something in @world (which is possibly not in ::gentoo), or is some form of no-longer needed dep. Otherwise I agree with Michał on the four items to be taken. I do still think that the ability to define additional information sets would be useful for building more invasive functionality sets, not necessarily supported by Gentoo. For an organization if they can define a set that grabs a certain amount of hardware details for example that could help with inventory management. Kind Regards, Jaco
