Ricardo Wurmus skribis:
> Ricardo Wurmus writes:
>
>> Hi Ludo,
>>
>>> Ricardo Wurmus skribis:
>>>
I’d like to push this to master in a couple of hours, unless there are
objections.
>>>
>>> Go for it, thanks a lot!
>>
>> Pushed to master with commit c4fb2b9f4. Thanks for helping me
>>
Hello,
Ricardo Wurmus skribis:
> The problem might be that we are using PYTHONPATH at all. On other
> distributions this is usually not required and thus doesn’t cause any
> problems.
It’s not required because Python modules live at a fixed location, no?
How does pip deal with that? I suppos
Hi,
Konrad Hinsen skribis:
> On 14/03/2018 12:39, Hartmut Goebel wrote:
>> Am 13.03.2018 um 22:52 schrieb Ludovic Courtès:
>>>2. Use different package names when we know things can be
>>> parallel-installed: “python2” vs. “python” (I’m talking about the
>>> package name, not its
Ludovic Courtès writes:
> Yes. OTOH we use the “python2-” prefix for 2.x packages and “python-”
> for 3.x packages.
Indeed. What a mess!
>> This does of course raise the question of how this will evolve in the
>> long run, but since so many bad decisions were already taken, I am not
...
> Not
On Tue, Mar 13, 2018 at 01:55:28AM +0530, Aakanksha Jain wrote:
> I have completed the GNU Guix installation using this script
> https://git.savannah.gnu.org/cgit/guix.git/tree/etc/guix-install.sh
>
> But while trying to run hello package, I get following error(image attached)
The error message i
Hi all,
to address problems with running Guix-built software on RHEL 6 due to
the low kernel version it reports, I have forked the “core-updates”
branch containing the glibc patch and pushed it as “rhel6” to the Guix
repository on Savannah.
The build farm at berlin.guixsd.org is currently buildin
Hi,
given the ongoing discussion around Python show that my explanation was
not good enough. I'll try to summarize and give more background.
With regard to Python, guix currently has a major issue, which my
proposals are addressing. There are other issues (like naming the
executables, the "wrappe
I succesfully built ovmf firmware for aarch64 on my aarch64 board.
Currently it builds for x86_64 and i686 on %intel platforms only. I
think it's best to create a make-ovmf-firmware procedure to build the
firmware for x86_64/i686/aarch64/armhf, but there's not a clear
cross-grade path from our curr
Am 14.03.2018 um 08:49 schrieb Pjotr Prins:
> On Tue, Mar 13, 2018 at 11:02:03PM +0100, Hartmut Goebel wrote:
>> Am 13.03.2018 um 22:44 schrieb Pjotr Prins:
>>> Another problem is that it does not cover special cases where, for
>>> example you compile Python with SSL and without. You don't want the
Efraim Flashner transcribed 2.0K bytes:
> I succesfully built ovmf firmware for aarch64 on my aarch64 board.
> Currently it builds for x86_64 and i686 on %intel platforms only. I
> think it's best to create a make-ovmf-firmware procedure to build the
> firmware for x86_64/i686/aarch64/armhf, but th
On Thu, Mar 15, 2018 at 08:29:37PM +, ng0 wrote:
> Efraim Flashner transcribed 2.0K bytes:
> > I succesfully built ovmf firmware for aarch64 on my aarch64 board.
> > Currently it builds for x86_64 and i686 on %intel platforms only. I
> > think it's best to create a make-ovmf-firmware procedure
11 matches
Mail list logo
