Re: RFC: Portability should be a higher priority for Guix (was Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.)

[Ricardo Wurmus]

Hi Mark,

> However, I do feel frustrated by the fact that it's considered
> acceptable in this community to leave non-x86_64 users with broken
> systems in the name of "moving things forward" for x86_64 users.

I don’t think this is true.

> When I suggest that the community would not take certain suggestions
> seriously, e.g. the suggestion to block upgrades or merges that would
> break non-x86_64 systems, that statement has some meaning.  I means that
> I expect that most people here would disagree, and that the maintainers
> would rule in favor of "moving forward" at full speed, and that it will
> be the responsibility of the tiny number of non-x86_64 Guix users to fix
> portability bugs as quickly as needed so that the x86_64-using majority
> need not suffer any delays.

It’s neither about “moving forward” at all costs nor about “full speed”;
while we are generally moving forward, it’s hardly at full speed.  The
last core-updates merge was blocked for months, but it contained
critical fixes that had to be worked around in other branches, which was
an untenable position given the number of developers.

FWIW, I’m using a i686 machine with 2GB RAM myself, and I did test the
core-updates things on that machine (as far as the software is concerned
that I’m using).  I was rather surprised by the GRUB bug, to be honest.

I do agree with your laments about a lack of popularity of non-x86_64
systems and thus developers, but I do think this has been getting better
with the work this community has done to support Guix for the aarch64
and armhf architectures, and by adding aarch64/armhf build servers to
the build farm.  We can and should do more of this, but it won’t happen
by decree.

One thing that would help, in my opinion, is to purchase hardware and
make it available to interested developers and/or join these new
machines to the build farm.  We would need to come to an agreement about
at least these things:

  * what exact system configurations do we want?
  * where would these systems be hosted?
  * how many do we need / can we afford to buy and pay hosting fees for?

The last time this has come up the discussion kinda tapered out.  It
would be good if someone or a group of people would volunteer to take
this on and drive this project to its conclusion.

--
Ricardo

Re: RFC: Portability should be a higher priority for Guix (was Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.)

[Kei Kebreau]

Mark H Weaver  writes:

> Hi Ludovic,
>
> l...@gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver  skribis:
>>
>>> The end result is that the wishes of the x86_64-using majority are the
>>> only ones that seem to matter in this community, and other users are
>>> frequently left in a bad spot.  This makes it increasingly unlikely that
>>> we'll ever gain a significant number of non-x86_64 users.
>>
>> This kind of rant is really unhelpful.  You’re shouting at someone who
>> *is* doing the work of keeping things running.
>
> I wasn't actually shouting, but in retrospect I can see how it came off
> that way.  I apologize for any hurt feelings that I caused.
>
> This is not Marius' fault, and I didn't intend to target him
> specifically.  I'm grateful for the large amount of important work that
> he does on Guix.
>
> However, I do feel frustrated by the fact that it's considered
> acceptable in this community to leave non-x86_64 users with broken
> systems in the name of "moving things forward" for x86_64 users.
>
> Portability is important to the long-term health of the free software
> movement.  Especially given that fact that Intel has long ago stopped
> producing processors that can be used without large amounts of nonfree
> software (including the Intel Management Engine), I think we should work
> to ensure that Guix works well for users of non-x86_64 systems.
>
> The origin of this problem is not in the Guix project.  Ultimately, it's
> due to the fact that x86_64 has far too much market share among
> GNU/Linux developers, and therefore the upstream projects upon which
> Guix depends are not being sufficiently tested on other platforms.
>
> However, there is one aspect of Guix that is greatly exacerbating this
> problem: our impatience to always have the latest software, even if it
> breaks other systems, is a serious problem in my view.
>
> It means that if I want to ensure that Guix works well for i686 or armhf
> users, then I would need to start trying to use Guix on those systems
> for real work, which at the present time would entail almost
> single-handedly fixing all of the portability bugs in all of the
> software that I use, at the full pace of upstream development.  I would
> need to keep this up for long enough to make Guix appear to be a safe
> choice for i686 or armhf users, so that some of them might help work on
> these portability issues in the future.
>
> Another problem is that Guile 2.2's compiler has become so heavy that
> it's nearly unbearable to use on slower hardware.  Simply running "make"
> in my Guix git checkout after updating on my mips-based Yeeloong is so
> slow that I'm in the habit of letting it run overnight.
>
> So again, and I'm saying this calmly but with great concern: given the
> current priorities of the project, I could not recommend Guix to users
> of non-x86_64 architectures, and I don't see how we can fix that without
> attracting more developers who use those architectures.  However, I
> don't see how we could attract those developers if we continue to
> prioritize "moving forward" at full speed for x86_64 users, even when it
> breaks other systems.
>
>> Generalizations about “this community” obviously make no sense.  You are
>> a part of “this community” so it cares just as much as you do.
>
> By that reasoning, since I'm part of the community of humans on planet
> Earth, the community of humans on planet Earth therefore cares as much
> about free software as I do.
>
> When I suggest that the community would not take certain suggestions
> seriously, e.g. the suggestion to block upgrades or merges that would
> break non-x86_64 systems, that statement has some meaning.  I means that
> I expect that most people here would disagree, and that the maintainers
> would rule in favor of "moving forward" at full speed, and that it will
> be the responsibility of the tiny number of non-x86_64 Guix users to fix
> portability bugs as quickly as needed so that the x86_64-using majority
> need not suffer any delays.  The problem is, we would need a *lot* more
> non-x86_64 developers in our community to make that work, and we cannot
> attract those developers given the current policies.
>
>> Please let’s work in a friendly manner towards finding solutions to the
>> problems.
>
> I'm open to suggestions.  Do you see any solution to the problem of how
> to attract more non-x86_64 users, given our current policies?
>
>  Thanks,
>Mark

