[gentoo-dev] Re: Last rites: user.eclass

Mike Gilbert wrote: > On Wed, Oct 19, 2022 at 3:08 PM Martin Vaeth wrote: >> >> Mike Gilbert wrote: >> > user.eclass [...] >> >> It is needed for ebuilds in non-gentoo repositories which cannot >> reserve a fixed number for users and groups. > >

[gentoo-dev] Re: Last rites: user.eclass

Mike Gilbert wrote: > user.eclass has been deprecated for two years. In the gentoo repo, it > is currently only used by acct-group.eclass and acct-user.eclass It is needed for ebuilds in non-gentoo repositories which cannot reserve a fixed number for users and groups.

[gentoo-dev] Re: Please port your packages to Python 3.8

Martin Vaeth wrote: > >> Even if I believe in a metadata angel and if we pretend that the PMS >> requires the metadata to be there, then rebuilding whenever metadata >> changes is still not 100% correct (as you point out), because it often >> rebuilds pointlessly. But t

[gentoo-dev] Re: Please port your packages to Python 3.8

u have to set up quite a bit for that (updating metadata is only one of several steps which you have to do manually in that case). A collection of scripts which do the missing steps is https://github.com/vaeth/portage-postsyncd-mv though I do not know whether they still work. Indeed (as probably

[gentoo-dev] Re: Please port your packages to Python 3.8

Michael Orlitzky wrote: > What's happening is that the PM is using the metadata from the installed > version of the package, rather than the ninja-edited metadata in the > repo (how would it know which ebuilds were edited meaningfully?). The question is easy to answer: It is reasonable to assume

[gentoo-dev] Re: mcrypt status

Andrew Savchenko wrote: > > Actually for local symmetric encryption this is the best tool I > know. What is the advantage over gpg --symmetric?

[gentoo-dev] Re: rfc: why are we still distributing the portage tree via rsync?

Matt Turner wrote: > The ebuild tree is 600MB with rsync and cannot fit on the partition > with git. > > I'd be happy to switch if the space requirements were similar. If one git repacks every few syncs one needs currently about 800 MB. With additionally squashfs (zstd) (+ overlayfs) the full

[gentoo-dev] Re: Current status with openssl-1.1

Lars Wendler wrote: > So, basically openssl is the last big showstopper for openssl-1.1 to > get out of p.mask. s/openssl/openssh/ Another showstopper is net-libs/wvstreams, hence net-dialup/wvdial. BTW, this is a Debian bug open without any comment since April 2017:

[gentoo-dev] Re: [RFC] multiversion ebuilds

R0b0t1 wrote: > On Tue, May 15, 2018 at 11:15 PM, Duncan <1i5t5.dun...@cox.net> wrote: >> >> AFAIK symlinks aren't allowed in the gentoo tree [...] >> >> Tho perhaps that can be reevaluated. [...] > > Cygwin and MSYS(2) are currently mostly supported by Prefix [...] For rsync

[gentoo-dev] Re: Mailing list moderation and community openness

Rich Freeman wrote: > > Certainly. Closing lists won't stop the private abuse, nor is it intended to. > > What it would stop is this particular thread talking endlessly about it. > >> Closing a mailing list >> will not close such a debate; it will then just happen elsewhere. >

[gentoo-dev] Re: Mailing list moderation and community openness

Rich Freeman wrote: > > Fred is a community member. Fred consistently harasses and trolls new > contributors in private. Sure, it's a problem. But not a problem which can be solved by closing the mailing list, in no step of the issue. First of all, this happens in private, so

[gentoo-dev] Re: Mailing list moderation and community openness

Rich Freeman <ri...@gentoo.org> wrote: > On Tue, Mar 27, 2018 at 3:34 AM, Martin Vaeth <mar...@mvath.de> wrote: >> >> It is about openness vs. isolation. > > I'm pretty sure most developers, myself included, want to welcome > contributions. Closing of

[gentoo-dev] Re: Mailing list moderation and community openness

Rich Freeman wrote: > On Tue, Mar 20, 2018 at 7:54 PM, Benda Xu wrote: >> >> It boils down to an attitude of assuming outsiders are good (blacklist >> to ML) or bad (whitelist to ML) by default. ++ This is the most crucial point. It is the general

