[gentoo-dev] last rites (kinda, long masked): sys-apps/opentmpfiles

2023-09-16 Thread Andreas K. Huettel
# 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

2023-09-12 Thread Andreas K. Huettel
> >> 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

2023-09-11 Thread Andreas K. Huettel
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

2023-09-11 Thread Andreas K. Huettel
# 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

2023-08-12 Thread Andreas K. Huettel
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?

2023-06-15 Thread Andreas K. Huettel
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

2023-03-29 Thread Andreas K. Huettel
> 
> 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...)

2023-01-29 Thread Andreas K. Huettel
> 
> 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?

2022-10-12 Thread Andreas K. Huettel
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"

2022-07-23 Thread Andreas K. Huettel
> 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"

2022-07-23 Thread Andreas K. Huettel
> 
> 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

2022-06-16 Thread Andreas K. Huettel
# 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

2022-05-28 Thread Andreas K. Huettel
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

2022-05-08 Thread Andreas K. Huettel
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

2022-03-10 Thread Andreas K. Huettel
> > 
> > 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

2022-02-27 Thread Andreas K. Huettel
# 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

2022-02-01 Thread Andreas K. Huettel
> 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

2022-01-27 Thread Andreas K. Huettel
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

2022-01-25 Thread 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).

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

2022-01-21 Thread Andreas K. Huettel
# 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

2022-01-11 Thread Andreas K. Huettel
> 
> 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

2021-12-25 Thread Andreas K. Huettel
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

2021-12-19 Thread Andreas K. Huettel
+# 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

2021-12-18 Thread Andreas K. Huettel
> 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/*

2021-12-12 Thread Andreas K. Huettel
# 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

2021-11-29 Thread Andreas K. Huettel
> 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

2021-11-19 Thread Andreas K. Huettel
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/*

2021-11-04 Thread Andreas K. Huettel
# 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

2021-11-03 Thread Andreas K. Huettel
> 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

2021-11-03 Thread Andreas K. Huettel
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

2021-11-03 Thread Andreas K. Huettel
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/

2021-10-28 Thread Andreas K. Huettel
> 
> 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/

2021-10-28 Thread Andreas K. Huettel

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! :)

2021-10-18 Thread Andreas K. Huettel
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! :)

2021-10-17 Thread Andreas K. Huettel
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

2021-10-16 Thread Andreas K. Huettel
# 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

2021-10-16 Thread Andreas K. Huettel
# 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/*

2021-10-13 Thread Andreas K. Huettel
# 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

2021-10-05 Thread Andreas K. Huettel
> 
> 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

2021-09-23 Thread Andreas K. Huettel
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

2021-09-22 Thread Andreas K. Huettel
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

2021-09-21 Thread Andreas K. Huettel
> 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

2021-09-21 Thread Andreas K. Huettel
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

2021-09-21 Thread Andreas K. Huettel
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

2021-09-02 Thread Andreas K. Huettel
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

2021-08-15 Thread Andreas K. Huettel
# 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

2021-08-15 Thread Andreas K. Huettel
# 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

2021-08-15 Thread Andreas K. Huettel
# 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

2021-08-07 Thread Andreas K. Huettel
> 
> 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

2021-08-06 Thread Andreas K. Huettel
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/*

2021-07-31 Thread Andreas K. Huettel
# 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

2021-07-25 Thread Andreas K. Huettel
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

2021-07-24 Thread Andreas K. Huettel
>  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

2021-07-23 Thread Andreas K. Huettel
> 
> 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/*

2021-07-17 Thread Andreas K. Huettel
# 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

2021-07-17 Thread Andreas K. Huettel
# 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

2021-07-14 Thread Andreas K. Huettel
> > 
> > 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

2021-07-13 Thread Andreas K. Huettel

> 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

2021-06-25 Thread Andreas K. Huettel
> > 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)

2021-06-22 Thread Andreas K. Huettel
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

2021-06-19 Thread Andreas K. Huettel
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)

2021-05-13 Thread Andreas K. Huettel
> > 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)

2021-05-13 Thread Andreas K. Huettel
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

2021-05-13 Thread 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.

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

2021-05-09 Thread Andreas K. Huettel
# 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

2021-05-08 Thread Andreas K. Huettel
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

2021-05-07 Thread Andreas K. Huettel
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

2021-05-07 Thread Andreas K. Huettel
> 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

2021-05-07 Thread Andreas K. Huettel
> > 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

2021-05-06 Thread Andreas K. Huettel
> 
> 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

2021-05-06 Thread Andreas K. Huettel
> 
> -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

2021-05-06 Thread Andreas K. Huettel
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

2021-05-06 Thread Andreas K. Huettel
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

2021-04-30 Thread Andreas K. Huettel
# 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/*

2021-04-30 Thread Andreas K. Huettel
# 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

2021-04-25 Thread Andreas K. Huettel
# 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

2021-04-25 Thread Andreas K. Huettel
# 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 ?

2021-03-22 Thread Andreas K. Huettel
> > 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 ?

2021-03-20 Thread Andreas K. Huettel
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

2021-03-06 Thread Andreas K. Huettel

# 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

2021-02-21 Thread Andreas K. Huettel

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

2021-01-06 Thread Andreas K. Huettel
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

2020-12-30 Thread Andreas K. Huettel
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

2020-12-30 Thread Andreas K. Huettel
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?

2020-12-30 Thread Andreas K. Huettel
> > 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?

2020-12-29 Thread Andreas K. Huettel
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?

2020-12-29 Thread Andreas K. Huettel
> 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?

2020-11-09 Thread Andreas K. Huettel



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?

2020-11-07 Thread Andreas K. Huettel



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

2020-11-07 Thread Andreas K. Huettel




>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

2020-08-08 Thread Andreas K. Huettel
> 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

2020-07-01 Thread Andreas K. Huettel
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

2020-03-28 Thread Andreas K. Huettel
# 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

2020-03-27 Thread Andreas K. Huettel
>
> 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

2020-03-26 Thread Andreas K. Huettel
# 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

2020-03-18 Thread Andreas K. Huettel
> 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

2020-03-18 Thread Andreas K. Huettel
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

2020-03-16 Thread Andreas K. Huettel
> 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

2020-03-16 Thread Andreas K. Huettel
> > 
> > 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/

2020-03-12 Thread Andreas K. Huettel
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.


  1   2   3   4   5   6   7   8   >