I am interested in helping with non-x86_64 issues. Particularly, helping
with i686-related changes should be just a change in workflow, but I'm
interested in obtaining freedom-respecting non-x86 hardware (or at least
using a virtual machine as close as possible to real hardware
configurations). Any recommendation or links for where I can get a
Yeeloong laptop or what freedom-respecting armhf computers are
available?


signature.asc
Description: PGP signature

Re: KDFONTOP/PIO_UNIMAPCLR: Input/output error

[Ludovic Courtès]

l...@gnu.org (Ludovic Courtès) skribis:

> Danny Milosavljevic  skribis:
>
>>> PIO_UNIMAPCLR: Input/output error
>>> 3) PIO_UNIMAPCLR: Input/output error
>>> 
>>> Anything to worry about?
>>
>> According to 
>> https://elixir.bootlin.com/linux/v3.2/source/include/linux/kd.h#L70
>> that's trying to clear the Unicode -> font map (that is, charmap).
>>
>> In Linux, ./drivers/tty/vt/vt_ioctl.c implements it.
>>
>> Can't see how that ever ends up in -EIO O_o
>
> Sometimes we also get:
>
>   putfont: KDFONTOP: Input/output error
>
> In both cases, the warning comes from the ‘setfont’ program, invoked
> from ‘console-font-shepherd-services’.
>
> I’ve looked at the code and man pages and like you, I don’t see where
> EIO comes from.  Maybe it’s a generic ioctl error that’s return before
> we reach the actual ioctl implementation in the VT driver, sorta like
> EBADF?

I think I have a plausible explanation.  :-)  The EIO comes from
‘hung_up_tty_ioctl’ in drivers/tty/tty_io.c.  This is because mingetty
would call ‘vhangup’, and presumably, there was a time window where
‘setfont’ would find itself talking to a hung-up terminal.  QED.

Anyway, in commit a043b5b81a080c47e24298c80857919b9ea21bb2 I’ve added
--nohangup to mingetty and now ‘setfont’ is happy, and so am I.

Ludo’.

Re: (Ab?)using aliases to set ls' and others' colours

[Ricardo Wurmus]

Hi Tobias,

> Tobias Geerinckx-Rice wrote:
>> Björn Höfling wrote:
>>> ls has a colored output. Nice.
>>> ls | less has ugly escape sequences. Only ls --color=no | less
>>> works.
>>
>> I'd be surprised if ‘ls | less -R’ didn't (and that would be a bug).
>>
>> Otherwise, this is standard behaviour for both ‘ls’ and ‘less’.
>
> Apologies, I made a reado.
>
> ‘ls | $foo’ should indeed detect a missing tty and stop spewing colour
> automatically. At least if ‘ls’ is properly aliased to ‘ls
> --color=auto’.
>
> Instead, it is aliased[0] to use ‘--color’ — short for ‘ls
> --color=always’ — for reasons I cannot understand. We do the same for
> ‘grep’.