[gentoo-dev] Re: How to deal with git sources?

Ulrich Mueller wrote: > > I think the conclusion is that github generates tarballs on the fly, > and therefore we cannot rely on them being invariant over a long time. Yes, but with emphasis on _long_ time and theory. In practice this was happening now exactly _once_ in a decade

[gentoo-dev] Re: How to deal with git sources?

NP-Hardass wrote: > > IIRC, it was attributed to > https://github.com/git/git/commit/22f0dcd9634a818a0c83f23ea1a48f2d620c0546 Thanks. That explains why I was not able to produce a difference: It involves only the rather exotic case that a path in a git repository is longer

[gentoo-dev] Re: How to deal with git sources?

Vadim A. Misbakh-Soloviov wrote: > > GH support answered me (in TL;DR version) "that's because we've upgraded git > on *some* of our nodes" (means, some other using older git) That would still require that the "git archive" output would have changed in some recent git versions.

[gentoo-dev] Re: How to deal with git sources?

Michael Orlitzky <m...@gentoo.org> wrote: > On 03/12/2018 04:29 AM, Martin Vaeth wrote: >> This was so many many years ago in the beginning of github. >> This has long been fixed since then. > > Every once in a while they still change. This is from a few weeks ago: >

[gentoo-dev] Re: How to deal with git sources?

Duncan <1i5t5.dun...@cox.net> wrote: > > If I'm recalling correctly a warning posted on this list, repeated calls > to the github tarballing API for the same commit will result in delivery > of tarballs with differing checksums. This was so many many years ago in the beginning of github. This has

[gentoo-dev] Re: SAT-based dependency solver: request for test cases

Michael Lienhardt wrote: > the criteria list you gave (maybe it's in the PMS) I doubt that it is in PMS, and IMHO it also does not belong there: As long as the result configuration is valid (no collisions or unresolvable loops) all should be equally fine from the

[gentoo-dev] Re: SAT-based dependency solver: request for test cases

Michał Górny wrote: >> >> d. In || ( ... ) clauses the left-most packages should be preserved. s/preserved/preferred/ > you've missed the most important point: we want to prefer > the newest version, whenever possible > ;-). Yes, you are right: I had thought only about

[gentoo-dev] Re: SAT-based dependency solver: request for test cases

Michael Lienhardt wrote: > > ad-hoc fixes and tweaks that can hardly be encoded into SAT constraints. The main difficulty which I see is that one does not want only _some_ solution, but among all solutions one which optimizes certain quantities. So it seems to me

[gentoo-dev] Re: News Item: Portage Dynamic Deps

Ulrich Mueller <u...@gentoo.org> wrote: > This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > --pgp+signed++Zg8D+I6sgRUw0D > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > >>>>>> On Wed, 24 Jan 2018, Martin Vaeth wro

[gentoo-dev] Re: News Item: Portage Dynamic Deps

Rich Freeman wrote: > > It would already be broken on any PMS-compliant package manager No, it is solely the interpretation of the package manager. PMS does not specify what information is stored in /var/db or how that information is used.

[gentoo-dev] Re: [PATCH] linux-mod.eclass: IUSE default support for MODULES_OPTIONAL_USE

Robin H. Johnson wrote: > That is counter-intuitive for somebody that puts > MODULES_OPTIONAL_USE_IUSE_DEFAULT=0 > Or tries to otherwise have it unset. What I usually do is: case ${MODULES_OPTIONAL_USE_IUSE_DEFAULT:-n} in [nNfF]*|[oO][fF]*|0|-) # false case ;; *) #

[gentoo-dev] Re: cmake + ninja vs autotools

Georg Rudoy <0xd34df...@gmail.com> wrote: > 1. Doing a full clean build [..] > the speed of make or ninja is hugely offset by the compilation speed, > and their overhead is negligible. It depends on the definition of negligible. For huge projects like boost or chromium it is several minutes:

[gentoo-dev] Re: cmake + ninja vs autotools

