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
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
On 22/05/23 22:41, Nick Sarnie wrote:
On 5/22/23 16:40, Matt Turner wrote:
On Mon, May 22, 2023 at 4:27 PM Sam James wrote:
Thanks to leio for this improved phrasing.
Signed-off-by: Sam James
---
profiles/use.desc | 1 +
1 file changed, 1 insertion(+)
diff --git a/profiles/use.desc b/pro
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 17/06/2018 06:40, Matt Turner wrote:
> I would like to somehow get rid of the 'classic' and 'gallium' USE
> flags entirely, but I'm not totally sure how. Maybe I can enable them
> dependent on VIDEO_CARDS...
But shouldn't mesa have a software fallback for a good deal of those
features?
Probabl
On 09/06/2018 10:22, Lars Wendler wrote:
> Hello dear Gentoo Devs,
>
> this is somewhat written out of frustration so please bear with me ;)
>
> CCing crypto@ in case they can provide some valuable input to the
> topic. If not, sorry guys for wasting your time.
>
> As you might have noticed, alt
On 18/09/2017 11:56, Andreas K. Huettel wrote:
So glibc-2.26 is already out for some time, but we still haven't keyworded it
yet. Why?
* I want to use the opportunity to make the long-delayed switchover from
glibc-internal SunRPC (long deprecated and outdated) to external
implementations (libtir
On 5/9/17 7:15 PM, Matthias Maier wrote:
> sys-devel/gcc-7.1.0 requires external dev-libs/boehm-gc, the internal
> copy got removed [1].
>
> [1] https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=242985
> ---
> eclass/toolchain.eclass | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --
On 5/3/17 6:43 PM, William Hubbs wrote:
> Hey all,
>
> I am asking about this because I have been asked to look into
> packaging software that has a specific requirement for >=gcc-6 in order
> to build [1].
>
> I see that gcc-6.3 doesn't have keywords, so I'm
> wondering when it will get them? Do
On 01/10/16 10:10, Michał Górny wrote:
> explicitly selecting all targets.
The item seems fine.
On 09/09/16 02:31, Ian Bloss wrote:
> Anyone actively using nftables for their firewall over iptables?
> Considering giving it a go as the syntax looks much nicer than iptables.
>
I'm using a bit and just works fine =)
lu
On 19/08/16 17:15, C Bergström wrote:
> On Fri, Aug 19, 2016 at 11:01 PM, Luca Barbato wrote:
>> BTW is pathscale ready to be used as system compiler as well?
>
> I wish, but no. We have known issues when building grub2, glibc and
> the Linux kernel at the very least. Someone*
On 19/08/16 19:13, C Bergström wrote:
> I finally got it to build and here's the size numbers
> 952K./lib/libc++abi.a
> 616K./lib/libc++abi.so.1.0
>
> If the above isn't enough motivation and you really want benchmarks
> which prove it's a pig... I'll try to figure something else
>
> Not
On 19/08/16 05:11, C Bergström wrote:
> I think you're getting a bit confused
>
> libsupc++ is the default now, from GNU
>
> libcxxabi is the bloated runtime from Apple
>
> libcxxrt is the faster c++ runtime, PathScale+David Chisnall, which
> PathScale and FreeBSD use by default. We don't need a
On 18/04/16 00:50, Anthony G. Basile wrote:
> Does base-system object if I bump it to EAPI=5 before I commit the
> ssl-cert patch? I'll start stabilization too obviously.
>
Please do.
On 09/04/16 14:37, Rich Freeman wrote:
> I've certainly haven't had many problems with dracut. When it fails
> it is usually because I'm doing something ELSE that is off-the-wall
> and it just doesn't have a plugin for it yet. (And in those cases it
> isn't like the kernel tends to get it right w
On 08/04/16 14:55, Rich Freeman wrote:
> The purpose of a /usr merge is to get all the stateless stuff into one place.
beside what you have in /etc ...
usr-merge, in practice just moves early-boot/core tools where the rest
of the userspace lives.
> Some of the ultimate goals include:
> 1. A rea
On 09/04/16 13:53, Rich Freeman wrote:
> On Sat, Apr 9, 2016 at 7:41 AM, Luca Barbato wrote:
>> On 05/04/16 03:19, William Hubbs wrote:
>>> Thoughts on any of this?
>>
>> The whole usr-merge moves the problem of putting stuff in / to putting
>> the very sam
On 05/04/16 03:19, William Hubbs wrote:
> Thoughts on any of this?
The whole usr-merge moves the problem of putting stuff in / to putting
the very same stuff in the initrd when something different from busybox
(or equivalent) is needed to get the early boot mounting.
Do we have a reliable way to
On 24/02/16 01:33, Duncan wrote:
> That option is there, and indeed, a patch providing it was specifically
> added to portage for infra to use, because appending entries to existing
> files is vastly easier and more performant than trying to prepend entries
> and having to rewrite the entire fil
On 16/02/16 19:05, William Hubbs wrote:
> All,
>
> I have a bug that points out a significant issue with
> /etc/init.d/mount-ro in OpenRC.
>
> Apparently, there are issues that cause it to not work properly for file
> systems which happen to be pre-mounted from an initramfs [1].
Who is using tha
On 09/02/16 04:09, Rich Freeman wrote:
> On Mon, Feb 8, 2016 at 7:58 PM, Anthony G. Basile wrote:
>>
>> what does in-house tool mean? i'm a gentoo developer but i also work
>> on an upstream project (eudev) that 14 distros use.
>>
>> some of the criticism given here are my concerns as well and i'
On 04/02/16 15:05, Alexis Ballier wrote:
> Hi,
>
> We've been supporting jack sound server [1] for a long time.
> Currently, we're supporting jack1 as
> media-sound/jack-audio-connection-kit. However, jack2 has been out for
> quite some time.
>
> As its name does not imply, jack2 is not really th
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 28/11/14 13:20, Sergey Popov wrote:
Packages that uses 'vaapi' local USE-flag:
media-libs/avidemux-core
media-libs/xine-lib
media-tv/mythtv
media-tv/xbmc
media-video/avidemux
media-video/ffmpeg
media-video/hwdecode-demos
media-video/libav.
media-video/mpv
media-video/vlc
virtual/ffmpeg
www-pl
On 26/11/14 22:52, Rich Freeman wrote:
On Wed, Nov 26, 2014 at 4:21 PM, Tom Wijsman wrote:
On Sat, 22 Nov 2014 00:34:33 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:
While it pains me to say this, unfortunately it looks like we have
another "toxic person" situation to deal with, with all t
On 07/11/14 06:06, Harsh Bhatt wrote:
This idea seems bit interesting, about how the bug tracker works.
In this i just need to confirm that how much mathematical aspect
can be included. It's a good idea to work on.
Also make might enjoy improvements.
lu
On 05/11/14 18:49, Mike Gilbert wrote:
On Wed, Nov 5, 2014 at 12:30 PM, Luca Barbato wrote:
On 05/11/14 02:16, Michael Orlitzky wrote:
When I was taking my ebuild quizzes, I asked for someone to clarify the
implicit system dependency that we have enshrined in the devmanual:
https
On 05/11/14 02:16, Michael Orlitzky wrote:
When I was taking my ebuild quizzes, I asked for someone to clarify the
implicit system dependency that we have enshrined in the devmanual:
https://bugs.gentoo.org/show_bug.cgi?id=485356
There is... some agreement, but also special cases and special
On 03/11/14 20:24, Andrés Martinelli wrote:
Yes, Vim license was the base of it, as I noticed, at least by now, that it
meets the requirements I thought necessary. About that mistake, thanks for
noticing it. It will be corrected.
Just:
- change the name, it conflicts with another package.
- u
On 02/11/14 14:22, Pacho Ramos wrote:
El dom, 02-11-2014 a las 13:07 +, Diego Elio Pettenò escribió:
How do you strip the html code? I was unsure about to do that :/
You should have asked. There is no need to strip. I upload both HTML
and text alike.
Ah, ok. Anyway, if AxS can tell me
On 01/11/14 11:47, Diego Elio Pettenò wrote:
The problem with "it's trivial to do that in python so just do it" is
that first of all Python is not my language of choice, so the whole
infrastructure is currently not written in Python at all. And all the
people, including Luca, who promised they ca
On 30/10/14 15:06, Jan Kundrát wrote:
On Saturday, 25 October 2014 12:47:21 CEST, Luca Barbato wrote:
The ABI mismatch is due the library not being versioned properly as
"usual"?
Please note that this would be a "hard thing to do". This is not just a
matter of calling an
On 27/10/14 12:07, M. Ziebell wrote:
Does clang compile glibc already?
At the last GNU Cauldron the speaker said that clang fails because
of:[1]
- nested functions
- VLAIS
How did you avoid that problem?
musl is known to work fine.
On 25/10/14 13:09, Matthias Maier wrote:
>
>> Not sure if the llvm C++ runtime might help here or it is any better
>> than the one provided by gnu, but might be a good time to gather
>> volunteers to provide a mean to use clang as main compiler out of box.
>
> libc++ makes stricter ABI guarantees
On 24/10/14 19:12, Anthony G. Basile wrote:
> bug 513386 - net-libs/webkit-gtk-2.4.3 - ./.libs/libwebkitgtk-3.0.so:
> undefined reference to `_ZNSt6chrono12steady_clock3nowEv@GLIBCXX_3.4.17'
> -> This is a problem. It relates to abi mismatching with libstdc++.
The ABI mismatch is due the library
On 20/10/14 00:53, Anthony G. Basile wrote:
> Hi everyone,
>
> I debated about whether to write a news item about c++11 abi. Usually
> our news items are about some change which requires user intervention.
> But this is just precautionary. With more packages needing c++11
> because of source cha
On 27/09/14 15:19, Luca Barbato wrote:
On 27/09/14 14:22, Ciaran McCreesh wrote:
On Sat, 27 Sep 2014 12:47:14 +0200
Luca Barbato wrote:
Because I'd expect a stage3 to be posix compliant
I agree. It's time to replace nano with Vim.
Surely certain stuff might enjoy having ex av
On 27/09/14 14:22, Ciaran McCreesh wrote:
On Sat, 27 Sep 2014 12:47:14 +0200
Luca Barbato wrote:
Because I'd expect a stage3 to be posix compliant
I agree. It's time to replace nano with Vim.
Surely certain stuff might enjoy having ex available as well.
Probably busybox could
On 17/09/14 14:09, Jorge Manuel B. S. Vicetto wrote:
On Wed, 17 Sep 2014, Luca Barbato wrote:
The bc utility is part of the posix tools and it might be used to build
linux among the other stuff.
Luca,
bc is not in the system set and is a dependency of the kernel or any
other package that
The bc utility is part of the posix tools and it might be used to build
linux among the other stuff.
lu
On 15/09/14 01:21, Patrick Lauer wrote:
> On Sunday 14 September 2014 15:42:15 hasufell wrote:
>> Patrick Lauer:
Are we going to disallow merge commits and ask devs to rebase local
changes in order to keep the history "clean"?
>>>
>>> Is that going to be sane with our commit frequency?
>>
On 14/09/14 17:30, Patrick Lauer wrote:
>> Are we going to disallow merge commits and ask devs to rebase local
>> changes in order to keep the history "clean"?
>
> Is that going to be sane with our commit frequency?
>
Which is our commit frequency? Worst case we can aggregate changes and
push th
On 14/09/14 16:46, Michał Górny wrote:
> Of course, if we can't spare the resources to do intermediate updates,
> we may as well switch to cron-based update method.
The mirror have a sync time, so basically regenerating the cache and
pushing the tree with further toward the user can happen the sam
On 14/09/14 17:15, Kent Fredric wrote:
> On 15 September 2014 02:40, Michał Górny wrote:
>
>> However, I'm wondering if it would be possible to restrict people from
>> accidentally committing straight into github (e.g. merging pull
>> requests there instead of to our main server).
>>
>
>
> Easy
On 08/12/13 00:44, hero...@gentoo.org wrote:
> yac writes:
>
>> Shouldn't pkg-conifg --libs handle this?
>
> Oh, good idea. But boost doesn't have pkg-config entries.
>
> Then I see this one, an upstream issue
>
> https://svn.boost.org/trac/boost/ticket/1094
>
Are you willing to poke up
On 29/09/13 04:12, hero...@gentoo.org wrote:
> It's just a starting point, though. I still don't have a clear plan yet.
>
> After reading carefully the thread Ulrich pointed out, it seems that
> refactoring ebuild/eclass is invevitable, which calls for an overlay to
> carry it on.
That would be m
On 14/08/13 17:56, Peter Stuge wrote:
> Luca Barbato wrote:
>>> [3] https://wiki.documentfoundation.org/Development/gerrit
>>
>> And all boils down to the fact gerrit needs to be fixed to take
>> patches from a mailing list
>
> Usually Gerrit just needs an Op
On 14/08/13 01:40, Ryan Hill wrote:
> On Tue, 13 Aug 2013 07:13:13 +0200
> Luca Barbato wrote:
>
>> On 13/08/13 03:41, Ryan Hill wrote:
>>> I don't see any reason to keep this masked other than bug #416069, which
>>> needs to be fixed anyways.
On 13/08/13 10:10, Tomáš Chvátal wrote:
> [3] https://wiki.documentfoundation.org/Development/gerrit
And all boils down to the fact gerrit needs to be fixed to take patches
from a mailing list or provide some sane alias to cope with it's
specific ways...
lu
On 13/08/13 03:41, Ryan Hill wrote:
> I don't see any reason to keep this masked other than bug #416069, which
> needs to be fixed anyways. How does Friday sound?
>
> https://bugs.gentoo.org/416069 xorg-2.eclass: add --disable-selective-werror
> to configure
> https://bugs.gentoo.org/461954 GC
On 01/08/13 04:48, William Hubbs wrote:
> I would rather not carry distro-specific patches forever to support
> something like this, so please forward your patches upstream.
The code is in a public git, it is even not written by me, anybody can
forward it to upstream...
lu
On 01/08/13 23:53, Michał Górny wrote:
> That would be a lot of effort if upstream doesn't accept it and we end
> up patching it all the way...
kmod isn't complex and probably could be made even a bit more compact,
considering also the pace of its development and the kind of changes in
the last mo
On 01/08/13 19:54, Samuli Suominen wrote:
> still, first the patch goes upstream and after upstream review and
> commit to git it goes in tree otherwise we opt to the fallback and
> disable udev from lvm2/cryptsetup when USE=static is enabled (like
> cryptsetup upstream suggested to me) gentoo-spe
On 01/08/13 19:46, Pacho Ramos wrote:
> El jue, 01-08-2013 a las 18:11 +0200, Luca Barbato escribió:
>> On 01/08/13 17:36, Michał Górny wrote:
>>> So esystemd and ekmod now?
>>
>> You know my stance on systemd, for me it is a jumble of bad and
>> interesting id
On 01/08/13 17:36, Michał Górny wrote:
> So esystemd and ekmod now?
You know my stance on systemd, for me it is a jumble of bad and
interesting ideas not so soundly implemented, I do not have much time or
will to play with that thing.
kmod on the other hand had a pressing issue and getting it fix
On 01/08/13 17:04, William Hubbs wrote:
> There is a hack in our udev and kmod ebuilds that makes it possible to
> build the static libraries, but I think we should remove that hack since
> upstream bans building them.
linking statically makes the problem apparent, I guess isn't that wise
hiding i
1 - 100 of 758 matches
Mail list logo
