Re: Replacing polkit by polkit-duktape on core-updates-frozen ?

Hi Thiago, Thiago Jung Bauermann writes: [...] > IIUC it’s a bug to test (%current-system) before > (%current-target-system). That’s because the latter is only defined > for cross-builds, while the former is always defined. So in practice > (%current-target-system) will never be checked. Oh, g

Re: Replacing polkit by polkit-duktape on core-updates-frozen ?

Hello, Ludovic Courtès writes: > Hi, > > Maxim Cournoyer skribis: > >> gnu: polkit: Define polkit package variable based on architecture. >> >> * gnu/packages/polkit.scm (polkit): Rename to... >> (polkit*): ... this. >> (polkit-duktape): Adjust to inherit from polkit*. >> (polkit-for-system): N

Re: ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?)

Hi Denis, On Wed, 24 Nov 2021 at 00:51, Denis 'GNUtoo' Carikli wrote: > If I understood correctly Florian, the argument here is that it is safe > to redistribute source code under a GPL incompatible license that links > to GPL code because it's in source form? Maybe you could be interested by t

Re: ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?)

On Wed, 24 Nov 2021 00:50:04 +0100 Denis 'GNUtoo' Carikli wrote: > Hi, > > On Tue, 23 Nov 2021 18:29:22 +0100 > Ludovic Courtès wrote: > > > When consensus cannot be met, maintainers have the last say. > > > > But again, my understanding is that there’s no new decision to be > > made here. >

Re: Proposal: Build timers

Do we even care that much about accuracy? I don't really care that the build takes 30 or 31 seconds, or even 1 minute, but I certainly care whether it takes 30s or 3h. I think this is also what SBUs give you: a rough estimate of which build is longer than the other. I think a simple proportional

Re: ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?)

Hi, On Tue, 23 Nov 2021 18:29:22 +0100 Ludovic Courtès wrote: > When consensus cannot be met, maintainers have the last say. > > But again, my understanding is that there’s no new decision to be made > here. If I understood correctly Florian, the argument here is that it is safe to redistribute

Re: Proposal: Build timers

Skimming through the research that lily provided our builds are reproducible so the changes in cpu cycles requirements should be same with any post-build implementation disabled, but i recognize that different CPUs might use different configuration that influences the calculation and it will be

Re: Proposal: Build timers

> Your Pokémon analogy is extremely flawed. The same CPU at a different > clockrate does not perform the same task in the same amount of cycles [1, 2]. > -- lily The theory is that the measurements could be taken after X amount of time to adjust the DPS that the CPU does to the package to get

Re: Replacing polkit by polkit-duktape on core-updates-frozen ?

Hello, Em terça-feira, 23 de novembro de 2021, às 14:18:10 -03, Ludovic Courtès escreveu: > > But my "test" fails the same: > > > > $ ./pre-inst-env guix build --system=aarch64-linux \ > > > > -e '(@ (gnu packages polkit) polkit)' -n |& grep polkit > > > > /gnu/store/dw11y85xfsb8hcg7w2cw57

Re: Proposal: Build timers

Am Montag, den 22.11.2021, 22:02 + schrieb Jacob Hrbek: > See the proposal in https://git.dotya.ml/guix.next/GUIX.next/issues/5 > > -- Jacob "Kreyren" Hrbek > > Sent with ProtonMail Secure Email. Your Pokémon analogy is extremely flawed. The same CPU at a different clockrate does not perform

Re: Help with package AppImage support

> Could you show the CMake output? I attach it in this email. It's a "TARGET NOT FOUND" :S > Sometimes there’s a -D flag you need to pass to help it find the > package. (I’m not much of a CMake person though…) yeah... I tried many, but I didn't find the one. > Thanks for working on it! Thank

Re: ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?)

Hi, "pelzflorian (Florian Pelz)" skribis: > On Sun, Nov 21, 2021 at 11:54:15AM +0100, pelzflorian (Florian Pelz) wrote: >> raid5atemyhomework wrote patches to add ZFS to Guix >> . I put them in CC. That there is >> no decision on ZFS and their patches is bad.

Re: Help with package AppImage support

Hello! Ekaitz Zarraga skribis: > I having issues with AppImageKit (see below)... I'm not able to make it load > the libsquashfuse I already packaged. CMake refuses to find it. > > I could use a hand to make this package work or at least some help with CMake, > because I'm not used to work with i

Re: Replacing polkit by polkit-duktape on core-updates-frozen ?

Hi, Maxim Cournoyer skribis: > gnu: polkit: Define polkit package variable based on architecture. > > * gnu/packages/polkit.scm (polkit): Rename to... > (polkit*): ... this. > (polkit-duktape): Adjust to inherit from polkit*. > (polkit-for-system): New procedure. > (polkit): New variable. LGTM!

Re: Using G-Expressions for public keys (substitutes and possibly more)

Liliana Marie Prikler skribis: > Am Montag, den 22.11.2021, 14:27 +0100 schrieb Ludovic Courtès: [...] > sexp->canonical-sexp is from the comment surrounding it a rather hacky > beast. I think (guile-)gcrypt could very well benefit from having a > better sexp construction API, but again that's

Re: Flag day for simplified package inputs

Hi, Jelle Licht skribis: > Ludovic Courtès writes: > >> Hi, >> >> Jelle Licht skribis: >> >>> When applying this and future bulk changes, could we perhaps list the >>> specific commits (+ commented shortlog line) in a file. To clarify, if >>> we were to store these commits in `.git-blame-ignor

Re: ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?)

On Mon, 22 Nov 2021 19:10:48 +0100 "pelzflorian (Florian Pelz)" wrote: > I don’t actually care about ZFS myself, but there should be a decision > because I think current badly supported ZFS makes people here unhappy. For people that really want the ZFS kernel module, would using an extra channel f

Re: Proposal: Build timers

Hi, On Tue, 23 Nov 2021 at 07:05, Julien Lepiller wrote: > LFS has a notion of a Standard Build Unit (SBU), that is the build > time of a particular package on your machine. Each package build time > is estimated in SBU. However, they do not take threads into account, > because the relation is n

Re: Proposal: Build timers

> Are you assuming here that the two machines are the same? Or are they > different? I am assuming that the two machines are the same with the exception of cpu frequency and threads that are used as a variable to assume the build time from known value. > This approximation would not even be a

Re: Proposal: Build timers

Le 23 novembre 2021 01:21:06 GMT-05:00, Jacob Hrbek a écrit : >I think you are overcomplicating the implementation.. What I am proposing is >to store the time value before and after the build and then log the >subtraction of these two values per package (or even per package's phase). > >For

Re: Proposal: Build timers

Hi, On Tue, 23 Nov 2021 at 06:21, Jacob Hrbek wrote: > 1. locally: Storing the value somewhere on the system and adding up to > it each build to provide more accurate average. Timing is already stored, see “guix build --log-file”. Give a look at ’/var/log/guix/drvs’. For instance, --8<--