William L. Thomson Jr. wrote: > > case ${CMAKE_MAKEFILE_GENERATOR} in > emake) > DEPEND="sys-devel/make" > ;; > ninja) > DEPEND="dev-util/ninja" > ;; This is broken: Static metadata like DEPEND

[gentoo-dev] Re: An example overlayfs sandbox test

Rich Freeman wrote: >> >> | "simple" | "fine grained" >> -++--- >> Overlay | 1 mount| 1 mount >> -++--- >> Container| 10? bind mounts| 1000? bind mounts > > Except it is more

[gentoo-dev] Re: An example overlayfs sandbox test

Rich Freeman wrote: >> >> For containers, at least a dozens of binds are minimally required >> (/usr /proc /sys /dev ...). > > I wouldn't be surprised if it works with a single bind mount with > /proc and /dev and so on mounted on top of that. Either you start with a writable

[gentoo-dev] Re: An example overlayfs sandbox test

Rich Freeman <ri...@gentoo.org> wrote: > On Sun, Sep 24, 2017 at 4:24 AM, Martin Vaeth <mar...@mvath.de> wrote: >> Tim Harder <radher...@gentoo.org> wrote: >> >> It is the big advantage of overlay that it is implemented in >> kernel and does not invol

[gentoo-dev] Re: An example overlayfs sandbox test

Tim Harder wrote: > On 2017-09-23 19:59, Rich Freeman wrote: >> A read-only container > > I doubt bind mounts will scale > > As has been mentioned before, a different way would be to write some > sort of FUSE fs The problem with both, containers and FUSE, is performance.

[gentoo-dev] Re: [PATCH] eapi7-ver.eclass: 'Early adopter' version of EAPI 7 version manip

Michał Górny wrote: > +# 1.2b-alpha4 -> 1 . 2 '' b - alpha '' 4 Is this only to explain the syntax or are there plans to extend the allowed versions for pms? There is a reason why pms currently does not allow "-" as separators within versions (with the exception of -r):

[gentoo-dev] Re: New SYMLINK_LIB=no migration tool for review

Michał Górny wrote: > > I have been running such a layout for over a year. [...] Thanks for clarifying that this already was discussed. Obviously, I was not aware about this discussion, and perhaps I was not the only one. > instead of waking up last-minute to redesign [...]

[gentoo-dev] Re: New SYMLINK_LIB=no migration tool for review

Mike Gilbert wrote: > Debian puts 64-bit libs in /lib/(host) Yes, this is somewhat weird: They have /lib/i386-linux-gnu/ and /lib/x86_64-linux-gnu/ but anyway they use /lib32 instead of e.g. /lib/i686-linux-gnu/ Their reasons for this are mysterious to me. > Migrating Gentoo

[gentoo-dev] Re: New SYMLINK_LIB=no migration tool for review

Michał Górny wrote: > > 'No mainstream' as you claim it doesn't mean it's fine to invent yet > another completely incompatible solution. As I understand, the compatibility with Debian might be increased (keeping /lib32), at the cost of slightly decreasing the compatibility

[gentoo-dev] Re: New SYMLINK_LIB=no migration tool for review

Mike Gilbert <flop...@gentoo.org> wrote: > On Wed, Aug 2, 2017 at 1:51 PM, Martin Vaeth <mar...@mvath.de> wrote: >> If this already was discussed then sorry for the noise: >> >> What is the rationale for merging lib32 with lib? >> Wouldn't it be somewha

[gentoo-dev] Re: New SYMLINK_LIB=no migration tool for review

Michał Górny wrote: > > What are your thoughts? If this already was discussed then sorry for the noise: What is the rationale for merging lib32 with lib? Wouldn't it be somewhat cleaner to have a completely split structure lib64 lib32 libx32 (possibly) lib

[gentoo-dev] Re: lua upgrade plan

Duncan <1i5t5.dun...@cox.net> wrote: >> >> http://article.gmane.org/gmane.comp.lang.lua.general/18519 > > That reply is from 2005 and is apparently specific to (32-bit) x86's Even more is true! The only argument there concerns pic. But most distributions (hopefully also gentoo in a not-so-distant