I think this is simply a mistake.  Using “--color=auto” is correct here.

> On the other hand, what I consider an obvious bug has been around
> since literal forever[1], so maybe I'm missing something obvious
> here. I've CC'd the original author. If everyone agrees or nobody
> responds, I'd like to change it to something less aggressive before
> 0.15.[2]

No objections from me.  Thank you!

--
Ricardo

Re: (Ab?)using aliases to set ls' and others' colours

[Ludovic Courtès]

Tobias Geerinckx-Rice  skribis:

> Instead, it is aliased[0] to use ‘--color’ — short for ‘ls
> --color=always’ — for reasons I cannot understand. We do the same for
> ‘grep’.

I fixed this in commit 9fd877247de6efec3aec53e93db5323a97d7b05e.

Thanks for reporting the issue!

Ludo’.

Re: GSoC: Adding a web interface similar to the Hydra web interface

[Jelle Licht]

2018-07-04 22:54 GMT+02:00 Tatiana Sholokhova :

> Hi all,
>
>
Hi Tatiana,


> I just committed the code I wrote trying to improve pagination. I screwed
> up a bit with the new pagination.
> The problem I encountered is following. If we want to maintain a link to
> the previous page we have to filter the database table entries with to
> types of filters: one with lower bound on the id, and the other with the
> upper bound. As we do so simultaneously with limiting the query output to
> the maximal page size, we need to change the ordering type depending on the
> type of the filter. At the moment I am not sure, what it the best way to
> implement database query with such properties. Could you please take a look
> on the commit and share your ideas on that?
>

> The current implementation of pagination works correctly but it does not
> support link to the previous page (first, and next only).
>

It has been some time since I last had a look at databases, so you have my
apologies
in advance if what I am saying does not really apply, or is even not
entirely correct.

You could perhaps have a look at reversing the sort order, and replace ">"
with "<" and "<"
with "<" in your WHERE clauses. The query to the previous page would be
similar to
retrieving the next page, but basically reversing the order you would page
through the results,
if that makes any sense.

If this works, you could also hack together a maybe-efficient query to
retrieve the items
for the last page; simply insert the maximum possible value in your query,
and retrieve the
previous page with regards to that maximum value. In the current case, you
could enter the
highest possible value any id can have.

If it is possible for new items to show up on previous pages as well (so
with id's that are lower
than the highest id), you would need to replace your sorting and filtering
to act on a composite
value of e.g. , instead of on only the id value.


>
> I have been trying to improve pagination for a while, and I now am
> thinking about starting the parallel work on the implementation of the
> features we listed before. What do you think about it?
>

> Best regards,
> Tatiana
>
> Good luck, and HTH!

- Jelle

Re: GSoC: Adding a web interface similar to the Hydra web interface

[Tatiana Sholokhova]

Hi all,

I just committed the code I wrote trying to improve pagination. I screwed
up a bit with the new pagination.
The problem I encountered is following. If we want to maintain a link to
the previous page we have to filter the database table entries with to
types of filters: one with lower bound on the id, and the other with the
upper bound. As we do so simultaneously with limiting the query output to
the maximal page size, we need to change the ordering type depending on the
type of the filter. At the moment I am not sure, what it the best way to
implement database query with such properties. Could you please take a look
on the commit and share your ideas on that?

The current implementation of pagination works correctly but it does not
support link to the previous page (first, and next only).

I have been trying to improve pagination for a while, and I now am thinking
about starting the parallel work on the implementation of the features we
listed before. What do you think about it?

Best regards,
Tatiana

ср, 27 июн. 2018 г. в 21:56, Ludovic Courtès :

