[gentoo-dev] last rites (kinda, long masked): sys-apps/opentmpfiles
# Andreas K. Hüttel (2021-07-06, 2023-09-15) # No longer maintained upstream; masked everywhere for two years now. # Please see also the 2021-07-15-opentmpfiles-deprecation news item. # https://www.gentoo.org/support/news-items/2021-07-15-opentmpfiles-deprecation.html # # The replacement is sys-apps/systemd-utils[tmpfiles]; new name # but otherwise identical to the solution described in the news item. # Removal on 2023-10-15. sys-apps/opentmpfiles -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] last rites: sys-fs/eudev
> >> I'm an outsider to Gentoo development (just a heavy user for over a > >> decade both personally and professionally) so I might have missed > >> something. I just find it puzzling. > > > > I'm not puzzled by what is going on, or by your email, because it > > happens basically anytime a high-profile package is treecleaned. Yes, > > Gentoo is about choice, but somebody has to actually do work to make > > the choices viable. There are always more people interested in using > > software than maintaining it. The frustration is completely > > understandable, but also kinda unavoidable. > > It starts to bother me that so many people straight away assume that when > someone questions things it's because they are a frustrated user The eudev experiment has failed. * It was false labeling from the start.[*] * It's barely alive and not keeping up with udev upstream. * It's effectively unmaintained in Gentoo. * You don't gain anything from using it instead of udev. (Nobody does.) So why should anyone put up the effort to package it? [*] Take something out of the systemd tarball, reapply every commit, make tiny changes so it looks different, sell it to the anti-systemd crowd. Sadly no profit, since open source... -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] last rites: sys-fs/eudev
Am Montag, 11. September 2023, 17:22:43 CEST schrieb orbea: > Upstream is maintained still. > > https://github.com/eudev-project/eudev > No, it's not. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: sys-fs/eudev
# Andreas K. Hüttel (2023-09-11) # Dead project accumulating open bugs and incompatibilities. # No maintainer commits since February 2021. # Bugs 673834, 713106, 753134, 667686, 771705, 668880, 770358, 851255, # 711462, 904741, ... Removal in 30 days. sys-fs/eudev -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] adding sec-keys/openpgp-keys-gentoo-release to @system
Dear all, I'd like to add sec-keys/openpgp-keys-gentoo-release to @system - any objections? The package contains a single file (~20k) with the public keys used for stage, manifest, and binpackage signing. This is more of a formal request since portage already depends on it anyway, and the package is present in every stage3. However, it in my opinion makes sense to explicitly state that it needs to be present. Cheers, Andreas -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, comrel, toolchain, base-system, perl, libreoffice) https://wiki.gentoo.org/wiki/User:Dilfridge signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] What happened to gcc-12.3.0?
Am Donnerstag, 15. Juni 2023, 06:02:14 CEST schrieb Joshua Kinard: > > Noticing that the ebuild for gcc-12.3.0 got dropped with little explanation. > It is the upstream stable > release. I am eyeballing #906310 as what may have triggered the drop, but I > find it a bit of a stretch ... This is for exactly the same reason as why we don't have glibc-2.36(-r0) or 2.37(-r0) in the tree anymore. There's a stable upstream branch which accumulates bug and security fixes. The only real difference is naming, but I could switch to glibc-2.36_p20230615 too... -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, comrel, toolchain, base-system, perl, libreoffice) https://wiki.gentoo.org/wiki/User:Dilfridge signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-announce] Gentoo Services Migration: Bugzilla, Forums, Wiki
> > Just keep in mind that CI can't search for open bugs on bugzilla (because of > a down of > course), so bugs that have already been reported in the past, may be reported > on github > too, but from my perspective is better have few duplicates rather than > unnoticed bugs > that may reach the end users. > Jesus. Please just stop it for three days, instead of wasting everyone's time. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, comrel, toolchain, base-system, perl, libreoffice) https://wiki.gentoo.org/wiki/User:Dilfridge signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Various packages up for grabs (avahi, curl, fcron, tor...)
> > acct-group/cron > acct-group/fcron > acct-user/cron > acct-user/fcron > dev-libs/libelf > net-misc/curl > sys-process/cronbase > sys-process/fcron > virtual/cron > virtual/libelf > These should probably go to base-system -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] 23.0 profiles - which features?
Hey all, in the past I already sent a mail about features for a next profile version. The feedback was rather limited, but anyway we got quite a list of ideas. The general tracker is bug 876891. In the following I would like to put up the various features for discussion, in order of bug number... Feedback very welcome. Cheers Andreas https://bugs.gentoo.org/515694 Bug 515694 - Update MIPS profiles to use ABI-specific CHOST values for clang/llvm compatibility Affects only mips profiles. Should eventually be done, I guess? https://bugs.gentoo.org/675050 Bug 675050 - [toolchain] Enable GCC's -fstack-clash-protection for all profiles in Gentoo by default https://bugs.gentoo.org/792081 Bug 792081 - rename no-multilib to nomultilib, also in profile names Apparently this simplifies things for some people, and a new profile is a good chance to do the cosmetic change. https://bugs.gentoo.org/818376 Bug 818376 - [toolchain] Adopt SHT_RELR/DT_RELR relative relocation format *very* new feature... https://bugs.gentoo.org/831045 Bug 831045 - profiles: remove USE=cli default and inline into ebuilds Easy. https://bugs.gentoo.org/849875 Bug 849875 - profiles: remove USE=dri default, clean up make.defaults Also easy. https://bugs.gentoo.org/876879 Bug 876879 - separate openrc and systemd features, not one overriding the other Right now all profiles inherit openrc-specific settings, and these are then again negated and/or overridden in the systemd profiles. Sorting this more cleanly would be nice. https://bugs.gentoo.org/876881 Bug 876881 - make merged usr the default configuration With the next profile version, the "default" setting (default/linux/XX.X/amd64) is a merged usr profile, while the old layout is still present as a split-usr feature. Not sure if this is worth the trouble. https://bugs.gentoo.org/876883 Bug 876883 - [tracker] time64 migration Needed. https://bugs.gentoo.org/876893 Bug 876893 - [toolchain] Adopt -D_FORTIFY_SOURCE=3 for hardened by default https://bugs.gentoo.org/876895 Bug 876895 - [toolchain] Adopt -D_GLIBCXX_ASSERTIONS for hardened by default -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-project] RFC: "Trusted contributor model"
> Once again new council has been elected: congratulations to the chosen > members! And once again many nominees expressed their wishes to see more > non-developer contributors to become official developers. Yet, only very > few people (if any) are interested in mentoring them. I get it, the > relationship between a mentor and their mentee is very intimate, and > mentoring takes a lot of time. While the Github PRs are helping us > increase the user contributions merged, perhaps it's distancing us from > creating stronger bonds with the contributors? But more about this topic > later. Actually, we are doing quite well in terms of recruiting at the moment. I would love to see this continue. And yes, mentors are important for that. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-project] RFC: "Trusted contributor model"
> > 2nd RFC: Recruiting proven contributors without a mentor > > I'm aware recruiters don't really need to ask a permission here, but I > believe it's great to gauge the general feelings about this beforehand. > What would you say if recruiters started more actively approaching > potential developers? And currently I'm talking about people who have > been active for a very long time (+year or two), who keep up with > development-wise changes in Gentoo (eclasses, EAPI, virtuals...), > participate in the community, and always provide top-quality > contributions, but for some reason never got a mentor? I'd like to point > out that this method would only be for the very few ones and recruiting > through mentoring would still be the desired method. > Recruiting through > recruiters would still require the candidate to fill the > ebuild/developer quiz, and they'd have to pass it without a mentor. So > I'll emphasize: Currently only few special ones would qualify. These who would fit here are the people where mentoring takes literally no effort. So someone could be mentor in name - which would also have the advantage that the future developer has someone to talk to if there are any problems or questions. I dont think this actually brings an improvement. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: mail-client/novell-groupwise-client
# Andreas K. Hüttel (2022-06-05) # Ages old, abandoned upstream, and server installs now provide an # actually useful webmail interface. Removal in 30 days. mail-client/novell-groupwise-client -- 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.
[gentoo-dev] it's time for 22.0 profiles
Hi all, it's time for introducing 22.0 profiles [1] - so if you have any things that need to be switched in an incompatible way tree-wide, or if you have any suggestions on how to change our default settings, please reply to this mail with details! Cheers, Andreas [1] Why? That's a quite long e-mail in itself. Very short summary... * All 32bit arches (except riscv32) have a problem. They by default use some datatypes in 32bit, but need to move to 64bit (think timestamps). That's fine for applications, but what do you do if the ABI of some library changes this way? * Plan is to keep the 32bit types as long as possible, and switch to 64bit with the new profile. Details are still being discussed. Pop into #g-toolchain if interested and poke Sam or me... -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] base-system team meeting 15/May 19:00 utc, #gentoo-base
Hey all, we'll do a base-system team meeting 15/May 19:00 utc, on #gentoo-base. There will be only one agenda item, lead election (since I'm stepping down as base lead and will not seek re-election). Cheers, Andreas -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Deprecating repoman
> > > > I wouldn't block anyone from doing this, but it's not something I'm > > personally interested in pursuing. I see very little value here. > > First, you're trying to justify replacing repoman on an entirely subjective > opinion of "I think is superior" ... Well, if you've ever tried it you'll notice that for != repoman actually finishes the checks within a finite amount of time. Kind of, the most blatant argument for ditching repoman, actually. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: net-libs/libnfsidmap
# Andreas K. Hüttel (2022-02-27) # Outdated, fails to build with glibc-2.34, bug 806755 # Has been integrated into net-fs/nfs-utils, please use that instead. # Removal in 30 days. net-libs/libnfsidmap -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH 01/12] toolchain.eclass: remove EAPI 5 and 6
> Dilfridge had a proposal to ensure 3/6/12 month old systems could still > upgrade, and I'm wondering if this could break those systems. > > There are 3 commits in the last year that finally removed the EAPI 5/6 > toolchain consumers: > 486b77ab8d28c5bfd5a4bdfc5f9a5f432ffde563 > b0a39e54065f7eda2dfc719ec05e270fa7e23e38 > 26f684adecb5b9135f9eba9f1b63c83e3d5e5722 > > The latest of those was in September 2021. > > Do we need to wait X months after those removals, to be able to commit > this change? Hmm. Portage saves and reuses the ebuild environment, so each installed package has its phases and related eclass code stored. Which means this is probably fine, since 1) after syncing, the ebuilds are gone, so you'll never be able to rebuild the consumer 2) and unmerging the consumer is done using the saved environment. More opinions welcome... -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] stable users: sys-libs/glibc-2.33-r10 needs testers
Am Mittwoch, 26. Januar 2022, 00:11:42 CET schrieb Andreas K. Huettel: > Hey all, > > I just added sys-libs/glibc-2.33-r9 which is a security fix for the 2.33 > series > (and also adds ebuild improvements backported from the 2.34 series). This just became 2.33-r10 - but the message stays the same! > > Please, if you're still running glibc-2.33, consider testing it! We want to > stabilize it rather soon. Building and normal use... > > (~arch users are already at glibc-2.34, and as you certainly know downgrading > glibc is not possible.) > > Thanks, > Andreas > > -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] stable users: sys-libs/glibc-2.33-r9 needs testers
Hey all, I just added sys-libs/glibc-2.33-r9 which is a security fix for the 2.33 series (and also adds ebuild improvements backported from the 2.34 series). Please, if you're still running glibc-2.33, consider testing it! We want to stabilize it rather soon. Building and normal use... (~arch users are already at glibc-2.34, and as you certainly know downgrading glibc is not possible.) Thanks, Andreas -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: sys-devel/prelink, app-crypt/hmaccalc
# Andreas K. Hüttel (2022-01-22) # Prelink support is being removed from glibc and was # already somewhat broken for a while... # hmaccalc hard-depends on it (?). # Removal in 30 days. sys-devel/prelink app-crypt/hmaccalc -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Looking for a solution to the distutils/setuptools .egg-info mess
> > TL;DR: how to deal with setuptools (and newer distutils vendored by > setuptools) replacing .egg-info files with directories? > I should probably emphasize here that the .egg-info path contains > the package version, so this is a problem only if the same upstream > version is being reinstalled. > > You can easily reproduce the problem by playing with: > > SETUPTOOLS_USE_DISTUTILS=stdlib > SETUPTOOLS_USE_DISTUTILS=local # vendored > 2. We could control the distutils version in ebuilds directly, > i.e. force "stdlib" for the current versions and have developers switch > to "local" on version bumps. Combined with 1., this will probably > increase the coverage a bit but dead packages will remain in the way. > It also relies on all devs understanding the problem. How about switching it with a new Python version? (since that is also in the path...) -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH] multilib.eclass: add initial defaults for ARCH=loong
Thank you! Pushed.
Am Samstag, 25. Dezember 2021, 05:23:41 CET schrieb WANG Xuerui:
> From: WANG Xuerui
>
> There is only full support for the LP64D ABI in the initial upstream
> submissions for the various low-level pieces, so full multilib
> combinations are not pursued at the moment; but the expected library
> search path of gcc (`lib64`) means the default of `lib` does not work
> in our case.
>
> Signed-off-by: WANG Xuerui
> ---
> eclass/multilib.eclass | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/eclass/multilib.eclass b/eclass/multilib.eclass
> index 483f8d10c72..b14b0ef7785 100644
> --- a/eclass/multilib.eclass
> +++ b/eclass/multilib.eclass
> @@ -368,6 +368,15 @@ multilib_env() {
> ;;
> esac
> ;;
> + loongarch64*)
> + export CFLAGS_lp64d=${CFLAGS_lp64d--mabi=lp64d}
> + export CHOST_lp64d=${CTARGET}
> + export CTARGET_lp64d=${CTARGET}
> + export LIBDIR_lp64d=${LIBDIR_lp64d-lib64}
> +
> + : ${MULTILIB_ABIS=lp64d}
> + : ${DEFAULT_ABI=lp64d}
> + ;;
> mips64*|mipsisa64*)
> export CFLAGS_o32=${CFLAGS_o32--mabi=32}
> export CHOST_o32=${CTARGET/mips64/mips}
--
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.
[gentoo-dev] last rites: app-emulation/qemu-riscv64-bin
+# Andreas K. Hüttel (2021-12-19) +# Outdated and not needed anymore (this was a releng workaround) +# Removal in 30 days, please compile it yourself from app-emulation/qemu +app-emulation/qemu-riscv64-bin + -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Printer drivers and net-print
> Maybe consider three new top-level categories?: > - print-drivers > - print-filters > - print-misc Only if you take care of them. printing project is somewhat understaffed. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: several perl-core/*
# Andreas K. Hüttel (2021-12-13) # Outdated, all versions in core Perl are newer. Removal in 30 days. perl-core/IO-Zlib perl-core/Module-CoreList perl-core/Test perl-core/Text-Balanced perl-core/Text-ParseWords perl-core/Thread-Semaphore perl-core/Time-HiRes perl-core/version -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Clang/LLVM profile
> Honestly, I think this is pretty on-topic for gentoo-dev given a lot of us > are quite interested in this. ^ this > - I'm not sure why you would need virtual/toolchain or virtual/binutils > unless it's just for usage within bootstrapping scripts? Seems more like > you could just remove gcc from @system and such? ^ this too FWIW, a minimal chroot (corresponding to a stage3) rebuilds quite nicely with clang, with one exception (sys-libs/glibc obviously). Being able to build glibc with clang is seen as a desirable long-term goal by glibc upstream, seems to be nontrivial to implement though. -- 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.
[gentoo-dev] 2021 retrospective
Hey all, in the spirit of our "2020 in retrospect & happy new year 2021!" front page article, https://www.gentoo.org/news/2021/01/15/new-year.html which was rather well received, I'd already like to start collecting news from 2021! Suggestions, text snippets, illustrations welcome- either as a reply here on-list, or directly to me. Cheers, Andreas -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: several perl-core/*
# Andreas K. Huettel (2021-11-04) # Unused and outdated packages; the version in core Perl is # newer. Removal in 30 days. perl-core/Module-Metadata perl-core/parent perl-core/podlators perl-core/Pod-Simple perl-core/Sys-Syslog perl-core/Term-ANSIColor -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Basic upgrade CI testing
> I think the obvious easy solution here is to run a CI that is using > older stuff, and report problems when commits break that. Something that's been bouncing around my head: * archive stage3 files somewhere official * run a weekly CI job that attempts to upgrade a N-weeks old stage3 to current, with "emerge -uDNav world" * for N=1,2,4,8,16,32 etc * if it fails, annoy people Limitations: 1) covers only stage3 2) solutions may not always be obvious 3) culprits may not always be obvious -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system
Am Mittwoch, 3. November 2021, 22:39:41 CET schrieb Ulrich Mueller: > >>>>> On Wed, 03 Nov 2021, Andreas K Huettel wrote: > > > The mistake was to allow the use of EAPI=8 too early. In the future, > > we should have a new EAPI supported by portage for at least some > > months before the EAPI is even used in the main tree. Not even > > speaking about stable here. > > I tend to disagree. Adding an ebuild with a new EAPI cannot break > anything, because it will simply be invisible to old package managers. Except that you need to keep track of version dependencies across the whole tree. So, yes, this is in principle correct, and in practice with our current tooling more or less impossible to do reliably. [Part of the output Whissi pasted was (more or less) that a Perl upgrade required a rebuild of Perl modules. Unfortunately, even a single one that is not available for rebuild makes the emerge bail out.] -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system
Am Mittwoch, 3. November 2021, 16:03:37 CET schrieb Thomas Deutschmann: > Hi, > > it is currently not possible to smoothly run a world upgrade on a 4 > months old system which doesn't even have a complicated package list: > [snip] Yup. We know. It's actually way worse than you describe [*] and was noticed already quite some time ago. Unfortunately this is a situation that can IMHO not be easily fixed, and we can only strive to do it better next time. The mistake was to allow the use of EAPI=8 too early. In the future, we should have a new EAPI supported by portage for at least some months before the EAPI is even used in the main tree. Not even speaking about stable here. From there on all the trouble cascades. And no, disallowing a new EAPI for only a part of the tree does not help. (Which part?) An alternative, which we should seriously consider (and which I've been advocating for several months now) is to make Portage more robust, so it can more easily upgrade itself, and keep the Portage ebuild at old EAPI. This means, * making Portage independent of the python eclasses, so it runs as long as any python3 interpreter exists * and bundling all Python dependencies it needs for functioning in it [*] Of course there are ways around this to upgrade the system. However, that is not the point. It should work out of the box. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: sys-apps/sandbox/
> > PS. > checking whether the C compiler works... * > /var/tmp/portage/sys-apps/sandbox-2.25/work/sandbox-2.25/libsandbox/trace.c:_do_ptrace():83: > failure (Function not implemented): > * ISE:_do_ptrace: ptrace(PTRACE_TRACEME, ..., 0x, > 0x): Function not implemented > configure: error: cannot run C compiled programs. > (and yes this is in qemu-alpha user space emulation) > Oops, sorry, this was the bump to sandbox-2.28 (?), not the stabilization. Main point still holds though. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: sys-apps/sandbox/
Mike,
could you please do this just like everyone else, i.e. file a bug and give
arch teams a go? Even if you're on all the arch teams? Even if you know the
code best? More eyes do not hurt.
(I am absolutely not in the mood right now for hunting down why alpha stage
builds now fail.)
TIA
Andreas
PS.
checking whether the C compiler works... *
/var/tmp/portage/sys-apps/sandbox-2.25/work/sandbox-2.25/libsandbox/trace.c:_do_ptrace():83:
failure (Function not implemented):
* ISE:_do_ptrace: ptrace(PTRACE_TRACEME, ..., 0x,
0x): Function not implemented
configure: error: cannot run C compiled programs.
(and yes this is in qemu-alpha user space emulation)
Am Freitag, 22. Oktober 2021, 01:01:01 CEST schrieb Mike Frysinger:
> commit: 9aac75c0adaf470a9c8605aa4aee59f37f625040
> Author: Mike Frysinger gentoo org>
> AuthorDate: Thu Oct 21 22:47:40 2021 +
> Commit: Mike Frysinger gentoo org>
> CommitDate: Thu Oct 21 22:57:23 2021 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9aac75c0
>
> sys-apps/sandbox: stabilize 2.25
>
> Signed-off-by: Mike Frysinger gentoo.org>
>
> sys-apps/sandbox/sandbox-2.25.ebuild | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/sys-apps/sandbox/sandbox-2.25.ebuild
> b/sys-apps/sandbox/sandbox-2.25.ebuild
> index d35f5327d29..70179abd1b9 100644
> --- a/sys-apps/sandbox/sandbox-2.25.ebuild
> +++ b/sys-apps/sandbox/sandbox-2.25.ebuild
> @@ -11,7 +11,7 @@ SRC_URI="https://dev.gentoo.org/~mgorny/dist/${P}.tar.xz;
>
> LICENSE="GPL-2"
> SLOT="0"
> -KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64
> ~riscv ~s390 ~sparc ~x86"
> +KEYWORDS="~alpha amd64 arm arm64 hppa ~ia64 ~m68k ~mips ppc ppc64 ~riscv
> ~s390 sparc x86"
> IUSE=""
>
> DEPEND="app-arch/xz-utils
>
>
--
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI=5 must go -- final sprint! :)
Am Sonntag, 17. Oktober 2021, 21:43:40 CEST schrieb Oskari Pirhonen: > On Sun, Oct 17, 2021 at 08:57:26PM +0200, Andreas K. Huettel wrote: > > So, let's make that number go down further fast! :D Cheers! > > What is the best way to help with that? Should I just grep for "EAPI=5" > in /var/db/repos/gentoo and submit a pr with an updated ebuild? Is the > new target EAPI 8? Moikka! Yes, and yes ... in many cases PR's are best, and the new target is EAPI=8. Not all Gentoo devs work with Github, but many do. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] EAPI=5 must go -- final sprint! :)
We've reached the number of only 1000 EAPI=5 ebuilds left in the gentoo repository today! So, let's make that number go down further fast! :D Cheers! -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: virtual/perl-Pod-Parser
# Andreas K. Hüttel (2021-10-16) # Outdated virtual; the respective module was removed # from core Perl with Perl 5.32. Use dev-perl/Pod-Parser # instead. Removal in 30days. virtual/perl-Pod-Parser -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: net-im/webex
# Andreas K. Hüttel (2021-10-16) # Binary-only package, cannot be distributed, download # is an unversioned URL which changes content. In brief, # a pain. Unmaintained from now on. If you pick it up, # you'll have to watch it closely. Removal in 30 days # otherwise. Bug 794700. net-im/webex -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: various perl-core/*
# Andreas K. Huettel (2021-10-14) # Unused and outdated packages; the version in core Perl is # newer. Removal in 30 days. perl-core/Locale-Maketext-Simple perl-core/Math-BigInt perl-core/Math-Complex perl-core/Memoize perl-core/MIME-Base64 -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH 1/1] glep-0068: Add notes element for package maintenance instructions
> > I generally agree that comments are more visible/noticeable than > metadata, however, I also think that this could be a good step forward > for overall maintainability. The issue with documenting these things > in comments is that the comment lives only within the specific version > of the ebuild in which it is authored: it is up to the maintainer to > carry those comments over when version bumping. While this is > generally not a problem due to copy/paste, I think it is messy - there > could be an update to the comment from one version to the next, > meaning I now have two version of the comment floating around. > > With , there is one localized "source of truth" for this > documentation, which should remove any ambiguity. > > I would hope that after launching the feature, there would be > a gradual (or sudden?!) shift away from the current comments towards > the tag, maybe even including this in the dev manual. > That makes no sense, since the notes could be version-dependent. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Experimental binary package hosting
Hi Vadim, > Finally it happened! > I already planned to try to ask infra/council about sponsoring few > servers for build farm for "official gentoo binhosts" when I had > enough time, but fortunately, you've already did that. > It's very good news. Thanks! Nice to see that this is appreciated :) So far I'm only using "spare time" on the machine that builds the releng stages (amd64, x86, m68k, riscv). So no need for a big server farm. > Btw, do you need any help with that? > I'd be very happy to help with that project. Sure! Feel free to add yourself to the Project:Binhost wiki page. I'll ask for an alias and a channel soon. The most useful steps now are only half related to actual building. I barely know any python and am not very familiar with portage internals... this is what in my opinion we'd need next: 1) a tool to manage and manipulate a binpkg/ directory tree The main functions that I see needed are * delete packages/versions that are not in the gentoo repository anymore (xpak and in index file), maybe with some grace time * merge xpak files built elsewhere into the directory (also in the index file) (imagine you have a second container that builds with same CFLAGS, but with use settings for gnome, not plasma... or with updated dependencies because of changes in gentoo.git... you want to merge the trees for distribution without having duplicate builds) 2) binary package cryptographic signing and verification Essentially we need to finish support for GLEP78; this is being worked on in RinCat's pull request https://github.com/gentoo/portage/pull/562 See also https://www.gentoo.org/glep/glep-0078.html 3) an easy way to figure out if a binary package repo is suitable for a profile / arch / ... or not, and a standard for path names This is not so important right now, and partially also already present I guess. The actual builder right now is very simple and wired up with a single daily cron job; the mirrors are only updated manually by me until bug 813528 is handled. Cheers Andreas -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Experimental binary package hosting
Am Mittwoch, 22. September 2021, 10:20:10 CEST schrieb Torokhov Sergey: > Sorry for previous html message. I tried to recend it as plaintext. > > I have repos configs placed into /etc/portage/repos.conf with > "rsync-type = git" fo all repos so I created binhost.cond file here > instead of /etc/portage/ as mentioned in blog post. Nope. As the blog post says, you need to put that text into a *file* with name -->>> /etc/portage/binrepos.conf <<<--- ... -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Experimental binary package hosting
> Andreas, > > How is USE=bindist treated? > Its on for stage building and off in profiles. USE=bindist is switched on, and in addition we have ACCEPT_RESTRICT="* -bindist" -- 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.
[gentoo-dev] Experimental binary package hosting
So let's experiment with this... :) announcing: https://gentoo.osuosl.org/experimental/amd64/binpkg/default/linux/17.1/x86-64/ More information can be found in a blog post, which will also be on planet.g.o soon: https://dilfridge.blogspot.com/2021/09/experimental-binary-gentoo-package.html Cheers -A -- 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] Guidance on distributed patented software
Am Montag, 20. September 2021, 19:27:37 CEST schrieb Rich Freeman: > On Mon, Sep 20, 2021 at 12:46 PM Alec Warner wrote: > > Could we add some text to the license concepts covering patents? It > > seems to have been omitted? > > Is my understanding of how we manage patented software correct? > > I think you have the gist of it. Is there actually anything in the > repo these days which is patent-encumbered? media-libs/openh264 for example (It right now prevents me from building firefox and chromium for the experimental binary package hosting [1], since I blanket mask everything with bindist restriction. That is likely a bit of overkill, it would be enough to not make any binary package from it (which ends up being distributed), but that function needs to still be programmed in portage.) [1] Blog post with details coming soon. Please wait for it before asking questions. -- 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.
[gentoo-dev] last rites : toolchain-glibc.eclass
toolchain-glibc.eclass is long obsolete and not used anymore since glibc-2.26. Last ebuild is gone now, so removing the eclass in 30 days. -- 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.
[gentoo-dev] last rites: dev-perl/POE-API-Peek
# Andreas K. Hüttel (2021-08-15) # Broken since Perl 5.22, bug 662318. Removal in 30 days. dev-perl/POE-API-Peek -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: dev-perl/MooseX-Types-DateTime-ButMaintained dev-perl/MooseX-Types-DateTimeX
# Andreas K. Hüttel (2021-08-15) # Broken-ish, upstream unmaintained, only one un-used revdep. # Removal in 30 days. Bug 623674. dev-perl/MooseX-Types-DateTime-ButMaintained dev-perl/MooseX-Types-DateTimeX -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: dev-perl/Perlbal-XS-HTTPHeaders
# Andreas K. Hüttel (2021-08-15) # Broken for years, see bug 642466. No reverse dependencies, # no easy fix. Removal in 30 days. dev-perl/Perlbal-XS-HTTPHeaders -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: new category for container related packages, instead of app-emulation
> > Categories themselves were not a design mistake. The design mistake is > using categories to permit conflicting package names. > > Categories are convenient. Sure, they're not perfect but they serve > their purpose to some degree and there's little harm in having them. > If you want to organize packages better, nobody's stopping you. Until > you've got a better and widespread replacement, I don't see why people > shouldn't be using categories as they see fit. > > The other part is something we could aim for fixing but so far most > developers seems to disagree with me, so there's no point in pursuing > that. > So how about improving categories instead? Rough idea: * introduce 1st, 2nd, 3rd class categories, categorized in metadata somewhere * 1st class is what you want in your world file (and default setting) * 2nd class is everything else * 3rd class is stuff that should never be in your world file (but still can be, if you want) Then tooling can (maybe output a warning but) default to highest class category if none is given. Examples: * 1st class: app-*, dev-lang, games-*, ... * 2nd class: dev-haskell, dev-perl, dev-php, dev-python, dev-texlive, media-libs, net-libs, sci-libs, ... * 3rd class: acct-*, perl-core, virtual -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: new category for container related packages, instead of app-emulation
Am Donnerstag, 5. August 2021, 23:44:40 CEST schrieb Georgy Yakovlev: > Hi, > > We've been collecting more and more container related packages in > app-emulation/* > > What do you think about finally moving those packages to separate category? > > probably app-containers/ > > Here's the tentative list, most tools have description attached for easier > review, 36 candidates so far, there may be more around, I only looked at > app-emulation. Sounds like a good idea! -a -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: various perl-core/*
# Andreas K. Hüttel (2021-07-31) # Obsolete; all versions in current Perl core distributions # are newer, and no virtuals currently pull these packages. # Removal in 30 days. perl-core/ExtUtils-MakeMaker perl-core/ExtUtils-Manifest perl-core/File-Path perl-core/Getopt-Long perl-core/HTTP-Tiny perl-core/JSON-PP perl-core/libnet -- 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] [RFC] Removing SHA512 hash from Manifests
Am Samstag, 24. Juli 2021, 17:16:23 CEST schrieb Michał Górny: > Hi, everyone. > > I've been asked to repost the idea of removing SHA512 hash from > Manifests, effectively limiting them to BLAKE2B. Just keep things as they are for now. Even reading this bike^H^H^H^Hthread is more effort than the potential gain. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice)
Re: [gentoo-dev] [PATCH] Add deblob support only for python3
> My modest opinion on the topic is: > As far that is free software and there are users that use deblob, I > don't see any reason on why we should not support this and give them > the > choice. Gentoo is about choice. [snip] > deblob is only supported for rt-sources. > gentoo-sources currently doesn't have deblob. So deblob is highly important for choice, you say. Also, the kernel sources that everyone uses don't offer deblob. Somehow this discussion is getting ridiculous. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH] Add deblob support only for python3
> > Gentoo is about choice. if there are users that want to use deblob I > don't see why we don't have to add the option. > Errr how is *removing the firmware loader* about choice? You have all the choice of the world by just not providing any firmware to load. Removing the loader removes that choice. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: several perl-core/*
# Andreas K. Hüttel (2021-07-17) # Obsolete; all versions in current Perl core distributions # are newer, and no virtuals currently pull these packages. # Removal in 30 days. perl-core/Archive-Tar perl-core/CPAN-Meta perl-core/CPAN-Meta-Requirements perl-core/Data-Dumper perl-core/Digest perl-core/Digest-MD5 perl-core/Digest-SHA perl-core/Dumpvalue perl-core/Encode perl-core/ExtUtils-Constant -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: virtual/perl-Pod-Parser
# Andreas K. Hüttel (2021-07-17) # Obsolete virtual; package was removed from the Perl # core distribution. Please depend on dev-perl/Pod-Parser # instead. Removal in 30 days. virtual/perl-Pod-Parser -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH] 2021-07-09-systemd-tmpfiles: re-add news item
> > > > 1) either the severity assignment of this bug by the Security project as B1 > > wrong (i.e. it should have been classified "harmless") > > > > The Gentoo model is not perfect and should be overhauled. However, it > works for most things and sometimes bugs fall between the cracks. > > The package shouldn't have been masked either based on a bug that was > purposely ignored for many years simply because they want to disband the > package now and found a "security reason" to add to the mask. Well, over the last year or so every 2-3 months the (uninformed) discussion came up, "don't use openrc stages because you are automatically rooted". That leaves a rather bad impression of Gentoo, independent of whether it is true or not. If noone from sec team noticed the discussions... > > 2) or the entire classification of severity levels according to the > > Security project pointless (i.e. you can't base any actions on them because > > a mystery onion needs to be taken into account). > > > > I am not sure if this is sarcasm, but every bug must be considered > through the correct aperture. That is, based on your environment, > protections in place, defense in depth, and other buzzwords... hence the > onion analogy. It's not sarcasm. The point of the classification is to give clear rules (why else would you list, e.g., required response times on the vulnerability treatment page (no matter how illusory they are)). If you don't take all factors into account when *making* the classification, then all gain you have from the classification is lost. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH] 2021-07-09-systemd-tmpfiles: re-add news item
> The package was masked due to a miscommunication with the Gentoo > Security project. > > While it is true that the way opentmpfiles is currently implemented > allows for certain races, from the security point of view, you always > have to classify the vulnerability in context of your threat model > because security depends on multiple layers (onion model). I would like to respectfully point out that this makes 1) either the severity assignment of this bug by the Security project as B1 wrong (i.e. it should have been classified "harmless") 2) or the entire classification of severity levels according to the Security project pointless (i.e. you can't base any actions on them because a mystery onion needs to be taken into account). https://www.gentoo.org/support/security/vulnerability-treatment-policy.html -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] 'pax_kernel' USE flag
> > The PaX community in Gentoo is still big and active. > > > > Many Gentoo users received free access to upstream sources or became > > paying customers. > > > > It's just not available for everyone for free/without registration > > anymore. But it is still a thing in Gentoo. > > Can you substantiate that claim? > > There was a pax-kernel USE flag on Mesa and I don't recall anyone > saying a word when I removed it. > > If there are paying customers that have PaX kernels, perhaps they'd be > interested in providing some support for Gentoo if we're being asked > to retain support for something we cannot test. Summary from the replies so far: * either noone is using it, * or noone is willing to admit using it. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] New Developer: Florian Schmaus (flow)
Welcome Florian!!! Where in Franconia are you from?! Regensburg here, so just "south beyond the border"... :D (Arcobräu!) Am Dienstag, 22. Juni 2021, 21:27:11 CEST schrieb Gokturk Yuksek: > Hello everyone, > > I'd like to announce with great pleasure our latest addition to the > developer community. Florian Schmaus is joining us from Germany. > > He is a computer scientist focusing on operating systems and runtime > systems for future many-core systems. His FOSS contributions include > participating in developing the XMPP protocol and maintaining an XMPP > client-side library Smack. In his free time, besides being a full-time > dad, he enjoys running and the cold beverages of his home region, > Franconia. > > Please give him a warm welcome! > > -- > gokturk -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] news item: riscv upgrade to 20.0 profiles
Feedback welcome... Title: riscv upgrade to 20.0 profiles Author: Andreas K. Hüttel Posted: 2021-06-25 Revision: 1 News-Item-Format: 2.0 Display-If-Profile: default/linux/riscv/17.0/rv64gc/lp64d Display-If-Profile: default/linux/riscv/17.0/rv64gc/lp64d/systemd Display-If-Profile: default/linux/riscv/17.0/rv64gc/lp64 Display-If-Profile: default/linux/riscv/17.0/rv64gc/lp64/systemd On RISC-V we are switching from two-level library directories (e.g., /usr/lib64/lp64d) to a more traditional directory architecture. This is done via the profile upgrade from 17.0 to 20.0 profiles. We recommend to re-install from scratch using a 20.0 profile based stage. 17.0 profiles will be deprecated immediately and removed in 6 months. If you want to upgrade an existing installation, the following steps should be taken. Please read all commands carefully first and make sure you understand them, since the procedure is risky. The commands are given for a lp64d profile; in case of a lp64 profile, always replace lp64d with lp64. # cd /usr/local/lib64 # cp -av lp64d/. . # rm -rf lp64d # ln -s . lp64d # cd /usr/lib64 # cp -av lp64d/. . # rm -rf lp64d # ln -s . lp64d # cd /lib64 # cp -av lp64d/. . # rm -rf lp64d # sln . lp64d Note that the last command uses "sln" instead of "ln -s". Then switch from your 17.0 profile to the corresponding 20.0 profile, either by using "eselect profile" or by manually changing the /etc/portage/make.profile symlink. Next, rebuild all packages: # emerge -eav world As last step, check if portage has removed any of the symlinks created above, and if yes, recreate them. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Need help with perl-cleaner (and app-admin/gentoo-perl-helpers)
> > https://github.com/gentoo-perl/gentoo-perl-helpers > > I believe infra were the inspiration for it and are the main > consumers. Worth speaking to them? Yes I will... It's not that I dont want to help them, but... -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Need help with perl-cleaner (and app-admin/gentoo-perl-helpers)
Am Donnerstag, 13. Mai 2021, 12:02:32 CEST schrieb Andreas K. Huettel: > Hi all, > > due to having somewhat too many Gentoo projects and not enough time > at the moment, I'd like to ask for help with perl-cleaner here. > PS. app-admin/gentoo-perl-helpers also needs a new maintainer, both in Gentoo and upstream. I have never touched it so far and am completely unfamiliar with the code and its usage. https://github.com/gentoo-perl/gentoo-perl-helpers -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Need help with perl-cleaner
Hi all,
due to having somewhat too many Gentoo projects and not enough time at
the moment, I'd like to ask for help with perl-cleaner here.
It is in most cases not necessary anymore, and I personally have not
used it for ages, since the automated rebuilds via subslots make it
obsolete. Still...
* The change in path structure with Perl 5.32 (from, e.g., /usr/lib64
perl5/5.30.3 to /usr/lib64/perl5/5.32) broke the rebuild functionality
[1]
* There are issues with the 17.1 profiles [2]
* There are several unrelated bugs and github issues.
* Testing is nontrivial since you basically need a snapshotted
install, where you can roll back a Perl upgrade.
* The code is, well, horrible. [3]
In any case, please have a look and file bugs and even better patches
and/or pull-requests...
https://github.com/gentoo-perl/perl-cleaner/
If no help materializes, my plan is to lobotomize perl-cleaner so it
only cleans out "known leftover files" and otherwise recommends a
portage command to rebuild all reverse dependencies of dev-lang/perl.
Unfortunately this kind of blocks Perl 5.32 stable.
Cheers,
Andreas
[1] https://bugs.gentoo.org/763021
[2] https://bugs.gentoo.org/589874
[3]
broken_libs="$(${scanelf} -qBn < <(awk '/^(obj|sym) [^ ]*\/(s?bin|
lib(32|64|x32)?)\// && ! /^obj [^ ]*\/usr\/lib\/debug\//{ print $2 }'
${content} ) | grep -o 'libperl\.\(so\|dylib\)\.[0-9.]*' | sort -u )"
--
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] removal: dev-perl/PortageXS app-portage/demerge app-portage/perl-info
# Andreas K. Hüttel (2021-05-09) # PortageXS saw its last release in 2016 and would need # a new upstream maintainer. Multiple bugs, e.g., # 688238, 625536, 613114, 473394, 332611, 289524, 264680 # Masked for removal in 30 days, including reverse deps. dev-perl/PortageXS app-portage/demerge app-portage/perl-info -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] How to structure our RISC-V support -- Summary
So, here's what I took away from the thread. Please shout if you disagree. 1) Advertised riscv profiles will all be non-multilib and use /usr/ lib64 (or /usr/lib if we ever get around to riscv32). [A] 2) The standard for keywording and stabilization is rv64gc/lp64d. We keep stages for other variants [B] around if feasible, but on these important packages may be masked and unavailable [C]. 3) We try to internally keep the multilib variant with the two-stage path going for now, as very low-priority thing. [D] 4) Medium term we discuss with the RISC-V, glibc, gcc people how multilib could be simplified, and then switch the multilib settings once this comes to a conclusion. If there are no protests I'll start planning the path migration for 1). (Maybe making a riscv-specific new profile version is best.) Cheers, Andreas [A] Note that the actual specs use /usr/lib32/... [B] Other ABI (lp64) or other ISA (riscv32...) [C] See rust etc. [D] Low priority means, it pretty much won't build every now and then, as, e.g., right now [E]. [E] Our monkeypatched glibc-2.32 rv32 support was experimental enough so it didnt survive the transition to official upstream glibc-2.33 support, so the multilib stages will have to be re-bootstrapped. > So, I would like to bring two proposals up for discussion. > > 1) We stop caring about anything except rv64gc/lp64d. > People can still bootstrap other stuff with crossdev etc, but the > Gentoo tree and the riscv keyword reflect that things work with > above -mabi and -march settings. > > 2) We drop the multilib paths and use "normal" lib64, with > additional "safety symlinks" (/usr)/lib64/lp64d -> . > This is what SuSE and (I think) Fedora already does. The symlink > should be there since "lib64" is NOT an official fallback coded into > gcc/glibc/binutils; the only fallback present is "lib" ... -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] How to structure our RISC-V support
Am Donnerstag, 6. Mai 2021, 22:34:52 CEST schrieb Palmer Dabbelt: > > TBH: I'm not really going to come up with something better beacuse I > came up with the current (and likely broken) scheme and I still > don't fully understand why. So if you have suggestions as to > something that would actually work that would be great, as > otherwise I'm just going to come up with something broken again ;) > Heh. No worries. I actually liked the idea, just until the moment when I remembered that we had been campaigning for months to replace all absolute symlinks in Gentoo with relative ones. And suddenly there is only on riscv not enough "../" in the link. > Is the constraint just "no sub-directories for libraries"? IIRC we > did that because someone else was already doing it and it seems to > be less of a FHS break that adding a bunch of first-level > directories. I need to read up on FHS. Time... -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] How to structure our RISC-V support
> I'm fine with rust masked in lp64/other profile.. > but in my opinion: it's really up to upstream should fix/support it > > > (Unless Palmer et al come up with a fix for the libdirs on the > > upstream side of things. Already e.g. libdir=lib64-lp64d would be > > much easier to handle I suspect.) > > using one level path (eg. lib64-lp64d) won't fix the problem, > the root cause is that we use a 'non-standard' lib path (QT5, Cmake > issue), not matter it's one level or two level path, see bug here I suspect this may need some more analysis. But, if we transition in non-multilib cases to normal lib64, then we have all the time in the world to figure it out. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] How to structure our RISC-V support
> > 1) We stop caring about anything except rv64gc/lp64d. > > People can still bootstrap other stuff with crossdev etc, but the > > Gentoo tree and the riscv keyword reflect that things work with > > above -mabi and -march settings. > > fine by me, for current software/upstream state, it's probably the > most practical way to only support lp64d, this will significantly > ease our life .. besides, it's relatively easy if people want to > support more (lp64/lp32..) later > ++ > > 2) We drop the multilib paths and use "normal" lib64, with > > additional "safety symlinks" (/usr)/lib64/lp64d -> . > > This is what SuSE and (I think) Fedora already does. The symlink > > should be there since "lib64" is NOT an official fallback coded > > into gcc/glibc/binutils; the only fallback present is "lib" ... > can we use different scheme for non-multilib vs multilib? > 1) non-multilibe: just use "normal" lib64, keep align with other > ARCHs (amd64)? ++ > 2) multilib: just stick to current two level lib path We can try that but it doesn't solve any of our problems (and we'd have to keep carrying the two-level dir patches). (I've already decided some time ago that supporting real multilib stages is too much effort for insufficient gain and stopped publishing them. Until recently I still built them; since glibc-2.33 they broke and while I know how to fix things I haven't had time to do it yet.) So if we keep the multilib scheme around, then IMHO only as internal workaround until we/upstream/... have figured out a better directory scheme. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] How to structure our RISC-V support
> > Haven't I told you using two-level libdirs is stupid? So yes, > please do that and let us be happy once again. > > That said, where does lp64gc land? Or isnon-multilib > one-or-the-other the goal? It would be non-multilib one-or-the-other then for us. The main relevant combination is rv64gc/lp64d, which is arguably what a linux machine "should have". (I could also imagine to keep rv64imac/lp64 profile and stages (also using lib64), these would have to mask stuff like rust then though.) (Unless Palmer et al come up with a fix for the libdirs on the upstream side of things. Already e.g. libdir=lib64-lp64d would be much easier to handle I suspect.) -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] How to structure our RISC-V support
>
> -mabi=rv64gc -march=lp64d
should be -march=rv64gc -mabi=lp64d
> libdir = lib64/lp64d
> ("hardfloat")
>
> -mabi=rv64imac -march=lp64
should be -march=rv64imac -mabi=lp64
> libdir = lib64/lp64
> ("softfloat")
>
(but that doesnt change the rest of the argument)
--
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] How to structure our RISC-V support
Howdy.
I'm sending this not only to the team members on the alias, but also
to the whole dev list for discussion.
So far I've been trying to support in Gentoo the full risc-v multilib
directory structure and the ABI sets supported by glibc. According to
specs this means for riscv64
-mabi=rv64gc -march=lp64d
libdir = lib64/lp64d
("hardfloat")
-mabi=rv64imac -march=lp64
libdir = lib64/lp64
("softfloat")
and theoretically similar for riscv32 (which just landed in glibc and
is still broken in qemu-user).
However, this leads to several levels of pain (and I definitely dont
have time to deal with it myself):
a) In many places the two-level libdir (e.g., /usr/lib64/lp64d) leads
to difficulties in build systems. Right now Qt5 and CMake are still
somewhat broken (in *Gentoo*).
b) Rust only supports rv64gc/lp64d. (Which is arguably what you should
have for decent Linux support.)
I'm pretty sure these are not the only things, but they are somewhat
symptomatic.
So, I would like to bring two proposals up for discussion.
1) We stop caring about anything except rv64gc/lp64d.
People can still bootstrap other stuff with crossdev etc, but the
Gentoo tree and the riscv keyword reflect that things work with above
-mabi and -march settings.
2) We drop the multilib paths and use "normal" lib64, with additional
"safety symlinks" (/usr)/lib64/lp64d -> .
This is what SuSE and (I think) Fedora already does. The symlink
should be there since "lib64" is NOT an official fallback coded into
gcc/glibc/binutils; the only fallback present is "lib" ...
Opinions?
Cheers,
Andreas
--
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [News item review] Exim >=4.94 transports: tainted not permitted
Am Sonntag, 2. Mai 2021, 11:56:34 CEST schrieb Fabian Groffen: > Title: Exim >=4.94 disallows tainted variables in transport > configurations Author: Fabian Groffen > Posted: 2021-05-?? > Revision: 1 > News-Item-Format: 2.0 > Display-If-Installed: mail-mta/exim > > Since the release of Exim-4.94, transports refuse to use tainted > data in constructing a delivery location. If you use this in your > transports, your configuration will break, causing errors and > possible downtime. > > Particularly, the use of $local_part in any transport, should likely > be updated with $local_part_data. Check your local_delivery > transport, which historically used $local_part. > > Unfortunately there is not much documentation on "tainted" data for > Exim[1], and to resolve this, non-official sources need to be used, > such as [2] and [3]. This is a safety mechanism that is part of Perl (essentially a way of tracking data that is derived from "insecure" sources). So it probably would make sense to at least point towards that concept in Perl. https://perldoc.perl.org/perlsec -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: dev-perl/Sane
# Andreas K. Hüttel (2021-04-30) # Superceded by dev-perl/Image-Sane. Tests hang, bug 626594 # Removal in 30 days. dev-perl/Sane -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: some outdated perl-core/*
# Andreas K. Hüttel (2021-04-30) # Outdated, not pulled in by any virtuals anymore, no # keywords. Removal in 30 days. perl-core/Devel-PPPort perl-core/Time-Local perl-core/Unicode-Normalize -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Last rites: dev-perl/HTTPD-User-Manage
# Andreas K. Hüttel (2021-04-25) # Broken, bug 616986; removal in 30 days dev-perl/HTTPD-User-Manage -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Last rites: dev-perl/Text-Unaccent
# Andreas K. Hüttel (2021-04-25) # Broken, bug 663274; removal in 30 days dev-perl/Text-Unaccent -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?
> > Council decided years ago that we don't support separate /usr without > > an initramfs, but we haven't completed that transition yet. > > Which doesn't imply that we deliberately break things. That's right. Though we should at some point start thinking about an end of support for separate usr without initramfs. Why? Because the number of required hacks and complexity will only increase, as will the number of uncooperative upstreams. It's called a strategic retreat. :D My suggestion would be that the next profile version (21? 22?) declares separate /usr a broken configuration, and explicitly encourages devs to introduce all ebuild simplifications that are made possible by this. (Like this symlink - no more conditional code.) No more discussions about "not breaking things" at that point. (Or to put it another way, I think we should stop wasting time and effort here just to be able to live in the past.) -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?
Hi all, why do we *copy* the timezone file to /etc/localtime, instead of symlinking it like everyone else? 1) Our handbook recommends: echo "Europe/Brussels" > /etc/timezone emerge --config sys-libs/timezone-data which is effectively doing echo "Europe/Brussels" > /etc/timezone cp -f /usr/share/zoneinfo/Europe/Brussels /etc/localtime 2) Most other distros seem to just do ln -sf /usr/share/zoneinfo/Europe/Brussels /etc/localtime and use the link content as timezone name (this is also what is required by systemd). Does anyone remember the reason for 1) ? Or is that lost in history? Cheers, Andreas PS See also bug https://bugs.gentoo.org/737914 , where support for 1) was removed from Qt. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice)
[gentoo-dev] Last rites: dev-libs/klibc
# Andreas K. Hüttel (2021-03-06) # Fails to build, multiple bugs, outdated, nontrival, unmaintained # Bug 729876 and several others; removal in 30days dev-libs/klibc -- 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] New project: binhost
Replying to a random post here- I'm sorry, briefly after I started this thread real life got in the way and a lot of other things became more urgent. As soon as I have time (next weekend?) I'll reply to the many e-mails here. Thanks -A -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Towards getting GCC 10 stable
Hey all,
it would be great if we could get gcc-10 stable at some point in the near
future... For that purpose we now have a new tracker:
https://bugs.gentoo.org/762907 ("gcc-10-stable", depends on 127 open bugs).
Please have a look if you can help anywhere with the blocking bugs.
Thanks a lot in advace :)
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] Getting rid of USE=unicode
Am Mittwoch, 30. Dezember 2020, 19:53:25 EET schrieb Aisha Tammy: > > Yes, this sounds nice. > What about packages which rely on/give unicode support outside of this flag? > Like the global icu flag, which supposedly needs dev-libs/icu ? > Hmmm... good point. I thought too simple. 1) We want to enable unicode unconditionally whereever that is possible without much impact. 2) If that pulls in large libraries like icu, a useflag remains useful. So maybe instead of any use.forcing we should just go through the ebuilds and a) reduce the number of occurences of IUSE=unicode as much as possible b) switch to IUSE=icu or similar where that makes sense -- 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.
[gentoo-dev] Getting rid of USE=unicode
Hi all, since utf8 encoding is everywhere by now, and since switching the useflag unicode off without taking precautions is a way to hose your installation, I would propose to medium-term get rid of this flag. Suggestion: 1) use.force unicode now/soon in the default profiles 2) step by step, modify ebuilds to enable the functionality unconditionally (and if necessary fix depstrings) 3) at some point the flag is gone Opinions? 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] [RFC] Discontinuing LibreSSL support?
> > a) The two cannot be installed concurrently. To fix that would require > > even > > more hacks. > > As we've discussed in another part of the thread, that's not really true. > Both can for sure be installed, just not in the same place and/or > with same names. Exactly that is what would require even more hacks. Given how many different and more or less hackish build systems exist in the Gentoo tree, this is just not feasible. > > -> all relevant ssl consumers on the user's system must be linked against > > the one selected > > Also not the case. Considering the two installed in different paths > with same names it's still easy for consumers to use one or the other > with -rpath at link time. Dito... Please remember, the point is to keep this somewhat maintainable. > > c) If a single package that the user wants to install is not "fixed" for > > one ssl library, it blocks that option for all packages. > > Please think of a libressl ebuild in a new way. Well, if it just drops the library somewhere where nothing can use it... that can for sure be done, but also does not really help anyone. > > I guess if you can come up with a solution that > > * provides secure usage of the libraries, > > * provides choice to the user, and > > * doesn't lead to unupgradeable systems or unresolvable dependencies > > we'd all be happier. So far we haven't found one. > > Right! I think letting a libressl ebuild install only libtls could be a > good start, because it provides a stable situation, without risking > conflicts. Would you agree? No idea to be honest, and not much opinion on this. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice)
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
Am Dienstag, 29. Dezember 2020, 13:29:35 EET schrieb Peter Stuge: > I agree completely that it's unreasonable for Gentoo (worse, 1 person!) > to continuosly patch the entire world for libressel. > > I'm asking to stop doing that, yet still enable the choice between > openssl and libressl where that is possible without patches, even > if that's only openntpd and one other package. a) The two cannot be installed concurrently. To fix that would require even more hacks. -> all relevant ssl consumers on the user's system must be linked against the one selected b) The libraries are not guaranteed to be binary compatible, so switching implementation requires rebuilding consumers. Especially since this is a security-sensitive package. -> all relevant ssl consumers on the user's system must be *built* against the one selected Which leads us to c) If a single package that the user wants to install is not "fixed" for one ssl library, it blocks that option for all packages. -> horrible (but real and justified) emerge blockers and general hilarity ensue I guess if you can come up with a solution that * provides secure usage of the libraries, * provides choice to the user, and * doesn't lead to unupgradeable systems or unresolvable dependencies we'd all be happier. So far we haven't found one. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice)
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
> TL;DR: is there really a point in continuing the never-ending always- > regressing struggle towards supporting LibreSSL in Gentoo? > > I would like to discuss the possibility of discontinuing LibreSSL > support in Gentoo in favor of sticking with OpenSSL. From a team member and initial "believer", yes please. Libressl turns out to be more pain than gain. -- 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] Deprecating AMD64 17.0 profiles?
On November 9, 2020 1:54:33 PM GMT+02:00, Peter Stuge wrote: >Andreas K. Hüttel wrote: >> it's probably time to deprecate the amd64 17.0 profiles! > >I for one am not so excited about the amd64 17.1 profiles. On the >surface >it appeared to me that one developer has "taken over" just about >everything, >which (regardless of the individual) can't be a good thing.. > Please wait a bit longer, I'm still working on my evil world domination plans! -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
On November 7, 2020 1:42:44 PM GMT+02:00, Alexey Sokolov wrote: >22.10.2020 20:16, Andreas K. Hüttel пишет: >> Am Donnerstag, 22. Oktober 2020, 18:44:48 EEST schrieb Michał Górny: >>> On Thu, 2020-10-22 at 11:17 -0400, Brian Evans wrote: Users frequently are choosing the wrong profile versions in new >installs and accidentally downgrading to 17.0 with some saying they see it >first. A simple reordering could help new installs. >> >> Independent of this useful change, it's probably time to deprecate >the amd64 >> 17.0 profiles! >> > >Prefix bootstrap script still makes new installations to use it Meh. Time to change that then... -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] LiveCD Project disbanding: packages up for grabs
>dev-util/dialog >sys-block/parted Im going to add base-system to these two later (in addition to dedicated maintainers) -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev
> I would like to propose that we switch the default udev provider on new > systems from eudev to udev. Well... maybe you could somewhat expand on the why? -- 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] Typo in julia-1.4.0-r2.ebuild
Fixed, thank you! Am Mittwoch, 1. Juli 2020, 12:35:09 EEST schrieb Xianwen Chen (陈贤文): > Dear all, > > There is a typo in > https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-lang/julia/julia-1.4.0-r2 > .ebuild. > > > On line 82, instead of *llvm_pkg_setp*, it should be *llvm_pkg_setup*. > > Yours sincerely, > > Xianwen -- 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.
[gentoo-dev] last rites: media-libs/openmoiv
# Andreas K. Hüttel (2020-03-27) # No consumers. Build problems, bug 668244. Removal in 30 days. media-libs/openmoiv -- 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] last rites: x11-terms/aterm, x11-terms/xvt
> > Andreas, perhaps this should be added to the mask comment? Happy to > push a PR or simply add this information to the bug report, at the very > least I thing the bug report should be closed with WONTFIX, may I > proceed with that? I'll same comments there if in order. Sure, adding the info to the bug is easiest, feel free! -A > > Kind Regards, > Jaco -- 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.
[gentoo-dev] last rites: x11-terms/aterm, x11-terms/xvt
# Andreas K. Hüttel (2020-03-26) # Fail to build with glibc-2.30; no maintainer. Removal in 30days. # Bugs 691756, 691710 x11-terms/aterm x11-terms/xvt -- 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] rfc: noarch keyword
> So, my question is, why can't we add a noarch/~noarch keyword and see > how things go? If it gets abused we can always nuke it later. I'm pretty sure we already discussed this in very much detail in the past at least once, and came to the conclusion that there are problems with that approach. What's different now? Sorry, but for the moment your mail is a bit big on fluffy ideas and a bit thin on details how it's going to work... as unsorted examples, * how is allarches supposed to interact with use.stable.mask? * who is doing allarches stabilizations? * what are the allowed dependencies? obviously an allarches package can only depend on other allarches packages... * what happens if an allarches package gets, e.g., masked on one arch? -- 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] rfc: noarch keyword
Am Mittwoch, 18. März 2020, 19:40:57 CET schrieb William Hubbs: > There would be no need to cc all arches on the bug, just make noarch@g.o > an alias that emails to all arch teams. We might as well just make an allarches@... alias. -- 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] [RFC] Discontinuing (more-than-absolutely-minimal) Python support for non-x86 arches
> Perhaps we could write a tool that > looks up newer versions of installed ebuilds that have dropped keywords > for a given arch and report which dependencies also need keywording. I > guess we don't have something like that? True, keeping track of long-running stable requests with complicated lists is a serious pain. Also true, additional automation could help here. In the end this boils down to the question, can we do something better than bugzilla for stabilization and keywording tracking? A dedicated webapp (which still needs to be integrated with bugzilla somehow to process blockers)? Obviously this is work. I am tempted to suggest Google Summer of Code, except that experience tells me that's the fastest way to get a half-functional pile of code that never goes into production. Any better ideas? -- 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] [RFC] Discontinuing (more-than-absolutely-minimal) Python support for non-x86 arches
> > > > https://github.com/zmedico/portage/compare/master...zmedico:drobbins-track > > -keywords?expand=1 > That's kind of what ALLARCHES is for although IIRC the rules state that > packages should still be initially keyworded in the usual way. Other > distros do "noarch" though so the idea isn't without precedent. It was a long discussion to get ALLARCHES finalized and accepted, and now barely anyone is using it. (Most arch teams never bothered to adapt their workflow.) Maybe we should do that for a start? Anyway, ALLARCHES only affects stabilization, not keyword requests. -- 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] Fwd: [gentoo-commits] repo/gentoo:master commit in: app-office/calcurse/
Am Donnerstag, 12. März 2020, 20:23:56 CET schrieb Michał Górny: > On Thu, 2020-03-12 at 11:44 -0700, Alec Warner wrote: > > On Thu, Mar 12, 2020 at 9:54 AM Andreas K. Huettel > > > > wrote: > > > Someone needs to grow up here. > > > > Meh, to me (someone who can't commit to ::gentoo) I have a few concerns > > here. First, I don't see a lot of QA reverts on the gentoo-dev list. Is it > > common practice to post reverts publicly? > > I suppose that a part of the problem is the default Reply-To in these > mails. Which was deliberately added... -- 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.
