Hello developers,
Does anyone know why namcap considers transient dependencies a good thing?
The terminology I use might be a bit confusing - I'm thinking of
"dependency-covered-by-link-dependence"
I've had a quick look through the namcap code, plus the wiki but could
not see anything.
I do agre
Hello Arch developers,
After an upstream issue reported by Laurent Carlier (aka lordheavy)
Istarted wondering why builds fail on his end and not my (Arch)
machine.
The key difference seems to be that he's using devtools, whereas I do not.
After a further chat, I got the impression that devtools i
Hi Kyle,
On 8 August 2017 at 17:59, keenerd wrote:
> There are many little details about Arch that are left in the hands of
> the maintainers, because setting a hard policy would involve far too
> much pointless bikeshedding. You have found one of these.
>
I think I've already found another topi
On 8 August 2017 at 23:20, keenerd wrote:
> Above all we're grown-ups who can weight the pros and cons on a case
> by case basis and make their own decisions as appropriate. I'm glad
> that Arch Linux has gotten so good that this is the worst issue you
> can find, but that doesn't mean it is wort
On 8 August 2017 at 18:28, Johannes Löthberg via arch-projects
wrote:
> Quoting Emil Velikov via arch-projects (2017-08-08 18:45:20)
>> Hello Arch developers,
>>
>> After an upstream issue reported by Laurent Carlier (aka lordheavy)
>> Istarted wondering why builds
When the system is very low on resources, select() may return 0 even
when wpa_supplicant is alive and kicking.
Don't disconnect as soon at that occurs - wait three times and clearly
log it.
Signed-off-by: Emil Velikov
---
Hi all,
Using [projects] since [wpa_actiond] gets kicked by the email fil
On 21 August 2017 at 10:34, Emil Velikov wrote:
> When the system is very low on resources, select() may return 0 even
> when wpa_supplicant is alive and kicking.
>
> Don't disconnect as soon at that occurs - wait three times and clearly
> log it.
>
> Signed-off-by: Emil Velikov
> ---
> Hi all,
>
On 9 October 2017 at 09:22, Bartłomiej Piotrowski
wrote:
> On 2017-09-29 15:03, Emil Velikov via arch-projects wrote:
>> On 21 August 2017 at 10:34, Emil Velikov wrote:
>>> When the system is very low on resources, select() may return 0 even
>>> when wpa_supp
Hi Eli,
Disclaimer: the following is a bit subtle topic, so I hope it doesn't
spur a lot of off-topic.
On 19 February 2018 at 20:11, Eli Schwartz via arch-projects
wrote:
> Catch some cases that were missed in the previous run.
>
> Signed-off-by: Eli Schwartz
> ---
>
> This patch is new + refac
On 20 February 2018 at 14:23, Eli Schwartz wrote:
> On 02/20/2018 06:59 AM, Emil Velikov wrote:
>> Disclaimer: the following is a bit subtle topic, so I hope it doesn't
>> spur a lot of off-topic.
>
> Eh, I don't mind.
>
>> Is there any performance or other technical benefit to using more bashisms
Hi Jouke,
Thanks for fixing this!
Sharing a couple of ideas that come to mind.
On 23 June 2018 at 12:25, Jouke Witteveen via arch-projects
wrote:
> Strictly speaking, we should check with the SSIDEncoding value sent out
> by the station, as specified in the 2012 version of 802.11 (page 566),
> b
From: Emil Velikov
Currently each profile is handles in two stages:
- a unique value is returned for a set of patterns matches
- depending on the value the profile/essid is added to global lists
A shorter and simpler solution is to omit the unnecessary value
passing/processing all together.
C
On 26 June 2018 at 11:40, Jouke Witteveen wrote:
> On Tue, Jun 26, 2018 at 12:27 PM Emil Velikov
> wrote:
>>
>> From: Emil Velikov
>>
>> Currently each profile is handles in two stages:
>> - a unique value is returned for a set of patterns matches
>> - depending on the value the profile/essid
On 26 June 2018 at 11:34, Jouke Witteveen wrote:
> On Tue, Jun 26, 2018 at 12:17 PM Emil Velikov
> wrote:
>> On 23 June 2018 at 12:25, Jouke Witteveen via arch-projects
>> wrote:
>> > Strictly speaking, we should check with the SSIDEncoding value sent out
>> > by the station, as specified in th
On Thu, 7 Feb 2019 at 14:50, Jouke Witteveen via arch-projects
wrote:
>
> The same functionality is provided by wpa_supplicant, so we do not need
> an extra and Arch Linux specific dependency.
The introduction of wpa_actiond [1] hints there are issues with wpa_cli. Namely:
- partial or missing lo
On Sat, 9 Feb 2019 at 09:19, Thomas Bächler wrote:
>
> Am 8. Februar 2019 20:17:52 MEZ schrieb Jouke Witteveen
> :
> >On Fri, Feb 8, 2019 at 3:36 PM Emil Velikov
> >wrote:
> >>
> >> On Thu, 7 Feb 2019 at 14:50, Jouke Witteveen via arch-projects
> >> wrote:
> >> >
> >> > The same functionality i
On Mon, 6 May 2019 at 15:10, Jelle van der Waa wrote:
>
> From: Jelle van der Waa
>
> finddeps depends on a no longer existing ABS tree. This data can also be
> queried via archweb.
> ---
Out of curiosity:
AFAICT all the information is already in the local DB, so
theoretically pacman can present
Hi team,
On Sat, 9 Feb 2019 at 09:19, Thomas Bächler wrote:
>
> Am 8. Februar 2019 20:17:52 MEZ schrieb Jouke Witteveen
> :
> >On Fri, Feb 8, 2019 at 3:36 PM Emil Velikov
> >wrote:
> >>
> >> On Thu, 7 Feb 2019 at 14:50, Jouke Witteveen via arch-projects
> >> wrote:
> >> >
> >> > The same funct
On Thu, 16 May 2019 at 13:19, Jouke Witteveen wrote:
>
> On Thu, May 16, 2019 at 11:53 AM Emil Velikov
> wrote:
> > After a bit of debugging I've noticed the move to wpa_cli broke my setup.
> > Namely: wpa_cli does not reliably detect when the laptop resumes into
> > another wireless network.
>
On Fri, 11 Dec 2020 at 20:29, Eli Schwartz via arch-projects
wrote:
>
> On 12/11/20 2:25 PM, meganomic via arch-projects wrote:
> > Adds handling of the compression and temporary storage into namcap.py
> > so it can be removed from the bash script.
> > https://bugs.archlinux.org/task/59844 mention
This produces shorter and faster code. The speed-up depends greatly on
the workload - so here are some examples:
File: mesa-18.3.2-1-x86_64.pkg.tar.xz from [1]
Before:
1.66s user 0.15s system 100% cpu 1.814 total
1.61s user 0.21s system 100% cpu 1.820 total
1.69s user 0.15s system 100% cpu 1.832
On Tue, 5 Jan 2021 at 01:40, Emil Velikov wrote:
>
> This produces shorter and faster code. The speed-up depends greatly on
> the workload - so here are some examples:
>
> File: mesa-18.3.2-1-x86_64.pkg.tar.xz from [1]
>
> Before:
> 1.66s user 0.15s system 100% cpu 1.814 total
> 1.61s user 0.21s s
On Sun, 10 Jan 2021 at 16:34, Emil Velikov wrote:
>
> On Tue, 5 Jan 2021 at 01:40, Emil Velikov wrote:
> >
> > This produces shorter and faster code. The speed-up depends greatly on
> > the workload - so here are some examples:
> >
> > File: mesa-18.3.2-1-x86_64.pkg.tar.xz from [1]
> >
> > Before
23 matches
Mail list logo
