Re: FW: [oss-security] accepting new members to (linux-)distros lists

[Alex Vong]

Leo Famulari  writes:

[...]
> But, the "Stack Clash" issues took us by surprise and we spent a few
> days writing and testing our fixes. We are committed to supporting
> 32-bit platforms where these bugs are apparently easy to exploit.
> Without access to the exploits or detailed discussion, it was very
> difficult to know if our fixes actually worked. So, we could have
> responded more quickly and effectively with early notice.
[...]

Should we bring this discussion to nix devs as well? I am sure they are
facing the same issue of not having early access to vulnerabilities. It
will be insightful to know how they dealt with it in the past and their
opinions on joining the list.


signature.asc
Description: PGP signature

GSoC project update 1

[Caleb Ristvedt]

Hello everyone. It's already almost July! Which means I've been working
on replacing the build daemon for about a month now. So it seems like a
good time for an update.

So far, I've replaced the register-path procedure in store.scm, which
means we now have some support for using sqlite (via guile-sqlite3 and
some utility macros) to access and modify the state database. We can
also now perform deduplication on individual store items. That's pretty
much all that's been produced so far code-wise (that you can see on the
guile-daemon branch at savannah, anyway), but that's okay, because I've
also gained a lot of knowledge.

Recently I've been trying to understand the details of how
nix/libstore/build.cc operates, and this has taught me the value of
trying to keep procedures no longer than one screen's height. It's also
taught me the value of immediately writing any insights I have down,
since the details, even of a single procedure I'm reading, are well past
the point where I can keep them all in my head.

Right now I'm working on implementing the building of derivations. There
are two main difficulties. The first is that the details of this process
(which files are included in the chroot by default, permissions,
ownership, environment variables, etc) are all in C++. I have discovered
that the picture I had of C++ going into this was, unfortunately, pretty
accurate. Here's a great example: reading through globals.cc, try to
figure out what "settings" refers to at each occurrence (I had a long
rant prepared, but that about sums it up).

The second, less obnoxious difficulty is that of code duplication. A lot
of the functionality of guix duplicates functionality from the daemon,
which was one of the motivations for the rewrite in the first place, but
the duplicated functionality is still built on top of remote procedure
calls, especially for accessing the database. For example,
topologically-sorted in store.scm is exactly what I wanted in order to
implement support for exportReferencesGraph, but it uses an RPC to get
the list of references of a store item. At the same time, there are
still many procedures that are what I need (derivations.scm is lovely),
so it's still worth checking if it's already implemented, but often a
miss.

My difficulties with Scheme are pretty minor, and the Guile reference
has been very useful. It took me awhile to realize that dynamic scoping
was very much not a thing in Scheme, as opposed to the sort-of-a-thing
state it's in in Common Lisp (I had a hack set up to shadow a hashing
function so that I could get the size of the thing being hashed as a
byproduct, but discovered it didn't work that way and ended up just
making a wrapper port that counted what went through it). I do get the
feeling when writing Scheme that set! is an unholy word, which makes for
a fun challenge, especially where iteration is involved. I want to
finally figure out how monads are supposed to be used, though. Perhaps I
should just read through the implementation in guix.

