f the headers seems to me a half solution that breaks a lot and
doesn't solve the problem either.
Paul
Btw embedded has already different way to archive the same result (ok,
removing headers and static libs after isn't really the cleanest
solution but works fine)
lu
--
Luca
til there is a proper replacement for this handling,
the Gentoo sources archive, we really shouldn't be putting the data in
non-permanent locations, the team should, nowadays, be on the same page
as me on this."
I read it as: before infra was against, now they should be on the same
page -> thus agree.
my 2 eurocents
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
On 03/23/2011 04:17 PM, Tomáš Chvátal wrote:
> And yep i think we should provide both options if they really continue
> to evolve (seems like libav is done by everyone and ffmpeg by vlc guys).
VLC is just graciously hosting the git...
lu
--
Luca Barbato
Gentoo/linux
http://dev.gent
On 5/17/11 6:57 PM, William Hubbs wrote:
All,
I think we should support the /run directory [1] [2]. The issue is
that there are at least two packages, udev and dracut, in gentoo, which
support the use of this directory. Support for it is being worked on in
openrc, and systemd will use it once it
On 5/20/11 6:54 PM, Mike Pagano wrote:
On Friday 20 May 2011 04:58:12 Luca Barbato wrote:
On 5/17/11 6:57 PM, William Hubbs wrote:
That shouldn't be read as endorsing the peculiar and conceptually broken
init replacement called systemd.
lu
Just curious, would you mind elaborating on
support burden for no gain...
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
On 9/15/11 1:33 PM, Joost Roeleveld wrote:
On Thursday, September 15, 2011 09:31:45 PM Luca Barbato wrote:
On 15/09/2011 16:33, Joost Roeleveld wrote:
Hi Devs,
Not sure if you are aware of the discussions on the gentoo-user list
about the upcoming change where systemd and udev require /usr to
sr so the
new and grand udev can do all its stuff...
Going around upstream asking to provide init.d files themselves might be
useful btw.
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
On 11/5/11 1:58 AM, Kacper Kowalik wrote:
Hi,
I'd like to ask that we enable verbose building by default. I have
cmake-utils.eclass in mind, because it's dead easy there, but there's a
lot of packages that support things like "make V=1" or "make VERBOSE=1" too.
I've seen too many bugs reports to
On 11/7/11 3:58 PM, Samuli Suominen wrote:
On 11/07/2011 11:57 AM, Diego Elio Pettenò wrote:
Il giorno dom, 06/11/2011 alle 19.37 +0200, Samuli Suominen ha scritto:
With bug 365121 we don't really have a working compiz in Portage
anymore
for quite a while.
I'm using it with USE=-dbus ... mayb
On 2/11/12 2:00 PM, Fabio Erculiani wrote:
I think this is not the first time it's been discussed here, but maybe
I'm wrong.
Other distros associate a more user-friendly package name (application
name) to packages.
Say, they bind libreoffice-writer to "LibreOffice Writer" in package metadata.
Ho
On 31/07/2018 09:35, Dirkjan Ochtman wrote:
> On Mon, Jul 30, 2018 at 5:02 PM gibix wrote:
>
> As far as I know, the Rust ecosystem is largely bimodal: stuff is either
> compatible with stable and later, or it works only on nightly. It seems
> very rare that code is actually tied to a particular
On 12/09/2018 12:38, Andreas Sturmlechner wrote:
> Is there anyone still working on libav support? It appears to me that
> transition[1] and stabilisation[2] trackers are stuck for a long time without
> activity. Missing libav-12 stabilisation means that in several stable
> packages, USE=libav i
On 13/10/2018 11:28, Michał Górny wrote:
> Two cases are unclear:
>
> media-video/libav: Use the external opus library for encoding and
> decoding.
> virtual/ffmpeg: Use the external opus library for encoding and
> decoding.
>
>
They should be renamed libopus I'm afraid
On 14/12/2018 21:00, Craig Andrews wrote:
Since ROC will eventually upstream all of it's work, (2) is ideal - but
I have no idea what the timeline on that upstreaming effort may be, and
I can't find anything that gives a hint.
I'd rather go with 1 and update the deps once llvm upstream gets th
On 06/06/2019 07:06, Andreas K. Huettel wrote:
Hi all,
for the package maintainers among you, here's the list of remaining EAPI=2
packages. Please help getting the number down to zero soon!!!
Cheers,
Andreas
sys-apps/powerpc-utils-1.1.3.18-r2
This is ancient in many different ways :) Anybody
On 06/06/2019 09:05, Matt Turner wrote:
On Wed, Jun 5, 2019 at 11:39 PM Agostino Sarubbo wrote:
On giovedì 6 giugno 2019 08:25:54 CEST Luca Barbato wrote:
Anybody has hardware to test it?
I can do it on timberdoodle.
The issue is that the package is for "OldWorld" Macs (like
On 23/11/2019 16:48, Michał Górny wrote:
Hello,
Some aspects of the current design of python-single-r1 are gross hack.
I'd like to discuss potential alternatives to them.
Preamble
For the purpose of this mail, let's establish two terms.
'Single' will refer to packages allowing the us
On 03/01/2020 23:34, Michael 'veremitz' Everitt wrote:
On 03/01/20 10:36, David Seifert wrote:
On Thu, 2020-01-02 at 21:54 +, Michael 'veremitz' Everitt wrote:
On 02/01/20 21:08, Michał Górny wrote:
On Thu, 2020-01-02 at 21:15 +0100, Ulrich Mueller wrote:
On Thu, 02 Jan 2020, Michał Górny
On 03/01/2020 12:52, Jason A. Donenfeld wrote:
A user reported that when compiling modules for a system with a 64-bit
kernel and a 32-bit userland, there were linker errors. This patch here
is an attempt to fix that by making sure that we always use the kernel
ABI when giving target build paramet
On 09/02/2020 22:16, Michael 'veremitz' Everitt wrote:
It is left as an exercise for the reader, who is transgressing here...
I warned you [once][1] that this kind of banter is not welcome.
This is the second warning.
lu
[1]: https://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg87818.
On 09/12/14 17:34, Michał Górny wrote:
I'm all for keeping it simple. However, backwards compatibility makes
it hard to keep things simple. I'd love to do, say, metadata.yml
supporting stuff like:
- maintainer: f...@gentoo.org, b...@gentoo.org
- maintainer:
- name: Foo Bar
email: f...@
On 16/01/15 18:30, Jan Matejka wrote:
> On Fri, 07 Nov 2014 10:49:13 +0100
> Luca Barbato wrote:
>
>> On 07/11/14 06:06, Harsh Bhatt wrote:
>
>> Also make might enjoy improvements.
>
> shake?
Anything written in haskell tend to be impractical to deploy.
tup mana
On 20/01/15 03:07, Michael Orlitzky wrote:
On 01/19/2015 05:44 PM, Pacho Ramos wrote:
I agree with your suggestion but I would prefer the Remi's approach of
letting people to know if they want "ffmpeg" or "libav", otherwise it is
not so obvious to know what disabling/enabling one of that USE fl
On 17/01/15 16:03, Ciaran McCreesh wrote:
On Sat, 17 Jan 2015 22:59:08 +0800
Patrick Lauer wrote:
The problem isn't the constants, though. The problem is the
resolution algorithm. There's not much point tweaking performance
until the resolver is fixed to produce a correct answer...
Patches we
On 19/01/15 16:47, hasufell wrote:
I think you forgot an important point:
* lack of practical QA: no review workflow and no appropriate tools for
reviewing
I could start a long text block about why reviewing is mandatory for QA,
but let's just think about it this way:
What do you think would ha
On 17/01/15 18:43, Anthony G. Basile wrote:
Hi everyone,
It looks like there aren't too many bugs against gcc-4.9 (bug #495124).
There are a couple having to do with lto and one which is hardened
specific, but its probably a good idea to start keywording on the
various arches so we can get more
On 25/01/15 03:57, Tom Gall wrote:
Hi All,
This is sort of a CFP in some ways but not quite that formal. I’ve
been throttled back on arm64 for a bit as the hardware I’ve had access
to has all been painfully remote and configured in ways that was less
than optimal for massive key wording efforts
On 27/01/15 01:19, Gordon Pettey wrote:
Chromaprint will work /differently/ depending on which is used. I added
libav support to it, but the fingerprints are not the same as fingerprints
generated when using ffmpeg. I've not gotten around to fixing that, so if
such a list is being compiled it sho
On 04/02/15 11:40, Michał Górny wrote:
It's easiest to look at the trackers:
- ffmpeg-2 [1] -- 26/26 fixed,
- ffmpeg-2.4 [2] -- 3/3 fixed (but unsure if there won't be more),
- libav-9 [3] -- 55/55 fixed,
- libav-10 [4] -- 11/25 fixed.
No offense here but in my experience, ffmpeg support in Gen
On 04/02/15 14:25, Jason A. Donenfeld wrote:
By now it should be clear to most people that everything goes smoother,
works better for the end user, and causes less breakage when *ffmpeg is the
default, not libav*.
"Works better" is a matter of perception, if I (and the few that help me
not afr
On 08/02/15 17:13, Alexis Ballier wrote:
What we need instead of such endless debate & happy bashing (been
there, done that) is people doing the work. That's what will improve
the distribution. I thought letting libav be the default would improve
that;
If nobody helps fixing the orphaned and ne
On 09/02/15 10:17, Alexis Ballier wrote:
(nb: you can see that this precise one is mostly fixed already.)
I hope it is completely fixed already =\
lu
On 14/02/15 19:41, Fabio Erculiani wrote:
If only libav and ffmpeg developers would stop breaking their API on
every release...
Just break it once and for all. It's so sad that I still can't upgrade
from libav-9 because of this.
Feature request: could you stop breaking the API for a couple of
ye
On 16/02/15 12:58, Mike Frysinger wrote:
On 16 Feb 2015 19:43, Patrick Lauer wrote:
On Monday 16 February 2015 06:13:10 Mike Frysinger wrote:
even then, deleting an ebuild purely due to different copyright is
complete bs. anyone who understands copyright knows the situation in
Gentoo is comple
On 19/02/15 01:05, Anthony G. Basile wrote:
I have about $1000 in grant money. Want to recommend some equipment?
The dragonboard might be good BUT there are doubts on software availability.
lu
On 27/02/15 08:45, Ben de Groot wrote:
> On 22 February 2015 at 03:43, Ben de Groot wrote:
>> To anyone within Gentoo who is interested in fonts
>>
>> I would like to announce a meeting to be held in #gentoo-meetings on
>> Freenode, on Friday February 27 at 06:00 UTC, unless another date
>> and/or
On 18/07/15 21:01, Matthew Marchese wrote:
> I'd like to hear it all so please speak your mind. Looking forward to
> hearing from you.
The plan is good, having multiple backends is a boon since then you can
have large install images and tiny install images.
An installer is basically covering part
On 07/08/15 19:01, Michał Górny wrote:
> Does this sound fine?
It does
> Any suggestions?
Having a reduced scope and not covering corner cases is fine now, so no =)
> [1]:https://bugs.gentoo.org/show_bug.cgi?id=482666
>
On 12/08/15 11:46, Shuai Zhao wrote:
> 2015-08-12 15:47 GMT+08:00 Mike Frysinger :
>
>> On 12 Aug 2015 15:20, Leno Hou wrote:
>>> **Most importantly, Any Ideas/steps of how to porting gentoo on ppc64le
>>> architecture?**
>>
>> do you have hardware ? then it's simply a matter of booting Gentoo
On 24/09/15 14:23, Leno Hou wrote:
> On Fri, Sep 11, 2015 at 8:01 PM, Leno Hou wrote:
>
>>
>> 2. We believe to make Gentoo support ppc64le, we still need to compile
>> kernel and bootloader
>>
>>- Which version of kernel provided by Gentoo would you suggest us to
>>use?
>>
>> As
On 01/11/15 23:07, Michael Orlitzky wrote:
> On 11/01/2015 12:44 PM, Michael Palimaka wrote:
>> There's been a lot of discussion about relying on GitHub for pull
>> requests and code review and such, so I have set up a Phabricator
>> instance against gentoo.git to see how a free alternative might w
On 11/11/15 10:09, Michał Górny wrote:
> I'd rather use the old standard 80. Minus 8 characters for friendly
> e-mail quoting, which is also kinda 'old standard'.
You can suggest as above, with this tone, and probably you would get
some consensus.
Personally I think 80col is nice since you can ha
On 10/05/2020 13:21, Aisha Tammy wrote:
On 5/10/20 2:02 AM, Michał Górny wrote:
W dniu sob, 09.05.2020 o godzinie 22∶39 -0400, użytkownik Aisha Tammy
napisał:
Hey all,
I was hoping to upgrade the dev-python/numba jit compiler in proxy-
maint but it depends on dev-python/llvmlite >=0.31
Curre
On 12/06/2020 05:15, Georgy Yakovlev wrote:
This will also allow me to start adding cross support to cargo.eclass
with new cross-friendly variables.
experimental cross support landed in rust-1.44.0 today [1]
Yes please :)
lu
On 12/06/2020 11:04, Georgy Yakovlev wrote:
+# cargo_src_configure --no-default-features
Shall we default in not-defaulting so we can spare some boilerplate?
lu
On 12/06/2020 18:24, Georgy Yakovlev wrote:
On 6/12/20 4:16 AM, Luca Barbato wrote:
On 12/06/2020 11:04, Georgy Yakovlev wrote:
+# cargo_src_configure --no-default-features
Shall we default in not-defaulting so we can spare some boilerplate?
I don't think so. Let me explain.
Fir
On 17/06/2020 12:57, Ulrich Mueller wrote:
On Wed, 17 Jun 2020, Michał Górny wrote:
+# @FUNCTION: kernel-install_pkg_pretend
+# @DESCRIPTION:
+# Check for missing optional dependencies and output warnings.
+kernel-install_pkg_pretend() {
+ debug-print-function ${FUNCNAME} "${@}"
+
+
On 24/07/21 17:16, Michał Górny wrote:
> Hi, everyone.
>
> I've been asked to repost the idea of removing SHA512 hash from
> Manifests, effectively limiting them to BLAKE2B.
>
> The 'old' set of Gentoo hashes including SHA512 went live in July 2012.
> In November 2017, we have decided to remove t
On 22/08/21 22:14, Anthony G. Basile wrote:
> Hi everyone,
>
> Yes! It is time to finally deprecate eudev! sys-fs/udev now builds
> under musl! My original purpose for maintaining eudev was because
> systemd + musl did not play well together when udev was absorbed into
> the sytemd repo. Now t
On 27/09/21 18:10, Mike Gilbert wrote:
> I'm looking to solicit opinions on when it is appropriate for an
> ebuild to check for kernel config options using linux-info.eclass. I
> don't think we have any guidelines documented, instead leaving it up
> to the "common sense" of package maintainers.
>
On 11/11/21 17:05, Michał Górny wrote:
> Hi,
>
> I'd like to add some dates regarding 3.8 removal and 3.10 switch to
> the implementation timeline [1].
>
> Unless I'm mistaken, CPython is following a yearly release cycle these
> days. I think it would make sense to also aim for a yearly cycle
>
On 12/01/22 03:45, Georgy Yakovlev wrote:
> it's an ancient codec that is barely used nowadays
> so let's disable it by default.
> Users are free to re-enable if required.
>
It is fine, btw this mpeg4 dialect is still supported by libavcodec so
only people wanting to encode using the original cod
On 12/10/24 15:03, Michał Górny wrote:
emerge =python-3.14 would install both a non-freethreading and a
freethreading version and it would satisfy 3_14 and 3_14t at the same.
But that's not how PMs work? It would install only the "newer" version,
which would probably mean freethreading, whic
On 12/10/24 11:13, Michał Górny wrote:
On Sat, 2024-10-12 at 10:50 +0200, Luca Barbato wrote:
On 12/10/24 10:12, Michał Górny wrote:
Comments?
I'm afraid it would lead to way too many packages and I'm not sure the
overall experience would be an improvement.
5 are too many?
pote
On 12/10/24 10:12, Michał Górny wrote:
Comments?
I'm afraid it would lead to way too many packages and I'm not sure the
overall experience would be an improvement.
With your proposed solution, if an user wants to have any version of
python what should ask to emerge?
An alternative for free
On 17/09/24 16:55, Matt Turner wrote:
I suggest making a new Vulkan project within Gentoo and moving these
packages from x11@ maintainership to it:
dev-cpp/robin-hood-hashing
dev-util/glslang
dev-util/spirv-headers
dev-util/spirv-tools
dev-util/volk
dev-util/vulkan-headers
dev-util/vulkan-tools
Otherwise host flags leak in and may break cross-building if `-march` is
present.
Signed-off-by: Luca Barbato
---
eclass/perl-module.eclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/eclass/perl-module.eclass b/eclass/perl-module.eclass
index 27cd053f0ea7..c25a9f81465f 100644
--- a
701 - 758 of 758 matches
Mail list logo
