metalune[m] | I have devuan on a second partition now | 00:00 |
---|---|---|
metalune[m] | tomorrow I will have to get rid of all the pre-isntalled crap | 00:00 |
metalune[m] | like ... the DE | 00:00 |
metalune[m] | the DisplayManager | 00:01 |
fsmithred | metalune[m], maybe you should have just installed the base system and then added stuff you want | 00:12 |
fsmithred | if you installed a desktop environment from the installer, you will have a hard time removing parts. | 00:12 |
metalune[m] | I did it! | 16:41 |
metalune[m] | I am running devuan rn | 16:41 |
metalune[m] | even tho the installer failed, I somehow made it run | 16:42 |
tuxd3v | metalune[m], what is devuan rn? | 16:47 |
metalune[m] | what | 16:53 |
metalune[m] | "I am running devuan righ now" | 16:54 |
metalune[m] | *right | 16:54 |
tuxd3v | metalune[m], congratz :) | 16:56 |
fsmithred | metalune[m], how did the installer fail? | 17:01 |
n4dir | Right after the grub menu i get a message about intel/<missing-part>. I try to find that message, but can't. Where would i look? | 17:17 |
fsmithred | possible firmware missing? | 17:18 |
n4dir | i think so, but it is intel/<missing-part> | 17:18 |
fsmithred | I think I get that message. Hang on. | 17:18 |
n4dir | i got no problems, as far i can tell. Just wondering if i should install some non-free firmware or such | 17:18 |
fsmithred | you can, but don't have to | 17:19 |
n4dir | i also might stay focused during boot, but it goes so quick, and without problems i don't think of it when booting | 17:19 |
n4dir | i looked at /var/log/boot and in dmesg. Both not my business, so they might be plain wrong for such | 17:20 |
fsmithred | well, I can't find it. I know I've seen it recently, but it's not in the most recent VMs I've booted and it's not on the laptop. | 17:26 |
fsmithred | I think it wants firmware-linux-nonfree or maybe xserver-xorg-video-intel | 17:26 |
metalune[m] | <fsmithred "metalune, how did the installer "> I don't know, when installing packages it just said "this step failed" or smth like that | 17:29 |
fsmithred | oh, that happens sometimes | 17:30 |
metalune[m] | all I had was a bare system | 17:30 |
metalune[m] | didn't even have sudo and stuff | 17:30 |
fsmithred | I think it's a network problem, losing connection to the server | 17:30 |
n4dir | fsmithred: let me write a note and put it on the PC, so next reboot i will remember to have a close look. | 17:30 |
metalune[m] | I used LAN | 17:30 |
fsmithred | repeat the step and it usually works | 17:30 |
metalune[m] | I tried that | 17:30 |
metalune[m] | I repeated the step 4 times | 17:30 |
fsmithred | wow | 17:30 |
metalune[m] | it never worked | 17:30 |
metalune[m] | so I just said fuck it and went on with the next step | 17:30 |
fsmithred | which iso did you use? | 17:30 |
n4dir | my main question was if there is a way to get that info after booting. | 17:30 |
metalune[m] | desktop | 17:31 |
metalune[m] | I have 2 questions tho | 17:31 |
fsmithred | ok | 17:31 |
metalune[m] | 1. about debian backports, can I just use `deb http://deb.debian.org/debian buster-backports main` or are there devuan-specific backports | 17:31 |
metalune[m] | 2. how can I install the linux-libre kernel? | 17:31 |
fsmithred | deb http://deb.devuan.org/merged beowulf-backports main | 17:32 |
fsmithred | that way you get the benefit of the banned-packages filter | 17:32 |
fsmithred | I've never installed a libre kernel. Someone said there's a repo for debian, and I also know that gnuinos has some libre kernels. | 17:33 |
metalune[m] | noise, thx | 17:33 |
metalune[m] | * noice, thx | 17:33 |
n4dir | metalune[m]: there probably is a repository for the libre kernel somewhere | 17:33 |
metalune[m] | yeah I know | 17:34 |
n4dir | well. then install it | 17:34 |
metalune[m] | but I was wondering where it is | 17:34 |
metalune[m] | because if someone here already knew it could save me a lot of time researching | 17:34 |
metalune[m] | * because if someone here already knew it could save me a lot of time searching for it | 17:34 |
fsmithred | https://linux-libre.fsfla.org/pub/linux-libre/freesh/ | 17:34 |
n4dir | https://romanrm.net/loongson/linux-libre try that | 17:35 |
metalune[m] | W: GPG error: http://www.fsfla.org/download/linux-libre/lemote/gnewsense metad Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY BCB7CF877E7D47A7 | 17:38 |
metalune[m] | I haven't used a debian based distro in ages | 17:39 |
fsmithred | you added a repo? You should be able to download the deb packages and install them with dpkg | 17:40 |
n4dir | apt-cache search key ; sometimes gives a key | 17:40 |
fsmithred | go up one level and there are key files | 17:41 |
n4dir | I once installed the libre kernel and what should i tell you? I saw no difference whatsoever. | 17:43 |
metalune[m] | the point is that there are no proprietary blobs | 17:45 |
n4dir | but then: i also never see differences in version upgrades ... ha ha | 17:45 |
IanJ | I guess if you really want no binary blobs or proprietary code in your kernel then that's what you want. But if you're going to those kind of extremes then you have to consider your bios and processor. | 17:45 |
metalune[m] | 1. I am already researching libreboot and coreboot | 17:46 |
metalune[m] | 2. why do I have to consider my processor? | 17:46 |
IanJ | Because if you have an intel processor with IME it has an entire OS running in there. | 17:46 |
metalune[m] | that's what Coreboot / Libreboot is for | 17:47 |
metalune[m] | isn't it | 17:47 |
IanJ | Not unless it somehow disables the IME on the processor. | 17:48 |
IanJ | looks like it can... https://www.coreboot.org/Intel_Management_Engine | 17:50 |
metalune[m] | I need to check that, I kinda assumed that's what it does, because otherwise.. what would be the point lolz | 17:50 |
IanJ | Looks like with varying degrees of success depending on the version of the ME. | 17:54 |
IanJ | https://github.com/corna/me_cleaner | 17:55 |
n4dir | What might be the reason there is no /var/log/Xorg log file? | 17:57 |
fsmithred | might be user's home | 17:58 |
fsmithred | I forget where. Maybe in .local | 17:58 |
metalune[m] | you wan't a logfile from what? | 17:58 |
IanJ | ~/.local/share/xorg/Xorg.0.log | 17:59 |
n4dir | that is where it is now? | 17:59 |
n4dir | well, it is there, but why? | 17:59 |
metalune[m] | why would it NOT be there? | 18:00 |
IanJ | I have one in /var/log/ too | 18:00 |
fsmithred | because X is running as user | 18:00 |
luser977 | could well be in /tmp | 18:01 |
n4dir | when did that change? | 18:01 |
fsmithred | in buster/beowulf | 18:01 |
fsmithred | uh, maybe in stretch/ascii | 18:01 |
IanJ | I'm on beowulf and mine is being written to in /var/log. | 18:02 |
luser977 | putting log files not subject to logrotate in a directory which is backed up is a bad idea. | 18:02 |
luser977 | $HOME abuse | 18:03 |
IanJ | the one in my home directory is old, pre beowulf | 18:03 |
IanJ | I didn't reformat my home directory when I installed beowulf. | 18:03 |
* luser977 nods sadly | 18:03 | |
IanJ | n4dir: I guess you would expect to find it in /var/log then if you're running beowulf. | 18:05 |
n4dir | i expect that, but it ain't there. | 18:05 |
IanJ | is xorg running ok? | 18:05 |
n4dir | yeah, sure. | 18:05 |
IanJ | hmmm, strange :) | 18:05 |
n4dir | If it is now in $HOME, fine with me. I will get used to it. I have to | 18:06 |
IanJ | n4dir: check the one in home is being written to. I had one there but it was from my previous debian install probably. | 18:06 |
IanJ | Maybe it depends how you're starting x, I'm using a lightdm. | 18:07 |
n4dir | It sure has content. And it can't be copied from somewhere else. --- startx here | 18:07 |
IanJ | check the date on the file. | 18:07 |
IanJ | I just did ls -al on mine and it was dated back November so I know it's not in use. The one in /var/log is dated today. | 18:08 |
n4dir | both today, it seems. | 18:08 |
n4dir | very odd. | 18:09 |
IanJ | Maybe that's due to the way you're starting x then. If you use a login manager maybe it puts it in /var/log | 18:09 |
IanJ | That's what seems to be happening here anyway. | 18:09 |
n4dir | yeah, lets assume that is the reason. Thanks for the info | 18:09 |
n4dir | In the qemu installation with lightdm it has Xorg.log in /var/log, and none in the users home. | 18:12 |
n4dir | that being ceres though. But i think that is the explanation. At least fine enough for me | 18:12 |
user____ | can anyone explain in 10 words why the running kernel and the running kernel package have 2 different numbers in them for version? | 18:24 |
user____ | running 4.19.0-10-amd64 from 4.19.132-1 -- uhh? | 18:24 |
user____ | [related] where the d* are the implementations of the magical /dev/{mem,kmem,port} devices in the kernel tree? | 18:25 |
koollman | user____: drivers/char/mem.c, I think | 18:31 |
fsmithred | user____, one number is the kernel version and the other number is the debian package version. | 18:34 |
user____ | found it yes https://github.com/torvalds/linux/blob/master/drivers/char/mem.c | 18:35 |
fsmithred | uname -a to see both | 18:35 |
user____ | fsmithred: which is which? | 18:35 |
user____ | I keep seeing both. | 18:35 |
user____ | ok | 18:35 |
fsmithred | the one ending in -amd64 is the package version | 18:35 |
user____ | ok | 18:35 |
aitor_ | hi | 18:35 |
fsmithred | hi aitor | 18:35 |
user____ | thanks | 18:35 |
user____ | could anyone explain why the read_port on /dev/port reads the port 64k times?! https://github.com/torvalds/linux/blob/master/drivers/char/mem.c#631 | 18:36 |
user____ | L 631 | 18:36 |
user____ | is that a busy spin or what? | 18:37 |
koollman | it doesn't | 18:38 |
user____ | oh it's a buffer read ok | 18:38 |
user____ | ok, I get it. I have a problem where reading a port is 250 times slower than writing the same address | 18:39 |
user____ | there is no hw reason for this. It's a plain io register on a PCI printer port. | 18:39 |
koollman | that code seems a bit strange to me, but shouldn't be too slow. maybe writing is async or going through a buffer, but reading can't ? | 18:41 |
aitor_ | today, building some iso images, i was getting a GPG error using the repository of gnuinos in the chroot jail of the live-sdk, even being it signed: | 18:57 |
aitor_ | E: The repository 'http://packages.gnuinos.org/merged beowulf InRelease' is not signed. | 18:57 |
aitor_ | Couldn't execute /usr/bin/apt-key to check blahblahblah... | 18:58 |
aitor_ | i solved this by adding a new config file to APT with the following line: | 18:59 |
aitor_ | APT::Sandbox::User "root"; | 18:59 |
aitor_ | i wonder if i should leave it int eh iso | 18:59 |
aitor_ | sorry | 18:59 |
aitor_ | i wonder if i should leave it in the iso, or remove it | 19:00 |
aitor_ | remove it before building the image, i mean | 19:00 |
aitor_ | fsmithred: yesterday i uploaded an image of gnuinos beowulf with vdev | 19:02 |
fsmithred | aitor, I don't know what to do about that apt config | 19:03 |
aitor_ | ok, no worries, never happened to me before | 19:04 |
fsmithred | cool that vdev still works | 19:04 |
aitor_ | yes! | 19:04 |
aitor_ | i upgraded the hardware database and the content of libudev1-compat, and i also added the cdrom_id binary, missing in the code of jude nelson and required for live sessions | 19:04 |
fsmithred | nice | 19:04 |
fsmithred | I thought I made live-isos with vdev | 19:05 |
fsmithred | yeah, in jessie | 19:05 |
aitor_ | yes, but some changes were needed after jessie | 19:06 |
fsmithred | ah, good work | 19:06 |
aitor_ | the boot time still sucks a bit, but quoting to steve litt, "sucks" is better than "depends on systemd" | 19:06 |
fsmithred | was just gonna ask about boot time | 19:06 |
fsmithred | and yeah, steve is right | 19:07 |
aitor_ | you can give it a try, it's the one with openbox | 19:08 |
aitor_ | we'll improve the boot time over time for sure | 19:09 |
aitor_ | need to go, see you later | 19:10 |
fsmithred | take care | 19:11 |
aitor_ | bye and happy 2021 :) | 19:11 |
fsmithred | :) | 19:11 |
amesser | user____: For transactional busses like PCI, PCI-E reading is two transactions (where to read, result) while writing is one transaction (where to write + data) | 19:16 |
amesser | To problem becomes more evident, the smaller the amount of data | 19:16 |
amesser | Also PCI-E and PCI are not supposed to transfer small data at all. (I have seen same read on PCI-E hardware even slower than on PCI hardware) | 19:19 |
luser977 | amesser 2.7msec/byte is ridiculous. there's a timeout somewhere, but where? | 19:56 |
DashiePie | does anyone know how to use winetricks with the wine-development configuration instead of base? | 23:56 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!