On Mon, May 04, 2020 at 11:57:03PM +0100, Andrey Utkin wrote:
> Since it is going to be opt-in and optional anyway, we seem to be fine with
> having just partial data.
>
> I assume we have logs of distfiles downloads from Gentoo infrastructure, and
> can negotiate access to relevant logs of our
media-gfx/svg2rlg 20200523-09:43 mgorny870019d3f18
media-sound/lyvi 20200523-09:37 mgorny888bfbefa0f
media-video/griffith 20200523-09:44 mgorny176d35ce731
net-misc/gns3-converter 20200524-22:38 bman 2412a2c9f40
net-misc/ssvnc
Ignore files passed to docompress -x in the QA check for
precompressed files.
Bug: https://bugs.gentoo.org/721516
Signed-off-by: Zac Medico
---
bin/ecompress | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/bin/ecompress b/bin/ecompress
index
On 5/24/20 9:40 AM, Daniel Buschke wrote:
> Am 24.05.2020 um 14:10 schrieb Daniel Pielmeier:
>> Here the bash version takes around 2.9 seconds while the python version
>> takes 3.2 seconds. Excluding the portage API it takes 2.8 seconds and
>> also excluding the data query it takes 0.3 seconds. So
Sending from the proper address so this mail also reaches the list!
Daniel Buschke schrieb am 24.05.20 um 18:40:
> Oh dear! I readded the database index for file names. Now the data query
> takes ~0.3 seconds *insert self slapping image here*
Good to hear! Now it's way quicker!
> Anyway, for
Am 24.05.2020 um 14:10 schrieb Daniel Pielmeier:
Here the bash version takes around 2.9 seconds while the python version
takes 3.2 seconds. Excluding the portage API it takes 2.8 seconds and
also excluding the data query it takes 0.3 seconds. So in the python
version the data query takes 2.5
On Sun, 24 May 2020 13:05:35 +
Peter Stuge wrote:
> The bar only needs to be raised high enough.
Sure. A lot of this is just "think about what could happen in the worst
case imaginable".
Its very unlikely our worst cases will happen.
But we should at least have the ability to easily add
Kent Fredric wrote:
> > While services such as reCAPTCHA are (as said) massively intrusive, there
> > are other, much less intrusive and even terminal-compatible ways to
> > construct
> > a CAPTCHA. Hello game developers, you have 80x23 "pixels" to render a puzzle
> > for a human above the
Michał Górny wrote:
> Hence my question: do you find 'do not remove kernels listed
> in bootloader config' feature useful? Do you think it should remain
> the default? Do you think it is worthwhile to continue supporting it?
I continue to use LILO because simpler and more mature code is good,
Daniel Buschke schrieb am 24.05.20 um 00:05:
> Am 23.05.2020 um 23:46 schrieb Daniel Pielmeier:
>> Hm correct me if I am wrong, but from looking at the patch Zac
>> provided I think he meant that the time portage consumes is only one
>> second while the "rest" is 3.2 seconds. So there is probably
On Sun, 24 May 2020 09:40:50 +0800
"Pengcheng Xu" wrote:
> > USE=-native-symlinks removes a bunch of links that most packages use by
> > default
> > until are overridden explicitly. Incomplete list is:
> > - /lib/cpp
> > - /usr/bin/{gcc,cc,g++,c++,...}
> > - /usr/bin/{as,ld,ranlib,dwp,...}
> >
On 24-05-2020 10:48:47 +0100, Sergei Trofimovich wrote:
> On Sat, 23 May 2020 22:41:02 -0400
> Mike Gilbert wrote:
> > I don't think we
> > want to give people the impression that this is a well-supported
> > configuration. I would only expect people to disable this if they want
> > to break
On Sat, 23 May 2020 22:41:02 -0400
Mike Gilbert wrote:
> On Fri, May 22, 2020 at 5:36 PM Sergei Trofimovich wrote:
> >
> > 'tc-directly' tracker https://bugs.gentoo.org/243502 tracks
> > packages that don't respect users' CC/AR/LD flags.
> >
> > I added new USE=-native-symlinks mode for
On Sat, 23 May 2020 23:40:22 -0700
Matt Turner wrote:
> On Sat, May 23, 2020 at 10:21 PM Joonas Niilola wrote:
> >
> >
> > On 5/24/20 5:41 AM, Mike Gilbert wrote:
> > > Also, people are likely to disable this accidentally via USE="-*".
> >
> > Counts as
> >
> > > if they want to break
On Sun, 24 May 2020 10:33:18 +0200
Michał Górny wrote:
> If it creates an invalid environment that is known to break packages
> and is not QA-sanctioned, it should be masked. Period.
Seems like yet another argument in favour of my initial position, that
it probably shouldn't be controlled by
On Sun, 2020-05-24 at 20:15 +1200, Kent Fredric wrote:
> On Sat, 23 May 2020 22:41:02 -0400
> Mike Gilbert wrote:
>
> > Could you please add this flag to package.use.force? I don't think we
>
> Sounds more like a case for package.use.stable.force or something.
>
> For non-stable, we don't give
On Sat, 23 May 2020 22:41:02 -0400
Mike Gilbert wrote:
> Could you please add this flag to package.use.force? I don't think we
Sounds more like a case for package.use.stable.force or something.
For non-stable, we don't give guarantees about well-supported, only
that there will be bugs, and
On Sun, 24 May 2020 09:40:50 +0800
"Pengcheng Xu" wrote:
> Do we currently have (or is there a plan for) a mechanism to manage the
> symbolic links and/or create them after merging the package when necessary?
> It's quite tiresome to type in $CHOST-gcc for simple everyday tasks.
There are
# Hans de Graaff (2020-05-24)
# No releases since 2011, upstream is gone, fails tests,
# no reverse dependencies.
# Masked for removal in 30 days.
dev-ruby/rack-mount
signature.asc
Description: This is a digitally signed message part
On Sat, May 23, 2020 at 10:21 PM Joonas Niilola wrote:
>
>
> On 5/24/20 5:41 AM, Mike Gilbert wrote:
> > Also, people are likely to disable this accidentally via USE="-*".
>
> Counts as
>
> > if they want to break their system intentionally.
Yes, but unfortunately catalyst's stage1 build does
20 matches
Mail list logo
