Re: KMScon vs. AMD Radeon
On Tue, Apr 02, 2019 at 06:31:40PM +0200, Danny Milosavljevic wrote: > Hi Mathieu, > > I would prefer if we just passed "nomodeset" to the Linux kernel in the > installer image (in the installer image only) in order to disable all those > funny drivers in the first place. > > Then, grub would use vesa in order to initialize graphics - which should have > seen testing for... forever... years. > > We could use "set gfxmode=..." in grub in order to set a specific graphics > mode. > > (The Linux kernel module is called uvesafb--but it should be picked up > automatically) > > (Use "vbeinfo" in the grub prompt in order to find out whether it's using > VESA) > > I don't think it's wise to complicate bootup when we could just use vesa. > There's nothing wrong with it as far as I know... Not using KMScon would prevent support for the Chinese and Japanese language during install, would it not? Currently there is no support because · the Chinese and Japanese locales are not added to the installer, it only includes glibc-utf8-locales, · there is no translated PO file for the installer yet anyway, but otherwise it would work, would it not? However, this means in particular that · when using KMScon, the installer should change the locale that gets used once it is selected, · when using mingetty, the locale should only be changed for languages other than Chinese and Japanese, · the console font should be changed to match the locale similar to console-setup on Debian. Maybe some of this is already supported, I don’t know. Regards, Florian
Re: KMScon vs. AMD Radeon
On Tue, Apr 02, 2019 at 01:42:38PM +0200, pelzflorian (Florian Pelz) wrote: > The more current commit 0e558640361b6ab4aac0f424cb587b21a642bab8 > without the patch runs into a Guile prompt because of an error in > resolve-variable of something with setuid-binaries on grandma’s laptop > and into a different error and a Guile prompt on QEMU with > [ 9.426604] random: dbus-uuidgen: uninitialized urandom read (12 bytes read) > [ 9.518845] attempt to access beyond end of device > [ 9.519037] sda: rw=524288, want=3194596, limit=3184000 > ERROR: In procedure primitive-load: > In procedure fport_read: Input/output error > > 0e558640361b6ab4aac0f424cb587b21a642bab8 with the AMD Radeon patch > runs into a kernel panic on QEMU and grandma’s laptop. I have not > tested AMD Radeon. > > Regards, > Florian > I am still bisecting. Will report back.
Re: Any interest in using HTML for locally-installed Texinfo documentation?
El 2/04/19 a las 5:10 p. m., Per Bothner escribió: On 4/2/19 1:12 PM, Ricardo Wurmus wrote: As far as I know GNOME’s Yelp is a frontend to different kinds of documentation and it does support Info files. That reads *info* files. We're talking about reading *html* files. See Gavin's original message for why we want to use html. Isn't it more about "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 find Yelp easy to use as a desktop user. I think it would be great to easily access info manuals or info manuals translated to docbook or mallard from the Yelp viewer. It would make GNU documentation easier to discover on the desktop. I think Matthieu's JavaScript interface would still be useful for the HTML documentation online. -- Luis Felipe López Acevedo http://sirgazil.bitbucket.io/
Re: Any interest in using HTML for locally-installed Texinfo documentation?
El 2/04/19 a las 3:27 p. m., Ricardo Wurmus escribió: Ricardo Wurmus writes: Ludovic Courtès writes: I hear the argument; it’s true that not everyone uses Emacs or is familiar with the standalone Info reader. Rendering of Info manuals in Emacs is not bad, but a modern browser can do a better job. Yet I’m not completely sold to the everything in the browser approach, and everything in JavaScript. In an ideal world (for me), we’d rather provide a local documentation viewer that renders Texinfo directly. As far as I know GNOME’s Yelp is a frontend to different kinds of documentation and it does support Info files. It may not work out of the box without setting some environment variables first, but I remember viewing Info manuals in Yelp not too long ago when I first learned that it supports Info. It actually does seem to just work. Try this: yelp info:guix It works for me too (even searching). But I see some things missing, although I'm using Yelp 3.18 from the host distro: * Clicking any index result in an error: error on line 1114 at column 428: PCDATA invalid Char value 8 * Info manuals are not in the list of manuals available. Being able to use Yelp would be great, in my opinion. After all, GNOME is the GNU Desktop. -- Luis Felipe López Acevedo http://sirgazil.bitbucket.io/
Re: Any interest in using HTML for locally-installed Texinfo documentation?
On 4/2/19 1:12 PM, Ricardo Wurmus wrote: As far as I know GNOME’s Yelp is a frontend to different kinds of documentation and it does support Info files. That reads *info* files. We're talking about reading *html* files. See Gavin's original message for why we want to use html. -- --Per Bothner p...@bothner.com http://per.bothner.com/
Re: Any interest in using HTML for locally-installed Texinfo documentation?
Hi Gavin, Gavin Smith writes: [...] > 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. Nice! I like seeing Info commands work on WWW-posted doc. This would be useful to an Emacs/Info user for packages that aren't installed or when their Info system is broken. To reach the more numerous "non Emacs/Info users", these commands need to be advertised and promoted. Is there a plan for this? WRT the current implementation ... In Emacs and Info, typing 'h' shows Info keyboard commands. It didn't do anything visiting this site with CHROME and Safari. It would be nice if a second 'C-s' advanced to the next match without requiring . 'C-s' on the site is so slow that I thought it was broken at first :( HTH - George
Re: Any interest in using HTML for locally-installed Texinfo documentation?
Ludovic Courtès writes: > I hear the argument; it’s true that not everyone uses Emacs or is > familiar with the standalone Info reader. Rendering of Info manuals in > Emacs is not bad, but a modern browser can do a better job. > > Yet I’m not completely sold to the everything in the browser approach, > and everything in JavaScript. In an ideal world (for me), we’d rather > provide a local documentation viewer that renders Texinfo directly. As far as I know GNOME’s Yelp is a frontend to different kinds of documentation and it does support Info files. It may not work out of the box without setting some environment variables first, but I remember viewing Info manuals in Yelp not too long ago when I first learned that it supports Info. -- Ricardo
Re: Video narration
Hi Paul! > Thank you for uploading the cli audios for the packaging3 video. That > completes the set! Yeah! > > I will be going to the studio in half an hour (11.00am UTC). They have > a space with low background noise. However, I will ask for a short > 'silence' recording too, so that we can use it for joining sections if > we need to. Great! :) Let me know when you have time to push them - no rush, just to test :) - Regards :) Laura
Re: Video narration
Hi :) > Sorry, I am late to the party. To clarify things, the following is > happening here: > 1. at first guix is built from source, in a guix environment guix > 2. the package is added > 3. the package build is tested using pre-inst-env guix build package > > So, the environment is not for r-aspi, but to get to the exact environment > where > the pre-inst-env was built, so the third step is reproducible. > > Does that make sense? Yes, that was the way I packaged and what was trying to explain, and asked the others in case I was wrong. Regards :) Laura
Re: Guix on a microkernel
Ludovic Courtès writes: > 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! That would be pretty cool! The GNU/Hurd could use some more device drivers, modern filesystem support, etc. > > Ludo’. > -- Joshua Branson Sent from Emacs and Gnus
Re: Video narration
Hello, Laura Lazzati ezt írta (időpont: 2019. ápr. 1., H, 20:02): > > 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? > Sorry, I am late to the party. To clarify things, the following is happening here: 1. at first guix is built from source, in a guix environment guix 2. the package is added 3. the package build is tested using pre-inst-env guix build package So, the environment is not for r-aspi, but to get to the exact environment where the pre-inst-env was built, so the third step is reproducible. Does that make sense? > Regards :) > Laura Best regards, g_bor
Re: Any interest in using HTML for locally-installed Texinfo documentation?
On 4/2/19 8:02 AM, Gavin Smith wrote:
Using JavaScript within a web browser has big drawbacks due to its
"sandboxed" nature. (You can't access environment variables, for
example.) However, we'd want to avoid having to re-implement too much
of the web browser; for example, input file parsing, text layout and font
rendering.
Both Electron and QtWebEngine have mechanisms for communicating between
the "browser" window and the main application, which is not sandboxed.
(For QtWebEngine the main application is regular non-sandboxed C++ code.)
For a desktop browser like Firefox, one could pass important environment
variables in the URL. For bi-directional communication between a
sandboxed desktop browser and the C/C++ wrapper program one can always
use WebSockets or XmlHttpRequest ("AJAX").
Note below I'm talking in terms of an ideal long-term roadmap.
Medium-term one would prioritize, of course.
I'm assuming you would prefer to not require either Qt or Electron as
a dependency. In that case my recommendation is two separate commands,
supplied by two separate distribution packages:
(1) A plain 'info' command can parse command-lines, find the right
html file, and then either open a window in the default desktop browser,
or display the file using 'emacs -nw'. (If old-style info files are
available, it could also display those directly.) If qtinfo or electroninfo are
installed, they could be used to open a window instead.
Cross-manual links and some other functionality may be restricted when
using a standard desktop browser.
(2) Either 'qtinfo' or 'electroninfo' or both, which is an alternative
or wrapper for info using QtWebEngine or Electron, respectively.
GtkWebView may also be worth considering, but I have no experience with it.
This doesn't address the issue of multiple installed versions of the
same manual or manuals in different "prefix hierarchies". I imagine the
Info browser would interpret the "../" string specially in a link and
go looking through a search path for the referenced manual. Again, this
may be difficult to implement in standard web browsers due to security
restrictions.
It can be done in a standard web browsers using WebSockets or
XmlHttpRequest (AJAX), but that's more work.
I'm getting the feeling that we need a web browser, or something like
it, which can integrate with the operating system a lot more, without
sandboxing or security restrictions.
I (tentatively) recommend using QtWebEngine (i.e. 'qtinfo'). Electron is easier
to write and less verbose, but it is heavy duty and packaging may be a pain.
(Though there are other good reasons to package Electron.) Qt is more
established in the GNU/Linux environment, and is easier to integrate
with C/C++ code, including re-using code from existing info.
A Gtk equivalent would have similar benefits.
If curious, you can look at the Qt code for DomTerm at:
https://github.com/PerBothner/DomTerm/tree/master/qtdomterm
This handles creating a QtWebEngine window, menus, and bi-directional
communication with the JavaScript in the QtWebEngine window. It's not
super-compact, but it's quite reasonable. (The main C code for
process/pty management is in the lws-term directory.)
--
--Per Bothner
p...@bothner.com http://per.bothner.com/
Re: KMScon vs. AMD Radeon
Hi Mathieu, I would prefer if we just passed "nomodeset" to the Linux kernel in the installer image (in the installer image only) in order to disable all those funny drivers in the first place. Then, grub would use vesa in order to initialize graphics - which should have seen testing for... forever... years. We could use "set gfxmode=..." in grub in order to set a specific graphics mode. (The Linux kernel module is called uvesafb--but it should be picked up automatically) (Use "vbeinfo" in the grub prompt in order to find out whether it's using VESA) I don't think it's wise to complicate bootup when we could just use vesa. There's nothing wrong with it as far as I know... pgpd0azper0_Z.pgp Description: OpenPGP digital signature
Re: Audio/sound (ALSA) in guix environment --container
Hello! Ricardo Wurmus skribis: > Ludovic Courtès writes: [...] >> Currently, without --user, we keep the current user’s name. So it would >> actually be consistent to inherit its UID as well. And with ‘--user’, >> we’d use the given user name and UID 1000. (Essentially what Pierre >> proposed above.) > > Excellent, this sounds good. Done in commit 1ccc0f807d3f22fa9ade1c607c112e04df833a72. Ludo’.
Re: Any interest in using HTML for locally-installed Texinfo documentation?
On Tue, Apr 02, 2019 at 11:37:51AM +0200, Ludovic Courtès wrote: > (For some reason ‘i’ does open the index search box for me, but then > hitting enter doesn’t produce any effect. The other navigation commands > work fine, though.) It works on Firefox 53, at least. > Yet I’m not completely sold to the everything in the browser approach, > and everything in JavaScript. In an ideal world (for me), we’d rather > provide a local documentation viewer that renders Texinfo directly. > TTN’s IXIN experiment was a step in the right direction IMO, but I > understand this approach is not something that’s happening now. To my knowledge, no program has ever been produced that does anything useful with IXIN. Using JavaScript within a web browser has big drawbacks due to its "sandboxed" nature. (You can't access environment variables, for example.) However, we'd want to avoid having to re-implement too much of the web browser; for example, input file parsing, text layout and font rendering. One thought is that there may be other "layout engines" that could be used, such as those in various GUI toolkits. > When talking about ease of access, we can’t ignore keyword searches. > How would you do ‘info -k’? I don't know. You would have to have some way of finding all the installed manuals. This may be difficult with a standard web browser due to security restrictions. > How would you even simply point your > browser to a specific manual? Maybe there could be a command for this within the browser. There could also be a command-line program that would launch the documentation browser. > What about inter-manual cross-references? > Would we need a mechanism similar to ‘htmlxref.cnf’ but that would > browse local manuals? Good question. The inter-manual links in locally-installed HTML files would have to be recognizable. They could look like Texinfo instead of https://www.gnu.org/software/texinfo/manual/texinfo/html_node/index.html#Top;>Texinfo as there were would no way of resolving the second link to a locally-installed file (it is not clear from the URL what the name of the manual even is). It would be quite simple to get texi2any to output this instead. (It can currently be done by passing '-c HTMLXREF=empty' where 'empty' is an empty file, but a better interface could be devised.) Then inter-manual links would all work, assuming the installed manuals are all subdirectories of the same directory (e.g. /usr/share/info/html). This doesn't address the issue of multiple installed versions of the same manual or manuals in different "prefix hierarchies". I imagine the Info browser would interpret the "../" string specially in a link and go looking through a search path for the referenced manual. Again, this may be difficult to implement in standard web browsers due to security restrictions. > What would be the recommended solution for Emacs > and console users? Info files would carry on as an option. I'm getting the feeling that we need a web browser, or something like it, which can integrate with the operating system a lot more, without sandboxing or security restrictions.
Re: custom kernel config
On Mon, Apr 01, 2019 at 09:46:27PM +0200, Ludovic Courtès wrote: > 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. > I'll see if I can find their kernel config and Guix-ify it. It should be easy to test since with one command Guix can build the kernel and the VM. -- 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: custom kernel config
On Tue, Apr 02, 2019 at 10:04:29AM +0200, Pierre Neidhardt wrote: > Efraim Flashner writes: > > > 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. > > Great success! :) > > My attempts on my Xiaomi Air 13: > > - Stock build time: ~50 minutes. > - Custom kernel, starting from nothing: 5-10 minutes. > It works, but the mousepad and the sound are missing. I can't figure > which component is missing. Does anyone know if there is any reliable > way to know the kernel config I need for that? I think I used Gentoo's documentation from the handbook¹ and laboriously going through `lsmod` and grepping our kernel configs (I think) to figure out what they were called in the kernel. > > - Custom kernel, starting from Linux-libre and removing components: 40 > minutes. It works, but I don't understand why it's still so long to > build. I've removed almost all devices I didn't need from the "device > section", but this is clearly not the bottleneck. I started that way too, but I wasn't sure just how much I could take out. > > Cheers! > > -- > Pierre Neidhardt > https://ambrevar.xyz/ ¹ https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Kernel -- 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
On Mon, Apr 01, 2019 at 10:01:58PM +0200, Ludovic Courtès wrote: > 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. :-) > I applied Mathieu’s patch to current Guix, but the kernel panics on QEMU and on non-AMD Radeon hardware. I have not tried on AMD Radeon yet. I will first try again an older Guix without the patch but it will take a few hours. Regards, Florian
Re: KMScon vs. AMD Radeon
Hey Ludo, Thanks for reviewing :) > Should we instead build this functionality into ‘kmscon-service-type’, > possibly with a flag to turn it off? Well I thought about it, but if kmscon-service-type does the DRM support detection and exits "cleanly", how could we fallback to mingetty? Thanks, Mathieu
