Hi Tobias!
OOPS! I have missed your replies as I am not subscribed to mail-list. Just saw
your replies when I revisited the bug thread via web.
Please ignore my report rearding icons. It was due to missing icon-theme
installed.
There were issues with privilege and disk management. I have sent
Hi,
pkill9 skribis:
> So it seems it tries to look for substitutes when the profile hooks are built,
> not when profile.drv is built.
>
> Here is the output without build hooks:
> ```
> itsme@antelope ~> guix environment --ad-hoc hello
> The following derivation will be built:
>
Hi Brice,
Brice Waegeneire skribis:
> It looks like now most of the major updaters that relied on FTP (GNU,
> kernel.org, KDE and Gnbome) now support HTTP(S). I think we can close
> this
> bug.
Yup. There’s still the ‘gnu-ftp’ and the ‘xorg’ updaters which,
according to ‘guix refresh
Hi,
Mathieu Othacehe skribis:
>> Can we throw a little bit more memory at it? :-)
>
> That's what I did with ae1a0f758 :)
Oh, good.
Next we should of course find out why ‘guix system init’ is consuming so
much memory. I haven’t tried GC-profiling that yet, but here’s a rough
figure:
Hi Tobias,
On Thu, 30 Apr 2020 at 21:20, Tobias Geerinckx-Rice wrote:
>
> Hartmut, Zimoun,
>
> Hartmut Goebel 写道：
> > After processing options, guix need to "expanduser()" (as it is
> > called
> > in Python) on all arguments which are paths.
>
> If any Python (or other) software does this, it's
On Thu, Apr 30, 2020 at 12:15:47AM +0200, Björn Höfling wrote:
> This is broken in a very strange, indeterministic way. At first I
> thought you were right. But with modified searches, there are several
> hits. For example this query:
>
> https://ci.guix.gnu.org/search?query=^bor
>
> has several
Hartmut, Zimoun,
Hartmut Goebel 写道：
After processing options, guix need to "expanduser()" (as it is
called
in Python) on all arguments which are paths.
If any Python (or other) software does this, it's broken. File a
bug there.
This is the wrong thing to do and makes the GNU system an
On Thu, 30 Apr 2020 at 19:53, Leo Famulari wrote:
> > UNIX tools do what they do, and this wart is here to stay in a lot of tools.
> > Then at least make it consistent across all the tools UNIX has.
I do not have a clear opinion on the subject so I fall with the
Danny's wise opinion.
On Thu, Apr 30, 2020 at 07:53:21PM +0300, Alexandru-Sergiu Marton wrote:
> For more than a week now, whenever I do a guix pull, it tells me it's
> building a profile with 1 package. If I do other operations, such as
> removing a package, it displays the number of packages installed in my
> profile
On Thu, Apr 30, 2020 at 07:34:39PM +0200, Danny Milosavljevic wrote:
> UNIX has its warts, and this is a well-known one (use ${HOME} instead).
>
> If we did expanduser, I'm sure we'd be seeing bug reports about paths where
> there was a tilde in the actual file name, NOT as a expanduser mark.
>
For more than a week now, whenever I do a guix pull, it tells me it's
building a profile with 1 package. If I do other operations, such as
removing a package, it displays the number of packages installed in my
profile correctly (180-ish).
Here's the bit that it's outputting at the end of guix
Dear Hartmut,
On Thu, 30 Apr 2020 at 18:42, Hartmut Goebel
wrote:
> The short option "-L ~/…" works, since thin this case the shell resolves the
> tilde. Whereas for the long-option the shell does not revolve the tilde,
> since the tilde is in the middle of the argument. Yu can verify this
Hi,
This is not related to #40549.
The short option "-L ~/…" works, since thin this case the shell resolves the
tilde. Whereas for the long-option the shell does not revolve the tilde, since
the tilde is in the middle of the argument. Yu can verify this yourself easily:
$ python -c 'import
Dear,
On Thu, 30 Apr 2020 at 10:17, Hartmut Goebel
wrote:
>
> Specifying the home directory using `~` (tilde) in `--load-path` does
> not add the proper path to
>
> Does not work (not who "mypackage":
>
> guix package --load-path=~/path/tp/my/project -A mypackage
It seems related to long vs
Christopher Howard skribis:
> Works now, thanks! Am able to feed data in from HackRF using osmosdr
> source block.
>
> (As a side note to posterity reading this: I have the hackrf system
> service set in my config.scm, as described in the hackrf package
> description.)
Ok, closing the bug.
Christopher Howard skribis:
> I can see the osmosdr sink, insert it into the flow graph, and change
> the settings. However, when trying to build the flow graph, I receive
> the following error. Apparently you need to also update whatever
> environment variable controls the python module load
16 matches
Mail list logo