[gentoo-dev] Re: [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

Martin Vaeth <mar...@mvath.de> wrote: Let me be more precise to avoid misunderstandings: > For the "standard" 2SAT case, one first determines the strongly > connected components in the implication graph (linear time). > Then for each such component one either _ena

[gentoo-dev] Re: [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

Ciaran McCreesh wrote: >> For 2SAT, there are linear time algorithms. > > "foo? ( bar )" does not encode as "( !foo \/ bar )" It does (see below). More precisely, at first it encodes as an arrow foo -> bar in the implication graph. > Good luck figuring out how to

[gentoo-dev] Re: [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

Michał Górny wrote: > b? ( a ) c? ( b ) d? ( c ) e? ( d ) ... As written in another posting: This is 2SAT. 2SAT is solvable in linear time. To get a hard example you have to use several 3SAT clauses, i.e. || ( ... ) with 3 (or more) entries (and all of these entries must

[gentoo-dev] Re: [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

Alexis Ballier wrote: > > I think we should really try to find a sub-exponential solution Most examples mentioned earlier were actually 2SAT, i.e., they are only of the form foo? ( bar ) (possibly with negations) or can be easily reduced to that. E.g. ^^ ( foo bar ) foo? (

[gentoo-portage-dev] Re: [PATCH] man/portage.5: document -* in profile "packages" files (bug 610670)

Zac Medico wrote: > > The -* affects both Thanks. Maybe this could be pointed out more explicit in the documentation patch you suggested: I have asked, because the text was not completely clear to me. > I don't think we need a -** token. What do you think? I do not need

[gentoo-portage-dev] Re: [PATCH] man/portage.5: document -* in profile "packages" files (bug 610670)

Zac Medico wrote: > The -* wildcard has been supported since portage-2.3.4, but it was > not explicitly documented. Shouldn't this be -** to remove all _system_ packages? Or does -* really mean to remove only _profile_ packages? Or does -* remove all profile _and_ system

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

Michał Górny wrote: >> If this is such a big problem, maybe we should be discussing how to >> redesign things to improve it? > > Like, by not using eclasses and instead inlining all the stuff? There are other ways. One way to mitigate the problem might be to require that

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

Kent Fredric wrote: > Fabian Groffen wrote: > >> Hardware or more deltas to >> download by users? Just wondering. > > Both. > > - End users using git end up having to do massive metadata-updates. > - Infra needs to have massive hits to metadata

[gentoo-dev] Re: [RFC] News item: GCC 6 defaults to USE="pie ssp"

Luis Ressel <ara...@aixah.de> wrote: > Martin Vaeth <mar...@mvath.de> wrote: > >> For instance, you cannot even compile the kernel without special >> patches (which disable pie) if you use a gcc which default-enables >> pie. > > Now I'm curious. Wouldn't t

[gentoo-dev] Re: [RFC] News item: GCC 6 defaults to USE="pie ssp"

Hanno Böck wrote: > > I could add my voice that I ran pie by default for a while I can confirm that the situation apparently has changed drastically since my last attempt. My previous assertion is no longer valid: Currently, I recompile world on x86 system with default pie, so

[gentoo-dev] Re: [RFC] News item: GCC 6 defaults to USE="pie ssp"

Hanno Böck wrote: > I really think it's about time that pie becomes the default in Gentoo. Although I agree from a security perspective, I must warn that this is not realistic, currently: I am using gcc-6 since ages and tried to run a desktop with default pie for quite a

[gentoo-dev] Re: Requirements for UID/GID management

Christopher Head wrote: > > Are you sure that said utility isn't simply chown --from=? As usual, I just checked the POSIX standard and not the GNU extensions before posting ;) I did now a quick audit of the coreutils-8.25 source: It seems to be safely implemented in the way I

[gentoo-dev] Re: Requirements for UID/GID management

Michael Orlitzky wrote: > > The fact that all permission and ownership information is shared is > precisely the problem. When you change ownership of the hardlink (which > you'll never know is a hardlink), you change ownership of /etc/shadow. Why should this be a problem except

[gentoo-dev] Re: tmpfiles virtual

Rich Freeman wrote: > > If systemd-tmpfiles can work when systemd isn't running According to a brief test (not very exhaustive), this seems to work, though I did not investigate whether it requires that e.g. dbus is running. Without entering the discussion _how_ an init-script

[gentoo-dev] Re: tmpfiles virtual

Rich Freeman wrote: > On Thu, Nov 17, 2016 at 3:07 PM, Ian Stakenvicius wrote: >> >> Realistically, software should ensure the directories it needs at >> runtime are created through their own code, but upstreams are lazy [...] > > This isn't really being lazy.

[gentoo-portage-dev] Re: [PATCH] [sync] Run `git update-index --refresh` when doing shallow pulls

Michał Górny wrote: > + if quiet: # -q needs to go first > + update_index_cmd.append('-q') The options -q --unmerged (which are implicitly passed by "git status") are not only to suppress verbosity: The git-update-index man page

[gentoo-dev] Re: grub-2 configuration

-program, etc. It can be found here: https://github.com/vaeth/grub-cfg-mv/ Library and exmample can also be installed by portage: Package sys-boot/grub-cfg-mv in the mv overlay (over layman)

[gentoo-dev] Re: Building a portage repo?

Michał Górny wrote: >> >>and subsequently egencache should give me the same type of portage tree >>that is currently officially distributed to users? > > Then remanifest, egencache with all options. You will also need to > include additional repositories for news, glsas and

[gentoo-dev] Re: chromium-54 needs ffmpeg-3.0.1

Duncan <1i5t5.dun...@cox.net> wrote: > Martin Vaeth posted on Wed, 31 Aug 2016 18:08:17 + as excerpted: > >> Kent Fredric <ken...@gentoo.org> wrote: >>> >>> I really wish there was a way to run ancient firefox with security >>> fixes :( >

[gentoo-dev] Re: chromium-54 needs ffmpeg-3.0.1

Kent Fredric wrote: > > I really wish there was a way to run ancient firefox with security > fixes :( There's palemoon

[gentoo-dev] Re: chromium-54 needs ffmpeg-3.0.1

Duncan <1i5t5.dun...@cox.net> wrote: > >> Alexis Ballier wrote: >> >> As opposed to "roll out ffmpeg 3 prematurely" which will break *more* >> than just firefox. > > Umm... you mean chromium, not firefox, correct? I also think so. I have unmasked ffmpeg-3 since several

[gentoo-dev] Re: rfc: /etc/hostname on gentoo

William Hubbs wrote: > > I am planning to change the logic in /etc/init.d/hostname so that if > /etc/hostname exists, the first word out of that file will be used as > the hostname rather than any setting in /etc/conf.d/hostname. You could also make the content of the

[gentoo-dev] Re: rfc: /etc/init.d/modules loading modules defined in files

Mike Gilbert wrote: >> >> modules=$(sed -n -e '/^[^;#]/p' /etc/modules-load.d/*.conf \ >> /usr/lib/modules-load.d/*.conf 2>/dev/null || : ) > > This simple implementation does not follow the precedence rules > documented in modules-load.d(5). I didn't mean it as the

[gentoo-dev] Re: rfc: /etc/init.d/modules loading modules defined in files

William Hubbs <willi...@gentoo.org> wrote: > > but I'm open to making the behaviour compatible > with what systemd does Since openrc already supports tmpfiles.d, support for modules-load.d would be natural. In fact, this is already done for quite a while in https://github.com/va

[gentoo-dev] Re: [RFC] Masterplan for solving LINGUAS problems

Mart Raudsepp <l...@gentoo.org> wrote: > Ühel kenal päeval, K, 01.06.2016 kell 20:24, kirjutas Martin Vaeth: >> Gentoo has chosen this name so that as a side effect of setting >> USE=linguas_* you also get a correct LINGUAS variable exported >> (according to the USE

[gentoo-dev] Re: [RFC] Masterplan for solving LINGUAS problems

Kent Fredric <kentfred...@gmail.com> wrote: > On 2 June 2016 at 07:33, Martin Vaeth <mar...@mvath.de> wrote: >> >> I prefer to have at least 5% of the ebuilds working and the other >> being fixable (if their maintainers want to spend the effort) >> tha

[gentoo-dev] Re: [RFC] Masterplan for solving LINGUAS problems

Raymond Jennings wrote: > > I'd honestly as a minor issue like ot know why we called it linguas in the > first place. > [...] > I think though I should also point out...don't we already have existing > ebuilds that expose LINGUAS options in their USE flags? >From this

[gentoo-dev] Re: [RFC] Masterplan for solving LINGUAS problems

Michał Górny wrote: > > If more than 95% of ebuilds are broken, this proves that a concept is > broken. > > Well, feel free to live in your fairy land. I prefer to have at least 5% of the ebuilds working and the other being fixable (if their maintainers want to spend the

[gentoo-dev] Re: [RFC] Masterplan for solving LINGUAS problems

Michał Górny wrote: > > Do you have any numbers on how many ebuilds were exactly being fixed? > And how many were broken in the process because someone failed to > update linguas_*? Broken ebuilds are a reason to fix the ebuilds, but not a reason to replace a working concept

[gentoo-dev] Re: [RFC] Masterplan for solving LINGUAS problems

Michał Górny wrote: >> >>Therefore, I suggest to put this line in l10n.eclass >>(perhaps with a mechanism to avoid it for some exceptional packages >>which have to treat LINGUAS differently.) >>This way, none of these ebuilds inheriting l10n needs to be patched. > > This eclass

[gentoo-dev] Re: [RFC] Masterplan for solving LINGUAS problems

Michał Górny wrote: > > 1. Get approval on INSTALL_MASK GLEP [1] and finish implementing it > in Portage. As already mentioned by some, INSTALL_MASK is something else than LINGUAS, because LINGUAS involves also files which are generated by the build system. Although I

[gentoo-dev] Re: Bug #565566: Why is it still not fixed?

Patrick Lauer wrote: > > Notice the --whole-file part there. Are there perhaps plans to remove this? Before the reversed ChangeLogs, this option was useful, but perhaps now removing it would really lower the traffic? One would have to make a bunch of tests over 1-2 months,

[gentoo-dev] Re: Bug #565566: Why is it still not fixed?

Rich Freeman wrote: > > Clearly it doesn't increase by a factor of 1 every year The yearly increase of the factor is rather precisely 1: According to current data, it is .95, see below. With xz compression for squashfs, it is even 1.4! (Note: increase _of_ the factor, not _by_

[gentoo-dev] Re: Bug #565566: Why is it still not fixed?

Rich Freeman wrote: >> >> And currently the git history is still almost empty... >> > > If you want pre-migration history you need to fetch that separately. How? Neither on gitweb.gentoo.org nor on github I found an obvious repository with this data. > It is about 1.7G. >

[gentoo-dev] Re: Bug #565566: Why is it still not fixed?

Gordon Pettey wrote: >> >> Already now this means that you need 2 (or already 3?) times the >> disk space as for an rysnc mirror; multiply all numbers by 4 >> if you used squashfs to store the tree. [...] > > Or, in 2-3 years, maybe people will stop with the hyperbole

[gentoo-dev] Re: Bug #565566: Why is it still not fixed?

Luis Ressel wrote: > > That would require a local git clone. And that's exactly what those who > still want Changelogs are trying to avoid. You need even a deep git clone with full history. Already now this means that you need 2 (or already 3?) times the disk space as for an

[gentoo-dev] Re: RFC: intel-sdp-r1.eclass

Justin Lecher (jlec) wrote: >>> [[ -n ${_INTEL_PV4} ]] && _INTEL_PV+="${_INTEL_PV4}-" >>> [[ -n ${_INTEL_PV1} ]] && _INTEL_PV+="${_INTEL_PV1}" >>> [[ -n ${_INTEL_PV2} ]] && _INTEL_PV+=".${_INTEL_PV2}" >>> [[ -n ${_INTEL_PV3} ]] && _INTEL_PV+=".${_INTEL_PV3}" >>> [[ -n

[gentoo-dev] Re: GLEP 67 is in, please update your metadata.dtd!

Mike Gilbert wrote: > On Mon, Jan 25, 2016 at 11:31 AM, Luis Ressel wrote: >> >> I might be asking this for a second time, but why does repoman download >> the metadata.dtd at all? If one fetches from >> git://../gentoo-mirror/gentoo (or via rsync, afaik) it

[gentoo-dev] Re: [PATCH] readme.gentoo-r1.eclass: Do not inherit eutils.

Michał Górny wrote: >> if [[ -n "${DISABLE_AUTOFORMATTING}" ]]; then >> echo "${DOC_CONTENTS}" > "${T}"/README.gentoo || die >> else >> echo -e ${DOC_CONTENTS} | fold -s -w 70 \ >> | sed 's/[[:space:]]*$//' > "${T}"/README.gentoo

[gentoo-dev] Re: EAPI 6 portage is out!

Michał Górny wrote: > > commit EAPI 6 ebuilds to ~arch. For an overlay maintainer like me, it is not reasonable to bump eclasses locally. So please bump the relevant eclasses timely, most notably (AFAICS these needs just extending the check; perhaps a *negative* check would

[gentoo-dev] Re: [EAPI 7] The future goals for PORTDIR, ECLASSDIR and... LICENSEDIR?

Ian Stakenvicius wrote: > '$(get_eclasspath [name])' or $(get_licensepath [name]) or the like Since we are at a brainstorm level: How about filling associative arrays instead? This would BTW also provide the names of the master repositories (although one could perhaps do the

[gentoo-dev] Re: Revise EAPI 6? (was: [RFC] ban use of base-4 casemods in ebuilds due to locale collation instability)

Jason A. Donenfeld wrote: > > I'd be in favor of full-on LC_ALL=C. Setting LC_ALL seems wrong as it is meant as a quick hack and should not be relied on by a "generic" tool like portage. Better define to *unset* LC_ALL (remembering the previous value, see below) and to set

[gentoo-dev] Re: ChangeLog

hasufell wrote: > > git clone --depth=1 The only reasonable option for the gentoo user (not for the gentoo developer) if he does not have megabytes to waste on his harddisk (which probably many users don't), if you want to *force* him to use git. Now how can this user

[gentoo-dev] Re: ChangeLog

Rich Freeman wrote: > > What discussion or decision is necessary? > What is needed is for those who want changelogs > to fix the bug The bug can only be fixed by somebody who knows the details how the rsync mirrors are set up. As mentioned in the discussion in bug 561454,

[gentoo-dev] Re: ChangeLog

Rich Freeman wrote: > > Keep in mind that "resources" is a vague term [...] > disk io and CPU to sync [...] For syncing, I think these latter resources are less important, because they influence only the *time* of a syncing action, which is normally not so important for the

[gentoo-dev] Re: ChangeLog

Мисбах-Соловьёв Вадим wrote: > >> Now how can this user display the ChangeLog for >> a certain package? > ``` > git log -- pkg-category/pkg-name/ You removed the crucial part of my posting: >> git clone --depth=1

[gentoo-dev] Re: ChangeLog

Мисбах-Соловьёв Вадим wrote: >> Perhaps there is a better choice of distribution for you if you are. > > Or you can just... use rsync. Or emerge-webrsync, emerge-delta-webrsync or squashdelta (I strongly hope that the latter will be available again in some future - IMHO it is

[gentoo-dev] Re: Dynamic dependencies

Rich Freeman wrote: > > Proposal 3a might be: Anytime an RDEPEND in an eclass is changed, the > eclass must be revisioned unless all ebuilds in the gentoo repository > will continue to work correctly with the old RDEPEND. > Proposal 4a might be: Anytime an RDEPEND in an eclass

[gentoo-dev] Re: QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server

Alexander Berntsen berna...@gentoo.org wrote: - -1. The way dedicated is used in games ebuilds is a very established term that all gamers know and expect to behave in a specific way. This will mess with our users. How do you know what the users know and expect? When installing a game, I was

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog kde5-functions.eclass kde5.eclass

Dan Douglas orm...@gmail.com wrote: for x in *; do [[ -e $x ]] || continue ... done You should also test for $x not being a symlink. Otherwise you can miss the corner case that you have a dead/unresolvable symlink called *.

[gentoo-dev] Re: RFC: using Ninja in more CMake-based packages

Franz Fellner alpine.art...@gmail.com wrote: IMHO a working build system always is better than a fast but potentially broken one :) Meanwhile, it is not so clear which of the two systems is more likely the potentially broken one: According to some of the mentioned bugs, it appears to me that

[gentoo-dev] Re: News item review: SquashDelta syncing support

Brian Dolbec dol...@gentoo.org wrote: Martin Vaeth mar...@mvath.de wrote: However, currently this does not play nicely with squashdelta: You have to undo the mounting of squashdelta and have to use different command (e.g. squashmount) afterwards. No, that is not correct [...] 2) /etc

[gentoo-dev] Re: News item review: SquashDelta syncing support

Rich Freeman ri...@gentoo.org wrote: Downsides include: 2. Impossible to tweak ebuilds without setting up an overlay. This might be annoying for devs/etc. It is still possible to setup a read-writable portage tree (using overlayfs/aufs/unionfs-fuse/... e.g. using the squashmount tool from

[gentoo-portage-dev] Re: Dynamic USE dependencies

Rich Freeman ri...@gentoo.org wrote: Keep in mind that keeping track of past decisions made by portage does not require user-editable config files in /etc. Yes, but you might not always agree with portage's decisions, and the resolution might be non-unique. Although the user might always

[gentoo-portage-dev] Re: [PATCH] Enable cgroup, ipc-sandbox network-sandbox by default

Michał Górny mgo...@gentoo.org wrote: All the features degrade gracefully when the relevant kernel features are not available. In conncetion with some old version of rescuecd, and fetching files, one can run into troubles with FEATURES=cgroups

[gentoo-portage-dev] Re: Dynamic USE dependencies

Rich Freeman ri...@gentoo.org wrote: 1. They can STILL populate /etc/portage/package.use 2. They could manually install a package with one-time specified USE Why do we need another mechanism to control what flags a package gets installed We do not *need* it. By why reject it if you can

[gentoo-portage-dev] Re: Dynamic USE dependencies

Rich Freeman ri...@gentoo.org wrote: On Sun, Apr 5, 2015 at 11:47 AM, Martin Vaeth mar...@mvath.de wrote: One suggestion around this problem would be to use different directories for these two types of use-flags, say package.use and package.use.needed. I still think we need a better long

[gentoo-portage-dev] Re: Dynamic USE dependencies

Zac Medico zmed...@gentoo.org wrote: On 04/02/2015 09:32 AM, Rich Freeman wrote: Out of curiosity, what is keeping us from having USE flag dependencies handled dynamically, in the same way that package dependencies are? It's already able to adjust USE automatically via autounmask support.

[gentoo-dev] Re: Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg

Zac Medico zmed...@gentoo.org wrote: Also, portage-2.2.16 will have support for special USE_EXPAND syntax in package.use I knew from reading portage-dev ml Actually, I am hoping that the introduction of the feature be taken as an opportunity to document USE_EXPAND better as a whole on some

[gentoo-dev] Re: Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg

Markos Chandras hwoar...@gentoo.org wrote: we bloat the make.conf file with new variables every now and then Although it often makes sense to set USE_EXPAND-variables in make.conf, it is not *necessary* to do it in this way and in this file: It can also happen in USE or in

[gentoo-dev] Re: Moving CPU flags into USE_EXPAND

Christopher Head ch...@chead.ca wrote: All that requires is knowing the names, though; it would be fine if no package actually uses the feature yet. ++ More precisely: When changing the names anyway, IMHO it would be a very good idea to follow the convention of the flag names in /proc/cpuinfo

[gentoo-dev] Re: Moving CPU flags into USE_EXPAND

Alexis Ballier aball...@gentoo.org wrote: More precisely: When changing the names anyway, IMHO it would be a very good idea to follow the convention of the flag names in /proc/cpuinfo and add all flags supported there as possible USE-flags, no matter, whether they are currently used in

[gentoo-dev] Re: sys-devel/gcc::mgorny up for testing

viv...@gmail.com viv...@gmail.com wrote: - The project only has 20 commit, last one 8 months ago https://github.com/m-click/mcpdf.git The project is just a few lines anyway: merely a wrapper to the library. All the work happens in the itext library which AFAIK is the same project (in

  1   2   3   >