I think I have the build environment just about figured out (I've been
writing a detailed description of the process, which I plan to post once
it's finished), and can get to implementing derivation-building
soon. I'll start with assuming that a chroot is used, then extend it to
work with non-chroot builds later.

So yeah, that's the state of the project so far.

- reepca

Re: compiling guix is too slow?

[Alex Vong]

"Feng Shu"  writes:

> Now I have found that 'guix pull' is too slow,
> I need 3 hours to compile guix, is it possible to speed it ?

Maybe you can try building from git instead? I used to run
'$ guix pull && guix package --upgrade', but it gets slower as the
number of packages of guix increases. So now I use
'$ git pull && make -j`nproc` && ./pre-inst-env guix package --upgrade'.
You can read the manual[0] for more info.

If you use emacs-guix, you need to tell emacs-guix the location of your
git repository as well. I am unware of how others do it. Here is how I
do it:

  (require 'guix-autoloads)
  (guix-prettify-global-mode)
  (setq-default guix-current-profile
(file-chase-links "~/.guix-profile" 1))
  (setq-default guix-directory "~/scm/guix/")

  (require 'guix-build-config)
  (let ((guix-src-dir (expand-file-name "~/scm/guix/")))
(setq-default guix-config-image-directory guix-src-dir)
(setq-default guix-config-guix-scheme-compiled-directory guix-src-dir))


[0]: https://www.gnu.org/software/guix/manual/html_node/Building-from-Git.html


signature.asc
Description: PGP signature

bootstrap-tarballs fails

[rennes]

Hello,

Currently compiling './pre-inst-env guix build --target=i586-pc-gnu  
bootstrap-tarballs' on core-updates fails with:

--
phase `set-paths' succeeded after 0.0 seconds
starting phase `install-locale'
warning: failed to install 'en_US.utf8' locale: Invalid argument
phase `install-locale' succeeded after 0.0 seconds
starting phase `unpack'
In execvp of tar: No such file or directory
phase `unpack' failed after 0.0 seconds
builder for  
`/gnu/store/6lg16ay4c6hxhk6w5f8blk6zpnscdzr1-make-boot0-4.2.1.drv'  
failed with exit code 1
@ build-failed  
/gnu/store/6lg16ay4c6hxhk6w5f8blk6zpnscdzr1-make-boot0-4.2.1.drv - 1  
builder for  
`/gnu/store/6lg16ay4c6hxhk6w5f8blk6zpnscdzr1-make-boot0-4.2.1.drv'  
failed with exit code 1
cannot build derivation  
`/gnu/store/4w89qisfs7s00dmz0wpii1hlnmd653sr-gcc-cross-boot0-5.4.0.drv':  
1 dependencies couldn't be built
guix build: error: build failed: build of  
`/gnu/store/4w89qisfs7s00dmz0wpii1hlnmd653sr-gcc-cross-boot0-5.4.0.drv'  
failed

--

I will continue to review.

Re: compiling guix is too slow?

[Leo Famulari]

On Thu, Jun 29, 2017 at 06:58:28AM +0800, Feng Shu wrote:
> 
> Now I have found that 'guix pull' is too slow,
> I need 3 hours to compile guix, is it possible to speed it ?

Wow, that's really slow :(

I don't know of any easy way to speed it up. Maybe you could build Guix
on a faster computer and use `guix copy` to move it to this slower
computer.

My understanding is that Guile 2.2 traded slower compilation for faster
execution of compiled programs. Hopefully the performance of the
compiler will be improved in later updates to Guile.

I'm curious, what machine are you using where it takes 3 hours? My
slowest machine takes 100 minutes, which is also too slow, but it's much
better than 3 hours.


signature.asc
Description: PGP signature

Re: compiling guix is too slow?

[Adonay Felipe Nogueira]

I'm also trying to understand the cause of this.

I still don't have enough time to begin investigating it or to suggest
improvements, but I notice that it gets worse and with *more* resource
usage if you pass the `--cores`/`-c` option with any value to `guix
pull`. Without this option the resource usage is short (in terms of how
long it lasts) and causes less heat.

-- 
- [[https://libreplanet.org/wiki/User:Adfeno]]
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre, por isso não uso. Iguais a ele prefiro
  GNU Ring, ou Tox. Quer outras formas de contato? Adicione o vCard
  que está no endereço acima aos teus contatos.
- Pretende me enviar arquivos .doc, .ppt, .cdr, ou .mp3? OK, eu
  aceito, mas não repasso. Entrego apenas em formatos favoráveis ao
  /software/ livre. Favor entrar em contato em caso de dúvida.

compiling guix is too slow?

[Feng Shu]

Now I have found that 'guix pull' is too slow,
I need 3 hours to compile guix, is it possible to speed it ?

-- 

Re: FW: [oss-security] accepting new members to (linux-)distros lists

[ng0]

Leo Famulari transcribed 14K bytes:
> It was hinted at ~1 week ago in the public "Stack Clash" discussion on
> oss-security, but now there has been an announcement: the private
> linux-distros early-notice security discussion and coordination mailing
> list is accepting new members:
> 
> http://seclists.org/oss-sec/2017/q2/638

W… ouch, some of these points are so very excluding.
If someone of us has the time to invest in there, of course it would
be good.

Guix being too obscure is the in-joke/"explanation"/excuse for
rejection which could happen, of course. But we can still try.
-- 
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://n0is.noblogs.org/my-keys
infotropique: https://www.infotropique.org


signature.asc
Description: PGP signature

FW: [oss-security] accepting new members to (linux-)distros lists

[Leo Famulari]

It was hinted at ~1 week ago in the public "Stack Clash" discussion on
oss-security, but now there has been an announcement: the private
linux-distros early-notice security discussion and coordination mailing
list is accepting new members:

http://seclists.org/oss-sec/2017/q2/638

The criteria are listed in the forwarded message below. I'd say we can
meet them. Perhaps they'd say that Guix is too obscure, but I don't have
any idea how many users we have. We'd need to have a good plan for #7,
"Be able and willing to contribute back". I'm assuming we'd have
somebody to vouch for us (#9).

I've seen some members of Guix express doubts about the utility of
private discussion forums like linux-distros, and I'm sympathetic.

In fact, even without early notification, we are usually shipping
security updates for embargoed issues within 24 hours of public
disclosure, and usually within a few hours. And for non-embargoed
issues, we are shipping fixes earlier than the major distros very often.
I read the "security update round-ups" on LWN, and typically they are
full of bugs we already fixed. So, perhaps it wouldn't make a big
difference in most cases.

But, the "Stack Clash" issues took us by surprise and we spent a few
days writing and testing our fixes. We are committed to supporting
32-bit platforms where these bugs are apparently easy to exploit.
Without access to the exploits or detailed discussion, it was very
difficult to know if our fixes actually worked. So, we could have
responded more quickly and effectively with early notice.

What do people think? Is anyone else interested in applying to join this
mailing list? Is anyone else willing to stick to the rules and to
participate?

Leo

- Forwarded message from Solar Designer  -

Date: Wed, 28 Jun 2017 22:02:40 +0200
From: Solar Designer 
To: oss-secur...@lists.openwall.com
Subject: [oss-security] accepting new members to (linux-)distros lists
User-Agent: Mutt/1.4.2.3i

Hi,

I have finally specified the criteria for accepting new members to the
(linux-)distros lists.  I intend to process the requests, which are to
be posted to new threads each (one thread per distro wanting to join).

I put quite some thought (and experience so far) into these criteria,
but I welcome any comments and suggested changes this community might
have.  The list of criteria will be maintained on the wiki:

http://oss-security.openwall.org/wiki/mailing-lists/distros#membership-criteria

Currently, to be eligible for (linux-)distros list membership, your
distro should:

1. Be an actively maintained Unix-like operating system distro with
substantial use of Open Source components

2. Have a userbase not limited to your own organization

3. Have a publicly verifiable track record, dating back at least 1 year
and continuing to present day, of fixing security issues (including some
that had been handled on (linux-)distros, meaning that membership would
have been relevant to you) and releasing the fixes within 10 days (and
preferably much less than that) of the issues being made public (if it
takes you ages to fix an issue, your users wouldn't substantially
benefit from the additional time, often around 7 days and sometimes up
to 14 days, that list membership could give you)

4. Not be (only) downstream or a rebuild of another distro (or else we
need convincing additional justification of how the list membership
would enable you to release fixes sooner, presumably not relying on the
upstream distro having released their fixes first?)

5. Be a participant and preferably an active contributor in relevant
public communities (most notably, if you're not watching for issues
being made public on oss-security, which are a superset of those that
had been handled on (linux-)distros, then there's no valid reason for
you to be on (linux-)distros)

6. Accept the list policy:
http://oss-security.openwall.org/wiki/mailing-lists/distros#list-policy-and-instructions-for-members
(also quoted below)

7. Be able and willing to contribute back, preferably in specific ways
announced in advance (so that you're responsible for a specific area and
so that we know what to expect from which member), and demonstrate
actual contributions once you've been a member for a while:
http://oss-security.openwall.org/wiki/mailing-lists/distros#contributing-back
(also quoted below)

8. Be able and willing to handle PGP-encrypted e-mail

9. Have someone already on the private list, or at least someone else
who has been active on oss-security for years but is not affiliated with
your distro nor your organization, vouch for at least one of the people
requesting membership on behalf of your distro (then that one
vouched-for person will be able to vouch for others on your team, in
case you'd like multiple people subscribed)

Membership requests should provide answers per each of these criteria.

I came up with many current tasks/roles that a new or existing member
could usefully help with, thereby contributing to the team eff

Re: Xorg tearing fix on Intel HD Graphics 4000

[Mark H Weaver]

Andy Wingo  writes:

> On Tue 27 Jun 2017 19:43, Mark H Weaver  writes:
>
>> In the meantime, how would you feel about pushing the following commit
>> to master?  It would still allow the use of SNA by explicitly asking for
>> it in xorg.conf, but auto-configuration would choose UXA by default.
>>
>> What do you think?
>
> Looks good to me.

Pushed as commit b049ae2f9708794f83c41171c19ffdfe4f11807e on master.

> We should report the problem though... ok I did that here:
>
>   https://bugs.freedesktop.org/show_bug.cgi?id=101620

Thank you!  I see that there has already been an informative response
from Chris Wilson:

  The issue is that gnome-shell is not synchrosing its texture reads
  with X rendering because mesa's glXWaitX() is broken.

  Mark

Re: Looking to contribute

[James Richardson]

cinde...@hushmail.com writes:

> Hello. I recently learned about GuixSD, and it seems like a distro
> I would actually _enjoy_ using. Essentially, my questions are:
>
> What is the current state of GuixSD? Is it currently too buggy or
> feature-deficient to use as a day-to-day os?
>
I use it on my laptop and my wife's laptop. feature-deficient is a
rather subjective term. I have xfce on my wife's laptop. Occasionally
she'll complain about lack of flash or that a website doesn't like
icecat. I have a few boxen that I haven't converted (from Debian) yes as
I rely heavily on lvm and don't want to sort out how to do without
lvm. On those boxen I use guix as a foreign package manager which
actually works out quite well.


> How can I best contribute?
>
I've found the people on the #guix channel and on this list to be very
helpful. The website has a section on how to contribute. I've started by
just packaging programs that I use that were net yet in Guix. Knowing
guile is not (IHMO) a prerequisite, although willingness to learn
probably is ;).

HTH, James.
-- 
I prefer encrypted email.
GPG Fingerprint = 8FD2 7619 C19A 2201 CB1D  E131 EA1C F14B D846 7AFB
https://jamestechnotes.com/gpgkey
https://jamestechnotes.com

Re: Looking to contribute

[Leo Famulari]

On Wed, Jun 28, 2017 at 03:49:43PM +0200, Danny Milosavljevic wrote:
> Note that a normal GuixSD system takes at least 80 GB of disk space
> (it will suck), better 160 GB (that will work very nicely).  That
> mostly because of the rollback feature.

This seems very high to me. I had >100 system generations over 6 months
with less than 100 GB, although that was not a graphical system. So, it
depends on how "big" you make each generation, and how many generations
you keep.


signature.asc
Description: PGP signature

Re: Looking to contribute

[Alex Vong]

Hi Cinder,

Welcome to Guix!

cinde...@hushmail.com writes:

> Hello. I recently learned about GuixSD, and it seems like a distro
> I would actually _enjoy_ using. Essentially, my questions are:
>
> What is the current state of GuixSD? Is it currently too buggy or
> feature-deficient to use as a day-to-day os?
>
> How can I best contribute?
>
This webpage contains a lot of useful information:


> -Andrew


signature.asc
Description: PGP signature

Re: Looking to contribute

[Danny Milosavljevic]

Hi and welcome,

On Tue, 27 Jun 2017 18:16:08 -0400
cinde...@hushmail.com wrote:

> What is the current state of GuixSD? Is it currently too buggy or
> feature-deficient to use as a day-to-day os?

I'm using it every day, also for professional programming.

It's quite okay to use.  There are occassional problems - which can be 
mitigated by the feature below:

If there are bugs on system update, you can roll back by selecting another 
entry in the bootloader menu (a new one is created everytime you reconfigure 
the system).  This includes all the installed packages ().  So it's pretty 
much indestructible - I think that this is the killer feature of GuixSD.

Check the package list https://www.gnu.org/software/guix/packages/ for 
information on which packages are available.

Note that a normal GuixSD system takes at least 80 GB of disk space (it will 
suck), better 160 GB (that will work very nicely).  That mostly because of the 
rollback feature.

> How can I best contribute?

If you want to install GuixSD there's a "wip-installer" (WIP means "work in 
progress") branch on git .  If you 
just want to test the finished installer please download 
http://web.fdn.fr/~lcourtes/software/guix/guixsd-graphical-installer-x86-64-linux.lz
 and unpack it by invoking "lzip -d guixsd*.lz".  This results in a disk image 
that you can flash onto a USB flash drive (don't copy it as a file unto the 
filesystem on the flash USB drive - rather replace the entire drive by it).

It has quite a few rough edges so don't expect Ubuntu-style usability (yet).

If you do try the installer, it would be good if you noted which areas suck :)

I think you should contribute in an area that you care about.  There's plenty 
to do.  For example:

Installer:
- Currently, the installer invokes the parted executable for partitioning which 
is quite jarring (it looks very different).  It would be nice if it just used 
the parted library.  But there's no good guile-parted yet.  I've started 
hacking on one and it's starting to look OK but it's not done.  If you are 
interested in that I can upload it somewhere (github, gitlab etc).
- No mouse support yet.
- We have ISO9660 CD support code so it would be quite easy to make it so that 
the image file for the graphical installer (see link above) also worked if you 
burned it to a CD.  See threads mentioning "grub-mkrescue" on the mainling list.

Bootloader:
- The bootloader support code doesn't support booting Windows systems etcetc.
- There's no u-boot installer yet.  (There's support for using existing u-boot 
but it doesn't install the u-boot bootloader itself yet.  That's because doing 
that safely is very difficult)

Packages:
- Texlive for a long time was a 2 GB download which was done every time one of 
the dependencies changed.  It's better now but there are still situations where 
it does that.  It should be more modular so the downloads aren't that large 
(and not done as often).
- Rust is not the newest version because they changed the build system they use 
(sigh...) and I didn't get it to work yet.
- Our packaging is such that each package goes into its own directory 
/gnu/store/3523523643262hashvaluehere WHICH IS READ-ONLY, you can't possibly 
write there.  But dub, the D package manager, sometimes tries to do that and 
fails.  This is a design limitation in the D package manager (it has so-called 
"configurations" and if you switch configurations it will try to switch 
symlinks) but it means you can't run many of the D tests.  Fixing that in dub 
would be great.
- The GUI hooks for desktop files and mime types suck.  Usually, the desktop 
file database is updated much too late (mostly by accident).  I've looked into 
fixing it but it would entail rebuilding almost all the graphical packages we 
have - and I think KDE would still not do it correctly.

Some of the areas I work in are mostly bootloader, filesystem and partitioning 
stuff - which happen to be the areas where I have to be quite careful about not 
breaking the killer feature.  If you like that anyway, please help us with it :)

What are your interests?

Looking to contribute

[cinder88]

Hello. I recently learned about GuixSD, and it seems like a distro
I would actually _enjoy_ using. Essentially, my questions are:

What is the current state of GuixSD? Is it currently too buggy or
feature-deficient to use as a day-to-day os?

How can I best contribute?

-Andrew

Re: Xorg tearing fix on Intel HD Graphics 4000

[Andy Wingo]

On Tue 27 Jun 2017 19:43, Mark H Weaver  writes:

> Andy Wingo  writes:
>
>> On Wed 21 Jun 2017 09:55, Roel Janssen  writes:
>>
>>> For a long time now, I have a tearing issue on GuixSD (parts of the
>>> screen do not get updated while others do, resulting in dissapearing
>>> text in Emacs).
>>
>> I wonder if it makes sense to update the intel driver to see if it fixed
>> it?  Then perhaps we could avoid the hack.  There are commits here that
>> touch SNA and things that look like they could be relevant:
>>
>>   https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/log/
>
> It's a good idea, but we're already using HEAD (6babcf1) from their
> repo, and have been since June 11 (guix commit e2de6bbdd5).  I can
> confirm that this didn't solve the problem for me.
>
> In the meantime, how would you feel about pushing the following commit
> to master?  It would still allow the use of SNA by explicitly asking for
> it in xorg.conf, but auto-configuration would choose UXA by default.
>
> What do you think?

Looks good to me.  We should report the problem though... ok I did that
here:

  https://bugs.freedesktop.org/show_bug.cgi?id=101620

Looking forward to having a normal Emacs again :)

Andy