Re: [gentoo-dev] Packages up for grabs
On 28-06-2024 13:12:15 +0200, Michał Górny wrote: > sys-apps/flashrom I will take this as I have means to test this for coreboot. Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-python/carbon
# Fabian Groffen (2024-04-16) # Official latest Python support 3.8, replacement app-metrics/go-carbon # is more performant and designed to be a drop-in replacement. # Removal on 2024-05-16, bug #929444 dev-python/carbon -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-python/PySensors
# Fabian Groffen (2024-04-13) # Python wrapper around liblmsensors, no reverse dependencies # Removal on 2024-05-13, bug #929495 dev-python/PySensors -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
On 06-04-2024 12:57:23 +0100, Eddie Chapman wrote: > There is one significant thing that breaks, which is Gemato > (app-portage/gemato). Gemato requires lzma support in core python in > order to do GPG signature verification. This means you will have to say > goodbye (for now) to verifying upstream GPG signatures on distfiles, and > verification of Portage metadata after doing an emerge --sync. These > features have been added to Portage relatively recently (2022?) so are > "nice to have", without them your system is just less hardened, but > still with the very high level of security that Gentoo systems have has > always had prior to these features, in my opinion. Personally I can live > without them for now. Verifying hashes in Manifest files still works > fine and that's the main thing. You may disagree in which case, well, > don't do this then. I'm going to figure out an alternative way I can > verify Portage metadata soon, as there are other ways if you are creative. If you just want to verify signatures and manifests after sync, qmanifest from portage-utils can help you do this. Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-dev] maintainer-needed: dev-python/thrift
I do not have any means to test/use this anymore, so I'm forced to drop it to maintainer-needed. It has bug https://bugs.gentoo.org/928502 open for an update and ebuild improvements. Fabian On 01-04-2022 14:56:15 +0200, Fabian Groffen wrote: > Dropped this mask again, I missed a dep in the tree. > > Fabian > > On 01-04-2022 13:53:24 +0200, Fabian Groffen wrote: > > # Fabian Groffen (2022-04-01) > > # unused package, not enabling tests, bug #796830 > > # Removal in 30 days > > dev-python/thrift -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-dev] Last rites: mail-filter/libsrs_alt
# Fabian Groffen (2024-01-26) # compilation issues, no reverse dependencies in the tree # Removal on 2024-02-26 mail-filter/libsrs_alt -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] New bootstrap-prefix global USE-flag and patch to llvm.eclass
On 12-09-2023 20:32:19 +0100, Alexey Sokolov wrote:
> Bug: https://bugs.gentoo.org/758167
> Full PR is at https://github.com/gentoo/gentoo/pull/32730
>
> Several LLVM packages require this early return, otherwise they fail to
> build on Darwin. I'll also need this USE-flag for
> sys-devel/clang-common, to distinguish between stage2 and stage3 of
> bootstrap-prefix.sh to configure clang differently.
>
> --
> Best regards,
> Alexey "DarthGandalf" Sokolov
> From de2bd1abc3e5c7607413633d132c604c6a801802 Mon Sep 17 00:00:00 2001
> From: Alexey Sokolov
> Date: Mon, 11 Sep 2023 23:26:49 +0100
> Subject: [PATCH] llvm.eclass: add global USE flag bootstrap-prefix
>
> Mask it everywhere except for prefix profiles
>
> Without this, stage2's LLVM packages fail to build.
>
> Bug: https://bugs.gentoo.org/758167
> Signed-off-by: Alexey Sokolov
> ---
> eclass/llvm.eclass| 7 +++
> profiles/base/use.mask| 4
> profiles/features/prefix/use.mask | 4
> profiles/use.desc | 1 +
> 4 files changed, 16 insertions(+)
>
> diff --git a/eclass/llvm.eclass b/eclass/llvm.eclass
> index 8198650aad9a7..87c2cedb3a376 100644
> --- a/eclass/llvm.eclass
> +++ b/eclass/llvm.eclass
> @@ -64,6 +64,8 @@ esac
> if [[ ! ${_LLVM_ECLASS} ]]; then
> _LLVM_ECLASS=1
>
> +IUSE="bootstrap-prefix"
> +
> # make sure that the versions installing straight into /usr/bin
> # are uninstalled
> DEPEND="!!sys-devel/llvm:0"
> @@ -242,6 +244,11 @@ llvm_fix_tool_path() {
> llvm_pkg_setup() {
> debug-print-function ${FUNCNAME} "${@}"
>
> + if use bootstrap-prefix; then
> + # AppleClang has unparseable version numbers, but it's
> irrelevant anyway
> + return
> + fi
> +
I might misunderstand this, but is this USE-flag supposed to be set only
during bootstrap, e.g. when host-provided Clang is used? If so, would
it be possible to use has_version or something instead?
Thanks,
Fabian
> if [[ ${MERGE_TYPE} != binary ]]; then
> LLVM_SLOT=$(get_llvm_slot "${LLVM_MAX_SLOT}")
>
> diff --git a/profiles/base/use.mask b/profiles/base/use.mask
> index 1d4f5b92865df..cc86fde21097a 100644
> --- a/profiles/base/use.mask
> +++ b/profiles/base/use.mask
> @@ -8,6 +8,10 @@
> # eudev is masked for removal
> eudev
>
> +# Alexey Sokolov (2023-09-11)
> +# Only needed during bootstrap of prefix
> +bootstrap-prefix
> +
> # David Seifert (2023-09-09)
> # EOL upstream in 2 months, causes major headaches for OpenSSL 1.1
> # masking. Removal on 2023-10-09.
> diff --git a/profiles/features/prefix/use.mask
> b/profiles/features/prefix/use.mask
> index 482ce57f04485..1f43ca23fd101 100644
> --- a/profiles/features/prefix/use.mask
> +++ b/profiles/features/prefix/use.mask
> @@ -4,6 +4,10 @@
> # prefix USE flag should always be unmasked in prefix profiles
> -prefix
>
> +# Alexey Sokolov (2023-09-11)
> +# Allow bootstrapping the prefix
> +-bootstrap-prefix
> +
> # USE flags inherited by the base/use.defaults file that shouldn't be in
> Prefix
> gpm
>
> diff --git a/profiles/use.desc b/profiles/use.desc
> index 6034f3bf6fc31..37c64f43759da 100644
> --- a/profiles/use.desc
> +++ b/profiles/use.desc
> @@ -29,6 +29,7 @@ big-endian - Big-endian toolchain support
> bindist - Flag to enable or disable options for prebuilt (GRP) packages (eg.
> due to licensing issues)
> blas - Add support for the virtual/blas numerical library
> bluetooth - Enable Bluetooth Support
> +bootstrap-prefix - !!internal use only!! DO NOT SET THIS FLAG YOURSELF!,
> used for bootstrapping Gentoo Prefix
> branding - Enable Gentoo specific branding
> build - !!internal use only!! DO NOT SET THIS FLAG YOURSELF!, used for
> creating build images and the first half of bootstrapping [make stage1]
> bzip2 - Use the bzlib compression library
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: obsolete acct-* packages
On 18-07-2023 11:42:39 +0300, Зураб Квачадзе wrote: > How do we handle this case, then. > Imagine we have a leaf package acct-user/foo, which has a reserved UID of 123. > It gets last rited and its entry is removed from uid-gid.txt. After a while > appears a new package acct-user/bar, which takes the 123 UID. Then a user, say > Bob, updates their system, which haven't been updated for some time. What if > they still have acct-user/foo, when acct-user/bar with the same UID is > installed? Should we even care about such cases? IMO we should, thus 123 should not be removed from uid-gid.txt, and instead be marked as reserved or something with a date. Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Package stabilization groups
On 16-07-2023 10:57:54 -0400, Matt Turner wrote: > Hello, > > Many of us have started using `pkgdev bugs` to file stabilization > bugs. It works well (Thanks Arthur!) and I encourage everyone to give > it a try. > > Where possible, it files one stabilization bug per package. This makes > arch testers' jobs easier and makes the task easier to automate. > > But sometimes we do want to stabilize packages together. For example > major versions of x11-wm/mutter and gnome-base/gnome-shell are tied > together. If a new mutter is stabilized without the new gnome-shell, > the tree will still be consistent, but emerge -u @world will warn > users that the mutter upgrade is blocked. > > There was some brief discussion on IRC about how to document these > groupings, and two main ideas were suggested: > > - add a field to metadata.xml to specify the group by an arbitrary name. > E.g. > Each package in the group would specify the same value of name="..." > > - maintain the groups in a separate place (similar to portage @sets). > > Can anyone think of particular advantages or disadvantages to one > solution versus the other? Any other (better) ideas? I don't know how widespread the problem is, and how much it can be generalised, but could you perhaps use a virtual, such that stabilisation of the virtual means the deps must be satisfied? Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-dev] Last rites: x11-themes/gtk-engines-quartz
# Fabian Groffen (2023-06-21) # Ancient OSX integration package, not keyworded for any current arch # Removal on 2023-07-21. Bug #908938. x11-themes/gtk-engines-quartz -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: app-admin/cygwin-rebase
On 26-05-2023 09:06:30 +0200, Fabian Groffen wrote: > # Fabian Groffen (2023-05-26) > # Cygwin package for which keyword/profile support was dropped > # Removal on 2023-06-25. Bug #907194. > app-admin/cygwin-rebase These two packages are appended to mask: dev-libs/pthreads4w sys-devel/parity -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-dev] Last rites: app-admin/cygwin-rebase
# Fabian Groffen (2023-05-26) # Cygwin package for which keyword/profile support was dropped # Removal on 2023-06-25. Bug #907194. app-admin/cygwin-rebase -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-dev] Last rites: sys-apps/superiotool
# Fabian Groffen (2022-12-27) # Old SVN version, with open bugs #830031, #770946, #712534, all fixed # in app-admin/coreboot-utils package. (Conflict in #888581) Removal # on 2023-01-26. sys-apps/superiotool -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 1/4] acct-group.eclass: Fix for when building in a rooted prefix (EROOT)
On 07-12-2022 11:52:58 -0500, Mike Gilbert wrote:
> On Wed, Dec 7, 2022 at 4:24 AM James Le Cuirot wrote:
> > The new eclasses also skip the operation if you are root. As that bug report
> > says, running a prefixed system as root is probably unsupported. I was doing
> > this as root into a ROOTed prefix though, which is slightly different.
> > Should
> > we also skip the operation if EPREFIX non-empty? I'll think about it.
>
> I would be in favor of skipping adding users/groups if EPREFIX is
> non-empty, at least as a temporary solution.
>
> If someone presents a use case where adding users to
> ${EROOT}/etc/passwd makes sense, we can revisit it then.
Would have to look if RAP uses this.
@heroxbd do you know if that is used?
Thanks,
Fabian
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: PGP signature
[gentoo-dev] Last rites: sys-apps/baselayout-prefix
# Fabian Groffen (2022-08-06) # superseeded by sys-apps/baselayout, removal in 30 days. bug #836114 sys-apps/baselayout-prefix -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Rust is here to eat your Pythonz
On 27-07-2022 13:30:32 +0200, Michał Górny wrote: > On Wed, 2022-07-27 at 12:52 +0200, Fabian Groffen wrote: > > On 26-07-2022 08:42:57 +0200, Michał Górny wrote: > > > Hi, everyone. > > > > > > Just a quick FYI: since Rust is going to be marked stable on the last > > > architecture (sparc) that it's going to support in Gentoo, we're going > > > to start cleaning up old dev-python/cryptography soon. If you don't > > > want Rust, removing cryptography entirely will be your only option. > > > > I believe this isn't always a "don't want", there's systems on which it > > simply is impossible to get Rust (ppc64-linux-musl for example). How > > much does "removing cryptography" impact an Gentoo system wrt > > availability of packages? I see pip in the list, so I expect the Python > > env will be seriously crippled? An estimation of the impact would be > > appreciated here. > > > > Check the wd40 profile, all relevant masks are included there. That helps, thanks! Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Rust is here to eat your Pythonz
On 26-07-2022 08:42:57 +0200, Michał Górny wrote: > Hi, everyone. > > Just a quick FYI: since Rust is going to be marked stable on the last > architecture (sparc) that it's going to support in Gentoo, we're going > to start cleaning up old dev-python/cryptography soon. If you don't > want Rust, removing cryptography entirely will be your only option. I believe this isn't always a "don't want", there's systems on which it simply is impossible to get Rust (ppc64-linux-musl for example). How much does "removing cryptography" impact an Gentoo system wrt availability of packages? I see pip in the list, so I expect the Python env will be seriously crippled? An estimation of the impact would be appreciated here. Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] proposal
On 06-07-2022 15:50:30 +0200, Michał Górny wrote: > On Mon, 2022-07-04 at 16:19 +0200, Florian Schmaus wrote: > > I'd like to propose a new metadata XML element for packages: > > > > > > > > Maintainers can signal to other developers (and of course contributors > > in general) that they are happy with others to make changes to the > > ebuilds without prior consultation of the maintainer. > > I don't think adding such an element is a good idea. In my opinion, > this will strengthen the assumption that "unless otherwise noted, you > don't dare touch anything" (even though that's not your goal). "Common > sense" should really be good enough for almost everything. Right, "common sense". The problem with that one, is that "common" is not as "common" as you think it is. Ask a bunch of people, and you'll find that what they consider "common" isn't the same. So, if you do this, then please define clearly what you think is OK. For example for me: - feel free to add patches necessary for operation - feel free to fix constructs (like an if or case that should apply for something else/different/mode) - feel free to fix typos - please do not needlessly change style: if you do not "maintain" the ebuild, respect the style of the maintainer, so only add the changes you need, keep it minimal, respect the original even though you don't like it (and don't use QA as an excuse to change style) - when you make a change, make sure you check for bugs in the following days, so you can cleanup yourself should there be fallout > I mean, I do realize that 10 years ago, in the golden years of Gentoo, > it was considered normal for developers to be like "my package, my > fortress, don't you dare add systemd unit or I will retire" but today I > think we're aiming for a more welcoming developer base, and I think > we're actually going in that direction. What I'm afraid is that some > people will use this as an excuse to push back once again. Not sure I have the same memories of how it used to be 10 years ago. I actually think it is pretty much the same as it is now, as it was then. Different and fewer people, but still different preferences/opinions/common sense. > Can you really think of a case when common sense really, really wouldn't > work? I mean, sure, we all make mistakes but we should be able to learn > from them and do better next time. This also implies package > maintainers learning that they're not the only people who will ever > touch the package in question and starting to document the pitfalls. Honestly, I've never been a fan of "maintainership". It basically is some sort of "sign" that says "beware for the dog, stay away". However, it's true that sometimes people really delve into a package, and thereby know very much how it works, and what you should/should not do. Something like LLVM is a good example, maybe. Anyway, in such situation, I think extreme care should be taken by non-maintainers. Dunno how to best indicate that, and/or if that's feasible -- like you said, it quickly ends up being an excuse for declaring a package to be off-limits. Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] last rites: dev-python/thrift
Dropped this mask again, I missed a dep in the tree. Fabian On 01-04-2022 13:53:24 +0200, Fabian Groffen wrote: > # Fabian Groffen (2022-04-01) > # unused package, not enabling tests, bug #796830 > # Removal in 30 days > dev-python/thrift -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] last rites: dev-python/thrift
On 01-04-2022 16:59:40 +0500, Anna Vyalkova wrote: > On 2022-04-01 13:53, Fabian Groffen wrote: > > # Fabian Groffen (2022-04-01) > > # unused package, not enabling tests, bug #796830 > > # Removal in 30 days > > dev-python/thrift > > It has a reverse dependency in GURU > dev-python/jaeger-client > > It will be needed if OpenStack packages are restored some day. Can we move/copy the package to GURU? Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-dev] last rites: dev-python/thrift
# Fabian Groffen (2022-04-01) # unused package, not enabling tests, bug #796830 # Removal in 30 days dev-python/thrift -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Policy on conditional patching
Hi, On 28-03-2022 13:05:03 +0200, Thomas Bracht Laumann Jespersen wrote: > Hi! > > I've been working on a new section in the devmanual regarding conditional > patching. In a PR [0] Sam suggested adding a section to clarify that > conditional > patching should be avoided, because it can quickly become a maintenance and > testing burden. > > The devmanual PR is here: [1] > > Ulrich points out that conditional patching is actually suggested elsewhere, > and > that actively discouraging conditional patching is a policy change, which > should > be brought up on this list. So this is what I'm doing now. He also pointed > out a > comment in eutils.eclass re [2] (the comment now lives in epatch.eclass). > > The overall policy (proposal, I guess) is something like: > > * Patches should be written such that they affect behaviour correctly based > on >e.g. build time definitions or config options, rather than USE flags >directly. > > * They should be applied unconditionally, so that, for version bumps and > other >development happening with a package, any failure to apply the patch will > be >caught by the developer. > > * Patching is ideally only done to make the package in question build > properly, >and should not be done to modify the runtime behaviour of the package. > (This >is what USE flags and configuration options of the package are for.) > > Sam made a specific point re musl: "for e.g. musl patches, we want a portable > fix, not a hack which is only applied for musl" > > Feedback on this very welcome. I'm grappling a bit with the exact wording to > go > for, so input on that is also appreciated. > > I think my question to this list is: Should it be policy that conditional > patching is to be avoided? We really don't want conditional patches, but I from my experience reality is that sometimes you have to. Therefore this should remain possible. I have no problems with highly discouraging conditional patching. About your other points, I think they are kind of debatable. Gentoo wants to be close to upstream, but with your set of rules, one can't e.g. add hpn patches to ssh, which would be really silly, as the point of Gentoo is that since you build from source, you can actually apply such patches, conditionally if they don't have a means to be disabled. In other words, I think the gist of your points is to be in an ideal world, but unfortunately reality is far from it. That said, repeating myself, nothing wrong with discouraging quick 'n' dirty, for as long as it remains a big fat warning and advice. My €0.02 Fabian > [0]: https://github.com/gentoo/gentoo/pull/24709#discussion_r832361402 > [1]: https://github.com/gentoo/devmanual/pull/281 > [2]: > https://gitweb.gentoo.org/archive/repo/gentoo-2.git/tree/eclass/eutils.eclass?id=50e8beda904760c773e5c67fdfe8242255e13495#n175 > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-dev] Last rites: www-apps/agendav
# Fabian Groffen (2022-03-16) # little activity upstream, doesn't work with PHP 8.0 # Removal in 30 days www-apps/agendav -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-dev] Re: Deprecating repoman
Just wondering, is there a "migration guide" or something? I've never used pkg* since joining in 2005. I can derive some things from the first look at the below commit, but an "expert opinion" to just map the standard things from repoman to appropriate commands would be nice. Are those pkg* keyworded *everywhere*, by the way? Thanks, Fabian On 11-03-2022 13:19:34 -0800, Matt Turner wrote: > I've filed a PR against devmanual.git to remove references to repoman > and replace them with references to pkgdev where appropriate. Most > everywhere already had pkgdev/pkgcheck text in place so there wasn't > much to do. See: https://github.com/gentoo/devmanual/pull/274 > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-dev] Last rites: sys-apps/tapi
# Fabian Groffen (2022-02-27) # Masked for removal, needs updates, significant amount of work, no # Clang toolchain available to test with # Removal on 2022-03-29. Bug #834306 sys-apps/tapi -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-dev] last-rite: dev-perl/Mac-Pasteboard
# Fabian Groffen (2022-01-29) # Fails to compile with GCC on macOS. No revdeps. # Removal on 2022-02-28. Bug #832309. dev-perl/Mac-Pasteboard -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] making rust-bin ordered first in virtual/rust
On 21-01-2022 11:29:54 +0100, Peter Böhm wrote: > Dear Developers, > > I like your goal to make Gentoo more user-friendly but Gentoo is a source > based distribution and I dont like binary versions as a default. My question > is: > > Who has problems with "big" packages like rust or firefox ? > > Only User which doesnt know there is a binary version. So, in every case we > need to describe it in our AMD64 handbook. > > Am Freitag, 21. Januar 2022, 10:22:14 CET schrieb Mart Raudsepp: > > Anyhow, my vote is to default to rust-bin - people can easily be told > > to move to dev-lang/rust at their convenience and then explicitly > > depclean rust-bin. > > I am dreaming about another solution where this is not needed: > > In our /etc/portage/make.conf we can have a new: > > MAKEBIN="rust firefox" > > ... resulting in an automatic switch to the binary version of all included > packages ... of course this is also as recommendation in our AMD64 handbook > (with a clue to delete it if not desired). or ... if we could have Portage check the requirements for building a package, and if it cannot be met, that it tries to resolve the || case, which would be the -bin variant in this case. Not sure if the information is available to Portage at dependency resolution time though. Fabian > > Kind reagards, > Peter > > > > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
On 05-10-2021 09:35:32 +0200, Michał Górny wrote: > On Thu, 2021-09-30 at 09:18 +0200, Fabian Groffen wrote: > > > > Final question, am I understanding correctly that normal lines are not > > > > prefixed with something? Would it be, for consistency, alignment, and > > > > certainty of selecting rows something to use a prefix for those lines > > > > too (assuming they aren't at this point)? > > > > > > I don't know, we've never done that. I suppose it would be possible but > > > it is even more controversial and unlike the proposed changes, it would > > > actually require mangling the process output. > > > > If I remember correctly, Portage already does. In which case, doing > > this (even if it were adding leading spaces) would not be that much > > work? > > > > I'm afraid this is not that simple. You need to account for all escape > sequences that can affect editing already output data including clean > handling of line wrapping. In the end, we'd have to have a complete > detachtty-class terminal emulator inside Portage. Fair enough, thanks for looking into it. Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
On 02-10-2021 23:03:56 -0400, Ionen Wolkens wrote: > On Sat, Oct 02, 2021 at 10:53:37PM -0400, Ionen Wolkens wrote: > > Guess there's a lot of other options that could be considered as well. > > > > --- files > > >>> text > > * current, it wasn't aligned now that I look at it again > > (relying only on color to convey type feels clearly wrong to me) > > > > --- files > > >>>> text > > [QA] new based on current PR > > > > >>> text > > [QA] aligned 1 character further, maybe skipping changing >>> is fine? > > (then again that it's further is what threw me off at first) > > > > >>> text > > QA* similar to before, but aligned using only 3 chars > > > > >>> text > > [Q] kinda more obscure but it can work > > > > Guess should also add these: > >>> text > Q* Notice: > E* Some error happened > (closest to before by making use of the former leading space, thus > no alignment changes) FWIW, I like this one. Perhaps even with lowercase make[4]: leaving directory src q* soname lacks version e* failed to die Fabian > > >>> text > QA Notice: > EE Some error happened > (at least clearer than Q* Notice, but unsure about no separator.. guess > it could work?) > > > >>>> text > > QA* probably closest to how it was before alignment-wise, but meh at 4 > > > > > >>> message > > QA> not convinced about this one, but throwing it here anyway > > (other characters could be considered as well) > > > > Maybe a poll of some kind may help, personally undecided on what I > > like better beside agreeing that a change is needed. > > > -- > ionen -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
On 30-09-2021 08:44:33 +0200, Michał Górny wrote: > On Thu, 2021-09-30 at 08:40 +0200, Fabian Groffen wrote: > > Hi, > > > > Would it be possible to have some switch (e.g. --style=legacy) that > > controls this new vs. the old behaviour? Would perhaps allow > > applications that parse the output to work via setting this in the > > global opts. > > Patches welcome. It shouldn't be hard, my commit shows which files need > to be edited to alter the prefixes and how to pass them into ebd. I see. > > In addition, much like the colour map, how do you see this change in > > light of eclasses, init-scripts, etc. that also use the same scheme as > > Portage at the moment? Would you expect to change those too at some > > point? > > Eclasses are supposed to use standard einfo, elog... functions, so they > should just work™. If someone's reinventing the wheel, it's not my > problem. > > Init scripts aren't supposed to be used inside the PM, so that's out of > scope. I was just referring to the overall "feel" of Gentoo, which your work changes. It is ok that you don't plan on doing anything there. > > Final question, am I understanding correctly that normal lines are not > > prefixed with something? Would it be, for consistency, alignment, and > > certainty of selecting rows something to use a prefix for those lines > > too (assuming they aren't at this point)? > > I don't know, we've never done that. I suppose it would be possible but > it is even more controversial and unlike the proposed changes, it would > actually require mangling the process output. If I remember correctly, Portage already does. In which case, doing this (even if it were adding leading spaces) would not be that much work? Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
Hi, Would it be possible to have some switch (e.g. --style=legacy) that controls this new vs. the old behaviour? Would perhaps allow applications that parse the output to work via setting this in the global opts. In addition, much like the colour map, how do you see this change in light of eclasses, init-scripts, etc. that also use the same scheme as Portage at the moment? Would you expect to change those too at some point? Final question, am I understanding correctly that normal lines are not prefixed with something? Would it be, for consistency, alignment, and certainty of selecting rows something to use a prefix for those lines too (assuming they aren't at this point)? Thanks, Fabian On 28-09-2021 17:36:25 +0200, Michał Górny wrote: > Hi, everyone. > > I know I'm going to regret asking this... but I've prepared a change to > the Portage output format and I think it asks for a wider discussion > than internally in Portage team. > > The primary problem with the current output format is that different > kinds of messages differ only in color. This makes them > indistinguishable without colors and hard to grep. ago's been asking > for a better way to grep for QA warnings and this is pretty much what > motivated me to do this. > > The proposed new format distinguished message types both using colors > and strings. This is roughly inspired by Xorg logs. For example, > instead of: > > * some message > * other message > * hell if i know what this is > > You get: > > [WW] some message > [EE] other message > [QA] hell if i know what this is > > I've also added more colors to explicitly distinguish einfo from elog, > and ewarn from eqawarn. Then, I've replaced most of '>>>' and '!!!' > used by Portage with four-character versions to keep messages aligned. > The 'zings' used for merging files remain three-character, so now it's > easily possible to distinguish messages from installed file list. > > The PR doing this is: https://github.com/gentoo/portage/pull/759 > > Example screenshot: > https://user-images.githubusercontent.com/110765/135119090-16e9599d-1b0f-41b8-a965-a55577183ffd.png > > -- > Best regards, > Michał Górny > > > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-dev] last-rite: app-admin/diamond
# Fabian Groffen (2021-05-24) # Hack on hack no longer sustainable # - seemingly dead upstream # - no (official) Python 3 support # removal in 30 days, bug: https://bugs.gentoo.org/791613 migrate to something like app-metrics/collectd using the the write_graphite plugin. -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] [News item review] Exim >=4.94 transports: tainted not permitted
On 06-05-2021 15:01:33 +0200, Andreas K. Huettel wrote: > > 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. I think the concept is clear to most from the descriptions one can find. The big problem however is the solution, how to fix one's configuration. Luckily it seems people find their way to Exim's bugtracker to get help there. Thanks for the suggestion though, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-dev] [News item review v2] Exim >=4.94 transports: tainted not permitted
Title: Exim>=4.94 transports: tainted not permitted Author: Fabian Groffen Posted: 2021-05-?? Revision: 1 News-Item-Format: 2.0 Display-If-Installed: mail-mta/exim The Message Transfer Agent Exim disallows tainted variables in transport configurations since version 4.94. Existing exim.conf configurations in /etc/exim need to be reviewed for breakage prior to upgrading to >=mail-mta/exim-4.94 to avoid error conditions at runtime. 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]. [1] https://lists.exim.org/lurker/message/20201109.222746.24ea3904.en.html [2] https://mox.sh/sysadmin/tainted-filename-errors-in-exim-4.94/ [3] https://jimbobmcgee.wordpress.com/2020/07/29/de-tainting-exim-configuration-variables/ -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] [News item review] Exim >=4.94 transports: tainted not permitted
On 02-05-2021 12:23:30 +0200, Ulrich Mueller wrote: > >>>>> On Sun, 02 May 2021, Fabian Groffen wrote: > > > Title: Exim >=4.94 disallows tainted variables in transport configurations > > Title is too long (GLEP 42 allows 50 chars max). ah, missed that > I have no idea what this news item is trying to tell me. But I don't use > Exim, so probably that's the reason. :) Maybe mention at least that Exim > is a mailer? Fair point. Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-dev] [News item review] Exim >=4.94 transports: tainted not permitted
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]. [1] https://lists.exim.org/lurker/message/20201109.222746.24ea3904.en.html [2] https://mox.sh/sysadmin/tainted-filename-errors-in-exim-4.94/ [3] https://jimbobmcgee.wordpress.com/2020/07/29/de-tainting-exim-configuration-variables/ -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Packages up for grabs: x11-misc/xbindkeys
Jeroen was sadly removed from the project. You go ahead and take it. Fabian On 22-02-2021 07:49:55 +0200, Jaco Kroon wrote: > Hi, > > Looks like Jeroen was the person mostly committing on this, Jeroen - are > you intending to keep maintaining this? > > The PR is legit but incomplete (it merely adds the patch, not use it). > > The patch has been merged upstream in 2014 already, instead we should > stable 1.8.7. > > I'll adjust the referenced bug referenced by the PR accordingly. > > Kind Regards, > Jaco > > On 2021/02/21 05:08, Jonas Stein wrote: > > Dear all > > > > the following packages are up for grabs after dropping > > desktop-misc: > > > > x11-misc/xbindkeys > > https://packages.gentoo.org/packages/x11-misc/xbindkeys > > > > There is an open PR > > https://github.com/gentoo/gentoo/pull/14706 > > > > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-dev] [PATCH] eclass/db.eclass: use get_libname for Darwin support
Signed-off-by: Fabian Groffen
---
eclass/db.eclass | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/eclass/db.eclass b/eclass/db.eclass
index 9a246d18979..52afe0b765f 100644
--- a/eclass/db.eclass
+++ b/eclass/db.eclass
@@ -23,13 +23,13 @@ db_fix_so() {
cd "${LIB}" || die
# first clean up old symlinks
- find "${LIB}" -maxdepth 1 -type l -name 'libdb[1._-]*so' -delete || die
- find "${LIB}" -maxdepth 1 -type l -name 'libdb[1._-]*so.[23]' -delete
|| die
+ find "${LIB}" -maxdepth 1 -type l -name 'libdb[1._-]*'"$(get_libname)"
-delete || die
+ find "${LIB}" -maxdepth 1 -type l -name 'libdb[1._-]*'"$(get_libname
"[23]")" -delete || die
find "${LIB}" -maxdepth 1 -type l -name 'libdb[1._-]*a' -delete || die
# now rebuild all the correct ones
local ext
- for ext in so a; do
+ for ext in so dylib a; do
for name in libdb libdb_{cxx,tcl,java,sql,stl}; do
target="$(find . -maxdepth 1 -type f -name
"${name}-*.${ext}" |sort -V |tail -n 1)"
[[ -n "${target}" ]] && ln -sf ${target//.\//}
${name}.${ext}
@@ -37,17 +37,17 @@ db_fix_so() {
done;
# db[23] gets some extra-special stuff
- if [[ -f libdb1.so.2 ]]; then
- ln -sf libdb1.so.2 libdb.so.2
- ln -sf libdb1.so.2 libdb1.so
- ln -sf libdb1.so.2 libdb-1.so
+ if [[ -f libdb1$(get_libname 2) ]]; then
+ ln -sf libdb1$(get_libname 2) libdb$(get_libname 2)
+ ln -sf libdb1$(get_libname 2) libdb1$(get_libname)
+ ln -sf libdb1$(get_libname 2) libdb-1$(get_libname)
fi
# what do we do if we ever get 3.3 ?
local i
for i in libdb libdb_{cxx,tcl,java,sql,stl}; do
- if [[ -f ${i}-3.2.so ]]; then
- ln -sf ${i}-3.2.so ${i}-3.so
- ln -sf ${i}-3.2.so ${i}.so.3
+ if [[ -f $i-3.2$(get_libname) ]]; then
+ ln -sf $i-3.2$(get_libname) $i-3$(get_libname)
+ ln -sf $i-3.2$(get_libname) $i$(get_libname 3)
fi
done
@@ -143,8 +143,8 @@ db_src_install_usrlibcleanup() {
mv "${LIB}/libdb_cxx.a" "${LIB}/libdb_cxx-${SLOT}.a" || die
fi
- find "${LIB}" -maxdepth 1 -type l -name 'libdb[1._-]*so' -delete || die
- find "${LIB}" -maxdepth 1 -type l -name 'libdb[1._-]*so.[23]' -delete
|| die
+ find "${LIB}" -maxdepth 1 -type l -name 'libdb[1._-]*'"$(get_libname)"
-delete || die
+ find "${LIB}" -maxdepth 1 -type l -name 'libdb[1._-]*'"$(get_libname
"[23]")" -delete || die
einfo "removing unversioned static archives"
find "${LIB}" -maxdepth 1 -type l -name 'libdb[1._-]*a' -delete || die
--
2.26.2
Re: [gentoo-dev] [RFC] Dealing with global /usr/bin/libtool use vs CC/CXX etc.
On 10-01-2021 14:34:13 +0100, Michał Górny wrote: > The vast majority of libtool-based programs use configure script to > generate libtool. However, a few non-autoconf packages also use libtool > by calling system-installed /usr/bin/libtool. The problem is that this > libtool hardcodes the values of CC/CXX at its' build time, so unless it > is rebuilt frequently, packages end up using the stale values. > The problem is known since 2005 [1] and hasn't been resolved yet. > > I can think of two ways of solving it: > > 1. We could patch system-installed libtool to respect environment > variables such as CC, CXX, etc. This will probably require carrying > a (possibly non-trivial) patch forever. On the bright side, libtool is > not exactly a package seeing frequent releases. I mean, the current > version is from 2015. > > 2. We could regenerate libtool and force local instance of libtool > in the packages needing it. The main advantage of this is that it's > a no-brainer. I could make a quick eclass that does configure a local > instance and prepends it into PATH. > > WDYT? I would prefer option 2, also because on some systems usr/bin/libtool is some entirely different tool than GNU libtool. I remember this being much more of a problem ~15 years ago, so I wonder do we have an easy way of crafting a list of affected packages, such that we can see how big the problem actually is nowadays? I'm thinking perhaps tinderbox logs or something can reveal /usr/bin/libtool usage somehow. Thanks, Fabian > [1] https://bugs.gentoo.org/88596 -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On 04-01-2021 17:14:47 +0100, Michał Górny wrote: > Yes, I don't mind an option, as long as it spews a big fat ewarn that > the user loses the right to support. However, that's still not > the right solution to the immediate problem, and I'm currently working > on a better patch, so I'd prefer if you waited with that to avoid merge > conflicts. Could you please share your intended approach? Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-dev] Last-rites: sys-kernel/xnu-headers, sys-libs/darwin-libc-headers, dev-libs/libmissing
# Fabian Groffen (2020-11-23) # No longer used, not really functional either, noone should be using # this, removal in 30 days. sys-kernel/xnu-headers sys-libs/darwin-libc-headers dev-libs/libmissing -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
On 10-11-2020 09:21:53 +, Alexey Sokolov wrote: > > What instructed you to perform the migration? Was it the news-item? I > > don't think it should apply for Prefix profiles, and perhaps we should > > be happy the tool won't work. > > It was the big scary warning about the deprecation whenever I run > emerge. It contains list of steps. Ok. I don't know if we can do anything about that. > > Did it do anything to your system like creating a lib64 directory? Does > > anything work (because I have doubts on whether your system can still > > find the libs in there now). > > Yes. Attaching logs. The logs seem to indicate that it thinks all libs on your systems do not belong to any package. This suggests the tool cannot locate the VDB or something, as most of the things in the list are obviously owned by packages. Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
On 10-11-2020 09:49:27 +0100, Michał Górny wrote: > > > So what you're saying is that you've had the wrong value of SYMLINK_LIB > > > for ages, and now you've created a meaningless 17.1 profile that chnages > > > it but isn't actually supposed to change anything, correct? > > > > I guess, because the amd64 17.0 profile is deprecated with force, and I > > had to do something ... > > Now that's a lie. Only the regular amd64 profiles are deprecated. > There are no deprecation notices e.g. in the x32 profile or prefix > profiles. Our profiles either directly depend on the amd64/17.0 profile, or we use a sub-profile from amd64/17.0 profile, so if it's going to get removed, we are having a problem, don't we? -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
On 10-11-2020 09:34:52 +0100, Michał Górny wrote: > On Tue, 2020-11-10 at 08:55 +0100, Fabian Groffen wrote: > > On 09-11-2020 19:38:28 +, Alexey Sokolov wrote: > > > Hi Fabian > > > I tried to migrate my prefix to 17.1, and there are issues. > > > > > > 1) unsymlink-lib requires "--root ~/gentoo" and otherwise produces an > > > error "/usr/lib is a real directory! was the migration done already?" > > > > I think unsymlink-lib doesn't have Prefix support, but in addition, > > what unsymlink-lib is trying to achieve, is not a thing perhaps on > > Prefix. > > > > A prefix system (at least all of mine) doesn't have libXX or lib/XX > > (a.k.a. multilib) directories. The /usr-split was long ago removed, > > and thus what we have is: > > > > lib -> usr/lib > > > > Now, SYMLINK_LIB=no seems to split into lib and lib64, but lib64 does > > not exist on Prefix systems. > > > > So what you're saying is that you've had the wrong value of SYMLINK_LIB > for ages, and now you've created a meaningless 17.1 profile that chnages > it but isn't actually supposed to change anything, correct? I guess, because the amd64 17.0 profile is deprecated with force, and I had to do something ... -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
On 09-11-2020 19:38:28 +, Alexey Sokolov wrote: > Hi Fabian > I tried to migrate my prefix to 17.1, and there are issues. > > 1) unsymlink-lib requires "--root ~/gentoo" and otherwise produces an > error "/usr/lib is a real directory! was the migration done already?" I think unsymlink-lib doesn't have Prefix support, but in addition, what unsymlink-lib is trying to achieve, is not a thing perhaps on Prefix. A prefix system (at least all of mine) doesn't have libXX or lib/XX (a.k.a. multilib) directories. The /usr-split was long ago removed, and thus what we have is: lib -> usr/lib Now, SYMLINK_LIB=no seems to split into lib and lib64, but lib64 does not exist on Prefix systems. Since Prefix is non-multilib by design*, I wonder if unsymlink-lib is necessary in the best case, but going to break the Prefix system in the worst case. What instructed you to perform the migration? Was it the news-item? I don't think it should apply for Prefix profiles, and perhaps we should be happy the tool won't work. * non-multilib is a decision dating back a decade or so, which means effectively any Prefix install you encounter should be non-multilib > 2) $ unsymlink-lib --root ~/gentoo --migrate --pretend > usage: unsymlink-lib [-h] [-p] [--root ROOT] [--analyze] [--migrate] > [--rollback] [--finish] [--force-rollback] > [--resume-finish] [-P PREFIX] [--hardlink] > unsymlink-lib: error: Requested action requires root privileges > > Well, I worked it around by adding "is_root = True" to unsymlink-lib Did it do anything to your system like creating a lib64 directory? Does anything work (because I have doubts on whether your system can still find the libs in there now). > > 3) Step 9 (Rebuild gcc) fails: > configure:4372: checking whether the C compiler works > > > > configure:4394: x86_64-pc-linux-gnu-gccconftest.c >&5 > > > > /home/user/gentoo/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/as: > error while loading shared libraries: > libopcodes-2.34.0.gentoo-sys-devel-binutils-st.so: cannot open shared Something like this I was suspecting. Can you still rollback? If you can, I'd try that and hope it restores your system in working order. For any Prefix user, DO NOT run unsymlink-lib, I believe you should NOT NEED IT! Thanks, Fabian > object file: No such file or directory > configure:4398: $? = 1 > > > > configure:4436: result: no > > The file exists: > $ find ~ -name libopcodes-2.34.0.gentoo-sys-devel-binutils-st.so > /home/user/gentoo/usr/lib/binutils/x86_64-pc-linux-gnu/2.34/libopcodes-2.34.0.gentoo-sys-devel-binutils-st.so > > -- > Best regards, > Alexey "DarthGandalf" Sokolov > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
On 07-11-2020 11:42:44 +, 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 This should be solved with b0445c0a8dd6d2f792c5bb088b154aca53868353 a9c478dc881ee18fefc7342da994b00e60eaad8e on gentoo.git and 0d7f6b6eb00d0f51f35019846b8f79048b30be93 on prefix.git. Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] net-misc/asterisk fails to compile: clang/LLVM: bug 731280
On 28-08-2020 08:52:09 +0100, Sergei Trofimovich wrote: > On Fri, 28 Aug 2020 07:37:54 +0100 > Sergei Trofimovich wrote: > > > On Fri, 28 Aug 2020 08:15:47 +0200 > > Jaco Kroon wrote: > > > > > Hi All, > > > > > > https://bugs.gentoo.org/731280 > > > > > > Summary: > > > > > > This machine uses a clang/LLVM toolchain. > > > Asterisk fails to compile, ./configure fails with: > > > > > > checking for RAII support... checking for clang -fblocks... > > > configure: error: BlocksRuntime is required for clang, please install > > > libblocksruntime > > > > > > I suspect this explains the issue: > > > > > > https://github.com/mackyle/blocksruntime > > > > > > I have no idea how to actually solve this. > > > > honggfuzz also needs it as it happens to use -fblocks on clang: > > https://bugs.gentoo.org/729256 > > > > We need to package the library. I can give it a try. > > Packaged library as sys-libs/blocksruntime: > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ae376c73ef197d6c7aa619e821c436ccab0cd77e > > Usage example for app-forensics/honggfuzz: > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fd841336dfdefbc14907e2d9b1eb1a1a3f5f8b8e This is cool, but shouldn't it be something like openmp? (e.g. blocks) There is no reason blocks have to be used if not on macOS (where system headers use blocks features). Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] euses(1) Reimplementation
g/378603 > [3] https://bugs.gentoo.org/663706#c4 > [4] https://dl.acm.org/doi/abs/10.1145/116825.116845 > [5] > https://sourceware.org/git/?p=glibc.git;a=blob;f=string/strcasestr.c;h=d2964c5548b9ea7a68fc5b18b25ddfe7ddd6835c;hb=HEAD#l45 > [6] http://git.suugaku.co.uk/ash-euses/tree/ > [7] http://git.suugaku.co.uk/ash-euses/snapshot/ash-euses-0.3.tar.gz > > -- > > Ashley Dixon > suugaku.co.uk > > 2A9A 4117 > DA96 D18A > 8A7B B0D2 > A30E BF25 > F290 A8AA > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] New USE=-native-symlinks for gcc-config and binutils-config
On 24-05-2020 10:48:47 +0100, Sergei Trofimovich wrote:
> On Sat, 23 May 2020 22:41:02 -0400
> Mike Gilbert wrote:
> > I don't think we
> > want to give people the impression that this is a well-supported
> > configuration. I would only expect people to disable this if they want
> > to break their system intentionally.
>
> Yeah, today it's certainly a way to get your system in a miserable state.
> My hope is that USE=-native-symlinks can get you a working Gentoo in a
> near future by only fixing real package problems and limitations of their
> build systems.
Portage adds PREROOTPATH, ROOTPATH and a standard set of
/usr/{local/,}{s,}bin to PATH in _doebuild_path. That means if you add
something like /usr/bin/native-toolchain to PATH only, users will get
gcc, ld, etc., while root and Portage will lack these. One can wonder
if root should have direct access to compilers, but it's easy enough to
add the compilers to PATH if really necessary.
I guess what I'm trying to say is: you can hide effect of the setup for
users if you'd like. That is, after we had buildbots point out the bulk
of packages that are wrong of course.
Thanks,
Fabian
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: PGP signature
Re: [gentoo-dev] [RFC] Anti-spam for goose
On 22-05-2020 21:58:54 +0200, Michał Górny wrote: > Let's put it like this. This thing starts working. Package X is > broken, and we see that almost nobody is using it. We remove that > package. Now somebody is angry. He submits a lot of fake data to > render the service useless so that we don't make any future decisions > based on it. I'm affraid that has a heroic flair to me. The service should never be used for decisions like that, because it's a biased sample at most. Doing stuff like this simply destroys the soul of the distribution. I hope this isn't one of your genuine objectives with the service. If it is, I can see why you fear spam so much. Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Anti-spam for goose
> === > An alternative of using a proof-of-work algorithm was suggested to me > yesterday. The idea is that every submission has to be accompanied with > the result of some cumbersome calculation that can't be trivially run > in parallel or optimized out to dedicated hardware. > > On the plus side, it would rely more on actual physical hardware than IP > addresses provided by ISPs. While it would be a waste of CPU time > and memory, doing it just once a week wouldn't be that much harm. > > On the minus side, it would penalize people with weak hardware. > > For example, 'time hashcash -m -b 28 -r test' gives: > > - 34 s (-s estimated 38 s) on Ryzen 5 3600 > > - 3 minutes (estimated 92 s) on some old 32-bit Celeron M > > At the same time, it would still permit a lot of fake submissions. For > example, randomx [1] claims to require 2G of memory in fast mode. This > would still allow me to use 7 threads. If we adjusted the algorithm to > take ~30 seconds, that means 7 submissions every 30 s, i.e. 20k > submissions a day. > > So in the end, while this is interesting, it doesn't seem like > a workable anti-spam measure. > > > Option 3: explicit CAPTCHA > == > A traditional way of dealing with spam -- require every new system > identifier to be confirmed by solving a CAPTCHA (or a few identifiers > for one CAPTCHA). > > The advantage of this method is that it requires a real human work to be > performed, effectively limiting the ability to submit spam. > The disadvantage is that it is cumbersome to users, so many of them will > just resign from participating. > > > Other ideas > === > Do you have any other ideas on how we could resolve this? > > > [1] https://github.com/tevador/RandomX > > > -- > Best regards, > Michał Górny > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Gentoo Identity Provider
On 18-05-2020 18:42:24 -0700, Alec Warner wrote: > TL;DR: What if we launched id.gentoo.org[1], an identity provider that > provides > authentication for Gentoo properties? Basically, 1 username / password for > wiki, > bugs, email, forums, and any other http service[0][1]. I'd be in favour of SSO for all http-, imap- and smtp-based Gentoo services. Thanks, Fabian > > Today Gentoo has numerous systems that mostly work in a segmented way. > > - To connect to hosts, we use ssh keys. > - Git is authenticated via ssh keys. > - Email uses LDAP passwords. > - Bugzilla has its own identities, with their own passwords. > - Wiki is separate, with its own passwords. > - Forums are separate. > - Infra has an additional 4 systems that use separate credentials. > > Some applications support 2FA (such as wiki.) > Some applications do not support 2FA. > Applications that require 2FA have a configuration for each app, so you have N > configurations. > > If we configured id.gentoo.org[2] you would have 1 identity across all gentoo > properties. > > Is this a thing people are interested in? > > [0] It's unlikely operations for git via ssh would change in this rollout. > [1] Its unclear if the scope is "gentoo developers" or "any community member." > The former have LDAP accounts and @gentoo.org[3] email addresses and so we can > manage them easily; managing 1000s of other accounts in the IDP remains to be > seem. > > > References >1. http://id.gentoo.org >2. http://id.gentoo.org >3. http://gentoo.org -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Last standing Python 2.7 dependency
On 02-05-2020 23:24:42 -0700, Brian Dolbec wrote: > On Sun, 3 May 2020 07:28:50 +0200 > Viktar Patotski wrote: > > > Hi all, > > > > I'd also like to clean my system and have it Python 2.7 free. Are > > there any guidelines to check which packages are still using pyton2_7 > > in my system? > > > > Thanks, > > Viktar > > > > There are both equery and enalyze commands in gentoolkit that can give > you reports about what pkgs are installed. > > equery hasuse > enalyze analyze [use|pkguse] > > for help on them: > equery -h > equery hasuse -h > enalyze -h > enalyze a -h In addition to these great tools, portage-utils' quse might also be useful: % quse python2_7 ... Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] fcaps.eclass: disable fcaps() on Prefix.
On 08-03-2020 15:26:50 +0800, hero...@gentoo.org wrote:
> From: Benda Xu
>
> Gentoo Prefix runs with a normal user and cannot grant extra
> capabilities. Exit gracefully with a message.
>
> Signed-off-by: Benda Xu
> ---
> eclass/fcaps.eclass | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/eclass/fcaps.eclass b/eclass/fcaps.eclass
> index 467f955f5e9a..563d177c92d5 100644
> --- a/eclass/fcaps.eclass
> +++ b/eclass/fcaps.eclass
> @@ -78,6 +78,11 @@ DEPEND="filecaps? ( sys-libs/libcap )"
> fcaps() {
> debug-print-function ${FUNCNAME} "$@"
>
> + if [[ ${EUID} != 0 ]] ; then
> + einfo "Insufficient privileges to execute ${FUNCNAME[0]}"
> + return 0
Perhaps add "ignoring" or something in the message here to make it clear
this isn't treated as an error?
Thanks,
Fabian
> + fi
> +
> # Process the user options first.
> local owner='root'
> local group='0'
> --
> 2.25.0
>
>
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: PGP signature
Re: [gentoo-dev] Keywordreqs and slacking arch teams
On 28-12-2019 22:27:02 +1300, Kent Fredric wrote: > On Sat, 28 Dec 2019 08:09:33 +0100 > Michał Górny wrote: > > > How can we improve this? > > Every time this kind of issue comes up, I can't help feeling we need > some sort of tool more advanced than what we currently have. > > Something that maintains persistence of keyword demands similar to how > the current bot does, but more ... > > Its the sort of thing I get tempted to implement myself, but get too > horrified about the prospect of working with portage internals to do it. Hmmm, interested to hear what kind of things you're thinking about here. I feel it would help if we would have the ability to at least compile/test ebuilds automatically. Not sure how helpful qemu could be there, but I know things like compiling for things like arm (RPi) works reasonably well. Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] New distfile mirror layout
On 29-10-2019 15:45:34 +0100, Michał Górny wrote: > On Tue, 2019-10-29 at 15:33 +0100, Fabian Groffen wrote: > > In addition, there are currently files there that aren't referenced from > > ebuilds. Prefix uses these files during bootstrap, local mirrors are > > often much faster than dev.g.o. > > > > If the files don't get mirrored anymore, I guess I can create a dummy > > ebuild that has the files in SRC_URI. > > Ok, this is something I wasn't aware of. I agree that dummy ebuild > should not be necessary here. However, I'm also not sure if distfiles- > local is really the proper way either, especially that I don't see such > files on woodpecker right now. There should be /space/distfiles-local and /space/distfiles-whitelist/prefix with a list of files to retain on the mirror. Thanks, Fabian > I don't think the matter is urgent right now, so let's ponder on it > a bit. In particular, I think we should have a clear indication of who > added which files, when, what for and where they came from. Those are > precisely the things that the current distfiles-local approach misses. > > > If the files get mirrored, but put in a subdir based on the filename > > hash, the original query endpoint on distfiles.g.o changes, much like > > the SRC_URI approach. > > > > Now I can use distfiles.prefix.b.n which redirects to the distfiles.g.o > > URL with subdir for most part I think, but it's sub-optimal from my > > point of view. Calculating the hash is not always feasible due to the > > lack of b2sum or other means. Hence my earlier request to have such > > official translation service on Gentoo hardware. > > > > (I just wrote a small wsgi script that calculates the hash and generates > > the redirect from Python, served via uwsgi/nginx, but there should be > > many ways to achieve the same goals, if and only if a blake2b > > implementation were available for it.) > > This is also something that needs thinking. I personally don't mind > having one but it would be nice if it was able to account for geodns > and such. > > -- > Best regards, > Michał Górny > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] New distfile mirror layout
On 29-10-2019 15:17:38 +0100, Ulrich Mueller wrote: > >>>>> On Tue, 29 Oct 2019, Michał Górny wrote: > > > On Tue, 2019-10-29 at 14:09 +0100, Ulrich Mueller wrote: > >> > What if the file is hosted at a non-standard tcp port upstream > >> > (like http://example.org:8080/)? The devmanual says that it _must_ > >> > be manually uploaded to /space/distfiles-local/ in such cases. > > >> Or another example, app-emacs/vhdl-mode-3.38.1, where (incompetent, > >> or nasty?) upstream blocks wget for some reason, but other methods > >> (e.g., curl, firefox) work? How would I get the file onto the mirrors > >> there? > > > If I were you, I would've explicitly mirrored the file anyway. > > If upstream blocks wget, then users who do not use GENTOO_MIRRORS will > > also suffer due to it. > > All what I'm saying is that there can be unusual circumstances where > manual uploading of a file is useful. So please don't take that > possibility away. In addition, there are currently files there that aren't referenced from ebuilds. Prefix uses these files during bootstrap, local mirrors are often much faster than dev.g.o. If the files don't get mirrored anymore, I guess I can create a dummy ebuild that has the files in SRC_URI. If the files get mirrored, but put in a subdir based on the filename hash, the original query endpoint on distfiles.g.o changes, much like the SRC_URI approach. Now I can use distfiles.prefix.b.n which redirects to the distfiles.g.o URL with subdir for most part I think, but it's sub-optimal from my point of view. Calculating the hash is not always feasible due to the lack of b2sum or other means. Hence my earlier request to have such official translation service on Gentoo hardware. (I just wrote a small wsgi script that calculates the hash and generates the redirect from Python, served via uwsgi/nginx, but there should be many ways to achieve the same goals, if and only if a blake2b implementation were available for it.) Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] New distfile mirror layout
On 29-10-2019 05:27:37 +0100, Michał Górny wrote: > On Tue, 2019-10-29 at 00:24 +0100, Chí-Thanh Christopher Nguyễn wrote: > > Hi! > > > > > Today you get chastised for using /space/distfiles-local and not > > > following policy changes. The devmanual states that it's deprecated > > > since at least 2011, and talks of using d.g.o [1]. > > > [1] > > https://devmanual.gentoo.org/general-concepts/mirrors/index.html#suitable-download-hosts > > > > Sorry I'm late to the party, but I would like to enquire about what happens > > if a file with existing filename but different b2sum gets uploaded to > > /space/distfiles-local now? > > The same as before. It gets put in top-level disfiles directory. > Hashes are calculated from filenames, so this wouldn't affect it. That > is, if it put those files in subdirectories in the first place because > it doesn't. /space/distfiles-local is no longer copied to the mirrors? or just not copied in the subdir-hierarchy? > > Doing so and updating the Manifest used to be another (not necessarily > > preferred) method to address upstream remaking release packages. > > > > It's no longer valid. Just wondering. Do you mean it isn't valid that some upstreams do this (yes horror)? We surely need a way to work around that ... Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] New distfile mirror layout
Hi, On 18-10-2019 15:41:32 +0200, Michał Górny wrote: > 3. Directly fetching files from distfiles.gentoo.org will become > a little harder. To fetch a distfile named 'foo-1.tar.gz', you'd have > to use something like: > > $ printf '%s' foo-1.tar.gz | b2sum | cut -c1-2 > 1b > $ wget http://distfiles.gentoo.org/distfiles/1b/foo-1.tar.gz > ... > > > Alternatively, you can: > > $ wget http://distfiles.gentoo.org/distfiles/INDEX > > and grep for the right path there. This INDEX is also a more > lightweight alternative to HTML indexes generated by the servers. Would it be possible to run a service that sends a 302 for the distfiles/foo-1.tar.gz to the appropriate bucket such that manual fetching doesn't require to calculate the hash? I prototyped this myself for distfiles.prefix, and seems like a nice guesture for at least the transition period? Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Underscores in USE flags
On 21-09-2019 09:06:01 +0200, Michał Górny wrote: > On Sat, 2019-09-21 at 08:43 +0200, Fabian Groffen wrote: > > Why not teach our tools (equery, quse, etc.) to print these USE-flags > > like Portage does? (looking them up to be valid expands) > > Then users have nothing to be confused about (no distinction between > > foo_bar and FOO="bar"), and new USE_EXPANDS cannot be > > silently/accidentially introduced. > > I don't see how that solves the problem. More tools having distinct > output don't change the fact that anyone with a bit of ebuild knowledge > will say 'this looks like USE_EXPAND' while looking at it, independently > of what some tools would say. Well... someone with a bit of ebuild knowledge would see odd USE-flags. USE_EXPAND is a (bad) hack, of having some USE-flags mean something different, or resolve through something different, while in reality they really don't do anything odd. In fact, sometimes users have to use FOO="bar" (make.conf), while other times foo_bar needs to be used (e.g. use.mask, or IUSE=). Consistency would be nice, the real question is, what does USE_EXPAND actually try to achieve, and can we fix it properly in the next EAPI, such that repoman can also do the proper complaints about USE-flag (and USE_EXPAND-flag) naming by then. Back to the thread, the point is, these flags exist today, and renaming flags is not something to be considered harmless. As much as the recent renaming of lm_sensors to lm-sensors caused breakage (and still does, apparently some tools keep caches, etc.) also renaming USE-flags goes by problems, in particular for managed systems (Chef, Puppet). It's not a matter of just fixing the name for a USE-flag. This is saying nothing about whether or not we'd want to change the flag. It's about the impact of the change, and whether that is worth it for the noble aim of consistency or correctness. I believe this was the OPs point in this thread. Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Underscores in USE flags
On 20-09-2019 22:53:53 +0200, Michał Górny wrote: > On Fri, 2019-09-20 at 13:46 -0700, Zac Medico wrote: > > > > If we take this underscore rule to its logical extreme, then we should > > rename python_targets_python3_7 to python_targets_python3-7, yes? > > Believe me, I would have done that already if not the fact that with all > the dependency logic around here it would be totally destructive to all > Gentoo systems. Honestly, with this reasoning, why force other packages to go through USE-flag renaming in that case? A major consumer of USE_EXPAND isn't sticking to the rule, which makes any benefit of it moot. Tools cannot assume the last underscore separates the USE_EXPAND var from its value, users cannot see what is the value either, without knowledge. Why not teach our tools (equery, quse, etc.) to print these USE-flags like Portage does? (looking them up to be valid expands) Then users have nothing to be confused about (no distinction between foo_bar and FOO="bar"), and new USE_EXPANDS cannot be silently/accidentially introduced. > But hey, expect hyphen on 3.8. I honestly feel for consistency and not confusing users, we should either do them all or stick to the current scheme. Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-dev] Last rites: app-portage/hashgen
# Fabian Groffen (2019-09-15) # Incorporated in >=app-portage/portage-utils-0.80 as qmanifest # Removal in 30 days. Bug #694428 app-portage/hashgen -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] use.desc: Introduce global USE=magic
Hi Michał, It looks like you missed two from your original set? app-editors/nano[magic] Add magic file support (sys-apps/file) to automatically detect appropriate syntax highlighting www-servers/pshs[magic] Enable automatic detection of Content-Type using libmagic (sys-apps/file) Thanks, Fabian On 19-08-2019 22:04:12 +0200, Michał Górny wrote: > On Sun, 2019-08-11 at 13:21 +0200, Michał Górny wrote: > > USE=magic is currently used consistently by 12 packages: > > > > Merged. > > -- > Best regards, > Michał Górny > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags
On 21-07-2019 23:47:02 +1200, Kent Fredric wrote: > Yes, yes, I'm suggesting something perverted like a build server or > system for aggregating built man-pages on gentoo-servers automatically > as part of CI, that end users can just trivially fetch. But that's just > one approach, surely, there are others. Right, or we go for some (official) form of binpkgs distribution. Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-dev] Re: RFC: isodate for packages.mask starting on 2019-07-01
I think ISO 8601 date format is an improvement. However, as you're suggesting to use a date at UTC time, this begs for scripting, such as the old echangelog did. Then, when scripted, the actual date format is no longer an issue. Somehow the current format looks easier to read (for humans) to me, so no real need to change if there was a script to just add/remove/update entries. (And commit without forgetting to add --signoff.) Fabian On 29-06-2019 13:23:10 +0200, Jonas Stein wrote: > Dear all, > > Situation: > We have different date formats in packages.mask. > > > Change: > I suggest that we start using the date format -mm-dd > for all dates in packages.mask > starting with 2019-07-01 > > The following changes in packages.mask will introduce the date format, > specify the timezone, and use Larry as example user. > > 3,6c3,6 > < # When you add an entry to the top of this file, add your name, the > date, and > < # an explanation of why something is getting masked. Please be extremely > < # careful not to commit atoms that are not valid, as it can cause > large-scale > < # breakage, especially if it ends up in the daily snapshot. > --- > > # When you add an entry to the top of this file, add your name, the date > > # in the UTC timezone, and an explanation of why something is getting > masked. > > # Please be extremely careful not to commit atoms that are not valid, > as it can > > # cause large-scale breakage, especially if it ends up in the daily > snapshot. > 10c10 > < ## # Dev E. Loper (28 Jun 2012) > --- > > ## # Larry the cow (2019-07-01) > 24,26c24,26 > < ## # Dev E. Loper (23 May 2015) > < ## # Masked for removal in 30 days. Doesn't work > < ## # with new libfoo. Upstream dead, gtk-1, smells > --- > > ## # Larry the cow (2019-07-01) > > ## # Masked for removal after 2019-08-01. > > ## # Doesn't work with new libfoo. Upstream dead, gtk-1, smells > > > Reason: > * Larry is the Gentoo Example > * 2019-01-01 + 30 days is unclear, if we do not use UTC time > * The new date format is easy to read and write and easy to parse > internationally. > > Do you have any objections? > > > By the way, you can get a formatted string of now in UTC with: > date -u +"%Y-%m-%d" > > -- > Best, > Jonas > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Deprecation and removal of 13.0 profiles is imminent
On 19-02-2019 22:52:10 +, Sergei Trofimovich wrote: > A few months passed and we almost finished with a long tail. > > To-be-deprecated profiles yet are: > https://bugs.gentoo.org/673278 > prefix/linux-standalone/ppc64 > > +prefix@, what is our plan here? Can we drop at least empty > 'deprecated' file to notify users? I cleaned it up, it isn't in use any more. Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Gentoo binary package container format
On 26-11-2018 21:13:53 +, Andrey Utkin wrote: > On Wed, Nov 21, 2018 at 11:45:54AM +0100, Fabian Groffen wrote: > > We agree it is hackish, and we agree we can do without. You simply > > exaggerate the problem, IMO, which mostly isn't there, because it works > > fine today. It can also be solved today using shell tools. > > I am sad that you don't see it as a productivity impediment that the > user is required to know the custom tooling to do even such a trivial > non-standard action as manual extraction. Huh? tar -jxf doesn't do the trick for you? > Maybe I will make myself look bad by admitting this, but I'm not meeting > your expectations. I use Gentoo for ~11 years, and for about one year I > am using my private binpkgs distributed to all my machines (i.e. I have > read binary package guide fair number of times, but I stopped rereading > it when I satisfied my needs). When in need, I still reached to trusty > tar, and I did not even know what are the names of special tools (a > toolchain?) qtbz2 and qxpak. > > Just few days ago I messed with binpkgs for investigation purpose. I > just wanted to extract few to somewhere (definitely not into system > root), and read a core dump with GDB asking it to use those extracted > files for debug symbols. > > Of course I used `tar xaf`, because what I know is that it's honest tbz2 > just with metadata appended. > > # tar xaf boost-1.65.0.tbz2 > > bzip2: (stdin): trailing garbage after EOF ignored > > Exit code is 0. > But the notice is annoying (on subconscious level), because Silence Is > Golden - "when a program has nothing interesting or surprising to say, > it should shut up". You seem to contradict yourself. You didn't know the tools, yet you say you needed to, to unpack the files. But you show here you just unpacked the files without said knowledge. > > % head -c `grep -abo 'XPAKPACK' > > $EPREFIX/usr/portage/packages/sys-apps/sed-4.5.tbz2 | sed 's/:.*$//'` > > $EPREFIX/usr/portage/packages/sys-apps/sed-4.5.tbz2 | tar -jxf - > > > > results in no warnings/errors from bzip about trailing garbage, possible > > thanks to the spec being smart enough about this. > > Thanks, this is a very concise **custom tool** to handle current binpkg > format. As is tar followed by tar. The obvious advantage of the latter is that you don't get a warning which could trigger you into thinking something is wrong. So, in my opinion, that is a better way of doing it compared to the current way. > > Not having to do this, when under stress and pressure to restore a > > system to get it back into production, is a plus. Though, in that > > scenario the trailing garbage warning wouldn't have been that bad > > either. > > When understress and pressure, the irrelevant warning is not bad? > I am sure it is really bad for operator's attention. I've been using Gentoo binpkgs for a long while, I think something like ~14 years ago when I used them extensively. Perhaps I'm an exception, but back then I knew already there was an extra bit attached to the tars, as were all my collegues around me back then. The fact it comes up now (as a surprise?) maybe means the knowledge has gone. So good thing we're replacing it with something easier to infer from inspecting it. Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] [pre-GLEP r2] Gentoo binary package container format
On 20-11-2018 21:33:17 +0100, Michał Górny wrote: > The volume label > > > The volume label provides an easy way for users to identify the binary > package without dedicated tooling or specific format knowledge. > > The implementations should include a volume label consisting of fixed > string ``gpkg:``, followed by a single space, followed by full package > identifier. However, the implementations must not rely on the volume > label being present or attempt to parse its value when it is. > > Furthermore, since the volume label is included in the .tar archive > as the first member, it provides a magic string at a fixed location > that can be used by tools such as file(1) to easily distinguish Gentoo > binary packages from regular .tar archives. Just for clarity on this point. Are you proposing that we patch file(1) to print the Volume Header here? file-5.35 seems to not say much but "tar archive" or "POSIX tar archive" for tar-files containing a Volume Header as shown by tar -tv. > Container and archive formats > - > > During the debate, the actual archive formats to use were considered. > The .tar format seemed an obvious choice for the image archive since > it is the only widely deployed archive format that stores all kinds > of file metadata on POSIX systems. However, multiple options for > the outer format has been debated. You mention POSIX, which triggered me. I think it would be good to specify which tar format to use. POSIX.1-2001/pax format doesn't have a 100/256 char filename length restriction, which is good but it is not (yet) used by default by GNU tar. busybox tar can read pax tars, it seems. Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Gentoo binary package container format
; a royal PITA when the user wants to do something that the author of > > > specialized tooling just happened not to think worthwhile, or when > > > the tooling is not available for some reason. And before you ask really > > > silly questions, yes, I did fight binary packages over hex editor > > > at some point. > > > > Which I still don't understand, to be frank. I think even Portage > > exposes python APIs to get to the data. > > Compare the time needed to make a trivial (but unforeseen) change > on a format that's transparent vs a format that requires you to learn > its spec and/or API, write a program and debug it. I was under the impression you could unpack a tbz2 into data and xpak, then unpack both, modify the contents with an editor or whatever, and then pack the whole stuff back into a tbz2 again. This can be done worst case scenario by emerge -k , modifying the vdb and quickpkg afterwards. I know that with portage-utils you can do this easily with the qtbz2 and qxpak commands. No need to do anything with a hex editor, or know anything about how it's done. Obvious advantage of your approach is that you don't need q* tools, but can use tar instead. The editting is as trivial though. In your case you need a special procedure to reconstruct the binpkg should you want to keep your special properties (label, order) which equates to q* tools somewhat. > > > The most trivial case is an attempted recovery of a broken system. > > > If you don't have Portage working and don't have portage-utils > > > installed, do you really prefer a custom format which will require you > > > to fetch and compile special tools? Or is one that can be processed > > > with tools you're quite likely to have on every system, like tar? > > > > Well, I think the idea behind the original binpkg format was to use tar > > directly on the files in emergency scenarios like these... > > The assumption was bzip2 decompressor and tar being available. > > I think it is an example of how you add something, while still allowing > > to fallback on existing tools. > > Except progress in compressors has made it work less and less reliably. > It's mostly an example how to be *clever*. However, being clever > usually doesn't pay off in the long term, compared to doing things *in a > simple way*. We agree it is hackish, and we agree we can do without. You simply exaggerate the problem, IMO, which mostly isn't there, because it works fine today. It can also be solved today using shell tools. % head -c `grep -abo 'XPAKPACK' $EPREFIX/usr/portage/packages/sys-apps/sed-4.5.tbz2 | sed 's/:.*$//'` $EPREFIX/usr/portage/packages/sys-apps/sed-4.5.tbz2 | tar -jxf - results in no warnings/errors from bzip about trailing garbage, possible thanks to the spec being smart enough about this. Not having to do this, when under stress and pressure to restore a system to get it back into production, is a plus. Though, in that scenario the trailing garbage warning wouldn't have been that bad either. > > > > > 3. **The file format should provide for partial fetching of binary > > > > >packages.** It should be possible to easily fetch and read > > > > >the package metadata without having to download the whole package. > > > > > > > > Like above, what is the use-case here? Why would you want this? I > > > > think I'm missing something here. > > > > > > Does this harm anything? Even if there's little real use for this, is > > > there any harm in supporting it? Are we supposed to do things the other > > > way around with no benefit just because you don't see any real use for > > > it? > > > > Well, you make a huge point out of it. And if it isn't used, then why > > bother so much about it. Then it just looks like you want to use it as > > an argument to get rid of something you just don't like. > > > > In my opinion you better just say "hey I would like to implement this > > binpkg format, because I think it would be easier to support with > > minimal tools since it doesn't have custom features". I would have > > nothing against that. Simple and elegant is nice, you don't need to > > invent arguments for that, in my opinion. > > The spec is now more focused on that. Thank you, much appreciated. Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Gentoo binary package container format
On 18-11-2018 10:38:51 +0100, Michał Górny wrote: > On Sun, 2018-11-18 at 10:16 +0100, Fabian Groffen wrote: > > On 17-11-2018 12:21:40 +0100, Michał Górny wrote: > > > Problems with the current binary package format > > > --- > > > > > > The following problems were identified with the package format currently > > > in use: > > > > > > 1. **The packages rely on custom binary archive format to store > > >metadata.** It is entirely Gentoo invented, and requires dedicated > > >tooling to work with it. In fact, the reference implementation > > >in Portage does not even include a CLI tool to work with tbz2 > > >packages; an unofficial implementation is provided as part > > >of portage-utils toolkit [#PORTAGE-UTILS]_. > > > > I think you should rewrite this section to the argument that the > > metadata is hard to edit, and that there is only one tool to do so > > (except a python interface from Portage?). > > On a separate note, I don't think portage-utils can be considered > > "unofficial", it is a Gentoo official project as far as I am aware. > > In this context, Portage is 'official'. Portage-utils is a project > that's developed entirely separately from Portage and doesn't use > Portage APIs but instead reinvents everything. As such, it is easy for > the two to go out of sync. Or for one of them to have bugs that > the other one doesn't have (say, with endianness). I'm not sure if it's actually true, I was under the impression the same author(s) worked on the Portage as well as portage-utils code. Anyway, aren't quickpkg and emerge enough from a user's perspective? > > > 2. **The format relies on obscure compressor feature of ignoring > > >trailing garbage**. While this behavior is traditionally implemented > > >by many compressors, the original reasons for it have become long > > >irrelevant and it is not surprising that new compressors do not > > >support it. In particular, Portage already hit this problem twice: > > >once when users replaced bzip2 with parallel-capable pbzip2 > > >implementation [#PBZIP2]_, and the second time when support for zstd > > >compressor was added [#ZSTD]_. > > > > I think this is actually the result of a rather opportunistic > > implementation. The fault is that we chose to use an extension that > > suggests the file is a regular compressed tarball. > > When one detects that a file is xpak padded, it is trivial to feed the > > decompressor just the relevant part of the datastream. The format > > itself isn't bad, and doesn't rely on obscure behaviour. > > Except if you don't have the proper tools installed. In which case > the 'opportunistic' behavior made it possible to extract the contents > without special tools... except when it actually happens not to work > anymore. Roy's reply indicates that there is actually interest in this > design feature. Your point is that the format is broken (== relies on obscure compressor feature). My point is that the format simply requires a special tool. The fact that we prefer to use existing tools doesn't imply in any way that the format is broken to me. I think you should rewrite your point to mention that you don't want to use a tool that doesn't exist in @system (?) to unpack a binpkg. My guess is that you could use some head/tail magic in a script if the trailing block is upsetting the decompressor. I'm not saying this may look ugly, I'm just saying that your point seems biased. > > > 3. **Placing metadata at the end of file makes partial fetches > > >complex.** While it is technically possible to obtain package > > >metadata remotely without fetching the whole package, it usually > > >requires e.g. 2-3 HTTP requests with rather complex driver. For > > >comparison, if metadata was placed at the beginning of the file, > > >early-terminated pipeline with a single fetch request would suffice. > > > > I think this point needs to be quantified somewhat why it is so > > important. > > I may be wrong, but the average binpkg is small, <1MiB, bigger packages > > are <50MiB. > > So what is the gain to be saved here? A "few" MiBs for what operation > > exactly? I say "few" because I know for some users this is actually not > > just a blib before it's downloaded. So if this is possible to achieve, > > in what scenarios is this going to be used (and is
Re: [gentoo-dev] [pre-GLEP] Gentoo binary package container format
> 5. **The file format must allow for efficient metadata updates.** >In particular, it should be possible to update the metadata without >having to recompress package files. > > 6. **The file format should account for easy recognition both through >filename and through contents.** Preferably, it should have distinct >features making it possible to detect it via file(1). > > 7. **The file format should allow for metadata compression.** > > 8. **The file format should make future extensions easily possible >without breaking backwards compatibility.** -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] app-emulation/libvirt-snmp: version bump to 0.0.4
On 27-10-2018 15:18:28 +0300, Joonas Niilola wrote: > Why can't you use Github like _everyone_ else? It's really simple and fast. Hrm ... given Github's not integrated with Gentoo, one can argue that sending a patch to the ML is actually more simple/fast for developers. I don't think sending patches to this ML targets the right audience, yet I welcome the contribution. -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Changing policy about -Werror
I think you misunderstood what I wrote, or I wasn't clear enough. Richard summed up my intention nicely in his response. Fabian On 15-09-2018 00:46:24 +0300, Alon Bar-Lev wrote: > On Sat, Sep 15, 2018 at 12:29 AM Fabian Groffen wrote: > > > > On 15-09-2018 00:07:12 +0300, Alon Bar-Lev wrote: > > > > > > > > Perhaps, if one persists on going this route, only do this for platforms > > > > that upstream supports, such that arches which will suffer from this > > > > (typically ppc, sparc, ...) don't have to be blocked by this. > > > > > > Exactly in these cases the -Werror is useful as if upstream expects no > > > warnings then any warning should block installation and trigger bug > > > report. In Gentoo in many cases we use packages on platform has no > > > access to, our feedback to upstream is valuable. A great example is > > > gnutls in which we collectively (maintainer, unstable users, > > > architecture teams, stable users) found issues on architectures that > > > almost nobody other than Gentoo has access to. > > > > > > > I don't believe Gentoo users are (supposed to be) an extension of > > upstreams. > > This is exactly what I think that is special about Gentoo, and the > reason I use Gentoo. Unlike other distribution Gentoo is the closest > thing of using upstream. A maintainer in Gentoo who is not see himself > part of the upstream packages he maintains has far less impact than a > maintainer who does see himself as part of upstream or is upstream. > > Per your statement, we should not allow any architecture or setup that > upstream, such as exact versioning, architecture or toolchain. > > > If upstreams insist on that, they should make their software > > non-free, adding a non-modification clause or something. In any case, > > it is not Gentoo's job IMHO. > > Then we cannot re-distribute or patch, how is it related to the > discussion? We are talking about open source projects and I know it is > cliche... the "greater good" and helping the "free open source > movement" a a viable alternative. I thought this is what unite us > here. > > > In the end it is Gentoo who needs to care > > for its users. I prefer we do that by giving them an option to become > > that extension of upstream, e.g. by USE=upstream-cflags, which Gentoo > > disables by default. > > Do you think someone do not care about the users? Do you actually > think upstream does not care about users? I do not understand this > statement. If downstream maintainer believes that upstream is friendly > for the Gentoo overhead (which is higher than binary distributions) or > create the relationship in which Gentoo is 1st citizen at upstream, > why do you think users cannot use vanilla upstream? > > > As maintainer and/or enthusiastic user, like you wrote for gnutls, I > > would be more than happy to provide build logs/errors for all the arches > > I have access to. So like I wrote before, I think we should consider > > case-by-case basis to make it easy to do so. > > This entire discussion is to allow case-by-case and not black and > white approach recently enforced. > > Regards, > Alon > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Changing policy about -Werror
On 15-09-2018 00:07:12 +0300, Alon Bar-Lev wrote: > > > > Perhaps, if one persists on going this route, only do this for platforms > > that upstream supports, such that arches which will suffer from this > > (typically ppc, sparc, ...) don't have to be blocked by this. > > Exactly in these cases the -Werror is useful as if upstream expects no > warnings then any warning should block installation and trigger bug > report. In Gentoo in many cases we use packages on platform has no > access to, our feedback to upstream is valuable. A great example is > gnutls in which we collectively (maintainer, unstable users, > architecture teams, stable users) found issues on architectures that > almost nobody other than Gentoo has access to. > I don't believe Gentoo users are (supposed to be) an extension of upstreams. If upstreams insist on that, they should make their software non-free, adding a non-modification clause or something. In any case, it is not Gentoo's job IMHO. In the end it is Gentoo who needs to care for its users. I prefer we do that by giving them an option to become that extension of upstream, e.g. by USE=upstream-cflags, which Gentoo disables by default. As maintainer and/or enthusiastic user, like you wrote for gnutls, I would be more than happy to provide build logs/errors for all the arches I have access to. So like I wrote before, I think we should consider case-by-case basis to make it easy to do so. Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Changing policy about -Werror
On 14-09-2018 16:29:43 -0400, Rich Freeman wrote: > On Fri, Sep 14, 2018 at 4:20 PM Michael Orlitzky wrote: > > > > On 09/14/2018 03:58 PM, Richard Yao wrote: > > >> > > >> No one has answered the question: what do you do when a stable package > > >> breaks because of a new warning? > > >> > > >> ...> > > > Wouldn’t this be largely covered as part of GCC stabilization? We could > > > reserve the right to kill -Werror in a package where it blocks GCC > > > stabilization if the maintainer does not handle it in a timely manner. > > >> > > > > They would be uncovered during GCC stabilization, but then you're right > > back in the original situation: how do you fix the stable package? The > > only answer that doesn't violate some other policy is to patch it in a > > new revision and wait for it to stabilize again. > > > > Other questions arise: Do we block stabilization of clang et al.? > > > > Presumably we could make it a blocker, so then portage won't install > the new stable toolchain. That buys time and only affects users of > that particular package. But, as I pointed out before you can do that > without using -Werror - just block installation with an unqualified > toolchain. > > You would only use an approach like this for packages where QA was > fairly important, so the inconvenience would be worth it. Perhaps, if one persists on going this route, only do this for platforms that upstream supports, such that arches which will suffer from this (typically ppc, sparc, ...) don't have to be blocked by this. Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Changing policy about -Werror
On 13-09-2018 18:56:13 +0300, Alon Bar-Lev wrote: > On Thu, Sep 13, 2018 at 6:51 PM Fabian Groffen wrote: > > > > On 12-09-2018 17:46:03 -0700, Matt Turner wrote: > > > On Wed, Sep 12, 2018 at 5:11 PM Rich Freeman wrote: > > > With new GCC comes new warnings, and harmless as the vast majority are > > > they cause the build to break with Werror. > > > > To illustrate harmless: > > warning: this statement may fall through [-Wimplicit-fallthrough=] > > The warning message already has it in it that it's just a pure guess. > > One that exposed a lot of unintentional fallthoughs which were fixed > when reporting to upstream. Sure that's why the warning is there. But you ignore the point that the same code compiled fine and ran fine for years without problems. > Once again... we should discuss to leave -Werror when policy of > upstream to have no warnings and is maintaining that policy properly > while we at downstream may cooperate and avoid patching upstream but > discuss issues when found. On a developer's system, that would be nice. For ordinary users on the other hand: Leaving -Werror is leaving our users alone in the dark. Don't do that. -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Changing policy about -Werror
On 12-09-2018 20:09:54 -0400, Rich Freeman wrote: > On Wed, Sep 12, 2018 at 7:32 PM Chí-Thanh Christopher Nguyễn > wrote: > > > > Alon Bar-Lev schrieb: > > > We > > > are unique as permutations and architectures that are used by Gentoo > > > users are so diverse that we find issues that nobody else finds. > > > > This needs to be highlighted more, as it is why suggestions that the > > maintainer can simply put -Werror back on their own system are insufficient. > > > > Wouldn't running into new runtime issues be exactly the sort of reason > why we'd want to build with -Werror on packages where these issues are > unacceptable? Can you think of a way in which a new runtime issue would occur that -Werror would have guarded? And that issue would also get through maintainer and ~arch testing? Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Changing policy about -Werror
On 13-09-2018 07:36:09 -0400, Richard Yao wrote:
>
>
> > On Sep 12, 2018, at 6:55 PM, Thomas Deutschmann wrote:
> >
> >> On 2018-09-12 16:50, Rich Freeman wrote:
> >> There is also the case where we want these warnings to block
> >> installation, because the risk of there being a problem is too great.
> >
> > I really disagree with that. So many devs have already said multiple
> > times in this thread that "-Werror" is only turning existing warnings
> > into fatal errors but "-Werror" itself doesn't add any new checks and
> > more often requires "-O3" to be useful.
> The way that compilers work is that the warnings are generated in the front
> end while the optimization level affects the backend. That means that -O3 has
> no effect on the code that does error generation. This remark about -O3 being
> needed to make -Werror useful is just plain wrong.
Huh? -O3 enables more checks, which can generate more warnings. -O3
isn't "needed", but if upstream is so interested in clean and correct
code, they should've fixed all warnings in the first place and thus
enabled all of them. In fact, I expect every sane upstream to use "-O3
-Wall -Werror" in one of their automated builds. Not that this catches
anything useful on x86{,_64} when there is for instance use of signed
and unsigned char types, so it isn't conclusive.
The whole point in here is that -Werror doesn't add much if you care.
The whole point why it is not desired in Gentoo is that users don't
necessarily are developers, or even interested in fixing warnings --
regardless whether they point to real problems or not.
If there are real problems in a package (exposed by a compiler or not)
then this should ideally stand out during ~arch testing, or even before
when the Gentoo maintainer examines the build (might even use -Werror
for his own purposes). If such code ends up in stable arch we just made
a stabilisation mistake, or got royally messed up by upstream, depending
how you look at it.
Fabian
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: PGP signature
Re: [gentoo-dev] Changing policy about -Werror
On 12-09-2018 17:46:03 -0700, Matt Turner wrote: > On Wed, Sep 12, 2018 at 5:11 PM Rich Freeman wrote: > > > > On Wed, Sep 12, 2018 at 7:52 PM Matt Turner wrote: > > > > > > On Wed, Sep 12, 2018 at 4:03 PM Rich Freeman wrote: > > > > Now, I could buy that -Werror turns NEW warnings into fatal errors, > > > > due to the use of a newer toolchain, since upstream probably didn't > > > > test with that toolchain and thus wouldn't have seen the warning. > > > > > > Yes, exactly. This is one of the major things people have said repeatedly. > > > > > > Werror makes moving gcc forward much more difficult. > > > > > > > Sure, but wouldn't a block on newer versions of gcc cause similar headaches? > > Sure...? Who is suggesting that? I'm not sure where you're going with this. > > With new GCC comes new warnings, and harmless as the vast majority are > they cause the build to break with Werror. To illustrate harmless: warning: this statement may fall through [-Wimplicit-fallthrough=] The warning message already has it in it that it's just a pure guess. -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Changing policy about -Werror
On 13-09-2018 00:55:45 +0200, Thomas Deutschmann wrote: > Unless you can do that we don't really need to discuss this. Simply > because everyone interested in "-Werror" *can* set that flag via CFLAGS, > even just per package, whereas the majority, not interested in this, > cannot do the same to filter "-Werror". Nobody advocating for "-Werror" > replied to that fact yet. Unfortunately adding -Werror to CFLAGS is not just possible. Many configure checks rely on the compiler just generating something, ignoring warnings for various reasons. If you add -Werror to your CFLAGS you basically introduce breakage for some autoconf-based packages. What we really should be having is an easy way for post-configure CFLAGS addition. Just to support devs/users who insist on this for their setups. Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Changing policy about -Werror
On 09-09-2018 11:22:41 -0400, Richard Yao wrote: > -Werror has caught bugs that could have resulted in data loss in ZFS in the > past thanks to it being built in userspace as part of zdb. So it is useful > for integrity too, not just security (although arguably, integrity is part of > security). This is a misconception, as jer already pointed out. Instead: -Werror has forced you to take notice of problems that could have resulted in data loss in ZFS ... Also, consider that for -Werror to be "better", you also need -O3 in order to activate the "proper" compiler checks like "variable set but never used" ones. > Perhaps we could have another USE flag for -Werror where it is a security > feature. e.g. USE=strict-compile-checks You better run a static code analyser, such as the one you can hook up with Travis. It usually points out real security problems such as races, which GCC doesn't do yet, as far as I'm aware. Let alone trigger with -Werror. Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] multilib: allow specifying the subtype of library in get_libname
Just wondering, we have get_libname, get_modname, shouldn't we just
introduce get_linklibname or something instead of trying to overload
get_libname?
The implementation of get_linklibname could be to just call get_libname
for anything but mingw of course.
Fabian
On 03-08-2018 00:09:41 -0500, Marty E. Plummer wrote:
> Signed-off-by: Marty E. Plummer
> ---
>
> On mingw-w64 (and perhaps cygwin and mingw.org), there are two forms of
> non-static libraries. Standard *.dll libraries are for runtime and are
> loaded from %PATH% on windows systems, and are typically stored in
> either /bin or /usr/bin on mingw-w64 cross-toolchain filesystems. Import
> libraries, *.dll.a, are used when linking and live in the ''normal''
> libdirs, eg, /lib, /usr/lib and so on.
>
> A number of ebuilds which otherwise work on mingw-w64 crossdev
> toolchains exhibit failure due to usage of get_libname not being able to
> specify which of the two types are required.
>
> For example, sys-libs/ncurses, uses the following snippet of code:
> ln -sf libncurses$(get_libname)
> "${ED}"/usr/$(get_libdir)/libcurses$(get_libname) || die
> in order to create a 'libcurses.so -> libncurses.so' symlink.
>
> However, on a crossdev-built mingw-w64 toolchain, one will end up with a
> broken 'libcurses.dll -> libncurses.dll' symlink, which should properly
> be a 'libcurses.dll.a -> libncurses.dll.a' symlink, as the symlink here
> is provided to allow linking with -lcurses instead of -lncurses.
>
> eclass/multilib.eclass | 52 ++
> 1 file changed, 48 insertions(+), 4 deletions(-)
>
> diff --git a/eclass/multilib.eclass b/eclass/multilib.eclass
> index 350b6f949d1..6a99f5977ec 100644
> --- a/eclass/multilib.eclass
> +++ b/eclass/multilib.eclass
> @@ -239,26 +239,70 @@ get_exeext() {
> }
>
> # @FUNCTION: get_libname
> -# @USAGE: [version]
> +# @USAGE: --link|--run [version]
> # @DESCRIPTION:
> # Returns libname with proper suffix {.so,.dylib,.dll,etc} and optionally
> # supplied version for the current platform identified by CHOST.
> #
> +# If '--link' argument is passed, the linktime library's suffix is returned,
> +# as in the file that must exist to let `gcc -lfoo foo.c -o foo` to work.
> +# If '--run' argument is passed, the runtime library's suffix is returned.
> +#
> +# In most unix-like platforms the two are identical, however on mingw-w64 the
> +# linktime library has the suffix of '.dll.a' and the runtime library '.dll'.
> +#
> # Example:
> # get_libname ${PV}
> # Returns: .so.${PV} (ELF) || .${PV}.dylib (MACH) || ...
> +# get_libname --link
> +# Returns: .so (ELF) || .dylib (MACH) || .dll.a (PE32) || ...
> get_libname() {
> - local libname
> - local ver=$1
> + local libtype="undefined"
> + local libname opt ver
> + for opt; do
> + case "${opt}" in
> + --link)
> + libtype="link"
> + shift
> + ;;
> + --run)
> + libtype="run"
> + shift
> + ;;
> + *)
> + ;;
> + esac
> + done
> + ver="$1"
> + # general unixy types
> case ${CHOST} in
> *-cygwin*) libname="dll.a";; # import lib
> - mingw*|*-mingw*) libname="dll";;
> *-darwin*) libname="dylib";;
> *-mint*) libname="irrelevant";;
> hppa*-hpux*) libname="sl";;
> *) libname="so";;
> esac
>
> + # wierd mingw-w64 stuff, maybe even cygwin
> + case ${CHOST} in
> + mingw*|*-mingw*)
> + case ${libtype} in
> + link)
> + libname="dll.a" # import library
> + ;;
> + run)
> + libname="dll" # runtime library
> + ;;
> + undefined)
> + eerror "please specify either --link or
> --run to get_libname"
> + eerror "for mingw builds, as there are
> two types of libraries"
> + eerror "on this platform"
> + die
> + ;;
> + esac
> + ;;
> + esac
> +
> if [[ -z $* ]] ; then
> echo ".${libname}"
> else
> --
> 2.18.0
>
>
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: PGP signature
Re: [gentoo-dev] rfc: [QA] Ban policy introduction
Completely agreeing with Sergei, with some additional suggestions: On 28-07-2018 23:14:12 +0100, Sergei Trofimovich wrote: > On Sun, 29 Jul 2018 00:40:18 +0300 > Mikle Kolyada wrote: > > > Hello, > > > > The Gentoo QA team would like to introduce the following policy that > > would be applied to individuals breaking the state and quality of the > > main gentoo.git tree > > > > ( as we do not have this strictly documented yet): > > > > > > > > If recommended > > It's not called "recommended" but "enforced". I agree. If you put penalties on these, they become hard rules. I think that change should be discussed by the council perhaps? > > Gentoo workflow policies are not followed by an > > individual developer > > (e.g make major changes to the widely used eclasses without prior > > discussion on the mailing list or > > commit changes that lead to multiple CI checks failure) > > Here should go exhaustive list of links to the policies to be enforced. At least. And they should be clear and concise. No "common sense" or anything involved for exceptions and the like. In addition, new checks should be introduced to the community and possibly approved by council as to whether being enforced or not. Fabian > > > the standard QA > > procedure is: > > > > 1.) Two warnings granted by QA team, after two independent breakages > > 2.) Revoking the commit access for 14 days > > > > These violations will be evaluated individually by all QA team members. > > Warnings can be revoked, if during 6 months period a developer makes at > > least 20 non trivial changes not producing more breakages. > > > > > > -- > > Sergei > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
On 06-07-2018 13:34:21 +0200, Ulrich Mueller wrote: > - Make creation of a revocation certificate (and storing it in a place > separate from the key) mandatory. What does this really achieve? Or require? Am I supposed to buy or hire a vault now? -- I'm assuming the word "safe" is missing from above sentence. Side observation: You can't check I have the revocation cert, let alone that you can check where it is stored, or if I lost it. Unless it is stored in a Gentoo owned vault or something, such that infra can invoke it on retirement scripts, this seems like unnecessary bureaucracy. Of course we want to encourage anyone to have a revocation cert, and to store it in a safe place somewhere. This is at best subject to means and opportunities of the person in question. In reality it is quite hard to store secrets securely, even more when they don't fit well in the human SSD. Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Developer commit timeline updates
On 24-06-2018 00:36:28 +0200, Michał Górny wrote: > I'd like to just make a short announcement that I've updated > the developer commit timeline [1]. Very nice stats, thanks for that. Suggestion: perhaps this can be cron-jobbed and updated every month or so? In any case, fun to look at. Thanks :) > [1]:https://dev.gentoo.org/~mgorny/dev-timeline.html > [2]:https://dev.gentoo.org/~mgorny/active-devs.html -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: empty directories in ${D}
On 29-03-2018 16:47:51 +0200, Michał Górny wrote: > W dniu czw, 29.03.2018 o godzinie 09∶39 -0500, użytkownik William Hubbs > napisał: > > All, > > > > I just happened to notice the following warning from portage when > > bumping dhcpcd. > > > > > One or more empty directories installed to /var: > > > /var/lib/dhcpcd > > > If those directories need to be preserved, please make sure to create > > > or mark them for keeping using 'keepdir'. Future versions of Portage > > > will strip empty directories from installation image. > > > > If we are going to require emptty directories to be marked with > > keepdir, I think we should hard fail the emerge rather than quietly > > strip the empty directories. If we just strip the directories, this > > will, more than likely, lead to broken packages. In the case of dhcpcd, > > the upstream build system installs the /var/lib/dhcpcd directory, then > > dhcpcd writes to the directory. > > > > Are you saying that dozens of packages should suddenly start failing > for users so that developers would feel more obliged to fix them? > Provided that the packages are still maintained, and it won't be > 'hey, we just made it impossible to install this package, maybe someone > will fix it one day'. I agree, packages shouldn't suddenly start failing. Not during install, not during runtime either. For changes like this EAPIs were invented. Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] New category: app-metrics
Hi! On 20-03-2018 06:21:00 +0100, Manuel Rüger wrote: > Hi everyone, > > I'm planning to add a new category app-metrics, which is mainly (at > least for my own use case) going to be used for prometheus[0] and its > exporters providing endpoints for prometheus. It can be used for other > packages whose _main_ purpose is to provide metrics, transform or > consume them. > > * net-analyzer/prometheus > * app-admin/bind_exporter > * app-admin/elasticsearch_exporter > * app-admin/mongodb_exporter > * app-admin/nginx-vts-exporter > * app-admin/prom2json > * dev-util/buildbot-prometheus Does the graphite stack fit in this too, you think? app-admin/diamond app-admin/collectd app-misc/carbon-c-relay dev-python/carbon net-analyzer/graphite-web www-apps/grafana-bin We might have more packages, but this is from the top off my head. Thanks, Fabian > > In addition, the following packages will drop their prometheus- prefix > during the package move: > > * net-analyzer/prometheus-blackbox_exporter > * net-analyzer/prometheus-node_exporter > * net-analyzer/prometheus-redis_exporter > * net-analyzer/prometheus-snmp_exporter > * net-analyzer/prometheus-uwsgi_exporter > * net-analyzer/prometheus-pushgateway > * net-analyzer/prometheus-alertmanager > > With the growing adoption of prometheus I expect more exporters to be > added (I have five more that I want to add in the near future). > > > Thanks, > > Manuel > > [0] https://prometheus.io > > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-dev] About making mastersync redundant
Hi, I know infra is working on fixing this, so they better focus on that for now. Thank you to infra for doing all the work! When this is resolved, perhaps we should have a discussion on how to make this service redundant? Currently the prefix rsync generation is redundant (== 2 generators) so I'm interested to discuss and see if that would be feasible for gx86 too. Fabian On 19-03-2018 21:13:37 -0400, Alec Warner wrote: > This is just an FYI: [1]https://infra-status.gentoo.org/ > > Hoping to have this fixed in a couple of days. In the meantime you may see > missing snapshots (for emerge webrsync) and no rsync propagation. > > -A > > > > References: >1. https://infra-status.gentoo.org/ > > read_char: errno==EILSEQ; invalid byte sequence for UTF-8: -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] about non-ebuild files in the tree (and verification thereof)
On 28-02-2018 22:08:54 +, Robin H. Johnson wrote: > On Wed, Feb 28, 2018 at 04:10:52PM +0100, Fabian Groffen wrote: > > Hi, > > > > I'm working on a verification implementation of > > https://www.gentoo.org/glep/glep-0074.html and ran into the following > > scenario that I don't know if it's right or wrong: > ... > > Does anybody know or have a pointer to what the policies on files in our > > ebuild dirs actually is? > PMS, 4.3 Package directories: > A package directory may contain other files or directories, whose > purpose is not covered by this specification. Ah, forwards compatibility. > GLEP74 itself makes no determination of files being permitted in a given > directory. > > > Now in a rsync checkout of the Prefix tree, where my own implementation > > also runs the fat manifest creation, this entry is not present, because > > I always believed only metadata.xml, ChangeLog* and *.ebuild files were > > allowed. > I'd say your separate implementation is wrong in this case, but that > file also should not permit at this time. I might change it not to bother about what should be in/out, but just assume it's right as-is. For now it is a nice headsup about something being unexpected. > > Now I'm confused as to whether this is the case or not, I can't find a > > GLEP or anything, but repoman also is as happy as it can be on this odd > > file (I thought it used to complain about stray/unadded files). > I personally think repoman should complain about it because it's weird. I'm sure this particular file was a mistake, that went unnoticed for a very long time. I do feel this should one way or the other not be allowed. Thanks for your insights, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-dev] about non-ebuild files in the tree (and verification thereof)
Hi, I'm working on a verification implementation of https://www.gentoo.org/glep/glep-0074.html and ran into the following scenario that I don't know if it's right or wrong: Consider net-misc/srf-ip-conn-srv % ls files Manifest metadata.xml srf-ip-conn-srv-.ebuild srf-ip-conn-srv.pid % cat Manifest DIST jsmn-35086597a72d.tar.gz 11056 DIST srf-ip-conn-140c9b8a8619.tar.gz 112882 Notice that there is a .pid file in the ebuild dir, checked in git, which even contains what appears to be a pid. It isn't used from the ebuild as far as I can tell. Apart from being odd, this is actually irrelevant. In an rsync checkout of the gentoo-x86 tree, I see in the Manifest for this package a DATA entry for the .pid-file. Hence, verification with both gemato as well as my own implementation succeed because the .pid-file is acknowledged. Now in a rsync checkout of the Prefix tree, where my own implementation also runs the fat manifest creation, this entry is not present, because I always believed only metadata.xml, ChangeLog* and *.ebuild files were allowed. Now I'm confused as to whether this is the case or not, I can't find a GLEP or anything, but repoman also is as happy as it can be on this odd file (I thought it used to complain about stray/unadded files). Does anybody know or have a pointer to what the policies on files in our ebuild dirs actually is? Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-dev] about commits in the future
Please consider commit 2fb923d758749be609c1daab2a72ad4f1ec4c2a9 (use something like git log --pretty=fuller app-emulation/nemu/nemu-1.4.0.ebuild) It was made roughly one day in the future. I'm wondering: 1) is this bad at all? 2) if it is bad (got me confused for another reason) is it technically possible to reject such commits? 3) if 2) should we decide on some clock skew and reject anything which is beyond that? How do others feel about this? Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Bugzilla arch list reordering
On 23-01-2018 12:49:00 +0100, Dirkjan Ochtman wrote: > On Tue, Jan 23, 2018 at 12:46 PM, Michał Górny <[1]mgo...@gentoo.org> wrote: > > > Since neither of the proposals has received any specific reply, I'm not > > sure how to proceed from here. I suppose we can possibly have two lists > > in different order so that people could use whichever they prefer. > > Not sure having two lists in Bugzilla would be an improvement. It would be > nice > if more people expressed a preference, though! I like the "popularity" order, but on top of that, I'd like to group 32/64 bits versions of arches. Basically djc converted into: AMD64 X86 PPC64 PPC ARM64 ARM SPARC64 (?) SPARC ALPHA IA64 HPPA MIPS ... Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-dev] Re: repo/gentoo:master commit in: sys-devel/llvm/
On 19-01-2018 22:21:55 +, Michał Górny wrote:
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5bcc52f0
>
> sys-devel/llvm: Fix implicit dependency on app-arch/libxar
>
> Support conditionally using app-arch/libxar in LLVM 6+, and explicitly
libxar
> @@ -45,6 +45,7 @@ RDEPEND="
> libedit? ( dev-libs/libedit:0=[${MULTILIB_USEDEP}] )
> libffi? ( >=virtual/libffi-3.0.13-r1:0=[${MULTILIB_USEDEP}] )
> ncurses? ( >=sys-libs/ncurses-5.9-r3:0=[${MULTILIB_USEDEP}] )
> + xar? ( app-arch/xar )
xar here
> --- a/sys-devel/llvm/metadata.xml
> +++ b/sys-devel/llvm/metadata.xml
> @@ -20,5 +20,7 @@
> Support querying terminal properties using
> ncurses' terminfo
> Build compiler-rt's sanitizers
> Install the Clang static analyzer
> (requires USE=clang)
> + Support dumping LLVM bitcode sections in
> Mach-O files
> + (uses app-arch/libxar)
I think you mean app-arch/xar everywhere?
Thanks,
Fabian
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: PGP signature
[gentoo-dev] about stable, dev and exp profile status
On 07-01-2018 21:25:28 +0100, Michał Górny wrote: > I'd like to follow this with a more precise proposal. Namely, redefine > the current profile statuses to apply the following: > > a. stable -> fully tested, all depgraph breakages are errors, > > b. exp -> fully tested, all depgraph breakages are warnings, > > c. dev -> developer's playground, not tested. I always was under the impression the following order (and explanation) was the case: stable -> development -> experimental For this reason, e.g. Prefix profiles are (still) experimental, which means they really shouldn't bother non-Prefix people. Prefix users and developers work on an environment where those profiles are promoted to development ones, such that repoman kicks in for their work. (At least that was the idea.) I see you (re-)define dev as "developer's playground", and I wonder if in that case it wouldn't be better to introduce a new one instead? Maybe I'm just one of a few who thinks the order is reversed now. Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list
On 09-01-2018 22:20:56 +0100, Andreas K. Huettel wrote: > If, as a non-developer, you want to participate in a discussion on > gentoo-dev, > - either reply directly to the author of a list mail and ask him/her to > forward your message, > - or ask any Gentoo developer of your choice to get you whitelisted. > > If, as a developer, you want to have someone whitelisted, please comment on > bug 644070 [3]. Similar to Bugzilla editbugs permission, if you are vouching > for a contributor you are expected to keep an eye on their activity. For the record, I do not like this decision. Not just because it puts a burden on developers to become comrel agents. A technical solution like this, doesn't solve the actual problem. Unfortunately this solution destroys much more than it intends to fix, which is a loss for Gentoo. Since this turns -dev into -core-light, I suggest to anyone who doesn't like this direction that we move discussions to -project instead. Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/
On 14-12-2017 14:41:17 +0100, Michał Górny wrote: > W dniu czw, 14.12.2017 o godzinie 13∶56 +0100, użytkownik Fabian Groffen > napisał: > > On 14-12-2017 13:39:18 +0100, Michał Górny wrote: > > > Dnia 14 grudnia 2017 13:21:47 CET, Fabian Groffen > > > napisał(a): > > > > Can we make it a policy to list /what/ QA issues are the justification > > > > for commits like these? A description in the commit message would be > > > > preferred, but a pointer to a location where said issues can be found > > > > would do too. > > > > > > Maintainer-needed is reason enough. If somebody couldn't be bothered to > > > maintain what he committed, why should we bother to list the issues? > > > > > > Using repoman and looking at CI mails is also a good idea. > > > > Obviously for me to learn something, I won't/can't use repoman here. So > > a pointer to said CI mails from the message of the QA commit would be > > nice. > > Last I checked, I wasn't personally responsible for teaching people > ebuild writing 101 while on phone. But here you go (in malformed paste > of ebuild below). You simply replied, and therefore took ownership from QA point of view. I can't help it you do that whilst on the phone. In fact, this is email, so being on the phone is not a good reason to be vague and avoid answering questions in the first place. [snip issues] Thanks, much appreciated. I'm completely convinced now. I'm referring back to my earlier suggestion to include such list or the type of issues found when a drastic commit like the one we discuss is done under the QA flag. It's good to know that the QA issue complaint was valid, and improvements can be made. A final suggestion is to talk to the committer before taking such drastic actions, in a situation where our users aren't endangered. As this one is, in my opinion. There is more problematic stuff in the tree, but teach a man to fish ... next time the problems may be avoided. Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/
On 14-12-2017 14:43:11 +0100, Michał Górny wrote: > Bull-shit. > > Breaking the dependency tree was a *honest* mistake on the person who > reverted this commit. Honestly, so making mistakes is evaluated based on honesty, then still, did Andreas (not a QA member as far as I can see) contact Andrey upfront to establish how honest his mistake was? > Andrey pretty clearly stated that he did this *on purpose*. Andreas also did his commit *on purpose*. Honestly. And he made things worse, now actually *affecting* our users. ... Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/
On 14-12-2017 14:34:51 +0100, Michał Górny wrote: > W dniu czw, 14.12.2017 o godzinie 20∶24 +0700, użytkownik > gro...@gentoo.org napisał: > > If the developers of liblinebreak had not decided to rename their library, > > I could safely bump it from 2.1 to 4.0, in spite of the fact that it is > > maintainer-needed, right? > > Am I personally responsible for their decision to use the new name > > libunibreak? > > No, it wouldn't be fine. We might not even have noticed it if you > at least bothered to update the Manifest. Please stop looking for > excuses and loopholes, and start doing something good for Gentoo. So, breaking the tree, just because someone forgot to set the maintainer field is doing something good for Gentoo? (That's called QA?) https://archives.gentoo.org/gentoo-commits/message/7f34111f0e45f451d5b3a5a58b057d51 Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/
On 14-12-2017 13:39:18 +0100, Michał Górny wrote: > Dnia 14 grudnia 2017 13:21:47 CET, Fabian Groffen > napisał(a): > >Can we make it a policy to list /what/ QA issues are the justification > >for commits like these? A description in the commit message would be > >preferred, but a pointer to a location where said issues can be found > >would do too. > > Maintainer-needed is reason enough. If somebody couldn't be bothered to > maintain what he committed, why should we bother to list the issues? It seems to me you are avoiding the question. There are no issues with the ebuild. It seems like there is just a false claim there are QA issues, and that is used as waiver to remove the package. > Using repoman and looking at CI mails is also a good idea. repoman full (stable) is happy on 8b4ea0f6d2bed140116f69855d1d3100ea0cf020. qa-reports.gentoo.org has nothing to report gentoo-qa@ ML has nothing to report Please list the QA issues: > >On 14-12-2017 12:10:59 +, Andreas Hüttel wrote: > >> Also other QA issues. Apart from that maintainer-needed has nothing to do with Quality of an ebuild, you mentioned it as an QA issue, so I am interested in the "other" QA issues, which seems to suggest 2+ problems in this *ebuild*. For the record, I didn't commit this ebuild. I'm just extremely unhappy about the tiggerhippy response of QA which in my opinion is totally uncalled for, and am extremely worried about the integrity of QA because of seemingly false claims to justify actions. Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/
On 14-12-2017 13:39:18 +0100, Michał Górny wrote:
> Dnia 14 grudnia 2017 13:21:47 CET, Fabian Groffen
> napisał(a):
> >Can we make it a policy to list /what/ QA issues are the justification
> >for commits like these? A description in the commit message would be
> >preferred, but a pointer to a location where said issues can be found
> >would do too.
>
> Maintainer-needed is reason enough. If somebody couldn't be bothered to
> maintain what he committed, why should we bother to list the issues?
>
> Using repoman and looking at CI mails is also a good idea.
Obviously for me to learn something, I won't/can't use repoman here. So
a pointer to said CI mails from the message of the QA commit would be
nice.
Thanks,
Fabian
> >
> >Thanks,
> >Fabian
> >
> >On 14-12-2017 12:10:59 +, Andreas Hüttel wrote:
> >> URL:
> >https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=34e2c43f
> >>
> >> Revert "dev-libs/libunibreak: initial import"
> >>
> >> Please write on the chalkboard 100 times: "I will not add ebuilds as
> >maintainer-needed".
> >> Also other QA issues.
> >> This reverts commit 8b4ea0f6d2bed140116f69855d1d3100ea0cf020.
> >>
> >> dev-libs/libunibreak/Manifest | 1 -
> >> dev-libs/libunibreak/libunibreak-4.0.ebuild | 39
> >-
> >> dev-libs/libunibreak/metadata.xml | 14 ---
> >> 3 files changed, 54 deletions(-)
> >>
> >> diff --git a/dev-libs/libunibreak/Manifest
> >b/dev-libs/libunibreak/Manifest
> >> deleted file mode 100644
> >> index 487fd898f5d..000
> >> --- a/dev-libs/libunibreak/Manifest
> >> +++ /dev/null
> >> @@ -1 +0,0 @@
> >> -DIST libunibreak-4.0.tar.gz 629403 SHA256
> >f7329bef1eb169d3363f040cefcc323cfd0a0bc53290a35a395e1d1adc849539 SHA512
> >43da73f66fabd8fdef444c5a06ad1800464a0aeab590938522d6c19973950a242f2ccc0575a93d10d87bdcf82610452117ac081ddb73f47271a8c2a65897e11c
> >WHIRLPOOL
> >ad71bc5910ca3dff994651022a5a6c6093cd4023852270fa243848f7576287b7cec4ad02a6b27686149491cb52824a93fdb6a6dac4c878d67db2f4041282d300
> >>
> >> diff --git a/dev-libs/libunibreak/libunibreak-4.0.ebuild
> >b/dev-libs/libunibreak/libunibreak-4.0.ebuild
> >> deleted file mode 100644
> >> index f531bb66e38..000
> >> --- a/dev-libs/libunibreak/libunibreak-4.0.ebuild
> >> +++ /dev/null
> >> @@ -1,39 +0,0 @@
> >> -# Copyright 1999-2017 Gentoo Foundation
> >> -# Distributed under the terms of the GNU General Public License v2
> >> -
> >> -EAPI=6
> >> -inherit versionator
> >> -
> >> -DESCRIPTION="Line and word breaking library"
> >> -HOMEPAGE="http://vimgadgets.sourceforge.net/libunibreak/";
> >>
> >-SRC_URI="https://github.com/adah1972/${PN}/releases/download/${PN}_$(replace_all_version_separators
> >'_')/${P}.tar.gz"
> >> -
> >> -LICENSE="ZLIB"
> >> -SLOT="0"
> >> -KEYWORDS="~amd64 ~arm ~ppc ~x86"
> >> -IUSE="doc +man static-libs"
> >> -
> >> -DEPEND="man? ( app-doc/doxygen )"
> >> -RDEPEND="!dev-libs/liblinebreak"
> >> -
> >> -src_prepare() {
> >> - use man && echo -e 'GENERATE_MAN=YES\nGENERATE_HTML=NO' >> Doxyfile
> >> - default
> >> -}
> >> -
> >> -src_configure() {
> >> - econf \
> >> - $(use_enable static-libs static)
> >> - use doc && export HTML_DOCS=( doc/html/. )
> >> -}
> >> -
> >> -src_compile() {
> >> - default
> >> - use man && doxygen || die
> >> -}
> >> -
> >> -src_install() {
> >> - default
> >> - prune_libtool_files
> >> - use man && find "${D}/usr/include" -type f -execdir doman
> >"${S}/doc/man/man3/{}.3" \;
> >> -}
> >>
> >> diff --git a/dev-libs/libunibreak/metadata.xml
> >b/dev-libs/libunibreak/metadata.xml
> >> deleted file mode 100644
> >> index a8bbb441f29..000
> >> --- a/dev-libs/libunibreak/metadata.xml
> >> +++ /dev/null
> >> @@ -1,14 +0,0 @@
> >> -
> >> - >"http://www.gentoo.org/dtd/metadata.dtd";>
> >> -
> >> -
> >> -
> >> - Libunibreak is an implementation of the line breaking and word
> >breaking algorithms
> >> - as described in Unicode Standard Annex 14 and Unicode Standard
> >Annex 29. It is
> >> - designed to be used in a generic text renderer.
> >> -
> >> -
> >> - Generate man pages with doxygen.
> >> - Install html API documentation.
> >> -
> >> -
> >>
> >>
>
>
> --
> Best regards,
> Michał Górny (by phone)
>
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: Digital signature
