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.
>
>
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.
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
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
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
Andrew Savchenko wrote:
>
> Actually for local symmetric encryption this is the best tool I
> know.
What is the advantage over gpg --symmetric?
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
ar
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:
https://bugs.debian.org/cgi-
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 users, the non-symli
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.
>
> And that is the g
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 you cannot prevent
Rich Freeman wrote:
> On Tue, Mar 27, 2018 at 3:34 AM, Martin Vaeth wrote:
>>
>> It is about openness vs. isolation.
>
> I'm pretty sure most developers, myself included, want to welcome
> contributions.
Closing of the mailing list does not sound like that.
>
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 attitude: Does Gentoo welcome contributions
or
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
(according to all
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 than 100 characters.
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. And at least betwe
Michael Orlitzky 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:
>
> https://m
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
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
viewpoint of PMS: It is in the re
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 packages, not about vers
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 that a discrete optimization unde
Ulrich Mueller 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 wrote:
>
>> Rich Fr
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.
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
;;
*) # true case
esac
This
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: That'
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 must not depend
on dyna
Rich Freeman wrote:
>>
>> | "simple" | "fine grained"
>> -++---
>> Overlay | 1 mount| 1 mount
>> -++---
>> Container| 10? bind mounts| 1000? bind mounts
>
> Except it is more like:
>
>
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 tree and bind-mount
Rich Freeman wrote:
> On Sun, Sep 24, 2017 at 4:24 AM, Martin Vaeth wrote:
>> Tim Harder wrote:
>>
>> It is the big advantage of overlay that it is implemented in
>> kernel and does not involve any time-consuming checks during
>> normal file operations.
>
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.
(For containers with thou
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):
With this general synt
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 [...]
Pointing me to the d
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 to a "multiarch" con
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
with Red Hat (concernin
Mike Gilbert wrote:
> On Wed, Aug 2, 2017 at 1:51 PM, Martin Vaeth wrote:
>> 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 st
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
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
Martin Vaeth 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 _enables_ or _disables_
> al
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 encode grounding in SAT
Easy ga
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
occur in the other clau
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? ( !bar graulty bazola )
c
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
eclasses contain some
#
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 regeneration
> - End users using rsync have to fet
Luis Ressel wrote:
> Martin Vaeth 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 that also affect the hardened gcc?
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 far with only one
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 while, but soon was forc
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 mentioned.
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 for a race between
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 should be
installe
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. This is just not re-inventing the
>
ound 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)
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 fetch extra files
> for
Duncan <1i5t5.dun...@cox.net> wrote:
> Martin Vaeth posted on Wed, 31 Aug 2016 18:08:17 + as excerpted:
>
>> Kent Fredric wrote:
>>>
>>> I really wish there was a way to run ancient firefox with security
>>> fixes :(
>>
>> There's
Kent Fredric wrote:
>
> I really wish there was a way to run ancient firefox with security
> fixes :(
There's palemoon
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 months,
because I don't use
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 default /etc/conf.d/hostname
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 recommended implementa
William Hubbs 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/vaeth/firewall-mv/blob
Mart Raudsepp 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-settings and your setting
Kent Fredric wrote:
> On 2 June 2016 at 07:33, Martin Vaeth 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)
>> than to remove a concept which breaks also these 5% and turns
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 posting, it is obvious that
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 effort)
than to remove a
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 by a hack which only
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 should be killed wi
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 appreciate a more configurab
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, perhaps:
a) two with
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_ the factor, of cou
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.
> Considering that this r
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
Hyperbole? Really?
Let's fi
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 rysnc mirror; multip
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 ${_INTEL_PV4} ]] && _INTEL_PV
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 is included
>> in /usr/portage/metadat
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
(omitted some line
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 latter more explici
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 be simpler for future
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 (all?) other LC_* to d
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 user.
Bandwidth and (
Мисбах-Соловьёв Вадим 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 perfect for most use
Мисбах-Соловьёв Вадим 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
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 display the ChangeLog for
a
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,
*essentially* all it ne
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 is changed, all
> eb
Alexander Berntsen 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 regularly surpr
Dan Douglas 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 "*".
Franz Fellner 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 some upstreams consi
Brian Dolbec wrote:
> Martin Vaeth 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 corr
Rich Freeman 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 the mv overlay).
Zac Medico 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 prominent places w
Markos Chandras 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 /etc/portage/package.use
In fact, this i
Alexis Ballier 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
>> >> u
Christopher Head 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 and add a
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 different versions)
Michał Górny wrote:
>
> Have you tried mcpdf?
I heard about it now for the first time.
If I understand correctly, it uses the same library
as pdfTK, only a somewhat later version
(e.g. with improved unicode handling).
The main difference seems to be that it does not insist
on gcj but apparently
Michał Górny wrote:
>
> 2. No gcj support. [...] Not sure if anybody
> actually uses it, and if it is actually useful for anything
The most important consumer is app-text/pdftk
Unfortunately, there is still no replacement for the latter
which works as good, especially if you have tricky pdfs to
p
Mike Gilbert wrote:
>
> FYI, Chromium currently has a ban on using C++ 11 library features.
I do not see how this would help to avoid the problem:
If a function with the same name returns a different type
in c++98 than in c++11, you could only avoid the problem by
not using the function at all (n
Ian Stakenvicius wrote:
> On 20/10/14 06:58 AM, Anthony G. Basile wrote:
>
>> I don't think we'll ever want to support a mixed abi system.
>
> Can we, even? Would it be a mixed-abi system or a multi-abi system?
I am afraid, we *have* to, in the moment when at least one program
adds -std=c++11 or
Anthony G. Basile wrote:
>> Since gcc-4.7 there is a -std=c++11 option, do not use it {+yet+}
>> since it breaks the ABI, resulting in a non-functional system.
>
> Yes. Eventually we'll have to clear the road for this.
Isn't Diego just starting a gcc-4.9 tinderbox run?
It might be worth to try
Nikos Chantziaras wrote:
> In bug 524074 (https://bugs.gentoo.org/show_bug.cgi?id=524074), Joshua
> Kinard mentioned that Gentoo cannot support systems where PAM isn't
> installed.
All my gentoo boxes run without pam from the very beginning
(since many years).
I hope that it will not be necessary
Diamond wrote:
>
> There's no git cp command.
> git mv is just git rm + git add.
I think there is a misunderstanding about how git works.
If you are used to e.g. svn (I suppose with CVS it is similar)
then it makes an important difference whether you use
"svn cp A B" or "/bin/cp A B", because sv
This discussion has now become rather OT and does not belong
to this list. Anyway, since there appear to be some misunderstandings
concerning my previous remarks, I contribute one more post.
Duncan <1i5t5.dun...@cox.net> wrote:
>>> > > > Please don't. Not all communication partners are linux users
1 - 100 of 242 matches
Mail list logo