> Hi Tatiana,
>
> Tatiana Sholokhova  skribis:
>
> > On the last week, I had fallen out of the process. I had been having
> exams
> > at the university since the beginning of June. The last exam was
> > rescheduled and that has affected my plans. I am sorry for that. Now the
> > semester is finished and I am having much more time to focus on our
> > project. I am very happy to pass the first evaluation. It is a pleasure
> for
> > me to work with such a great team!
>
> Thank you, and thanks for letting us know.
>
> > In a few days, I am going to implement the whitelist for the static files
> > and improve pagination tool performance as we discussed before. Also, I
> > intend to make the pagination tool universal and add it to the page which
> > displays all builds of a selected evaluation.
>
> Sounds cool!  I haven’t followed your work as closely as I was hoping
> for, but it seems like we could merge it quickly, notably because
> everyone wants these enhancements.  :-)
>
> > Do you think it would be okay if I add auxiliary pagination filters to
> > the request which retrieves builds from the database?
>
> Why not.  Depending on the filter, We may need to add indexes to the
> database (see the bottom of ‘schema.sql’) so that requests aren’t too
> slow.
>
> Thank you for the update!
>
> Ludo’.
>

RFC: Portability should be a higher priority for Guix (was Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.)

[Mark H Weaver]

Hi Ludovic,

l...@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver  skribis:
>
>> The end result is that the wishes of the x86_64-using majority are the
>> only ones that seem to matter in this community, and other users are
>> frequently left in a bad spot.  This makes it increasingly unlikely that
>> we'll ever gain a significant number of non-x86_64 users.
>
> This kind of rant is really unhelpful.  You’re shouting at someone who
> *is* doing the work of keeping things running.

I wasn't actually shouting, but in retrospect I can see how it came off
that way.  I apologize for any hurt feelings that I caused.

This is not Marius' fault, and I didn't intend to target him
specifically.  I'm grateful for the large amount of important work that
he does on Guix.

However, I do feel frustrated by the fact that it's considered
acceptable in this community to leave non-x86_64 users with broken
systems in the name of "moving things forward" for x86_64 users.

Portability is important to the long-term health of the free software
movement.  Especially given that fact that Intel has long ago stopped
producing processors that can be used without large amounts of nonfree
software (including the Intel Management Engine), I think we should work
to ensure that Guix works well for users of non-x86_64 systems.

The origin of this problem is not in the Guix project.  Ultimately, it's
due to the fact that x86_64 has far too much market share among
GNU/Linux developers, and therefore the upstream projects upon which
Guix depends are not being sufficiently tested on other platforms.

However, there is one aspect of Guix that is greatly exacerbating this
problem: our impatience to always have the latest software, even if it
breaks other systems, is a serious problem in my view.

It means that if I want to ensure that Guix works well for i686 or armhf
users, then I would need to start trying to use Guix on those systems
for real work, which at the present time would entail almost
single-handedly fixing all of the portability bugs in all of the
software that I use, at the full pace of upstream development.  I would
need to keep this up for long enough to make Guix appear to be a safe
choice for i686 or armhf users, so that some of them might help work on
these portability issues in the future.

Another problem is that Guile 2.2's compiler has become so heavy that
it's nearly unbearable to use on slower hardware.  Simply running "make"
in my Guix git checkout after updating on my mips-based Yeeloong is so
slow that I'm in the habit of letting it run overnight.

So again, and I'm saying this calmly but with great concern: given the
current priorities of the project, I could not recommend Guix to users
of non-x86_64 architectures, and I don't see how we can fix that without
attracting more developers who use those architectures.  However, I
don't see how we could attract those developers if we continue to
prioritize "moving forward" at full speed for x86_64 users, even when it
breaks other systems.

> Generalizations about “this community” obviously make no sense.  You are
> a part of “this community” so it cares just as much as you do.

By that reasoning, since I'm part of the community of humans on planet
Earth, the community of humans on planet Earth therefore cares as much
about free software as I do.

When I suggest that the community would not take certain suggestions
seriously, e.g. the suggestion to block upgrades or merges that would
break non-x86_64 systems, that statement has some meaning.  I means that
I expect that most people here would disagree, and that the maintainers
would rule in favor of "moving forward" at full speed, and that it will
be the responsibility of the tiny number of non-x86_64 Guix users to fix
portability bugs as quickly as needed so that the x86_64-using majority
need not suffer any delays.  The problem is, we would need a *lot* more
non-x86_64 developers in our community to make that work, and we cannot
attract those developers given the current policies.

