Re: how to get the path of the logfile after an unsuccesful build?

[Catonano]

2018-03-11 7:28 GMT+01:00 Catonano :

>
>
> 2018-03-09 10:15 GMT+01:00 ng0 :
>
>> Hi,
>>
>> did we ever talk about that there's too little information on how to get
>> the current log file of a failed build? I need this right now (the full
>> log)
>> and I can't remember how, and making use of the log folder in
>> var/log/guix/ won't
>> help either.
>
>
> last time I needed to see a build log, I think it was the "-K" option
> passed to guix build
>
> If the build fails, you'll see a line at the end, in the terminal,
> reminding you that the build log is reachable at a certain location
>
>
>
Look, there's a manual page about that !

https://www.gnu.org/software/guix/manual/html_node/Debugging-Build-Failures.html#Debugging-Build-Failures

Are we talking about the same thing ?

Re: how to get the path of the logfile after an unsuccesful build?

[Catonano]

2018-03-09 10:15 GMT+01:00 ng0 :

> Hi,
>
> did we ever talk about that there's too little information on how to get
> the current log file of a failed build? I need this right now (the full
> log)
> and I can't remember how, and making use of the log folder in
> var/log/guix/ won't
> help either.


last time I needed to see a build log, I think it was the "-K" option
passed to guix build

If the build fails, you'll see a line at the end, in the terminal,
reminding you that the build log is reachable at a certain location

Re: how to get the path of the logfile after an unsuccesful build?

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Hartmut Goebel  skribis:
>
>> Am 09.03.2018 um 15:06 schrieb ng0:
>>> The daemon doesn’t keep logs for failed builds.
>>
>> I asked this a few month ago and was told this is a bug.
>
> It does keep build logs even for aborted and failed builds.  If you have
> evidence that it doesn’t, then please report it.  :-)

Oh, my bad.  I misremembered and didn’t check.

Thanks for the correction!

--
Ricardo

Re: how to get the path of the logfile after an unsuccesful build?

[Ludovic Courtès]

Hartmut Goebel  skribis:

> Am 09.03.2018 um 15:06 schrieb ng0:
>> The daemon doesn’t keep logs for failed builds.
>
> I asked this a few month ago and was told this is a bug.

It does keep build logs even for aborted and failed builds.  If you have
evidence that it doesn’t, then please report it.  :-)

Ludo’.

Re: bug#30706: Nginx service fails

[Ludovic Courtès]

Heya,

Danny Milosavljevic  skribis:

>> If you run this on an “old” GuixSD, ‘find-long-options’ is undefined.
>
> How can it be that (gnu services base) with find-long-options call is present
> but the (gnu build linux-boot)'s find-long options isn't present?

The service-upgrade code loads new service definitions in PID 1.
However, it does not force a reload of already-loaded modules.

What happens here is that (gnu build linux-boot), the one without
‘find-long-options’, is already available in PID 1.  Thus, when end up
using that one, which lacks ‘find-long-options’.

We could call ‘reload-module’, but that’s probably not a great idea as
it could cause breakage in previously-loaded code in PID 1.  So I think
the current approach is the safest, and breakage of this sort should be
quite rare; we should pay attention to such issues, though, and try hard
to avoid them.

(Note that there’s no problem once you reboot, of course.)

>>   1. ‘guix system reconfigure’ should probably register services one by
>>  one so that if one of the service expressions is erroneous, we
>>  don’t bork everything.  See ‘upgrade-shepherd-services’.
>
> Yes please.
>
>>   2. IWBN to delay execution of this whole default-tty thing to the
>>  #:start method.  Ideas, Danny?
>
> The idea was that if you specify a serial console at boot that you can
> actually log in at that console.
>
> So it's trying to find out whether, at the time of service start,
> there is a serial console specified (in the Linux command line), and if
> so, start an agetty.  Otherwise do not start that agetty.
>
> We could also do that without a guix service - but I thought it would be
> nice to have a guix service for it as well.

I agree.  I think what you did in
c32e3ddedd103318ca3f0a4bf0c91c91e2517806 is good.  The effect here is
just that agetty would fail to start upon reconfigure, but that’s an
acceptable limitation IMO.

