Re: custom kernel config

[Efraim Flashner]

On Mon, Apr 01, 2019 at 08:30:28PM +0200, Pierre Neidhardt wrote:
> This is very interesting, I've been wanting to do this for a while.
> Is it working for you?  What are the before/after build times?
> 

I haven't checked to see if my custom kernel works yet on my laptop, but
compile time was 43 minutes on my kids' computer. Stock
linux-libre@5.0.5 took 267 minutes.

My custom kernel came in at 34MB, the stock kernel is 251MB.


-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: KMScon vs. AMD Radeon

[Ludovic Courtès]

Hi Mathieu,

Mathieu Othacehe  skribis:

> Here's a patch that fallback to mingetty if kmscon is not supported. I
> don't have a machine with AMD GPU for testing so if Florian or Pierre
> could test the patch that would be very helpful :)

That was fast, thanks!

We’ll wait for your feedback Florian & Pierre.  :-)

> From f728749dc02f8bb8a1870925547d96d8ce352f55 Mon Sep 17 00:00:00 2001
> From: Mathieu Othacehe 
> Date: Mon, 1 Apr 2019 15:54:26 +0200
> Subject: [PATCH] wip: Fallback to mingetty if kmscon is not supported.

[...]

> +  (define is-kmscon-supported?
> +#~(let ((drm-regex (make-regexp "(card|render).*$")))
> +(not (null? (scandir "/sys/class/drm"
> + (cut regexp-exec drm-regex <>))

No need for “is-”.  :-)

> +  (let ((mingetty
> + (service mingetty-service-type
> +  (mingetty-configuration
> +   (tty "tty1")
> +   (auto-login "root")
> +   (%auto-start? #f
> +(kmscon
> + (service kmscon-service-type
> +  (kmscon-configuration
> +   (virtual-terminal "tty1")
> +   (login-program (installer-program))
> +   (%auto-start? #f)
> +(list
> + mingetty
> + kmscon
> + (service
> +  (shepherd-service-type
> +   'installer-tty
> +   (lambda _
> + (shepherd-service
> +  (provision '(installer-tty))
> +  (requirement '(user-processes host-name udev virtual-terminal))
> +  (start #~(lambda _
> + (if #$is-kmscon-supported?
> + (start 'kmscon-tty1)
> + (start 'term-tty1
> +  (stop #~(make-kill-destructor))
> +  (modules `((ice-9 ftw)
> + (ice-9 regex)
> + (srfi srfi-26)
> + ,@%default-modules)
> +  '()

Should we instead build this functionality into ‘kmscon-service-type’,
possibly with a flag to turn it off?

Thank you!

Ludo’.

Re: custom kernel config

[Ludovic Courtès]

Hello!

Related to that (somewhat :-)), it’d be great to have a kernel config
specialized for VMs that can boot very quickly.

The Kata Containers folks (it has the word “containers” in it but it’s
really about VMs) pride themselves on having a kernel that boots in
600ms in KVM.

Ludo’.

Re: 02/09: guix: store: Make register-items transactional, register drv outputs

[Ludovic Courtès]

Hello,

Caleb Ristvedt  skribis:

>> A problem is that we should not pull in these two modules here, because
>> they are conceptually at a higher level (they have to do with talking to
>> a separate daemon process.)
>>
>> So perhaps a first step would be to re-arrange things, probably along
>> these lines:
>>
>>   • Move the .drv parsing code and the  record type from
>> (guix derivations) to, say, (guix store derivations).
>>
>>   • Re-export all these bindings from (guix derivations).
>>
>>   • Move ‘store-path?’, ‘derivation-path?’ & co. (everything below line
>> 1745 in guix/store.scm) to, say, (guix store files).  Re-export
>> appropriately so the API remains unchanged.
>>
>> At this point, (guix store …) modules won’t have to use (guix store) and
>> (guix derivations) at all.
>>
>> How does that sound?
>
> As we found out on IRC yesterday, https://bugs.gnu.org/15602 is causing
> this to fail. If I understand correctly, the workaround involves trying
> to make sure that modules that use (guix memoization) are compiled
> before (guix memoization) is (and it turns out that once that's solved
> the same issue occurs with (guix config)). Considering that the
> module-import-compiled builders just do a depth-first-search for scheme
> source files ordered alphabetically, that's a bit tricky. I ended up
> making a dummy module, (gnu build dummy), that does nothing but use
> (guix config) and (guix memoization), and the tests now pass.
>
> Does a better workaround exist? Could we pass an ordered list of files
> to the builder somehow instead of just a directory? But then again,
> changing every module-import-compiled would mean rebuilding the
> world. Eh.

We could go with the clunky workaround for now.

Then we should fix ‘compiled-modules’ in a way that does not force a
full rebuild.  That can be done by having a keyword argument to select
between the correct implementation and the buggy one; in (guix
packages), we’d ask for the buggy one so that we don’t trigger a
rebuild.

As for how to fix it, we could use (guix build compile) which already
does the right thing.

> Oh, also, should I just copy all the copyright lines from the old
> modules to the new ones?

Ideally you’d just copy the relevant lines; if it’s too tricky to find
out which lines correspond to what, you could copy them all (I’d argue
it’s not an unreasonable thing to do.)

Thanks!

Ludo’.

Re: Updating mono. Adding MSBuild.

[Brett Gilio]

Ricardo Wurmus writes:

> Brett Gilio  writes:
>
>> Although, there is a possible issue here that needs to be
>> addressed. Both Mono and Chicken produce a binary called `csi`. This is
>> a naming conflict, and I do not know the Guix-way for resolving naming
>> conflicts.
>
> This is not a problem as during the build you probably won’t use Chicken
> together with Mono.
>
>> Most distributions renamed the Chicken csi to `chicken-csi`
>> and left mono to `csi`. Does Guix have namespaces for binaries we
>> produce? How should I proceed here?
>
> The Guix way is to install these things into separate profiles.

Hi all.

First, thank you ricardo for your response.

I have a few things that seem to be important to note. On the plus side,
I got Mono-5.0 to build successfully. But, during this process of
building mono-5.0 I discovered that the mono documentation is either
incorrect or misleading. Their documentation states that you need to
have a mono-lite binary seed or a previous version of mono to compile
newer versions. This doesn't seem to be true. Regardless of whether I
pass our older version of mono to build mono-5.0, it compiles a csc (C#
compiler) from its own source tree that it uses to build the full mono
stack. So, I am inclined to think that bootstrapping mono from an
earlier version isn't necessary since that csc compiler is C code.

Okay, great Mono-5.0 builds successfully. So with that knowledge, I
tried to compile the latest Mono-5.18. However, shortly after the
configuration step it throws

CMake Error: CMake was unable to find a build program corresponding to "Unix 
Makefiles".  CMAKE_MAKE_PROGRAM is not set.  You probably need to select a 
different build tool.
CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!
See also
"/tmp/guix-build-mono-5.18.1.0.drv-0/mono-5.18.1.0/mono/btls/build-shared/CMakeFiles/CMakeOutput.log".

The interesting thing is that it uses the gnu-build-system to build the
csc compiler, and I had to pass cmake as a native-input or else the
configuration step would fail. So, does anybody know how to deal with
this cmake issue?

Thanks,

Brett Gilio

custom kernel config

[Efraim Flashner]

I'm playing around with the idea of creating a custom kernel for my
laptop and I started by following Gentoo's kernel config instructions.
I'm including what I have currently. I want to create a kernel which is
good for my laptop and takes less time to build than the standard
kernel. By leaving the #:configuration-file blank I'm only filling in
the fields I supply, right?


-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
(define-module (kernel)
  #:use-module (gnu packages linux))

(define %macbook41-config-options
  `(("CONFIG_USB_NET_RNDIS_HOST" . m)
("CONFIG_USB_NET_CDCETHER" . m)
("CONFIG_USB_USBNET" . m)
("CONFIG_MII" . m)
("CONFIG_RT8XXXU" . m)
("CONFIG_CRYPTO_ARC4" . m)
("CONFIG_RTL8192CU" . m)
;; rtlusb
("CONFIG_RTL8192C_COMMON" . m)
("CONFIG_RTLWIFI" . m)
("CONFIG_USB_ACM" . m)
("CONFIG_VLAN_8021Q" . m)
("CONFIG_GARP" . m)
("CONFIG_MRP" . m)
("CONFIG_XT_TARGET_CHECKSUM" . m)
("CONFIG_IP_NF_MANGLE" . m)
("CONFIG_IP_TABLE_MASQUERADE" . m)
("CONFIG_IP_NF_NAT" . m)
("CONFIG_NF_NAT_IPV4" . m)
("CONFIG_NF_NAT" . m)
("CONFIG_NETFILTER_XT_MATCH_CONNTRACK" . m)
("CONFIG_NF_CONNTRACK" . m)
("CONFIG_NF_DEFRAG_IPV6" . m)
("CONFIG_NF_DEFRAG_IPV4" . m)
("CONFIG_IP_NF_TARGET_REJECT" . m)
("CONFIG_NF_REJECT_IPV4" . m)
;; tcpudp
("CONFIG_BRIDGE" . m)
("CONFIG_STP" . m)
("CONFIG_LLC" . m)
("CONFIG_BRIDGE_EBT_T_FILTER" . m)
("CONFIG_BRIDGE_EBTABLES" . m) ; ?
("CONFIG_IP6_NF_FILTER" . m)
("CONFIG_IP6_NF_IPTABLES" . m)
("CONFIG_IP_NF_FILTER" . m)
("CONFIG_NET_DEVLINK" . m)
;; one of the two following is corrent
("CONFIG_IP_NF_TABLES" . m)
("CONFIG_IP_NF_IPTABLES" . m)
("CONFIG_NETFILTER_XTABLES" . m)
("CONFIG_FB_INTEL" . m)
("CONFIG_B43" . m)
("CONFIG_BCMA" . m)
("CONFIG_MAC80211" . m)
("CONFIG_INPUT_JOYDEV" . m)
("CONFIG_INPUT_LEDS" . m)
("CONFIG_CFG80211" . m)
("CONFIG_USB_HCD_SSB" . m)
("CONFIG_USB_MOUSE" . m)
("CONFIG_ITCO_WDT" . m)
("CONFIG_ITCO_VENDOR_SUPPORT" . #t)
("CONFIG_USB_KBD" . m)
("CONFIG_MOUSE_APPLETOUCH" . m)
("CONFIG_SENSORS_APPLESMC" . m)
("CONFIG_INPUT_POLLDEV" . m)
("CONFIG_SENSORS_CORETEMP" . m)
("CONFIG_KVM_INTEL" . m)
("CONFIG_KVM" . m)
("CONFIG_HAVE_KVM_IRQ_BYPASS" . #t)
("CONFIG_HID_APPLEIR" . m)
("CONFIG_USB_ISIGHTFW" . m)
("CONFIG_PCSPKR_PLATFORM" . #t)
("CONFIG_I2C_I801" . m)
("CONFIG_SND_HDA_CODEC_REALTEK" . m)
("CONFIG_FIREWIRE_OHCI" . m)
("CONFIG_LPC_ICH" . m)
("CONFIG_CRC_ITU_T" . m)
("CONFIG_SKY2" . m)
("CONFIG_SSB" . m)
("CONFIG_DRM_I915" . m)
("CONFIG_SND_HDA_INTEL" . m)
("CONFIG_ACPI_SBS" . m)
("CONFIG_BATTERY_SBS" . m)
("CONFIG_CHARGER_SBS" . m)
("CONFIG_MANAGER_SBS" . m)
("CONFIG_CEC_CORE" . m)
("CONFIG_DRM_KMS_HELPER" . m)
("CONFIG_SND_HDA_CORE" . m)
("CONFIG_SND_HWDEP" . m)
("CONFIG_SND_PCM" . m)
("CONFIG_DRM" . m)
("CONFIG_ACPI_VIDEO" . m)
("CONFIG_SND_TIMER" . m)
("CONFIG_I2C_ALGOBIT" . m)
("CONFIG_BACKLIGHT_APPLE" . m)
("CONFIG_HID_APPLE" . m)
("CONFIG_FB_SYS_FOPS" . m)
("CONFIG_FB_SYS_COPYAREA" . m)
("CONFIG_FB_SYS_FILLRECT" . m)
("CONFIG_SND" . m)
("CONFIG_FB_SYS_IMAGEBLIT" . m)
("CONFIG_SOUND" . m)
("CONFIG_BTRFS_FS" . m)
("CONFIG_XOR_BLOCKS" . m)
("CONFIG_RAID6_PQ" . m)
("CONFIG_ZSTD_DECOMPRESS" . m)
("CONFIG_ZSTD_COMPRESS" . m)
("CONFIG_XXHASH" . m)
("CONFIG_LIBCRC32C" . m)
("CONFIG_HW_RANDOM_VIRTIO" . m)
("CONFIG_VIRTIO_CONSOLE" . #t)
("CONFIG_VIRTIO_NET" . #t)
("CONFIG_VIRTIO_BLK" . #t)
("CONFIG_VIRTIO_BALLOON" . #t)
("CONFIG_VIRTIO_PCI" . #t)
("CONFIG_VIRTIO" . #t)
;; virtio_ring
("CONFIG_SCSI_ISCI" . m)
("CONFIG_SCSI_SAS_LIBSAS" . m)
("CONFIG_SCSI_SAS_ATTRS" . m)
("CONFIG_PATA_ATIIXP" . m)
("CONFIG_PATA_ACPI" . m)
("CONFIG_NLS_ISO8859_1" . m)
("CONFIG_CRYPTO_WP512" . m)
;; is this not a real flag?
("CONFIG_CRYPTO_GENERIC" . #t)
("CONFIG_CRYPTO_XTS" . m)
("CONFIG_DM_CRYPT" . m)
("CONFIG_HID" . m)
("CONFIG_USB_HID" . m)
("CONFIG_USB_UAS" . m)
("CONFIG_USB_STORAGE" . m)
("CONFIG_SATA_AHCI" . m)
("CONFIG_SATA_AHCI_PLATFORM" . m)

("CONFIG_USB_EHCI_HCD" . #t)
("CONFIG_USB_UHCI_HCD" . #t)

("CONFIG_BT" . m)
("CONFIG_BT_HCIBTUSB" . m)
("CONFIG_BT_BCM" . m)
("CONFIG_BT_RTL" . m)
("CONFIG_BT_INTEL" . m)

;;filesystems
("CONFIG_EXT4_FS" . #t)
("CONFIG_EXT4_USE_FOR_EXT2" . #t)
("CONFIG_XFS_FS" . m)
("CONFIG_MSDOS_FS" . m)
("CONFIG_VFAT_FS" . #t)
("CONFIG_TMPFS" . #t)
("CONFIG_DEVTMPFS" . #t)
("CONFIG_DEVTMPFS_MOUNT" . #t)
("CONFIG_PROC_FS" . #t)
("CONFIG_MSDOS_PARTITION" . #t)

;;efi-support

Re: Video narration

[Laura Lazzati]

Hi Paul!


> I have finished updating the transcripts and I am preparing to do the
> recordings tomorrow.
Great! Could you remind me in UTC at which time of the day? Because I
generally have to record them at 00 UTC to reduce the environmental
noise. And then match them.
>
> One question about the makefile: am I right in thinking that the
> makefile automatically adjusts the duration of each slide according to
> the duration of the corresponding audio file?  In other words it would
> not matter if I supply audio files that are slightly longer (or
> shorter) than your originals?
Yes, the slides videos take the duration of the audio file. And the
cli session videos, let me check, but they are easier in terms that
you have to say what is said during while listening to the audio, to
match the command.
>
> > Shouldn't the 'guix environment' step be later in the list of steps?
> > If I was packaging the aspi package I would do:
> >
> > $ guix environment --pure r-aspi
> > The environment was set up in the first packaging video. As far as I
> > am concerned, the idea is to have a clean guix environment and
> > package
> > everything there. If you are using a foreign distro then I believe
> > that it could not be reproducible if you package it first.
> > Please, let the others correct me if I am wrong.
>
> I think that this question has to do with the complexity of the
> package.  The aspi example is a simple case that does not have any
> dependencies outside the R build system.  For a more complex package
> (newPackage, for example) using:
>
> $ guix environment --pure guix
> $ guix build newPackage
>
> would fail if newPackage has extra inputs.  Instead, the commands
> should be:
>
> $ guix environment --pure newPackage
> $ guix build newPackage
>
> I think this would be easy to communicate to new users if steps 1 and 2
> are switched on Slide 2 and I add some extra words to the transcript.
>
> Do you (and others) agree?
When I packaged, I did it the other way, and my mentors approved them.
Recall that you are "touching" .scm files from your the guix you have
installed if you do it the other way around. But if the others can
shed some light it would be great. In case I am wrong, I would need to
change not only the slides but also the cli sessions :/. In that case,
could you reschedule the day for the recordings?

Regards :)
Laura

Re: 02/09: guix: store: Make register-items transactional, register drv outputs

[Caleb Ristvedt]

> A problem is that we should not pull in these two modules here, because
> they are conceptually at a higher level (they have to do with talking to
> a separate daemon process.)
>
> So perhaps a first step would be to re-arrange things, probably along
> these lines:
>
>   • Move the .drv parsing code and the  record type from
> (guix derivations) to, say, (guix store derivations).
>
>   • Re-export all these bindings from (guix derivations).
>
>   • Move ‘store-path?’, ‘derivation-path?’ & co. (everything below line
> 1745 in guix/store.scm) to, say, (guix store files).  Re-export
> appropriately so the API remains unchanged.
>
> At this point, (guix store …) modules won’t have to use (guix store) and
> (guix derivations) at all.
>
> How does that sound?

As we found out on IRC yesterday, https://bugs.gnu.org/15602 is causing
this to fail. If I understand correctly, the workaround involves trying
to make sure that modules that use (guix memoization) are compiled
before (guix memoization) is (and it turns out that once that's solved
the same issue occurs with (guix config)). Considering that the
module-import-compiled builders just do a depth-first-search for scheme
source files ordered alphabetically, that's a bit tricky. I ended up
making a dummy module, (gnu build dummy), that does nothing but use
(guix config) and (guix memoization), and the tests now pass.

Does a better workaround exist? Could we pass an ordered list of files
to the builder somehow instead of just a directory? But then again,
changing every module-import-compiled would mean rebuilding the
world. Eh.

Thoughts?

Oh, also, should I just copy all the copyright lines from the old
modules to the new ones?

- reepca

Re: ‘staging’ and GNOME updates

[Efraim Flashner]

On Sun, Mar 31, 2019 at 10:52:49PM +0200, Ludovic Courtès wrote:
> Hi!
> 
> Ricardo Wurmus  skribis:
> 
> > Ludovic Courtès  writes:
> >
> >>> I don't think we should release 1.0 until at least
> >>>  and  are
> >>> fixed.  Trying a new distribution only to find your favourite programs
> >>> are crashing would be a _terrible_ first impression.
> >>
> >> Do we have any leads on this IceCat issue?  I use IceCat daily and never
> >> have any problems of this sort, FWIW.
> >
> > I’ve seen something like this before, but *only* on i686 machines.  I
> > never managed to figure out why.
> 
> It looks like Mark fixed this in
> bc91562939ee002e84c95d13c907482b6d1e9339.  \o/
> 
> > One of the GNOME update branches (for 2.28?) has already been merged
> > into staging.  There are rumours of crashes, though, so this will
> > require testing by more people.
> 
> OK, so I guess we should first focus on getting ‘staging’ tested and
> merged.
> 
> x86_64 substitutes on ci.guix.info cover 60% of the packages right now.
> The main issue is that libdrm has one test failure (see
> ):
> 
> --8<---cut here---start->8---
> starting phase `check'
> [0/1] Running all tests.
>  1/16 kms-symbol-checkOK   0.12 s 
>  2/16 gen4-3d.batch   OK   0.04 s 
>  3/16 gen45-3d.batch  OK   0.04 s 
>  4/16 gen5-3d.batch   OK   0.04 s 
>  5/16 gen6-3d.batch   OK   0.04 s 
>  6/16 gen7-3d.batch   OK   0.04 s 
>  7/16 gen7-2d-copy.batch  OK   0.02 s 
>  8/16 intel-symbol-check  OK   0.67 s 
>  9/16 nouveau-symbol-checkOK   0.32 s 
> 10/16 radeon-symbol-check OK   0.37 s 
> 11/16 amdgpu-symbol-check OK   0.52 s 
> 12/16 threadedSKIP 0.01 s 
> 13/16 random  TIMEOUT 240.01 s 
> 14/16 hashOK   0.02 s 
> 15/16 drmsl   OK   1.23 s 
> 16/16 drmdevice   SKIP 0.01 s 
> 
> Ok:   13
> Expected Fail: 0
> Fail:  1
> Unexpected Pass:   0
> Skipped:   2
> Timeout:   1
> 
> 
> The output from the failed tests:
> 
> 13/16 random  TIMEOUT 240.01 s 
> --8<---cut here---end--->8---
> 
> > The other GNOME upgrade that I worked on months ago still awaits a
> > rebase onto staging.  I’ll try to get it into good shape to have the
> > build farm build it out, so that more people can test it and provide
> > fixes where needed.
> 
> Perhaps we can first merge ‘staging’ in its current form, then make this
> branch the new ‘staging’ and aim for a merge as is (with only fixes
> committed there.)  How does that sound?
> 
> Ludo’.
> 

This libdrm test suite timeout looks a lot like the error I was having
in the past on armhf. For armhf it's fixed on staging in fe7c6f91dda,
but it can easily be extended to other/all architectures.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: Guix on a microkernel

[Ludovic Courtès]

Hi!

Pjotr Prins  skribis:

> Call it an accident of history ;). Being a GNU project we have a stake
> in getting the Hurd to a usable level and get people to start using
> it for daily work. 

Maybe I shouldn’t write such a thing today, or maybe writing it today is
more fun because it lets people interpret it the way they want, but
anyway: there’s this idea of us Guix hackers getting to work on the Hurd
once Guix 1.0 is out!

Ludo’.

Re: Guix on a microkernel

[mikadoZero]

Pjotr Prins writes:

> ... Being a GNU project we have a stake
> in getting the Hurd to a usable level and get people to start using
> it for daily work. 

I do not understand this.  Could someone elaborate on this "stake"
idea further.

Does Guix give preferential treatment to GNU projects over other free
software projects?

> I attended a talk at FOSDEM this year which gave an overview
>
> https://fosdem.org/2019/schedule/event/roadmap_for_the_hurd/attachments/slides/3270/export/events/attachments/roadmap_for_the_hurd/slides/3270/2019_02_01_fosdem_roadmap.pdf
>
> It looks like not a fat lot is needed to make this usable for many
> people. Most free software will actually run on Hurd today.

Thanks for sharing this link.  I will watch that talk.

Re: Video narration

[Paul Garlick]

Hi Laura,

I have finished updating the transcripts and I am preparing to do the
recordings tomorrow.

One question about the makefile: am I right in thinking that the
makefile automatically adjusts the duration of each slide according to
the duration of the corresponding audio file?  In other words it would
not matter if I supply audio files that are slightly longer (or
shorter) than your originals?

> Shouldn't the 'guix environment' step be later in the list of steps?
> If I was packaging the aspi package I would do:
> 
> $ guix environment --pure r-aspi
> The environment was set up in the first packaging video. As far as I
> am concerned, the idea is to have a clean guix environment and
> package
> everything there. If you are using a foreign distro then I believe
> that it could not be reproducible if you package it first.
> Please, let the others correct me if I am wrong.

I think that this question has to do with the complexity of the
package.  The aspi example is a simple case that does not have any
dependencies outside the R build system.  For a more complex package
(newPackage, for example) using:

$ guix environment --pure guix
$ guix build newPackage

would fail if newPackage has extra inputs.  Instead, the commands
should be:

$ guix environment --pure newPackage
$ guix build newPackage

I think this would be easy to communicate to new users if steps 1 and 2
are switched on Slide 2 and I add some extra words to the transcript.

Do you (and others) agree?  

Best regards,

Paul.

Re: Guix on a microkernel

[mikadoZero]

I do not have benchmark information.

Thank you for sharing the link.

zna...@tutanota.com writes:

> Thanks for your compilation.
> Do you have found actual benchmark tests? 
> https://www.gnu.org/software/hurd/faq/slow.html 
> 
> "The Hurd is currently slower than Linux, yes. But not very much, so it is 
> completely usable."
> Vulnerabilities of processors is also sensitive task. Maybe RISC-V will not 
> have such bugs? Need to know in a practice.
>
> Mar 31, 2019, 12:05 AM by mikadoz...@yandex.com:
>
>> # Appreciation
>>
>> I appreciate:
>>
>> * many of Guix's design decisions.  The one that is relevant to this
>>  discussion is the kernel.  I like that Guix uses the linux-libre (no
>>  binary blobs) instead of the linux kernel.
>>
>> * that work is underway to get Guix to work with GNU Hurd.  I like that
>>  a microkernel is a potential kernel option. 
>>
>>  > http://lists.gnu.org/archive/html/guix-devel/2016-12/msg00857.html 
>> 
>>
>> * the effort that has been put into GNU Hurd to get it to where it is.
>>
>> * the bootsrapping initiative.
>>
>>  > https://bootstrappable.org 
>>  > https://fosdem.org/2019/schedule/event/gnumes 
>> 
>>
>> # Intent
>>
>> * I would like to understand why GNU Hurd is being focused
>>  on (my perception) given other microkernel options. 
>> * I want to share what I have found after doing some looking into
>>  microkernels.
>> * I am curious what others think of microkernels.
>>
>> I mention the appreciations above because I am aiming for a tone of
>> appreciation and curiosity and not a critical one.  The tone can be a
>> challenge for written communication. 
>>
>> # My microkernel experience
>>
>> Currently I do not have any practical experience using any microkernel.
>> I have just spent time looking into the topic as it is interesting to
>> me.
>>
>> # Why microkernels?
>>
>> I think Andrew Tanenbaum explains benefits of microkernel entertainingly
>> in this talk:
>> http://www.youtube.com/watch?v=bx3KuE7UjGA 
>> 
>>
>> The talks has a focus on Minix but I think the benefits are transferable
>> to other microkernels.
>>
>> # GNU Hurd
>>
>> ## Perceived focus
>>
>> I looks to me like there is a effort (which I appreciate) to get Guix
>> working on Hurd.  I get this perception from:
>>
>> http://lists.gnu.org/archive/html/guix-devel/2016-12/msg00857.html 
>> 
>>
>> These comments from this thread:
>>
>> https://lists.gnu.org/archive/html/help-guix/2019-03/msg00158.html 
>> 
>>
>> Ricardo Wurmus:  "Let’s work on the Hurd, people!  It’s beautiful!"
>>
>> Jan Nieuwenhuizen: "FWIW the Mes port to the Hurd is ongoing and mes now
>> runs, next thing up is fork which we need for running mescc."
>>
>> ## Critiques of Hurd
>>
>> I would be curious what people think about these third party critiques
>> (not mine) of Hurd.
>>
>> ### From X15
>>
>> https://www.sceen.net/x15 
>>
>> "Although the design of the Hurd is promising and attractive, its
>> implementation has a number of severe issues. X15 takes the approach of
>> the complete rewrite to make sure that key ideas are kept in mind at all
>> times during development. Since it’s not meant to be compatible with the
>> Hurd, critical interfaces such as IPC and signals can be re-implemented
>> completely differently. There is a lot of emphasis on code quality and
>> ease of maintenance, obtained from disciplined application of best
>> practices."
>>
>> ### From HelenOS
>>
>> http://www.helenos.org/wiki/FAQ#HowisHelenOSdifferentfromGNUHurd 
>> 
>>
>> ### Why Hurd?
>>
>> Why the focus on Hurd given other microkernel options?  I ask this
>> question out of curiosity and a lack of practical experience with
>> microkernels.
>>
>> # Microkernel wish list
>>
>> These are things that I see as desirable in a microkernel.
>>
>> ## Free software
>>
>> It should be completely free software.  No binary blobs included.  It
>> looks like all of the microkernel listed here are:
>> http://www.microkernel.info 
>>
>> ## RISC-V
>>
>> RISC-V a free and open instruction set architecture is a nice complement
>> to a free operating system.  It is nice if a mircokernel already has
>> plans to run on RISC-V. 
>>
>> Intel security issues:
>> https://libreboot.org/faq.html#intel 
>>
>> ARM security issues:
>> https://libreboot.org/faq.html#amd 
>>
>> ### Entirely free RISC-V computers
>>
>> These two initiatives are entirely free hardware based on RISC-V.
>>
>> * HiFive Unleashed
>>  > 

Re: Any interest in using HTML for locally-installed Texinfo documentation?

[sirgazil]

Hello, Gavin :)

El 1/04/19 a las 7:55 a. m., Gavin Smith escribió:

Dear Guix developers,

I hope I am not intruding by advertising a project that may be of
interest to you.

Documentation for GNU packages and others is often installed in the
Info format, a plain text format.  Using a plaintext based format for
documentation does not take advantage of bitmapped displays that have
been available for decades.  It does not allow styling of text or
reflowing of text.  Much information is lost in the conversion from
Texinfo to Info and any attempt in, for example, Emacs to re-add this
information is unreliable.

Nonetheless, Info viewers have continued to have advantages over web
browsers.  They are fast, and have features for searching the manual
with index lookup.  They allow the use of keyboard commands.

In attempt to bring some of the benefits of the Info viewers to HTML
documentation in web browsers, in 2017, as part of Google Summer of
Code, Matthieu Lirzin worked on a JavaScript interface that works with
the HTML that texi2any produces.  His work is substantially complete.
A manual with this interface added is at
https://www.gnu.org/software/texinfo/manual/texinfo-html/Overview.html.
All the important keyboard commands that work in the Info viewers are
implemented, including index lookup.

The code he produced is in the js/ subdirectory of the Texinfo git
repository, and also available at
https://alpha.gnu.org/gnu/texinfo/texinfo-js-0.0.90.tar.gz

I believe this work has great potential to increase the ease of
accessing documentation, including documentation locally installed on
a user's own computer.  When a user is using a bitmapped display (e.g.
with X11), this could become the default way that they access
documentation.

I am contacting you because the distribution level may be the best
place to push this forward.  There are two reasons:
* The distribution could take care of installation of HTML
documentation files (at the moment, there is no standard place to
install these, and Automake does not support installing HTML files
generated from Texinfo).
* It could also take responsibility for checking web browser
compatibility.  Even if we don't use the JavaScript interface for
documentation on the GNU website due to browser compatibility
concerns, an OS distribution would have control over which browser was
used to view documentation.

Although I have little knowledge of Guix, it is the natural choice of
operating system distribution to contact about this possibility, as
both Texinfo and Guix are GNU projects.

If there is nobody who wants to take this forward within Guix, then
suggestions would also be welcome on how to otherwise push this
forward.



I didn't know this project existed, I wanted something like this.

As a high-level user of computers, I'd like to see this kind of 
documentation available both in the desktop and on the Web. I support it.


Thanks for the information,


--
Luis Felipe López Acevedo
http://sirgazil.bitbucket.io/

Re: KMScon vs. AMD Radeon

[Mathieu Othacehe]

Hello,

> On Guix System 0.16 the directory /sys/class/drm contains only
> ttm and version.

Ok, thanks for testing.

Here's a patch that fallback to mingetty if kmscon is not supported. I
don't have a machine with AMD GPU for testing so if Florian or Pierre
could test the patch that would be very helpful :)

Thanks,

Mathieu
>From f728749dc02f8bb8a1870925547d96d8ce352f55 Mon Sep 17 00:00:00 2001
From: Mathieu Othacehe 
Date: Mon, 1 Apr 2019 15:54:26 +0200
Subject: [PATCH] wip: Fallback to mingetty if kmscon is not supported.

---
 gnu/services/base.scm  |  29 +++--
 gnu/system/install.scm | 240 +++--
 2 files changed, 160 insertions(+), 109 deletions(-)

diff --git a/gnu/services/base.scm b/gnu/services/base.scm
index 04b123b833..fde2cdbcfb 100644
--- a/gnu/services/base.scm
+++ b/gnu/services/base.scm
@@ -1105,12 +1105,18 @@ the tty to run, among other things."
   (login-program  mingetty-login-program  ;gexp
   (default #f))
   (login-pause?   mingetty-login-pause?   ;Boolean
-  (default #f)))
+  (default #f))
+  ;; Boolean
+  ;; XXX: This should really be handled in an orthogonal way, for instance as
+  ;; proposed in .  Keep it internal/undocumented
+  ;; for now.
+  (%auto-start?   mingetty-auto-start?
+  (default #t)))
 
 (define mingetty-shepherd-service
   (match-lambda
 (($  mingetty tty auto-login login-program
- login-pause?)
+ login-pause? %auto-start?)
  (list
   (shepherd-service
(documentation "Run mingetty on an tty.")
@@ -1140,7 +1146,8 @@ the tty to run, among other things."
 #$@(if login-pause?
#~("--loginpause")
#~()
-   (stop   #~(make-kill-destructor)))
+   (stop   #~(make-kill-destructor))
+   (auto-start? %auto-start?))
 
 (define mingetty-service-type
   (service-type (name 'mingetty)
@@ -2146,7 +2153,13 @@ This service is not part of @var{%base-services}."
   (auto-login  kmscon-configuration-auto-login
(default #f))
   (hardware-acceleration?  kmscon-configuration-hardware-acceleration?
-   (default #f))) ; #t causes failure
+   (default #f))  ; #t causes failure
+  ;; Boolean
+  ;; XXX: This should really be handled in an orthogonal way, for instance as
+  ;; proposed in .  Keep it internal/undocumented
+  ;; for now.
+  (%auto-start?kmscon-configuration-auto-start?
+   (default #t)))
 
 (define kmscon-service-type
   (shepherd-service-type
@@ -2157,7 +2170,8 @@ This service is not part of @var{%base-services}."
(login-program (kmscon-configuration-login-program config))
(login-arguments (kmscon-configuration-login-arguments config))
(auto-login (kmscon-configuration-auto-login config))
-   (hardware-acceleration? (kmscon-configuration-hardware-acceleration? config)))
+   (hardware-acceleration? (kmscon-configuration-hardware-acceleration? config))
+   (auto-start? (kmscon-configuration-auto-start? config)))
 
(define kmscon-command
  #~(list
@@ -2174,9 +2188,10 @@ This service is not part of @var{%base-services}."
(shepherd-service
 (documentation "kmscon virtual terminal")
 (requirement '(user-processes udev dbus-system))
-(provision (list (symbol-append 'term- (string->symbol virtual-terminal
+(provision (list (symbol-append 'kmscon- (string->symbol virtual-terminal
 (start #~(make-forkexec-constructor #$kmscon-command))
-(stop #~(make-kill-destructor)))
+(stop #~(make-kill-destructor))
+(auto-start? auto-start?))
 
 (define-record-type* 
   static-networking make-static-networking
diff --git a/gnu/system/install.scm b/gnu/system/install.scm
index aad1deb913..b9c58691d4 100644
--- a/gnu/system/install.scm
+++ b/gnu/system/install.scm
@@ -209,6 +209,45 @@ the user's target storage device rather than on the RAM disk."
 (persistent? #f)
 (max-database-size (* 5 (expt 2 20)) ;5 MiB
 
+(define (installer-services)
+  (define is-kmscon-supported?
+#~(let ((drm-regex (make-regexp "(card|render).*$")))
+(not (null? (scandir "/sys/class/drm"
+ (cut regexp-exec drm-regex <>))
+
+  (let ((mingetty
+ (service mingetty-service-type
+  (mingetty-configuration
+   (tty "tty1")
+   (auto-login "root")
+   (%auto-start? #f
+(kmscon
+ (service kmscon-service-type
+  (kmscon-configuration
+   (virtual-terminal "tty1")
+   

Any interest in using HTML for locally-installed Texinfo documentation?

[Gavin Smith]

Dear Guix developers,

I hope I am not intruding by advertising a project that may be of
interest to you.

Documentation for GNU packages and others is often installed in the
Info format, a plain text format.  Using a plaintext based format for
documentation does not take advantage of bitmapped displays that have
been available for decades.  It does not allow styling of text or
reflowing of text.  Much information is lost in the conversion from
Texinfo to Info and any attempt in, for example, Emacs to re-add this
information is unreliable.

Nonetheless, Info viewers have continued to have advantages over web
browsers.  They are fast, and have features for searching the manual
with index lookup.  They allow the use of keyboard commands.

In attempt to bring some of the benefits of the Info viewers to HTML
documentation in web browsers, in 2017, as part of Google Summer of
Code, Matthieu Lirzin worked on a JavaScript interface that works with
the HTML that texi2any produces.  His work is substantially complete.
A manual with this interface added is at
https://www.gnu.org/software/texinfo/manual/texinfo-html/Overview.html.
All the important keyboard commands that work in the Info viewers are
implemented, including index lookup.

The code he produced is in the js/ subdirectory of the Texinfo git
repository, and also available at
https://alpha.gnu.org/gnu/texinfo/texinfo-js-0.0.90.tar.gz

I believe this work has great potential to increase the ease of
accessing documentation, including documentation locally installed on
a user's own computer.  When a user is using a bitmapped display (e.g.
with X11), this could become the default way that they access
documentation.

I am contacting you because the distribution level may be the best
place to push this forward.  There are two reasons:
* The distribution could take care of installation of HTML
documentation files (at the moment, there is no standard place to
install these, and Automake does not support installing HTML files
generated from Texinfo).
* It could also take responsibility for checking web browser
compatibility.  Even if we don't use the JavaScript interface for
documentation on the GNU website due to browser compatibility
concerns, an OS distribution would have control over which browser was
used to view documentation.

Although I have little knowledge of Guix, it is the natural choice of
operating system distribution to contact about this possibility, as
both Texinfo and Guix are GNU projects.

If there is nobody who wants to take this forward within Guix, then
suggestions would also be welcome on how to otherwise push this
forward.

Best wishes,

Gavin

Re: Software Heritage & Guix

[znavko]

Do not think it is necessary, but may be it will have sense for SWH team.
In Russia their ip 217.70.184.38 is blocked by Roskomnadzor (this is a ministry 
of communications and Internet), so it is not opening. 
https://reestr.rublacklist.net/search/?q=217.70.184.38 


Are their servers all right? Are they in blacklists also anywhere?


Mar 29, 2019, 4:05 PM by l...@gnu.org:

> Hello!
>
> I’ve written a post on the Software Heritage support in Guix:
>
>  > 
> https://gnu.org/s/guix/blog/2019/connecting-reproducible-deployment-to-a-long-term-source-code-archive
>  
> 
>
> Happy reading!  :-)
>
> Ludo’.
>