> Please let’s work in a friendly manner towards finding solutions to the
> problems.

I'm open to suggestions.  Do you see any solution to the problem of how
to attract more non-x86_64 users, given our current policies?

 Thanks,
   Mark

New French PO file for 'guix' (version 0.15.0)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'guix' has been submitted
by the French team of translators.  The file is available at:

http://translationproject.org/latest/guix/fr.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

http://translationproject.org/latest/guix/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/guix.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: Installation-Protocol for GuixSD x86_64 v0.15-preview

[Björn Höfling]

On Tue, 03 Jul 2018 23:42:28 +0200
l...@gnu.org (Ludovic Courtès) wrote:

[..]
> Did you have troubles with substitutes?  In particular, did it hang as
> described in ?  (I’m still experiencing it
> occasionally and I can’t believe I’m the only one.)

No. But it looks like you found your example to reproduce.

Björn


pgpDHqTfLX23E.pgp
Description: OpenPGP digital signature

Re: (Ab?)using aliases to set ls' and others' colours

[Björn Höfling]

On Tue, 03 Jul 2018 13:38:34 +0200
Tobias Geerinckx-Rice  wrote:

> Tobias Geerinckx-Rice wrote:
> > Björn Höfling wrote:  
> >> ls has a colored output. Nice.
> >> ls | less has ugly escape sequences. Only ls --color=no | less
> >> works.  

[..]

> 
> Perhaps it was assumed that ‘--color’ on its own implies ‘auto’ 
> instead of ‘always’ (I could see how that could happen)? Or 
> ‘--color=auto’ is too cautious, and disables colour in a situation 
> where the author expects it? In that case I don't think the 
> trade-off is worth it.


Just for reference: Here is what my Ubuntu has in /etc/skel/.bashrc:

# enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval 
"$(dircolors -b)"
alias ls='ls --color=auto'
#alias dir='dir --color=auto'
#alias vdir='vdir --color=auto'

alias grep='grep --color=auto'
alias fgrep='fgrep --color=auto'
alias egrep='egrep --color=auto'
fi

[..]

> Oh, I don't know.
> 
> This is the kind of trivial bug that would've put me off a distro, 
> I guess.

Yeah, it's one of those nasty little things that are totally silly but
on the other hand are expected to "just work".

Björn


pgpTWKMRySbR_.pgp
Description: OpenPGP digital signature

Re: Installation-Protocol for GuixSD x86_64 v0.15-preview

[Björn Höfling]

Hi Tobias,

On Tue, 03 Jul 2018 12:49:12 +0200
Tobias Geerinckx-Rice  wrote:

> Hullo Bjrn,
> 
> Björn Höfling wrote:
> > Hi people,
> >
> > as Ludo "requested", today I freshly installed GuixSD in a QEMU
> > environment (x86_64 on both host and virtual env) to check the
> > installation process of the upcoming release.  
> 
> Wow. Thanks!
> 
> You've motivated me to try it on a headless server (if that 
> works).

Are you doing that with QEMU? I would be interested in improving my
Q-foo and know how to create a headless, SSH-only QEMU-server.

 
> > qemu-system-x86_64 -m 1024 -smp 1 \
> >   -net user -net nic,model=virtio -boot menu=on \
> >   -drive file=guixsd-install-0.14.0.system.iso \
> >   -drive file=guixsd.img
> >
> > I prefered writing the disk like this:
> >
> >  -drive readonly,media=cdrom,\
> > file=/gnu/store/70p7140n5igrqsfl989cxfzx6q3czc9a-image.iso
> >
> > In that way, I can use the RO store entry and QEMU will not 
> > complain
> > about not being able to write to.  
> 
> My QEMU-FU is, to say the least, rusty.
> 
> Do I parse this correctly as two separate (but related) 
> suggestions: adding ‘readonly,media=cdrom’ to silence the 
> complaint and ‘file=/gnu/store/...’ to use an image from the 
> store?
> 
> > Should we update the manual?  
> 
> ...if so: +1 to the first suggestion.

Yes, that is what I mean. Maybe the "readonly" is superfluous with
"media=cdrom", I have to read/try that.