Thanks,
Ludo’.

Re: Posts in languages other than English on help-guix?

[Ludovic Courtès]

Hi Julien,

julien lepiller  skribis:

> Oh, with the traditional version being on only one line, the following
> paragraph (bug reporting) is indented with the "zh" box.
>
> You could try adding a style="clear: both" to the last "p" block in
> the contact-medium div, and add "; clear: both" on each div (if there
> is a one-line paragraph, the next language block would be indented).

I don’t see the problem with IceCat 52.6.0-gnu1 from Guix:


Does this show up with different browsers?

Regardless, please feel free to commit something that works for you in
the guix-artwork.git repo.  I’m not much of a Web developer so any help
in that area is greatly appreciated.  :-)

Thanks,
Ludo’.

Re: Posts in languages other than English on help-guix?

[Ludovic Courtès]

Здра́вствуйте!

Oleg Pykhalov  skribis:

>   ("ru"
>"Подпишитесь на список рассылки «Help», чтобы получить помощь от
> сообщества GuixSD и GNU Guix по электронной почте.  Вы можете писать на 
> русском
> языке.")

Applied, thank you!

Ludo’.

Re: Posts in languages other than English on help-guix?

[Oleg Pykhalov]

Hello Alex,

Alex Kost  writes:

> Oleg Pykhalov (2018-03-07 12:46 +0300) wrote:
> 
>>> +`(("en"
>>> +   "Subscribe to the Help mailing list to get support from the GuixSD
>>> +and GNU Guix community via email.  You can post messages in English though 
>>> we
>>> +also accept other languages.")
>>
>>   ("ru"
>>"Подпишитесь на список рассылки «Help», чтобы получить помощь от
>> сообществ GuixSD и GNU Guix по электронной почте.  Вы можете писать на 
>> русском
>   ^
>
> I would write "сообщества" here (in a singular form, not the plural one)
> as there is a single GuixSD and GNU Guix community, not 2 separate
> communities.

I agree, apologies for this.  Also the original English text has a
“community” word, not “communities”.  So, at the end we got:

  ("ru"
   "Подпишитесь на список рассылки «Help», чтобы получить помощь от
сообщества GuixSD и GNU Guix по электронной почте.  Вы можете писать на русском
языке.")

Thanks,
Oleg.


signature.asc
Description: PGP signature

Re: installing python 2 and python 3 in the same profile

[Pjotr Prins]

On Wed, Mar 07, 2018 at 08:50:48AM +0100, Ricardo Wurmus wrote:
> Hi Guix,
> 
> with the introduction of the collision avoidance feature that prevents
> you from installing different variants of the same package into a
> profile we made it impossible to install “python” and “python@2” into
> the same profile.

I am happy with this idea. Maybe guix can give an informative message
in the case of Python.

Generally, mixing Python2 and 3 in one profile makes no sense. During a
course we gave this week we saw multiple occurances of students
messing up with python versions inside notebooks(!) That is how bad it
gets. I think the Python community rather screwed up on that one. That
is why people use virtualenv which is a full copy of a Python setup.

> It still works with ad-hoc environments, but manifests containing both
> Python versions cannot be instantiated any more.  This is too strict,
> because we know that these two variants don’t cause conflicts.

That is not my experience. Any mix is a problem.

> What can we do to make this feature a little smarter?
> 
> How about a package property that defines a “conflicts?” predicate that
> takes two packages of the same name and determines (e.g. by checking the
> major version) if these two packages are conflicting?  If no such
> predicate is provided we assume that packages with the same name cause a
> conflict and prevent installation.

I suggest not to go there. Teach people about profiles and
environments and all should be fine. You can support Python 3, Python
2.7 and Python 2.4 (etc), but it is better not to put them in one
profile. A profile represents a sane environment. That is how it
should be. 

I must add that in most of my Guix experience I relied on
$HOME/.guix-profile. But these days I hardly use that anymore. Just
for some basic desktop tooling. Using multiple profiles is the only
way to mix versions and keep a level of sanity.

Pj.
--