I can write a docs-patch by the end of the week.

 
> The second one seems to depend on your situation. The manual 
> assumes you've downloaded the image (probably not using ‘guix 
> download’) instead of building it from scratch, but we could 
> document both. Especially since the latter can be written as one 
> easy command:
> 
>   qemu-system-x86_64 [...] -drive readonly,media=cdrom,file=$(guix 
>   ...)

Yes, we should take that as a separate thing.

AFAIK the combination might be a bit dangerous: Building the
installation media is not (yet?) reproducible, so the $(guix ...)
command will produce every time a new image, not just a reference on
the existing store item as would be the case for reproducibly-stable
package builds.

[...]

> > I tried instead wget or curl. But both are not there. Do we have
> > "HTTP client" tools in the installer package to test the network 
> > this
> > way? Or is this too heavy in size for the installer? Do we have
> > anything else to give the user at it's hand besides ping?  
> 
> ‘guix download’. (Hey, if we include a static example and its hash 
> in the manual you'll even know when your being MITM'd by an 
> incompetent!)

Of cause. Cool!

 
[..]

> > 6) Editors: When it comes about editing the standard config, 
> > there are
> > three editors mentioned: zile, nano, nvi. The first ones are 
> > fired up as
> > named, for "nvi" the command is "vi". This is not obvious for 
> > everyone.  
> 
> Thorough testing :-) Good catch! Do you have time to submit a 
> patch?

Yes. This week.

 
[..]

> > 12) ls | less
> >
> > ls has a colored output. Nice.
> > ls | less has ugly escape sequences. Only ls --color=no | less 
> > works.  
> 
> I'd be surprised if ‘ls | less -R’ didn't (and that would be a 
> bug).
> 
> Otherwise, this is standard behaviour for both ‘ls’ and ‘less’. If 
> other distributions wrap it in magick, it would be interesting to 
> know how, and where, and if it's clean enough for us to copy.

I saw your discussions on IRC and look forward for a patch :-)

Björn


pgp5bcZ1x5Kum.pgp
Description: OpenPGP digital signature

Re: KDFONTOP/PIO_UNIMAPCLR: Input/output error

[Marius Bakke]

l...@gnu.org (Ludovic Courtès) writes:

> Hello Danny & all,
>
> Danny Milosavljevic  skribis:
>
>>> PIO_UNIMAPCLR: Input/output error
>>> 3) PIO_UNIMAPCLR: Input/output error
>>> 
>>> Anything to worry about?
>>
>> According to 
>> https://elixir.bootlin.com/linux/v3.2/source/include/linux/kd.h#L70
>> that's trying to clear the Unicode -> font map (that is, charmap).
>>
>> In Linux, ./drivers/tty/vt/vt_ioctl.c implements it.
>>
>> Can't see how that ever ends up in -EIO O_o
>
> Sometimes we also get:
>
>   putfont: KDFONTOP: Input/output error
>
> In both cases, the warning comes from the ‘setfont’ program, invoked
> from ‘console-font-shepherd-services’.
>
> I’ve looked at the code and man pages and like you, I don’t see where
> EIO comes from.  Maybe it’s a generic ioctl error that’s return before
> we reach the actual ioctl implementation in the VT driver, sorta like
> EBADF?
>
> Until we find out, I’d like to just silence the warnings:
>
> --- a/gnu/services/base.scm
> +++ b/gnu/services/base.scm
> @@ -754,8 +754,10 @@ to add @var{device} to the kernel's entropy pool.  The 
> service will fail if
>  ;; systemd's vconsole support, let's not treat
>  ;; this as an error.
>  (case (status:exit-val
> -   (system* #$(file-append kbd "/bin/setfont")
> -"-C" #$device #$font))
> +   (with-error-to-port (%make-void-port "w")
> + (lambda ()
> +   (system* #$(file-append kbd 
> "/bin/setfont")
> +"-C" #$device #$font
>((0 71) #t)
>(else #f
>   (stop #~(const #t))
>
> Sounds good?

Less scary warnings in the first impression sounds great :-)

There should be an explaining comment with that code though.


signature.asc
Description: PGP signature

Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.

[Marius Bakke]

l...@gnu.org (Ludovic Courtès) writes:

> Hello,
>
> Mark H Weaver  skribis:
>
>> Marius Bakke  writes:
>
> [...]
>
>>> I'm sorry, I forgot to address your actual concerns.  The (buggy)
>>> workaround was put in place and discussed in
>>> .  The meat of it can be found in (guix
>>> build-system meson):
>>>
>>> ;; XXX PatchELF fails to build on armhf, so we skip
>>> ;; the 'fix-runpath' phase there for now.  It is used
>>> ;; to avoid superfluous entries in RUNPATH as described
>>> ;; in , so armhf may now
>>> ;; have different runtime dependencies from other arches.
>>
>> Thanks for this, but I'd still like to know the answer to my questions:
>> "What does the [fix-runpath] phase accomplish, and how will armhf users
>> be disadvantaged by the removal of that phase?"
>
> As discussed in  and
> , Meson does not (or did not) adjust
> RUNPATHs upon installation (contrary to what Libtool does, for
> instance.)
>
> Consequently, the RUNPATH is left with /tmp/guix-build-… entries, which
> is not great but okay, but more importantly if usually lacks OUTPUT/lib
> as well.

I haven't seen /tmp in RUNPATH during my testing, which would be a
*huge* security problem.  The only consequence I've noticed from
dropping 'fix-runpath' is that it sometimes contain entries that are not
in NEEDED (but often required for a "neighbour" library, so no big deal).

> However, the commit Marius referred to¹ as well as what you reported for
> Epiphany in #31974 suggest that things are improving in Meson proper,
> and that we might be able to remove that ‘fix-runpath’ phase altogether
> soon.
>
> I think we should simply try building things without ‘fix-runpath’ and
> see if ‘validate-runpath’ reports anything.
>
> Thoughts?

I'm in favor of removing it on all architectures and see how it fares.
I suspect the main reason for adding it was that /lib was often
lacking, which is mitigated by 09a45ffb146fda75b87f89c729c31d1da5bf93da.

I'll prepare patches for this for the next staging round.


signature.asc
Description: PGP signature

Re: Guix support in cachix

[Marius Bakke]

l...@gnu.org (Ludovic Courtès) writes:

> Hello!
>
> Oleg Pykhalov  skribis:
>
>> Domen Kožar  recently was in #guix (IRC) 2 days ago asking
>> about support of Guix in cachix.  Also he opened an issue on GitHub:
>>
>>> I'm opening this issue for interest around supporting Guix.
>>
>> [1] https://github.com/cachix/cachix/issues/85
>
> Cachix looks interesting!  It’s good to collaboratively provide
> binaries.  It’s easier than having everyone set up ‘guix publish’, at
> the cost of being more centralized.
>
> The “cachix use ” example on https://cachix.org/ glosses over
> security “details” though.  I wonder how one gets to authenticate a
> particular user of Cachix and to authorize binaries coming from them.
> There’s also the issue that said user could be publishing binaries they
> themselves obtained from a source that you do not trust yourself.  Tough
> issues!

I asked about discovering signing keys and apparently you'll find it at
https://.cachix.net, and that's the substitute URL too.

It looks useful for those who don't want to or can't publish their own
substitutes.  And `guix challenge` makes it easy to verify the builds
coming from a particular "channel".

I would not want to publish all my builds there, though.  Not sure how
it would be integrated on the client side.


signature.asc
Description: PGP signature

KDFONTOP/PIO_UNIMAPCLR: Input/output error

[Ludovic Courtès]

Hello Danny & all,

Danny Milosavljevic  skribis:

>> PIO_UNIMAPCLR: Input/output error
>> 3) PIO_UNIMAPCLR: Input/output error
>> 
>> Anything to worry about?
>
> According to 
> https://elixir.bootlin.com/linux/v3.2/source/include/linux/kd.h#L70
> that's trying to clear the Unicode -> font map (that is, charmap).
>
> In Linux, ./drivers/tty/vt/vt_ioctl.c implements it.
>
> Can't see how that ever ends up in -EIO O_o

Sometimes we also get:

  putfont: KDFONTOP: Input/output error

In both cases, the warning comes from the ‘setfont’ program, invoked
from ‘console-font-shepherd-services’.

I’ve looked at the code and man pages and like you, I don’t see where
EIO comes from.  Maybe it’s a generic ioctl error that’s return before
we reach the actual ioctl implementation in the VT driver, sorta like
EBADF?

Until we find out, I’d like to just silence the warnings:

--- a/gnu/services/base.scm
+++ b/gnu/services/base.scm
@@ -754,8 +754,10 @@ to add @var{device} to the kernel's entropy pool.  The service will fail if
 ;; systemd's vconsole support, let's not treat
 ;; this as an error.
 (case (status:exit-val
-   (system* #$(file-append kbd "/bin/setfont")
-"-C" #$device #$font))
+   (with-error-to-port (%make-void-port "w")
+ (lambda ()
+   (system* #$(file-append kbd "/bin/setfont")
+"-C" #$device #$font
   ((0 71) #t)
   (else #f
  (stop #~(const #t))

Sounds good?

Ludo’.

Re: preparing the next release v0.15.0

[Ludovic Courtès]

l...@gnu.org (Ludovic Courtès) skribis:

> In other news, these installation tests pass for me, as of
> a51cf16031c974ffa238e5dd9ced32f0d68c9227, on x86_64:

All of these pass at this commit:

PASS: /gnu/store/rdaib0mw3r81h1d87kv669z9wd49072s-installed-os
PASS: /gnu/store/9wzidlrcv38rspvai26k62h64ba1dclf-separate-home-os
PASS: /gnu/store/vjd7q1sxf383d0gn5hhhraqlh7qmjldz-btrfs-root-os
PASS: /gnu/store/2p4vfrfxxp57n74wz9288q8zv2sgmzfw-iso-image-installer
PASS: /gnu/store/7wv54d8abkl7l1mifwfwa0za0ypf5r9l-raid-root-os
PASS: /gnu/store/kj85ns1kymx9g2a12cr85h955bsh3ssx-encrypted-root-os

Ludo’.

Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.

[Ludovic Courtès]

Hello,

Mark H Weaver  skribis:

> Marius Bakke  writes:

[...]

>> I'm sorry, I forgot to address your actual concerns.  The (buggy)
>> workaround was put in place and discussed in
>> .  The meat of it can be found in (guix
>> build-system meson):
>>
>> ;; XXX PatchELF fails to build on armhf, so we skip
>> ;; the 'fix-runpath' phase there for now.  It is used
>> ;; to avoid superfluous entries in RUNPATH as described
>> ;; in , so armhf may now
>> ;; have different runtime dependencies from other arches.
>
> Thanks for this, but I'd still like to know the answer to my questions:
> "What does the [fix-runpath] phase accomplish, and how will armhf users
> be disadvantaged by the removal of that phase?"

As discussed in  and
, Meson does not (or did not) adjust
RUNPATHs upon installation (contrary to what Libtool does, for
instance.)

Consequently, the RUNPATH is left with /tmp/guix-build-… entries, which
is not great but okay, but more importantly if usually lacks OUTPUT/lib
as well.

However, the commit Marius referred to¹ as well as what you reported for
Epiphany in #31974 suggest that things are improving in Meson proper,
and that we might be able to remove that ‘fix-runpath’ phase altogether
soon.

I think we should simply try building things without ‘fix-runpath’ and
see if ‘validate-runpath’ reports anything.

Thoughts?

Ludo’.

¹ 
https://github.com/mesonbuild/meson/commit/e3757e3d3cf24327c89dd3fc40f6cc933510f676

Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.

[Ludovic Courtès]

Hi Mark,

Mark H Weaver  skribis:

> The end result is that the wishes of the x86_64-using majority are the
> only ones that seem to matter in this community, and other users are
> frequently left in a bad spot.  This makes it increasingly unlikely that
> we'll ever gain a significant number of non-x86_64 users.

This kind of rant is really unhelpful.  You’re shouting at someone who
*is* doing the work of keeping things running.  And yes, when you do
that work, sometimes you have to choose between two suboptimal solutions
while waiting for a proper fix.

Generalizations about “this community” obviously make no sense.  You are
a part of “this community” so it cares just as much as you do.

Please let’s work in a friendly manner towards finding solutions to the
problems.

Thank you,
Ludo’.