nemo | Bit of a mystery with a home devuan machine | 04:29 |
---|---|---|
nemo | it consists of a Dell XPS with 2 HDs - a spinning rust setup as /home, and a built-in SSD setup for UEFI boot | 04:30 |
nemo | It had been running devuan for several years, but recently the spinning rust /home was failing, causing an increasing number of write errors and confusing a bunch of apps as a result | 04:30 |
nemo | I finally got a replacement authorise, and as I rebooted to do a dd if=/fail of=/new I was shocked by a GRUB> prompt | 04:31 |
nemo | I guessed that maybe some grub update got interrupted due to file system errors on the /home mount (odd but not impossible I guess) so I ignored it and went on with the copy | 04:31 |
nemo | once /home was rescued and clean (which took about a dozen tries due to having to skip past sections - I blame the purchase of a Seagate) | 04:32 |
nemo | I try rebooting. GRUB> prompt. | 04:32 |
nemo | Fine. I grab Devuan Bewulf live image (fail right there 'cause it can't even detect the UEFI SSD)... | 04:33 |
nemo | Grab Devuan Beowulf netinst instead, which I guess is what I should have done first time around. Select rescue, go to the disc | 04:33 |
nemo | everything seems fine | 04:33 |
nemo | / mounted on /dev/nvme01p7 and /boot/efi on p1. try grub update, grub install. everything looks normal. config seems fine | 04:34 |
nemo | reboot. GRUB> prompt | 04:34 |
nemo | ok... maybe... a kernel update got interrupted... somehow? apt install --reinstall linux-image-amd64... reboot. GRUB> | 04:34 |
nemo | ummm grub config file corruption? apt install --reinstall every bloody grub-efi package | 04:35 |
nemo | reboot. GRUB> | 04:35 |
nemo | so... here's where it gets weird | 04:35 |
nemo | I do: | 04:35 |
nemo | ls (hd3,gpt1)/efi/devuan/grub.cfg | 04:35 |
nemo | cat (hd3,gpt1)/efi/devuan/grub.cfg | 04:36 |
nemo | the grub.cfg has 3 lines. | 04:36 |
nemo | searches for the UUID that corresponds to p7 | 04:36 |
nemo | sets it to root | 04:36 |
nemo | then loads that grub.cfg | 04:36 |
nemo | I retype, manually, every line in that grub.cfg that I just catted | 04:36 |
nemo | and my Devuan grub splash pops up. And boot proceeds | 04:37 |
nemo | now I would rather like to not have to type out those 3 lines every time I boot this machine. not to mention kinda weird this happened in the first place | 04:37 |
nemo | oh. I almost forgot. important | 04:37 |
nemo | I tried: | 04:37 |
gnarface | make sure there's a newline at the end of the file | 04:38 |
nemo | configfile (hd3,gpt1)/efi/devuan/grub.cfg | 04:38 |
nemo | gnarface: kk one moment | 04:38 |
* rrq would look for/at (hd3,gpt1)/efi/debian/grub.cfg as well | 04:38 | |
nemo | rrq: you're suggesting I copy it there? | 04:39 |
rrq | yes... that's the one the uei boot is using | 04:39 |
nemo | gnarface: 0a | 04:39 |
nemo | gnarface: does it need dos format? | 04:39 |
gnarface | i don't think so | 04:39 |
rrq | the uefi boot image has the hardcoded and is then signed | 04:40 |
nemo | kaaaaay | 04:40 |
nemo | hm. don't think I have secure boot enabled | 04:40 |
nemo | also devuan shows up fine in the uefi boot menu | 04:40 |
nemo | but can't hurt to try I suppose | 04:40 |
nemo | would like to note this system has been working for a long time. I kind of assume this is related to the failing spinning rust. but now I'm not sure | 04:40 |
rrq | yes, hte boot program is in /efi/devuan so that gives the name, but the program looks for /efi/debian/grub.cfg | 04:41 |
nemo | rrq: why did configfile (hd3,gpt1)/efi/devuan/grub.cfg fail? | 04:41 |
nemo | it was like grub wasn't reading it | 04:41 |
rrq | exactly. | 04:41 |
nemo | but I mean. I gave an explicit path | 04:41 |
nemo | rrq: is this related to the boothole vulnerability fixes? | 04:42 |
nemo | from last fall? | 04:42 |
rrq | the boot program whatever.efi has /efi/debian/grub.cfg hard coded, and that program is signed | 04:42 |
nemo | kk | 04:42 |
nemo | /boot/efi/EFI/devuan# strings *.efi | grep debian | 04:43 |
nemo | /EFI/debian | 04:43 |
nemo | looks like you are exactly correct | 04:43 |
nemo | rrq: sooo... how'd I get a devuan in there. from an earlier installer? | 04:43 |
nemo | I guess I need to fix that across the board | 04:43 |
nemo | rrq: and. maybe on other devuan machines too.. | 04:43 |
nemo | let's see what the one I'm typing on here has | 04:44 |
rrq | copy from /efi/devuan ... | 04:44 |
nemo | rrq: I will I will! you clearly know what you're talking about. I just don't want to have to do manual stuff every grub update | 04:44 |
nemo | and right now grub seems to write to EFI/devuan | 04:44 |
rrq | I thought it was so generic it wouldn't ever change ... but that was wrong apparently | 04:44 |
Xenguy | .oO( It's sometimes not easy being on the fringe ) | 04:45 |
rrq | the alternative would have been to fork enough to make a proper devuan boot loader | 04:46 |
nemo | Xenguy: heh. at least my new system didn't bootloop due to RDRAND systemd bug ☺ | 04:46 |
nemo | rrq: so... right now devuan grub seems to write to efi/devuan | 04:46 |
Xenguy | been under a rock | 04:46 |
nemo | rrq: so I need to manually perform this copy after every upgrade? | 04:47 |
nemo | rrq: so is this related to the boothole fixes? and does this break every Devuan UEFI out there? | 04:47 |
nemo | rrq: sounds like it is something brand new and completely unrelated to my HD woes, just bad timing for me that I have 2 issues at once ☺ | 04:48 |
nemo | https://www.debian.org/security/2020-GRUB-UEFI-SecureBoot/ that is | 04:48 |
nemo | like they hardcoded the config path to prevent alternates | 04:48 |
nemo | ah. good. machine I'm typing on right now isn't even using UEFI so no concerns there | 04:49 |
nemo | couldn't remember at all what I'd setup | 04:49 |
rrq | yes; grub is clever enough to install under EFI/devuan, but it installs the debian binary which refers to EFI/debian ... all on a FAT file system so linking is not possible | 04:50 |
nemo | rrq: heh. I'd mentally ruled out linking for that reason | 04:50 |
nemo | gah | 04:50 |
nemo | so annoying | 04:50 |
nemo | rrq: so... this is kinda bad then. I'm not the only one hitting this. just the first to notice/complain | 04:51 |
nemo | thankfully that grub.cfg is crazy-generic, so I guess I probably don't need to run a cp every update at least | 04:51 |
rrq | yes, that grub.cfg looked very generic so wouldn't need to change .. | 04:52 |
nemo | welp... thanks for your help. time for me to fix every UEFI devuan I have | 04:53 |
nemo | good luck with a proper solution | 04:53 |
nemo | a grub shim to do the copy? ☺ | 04:53 |
rrq | felt like too much work to me :) learning how efi signing works | 04:54 |
nemo | rrq: hope you don't need like some cross-sign from microsoft ☹ | 04:55 |
rrq | I understood it to be two levels: first signing of the programs (always), and then an application level verification signing, the latter being the secure boot | 04:56 |
rrq | and that latter can be include time bomb as well | 04:57 |
rrq | I suppose we should work out a fix-it script to add to update-grub's post-processing scripts | 05:01 |
nemo | definitely sounds like fastest and easiest | 05:02 |
nemo | and fewer people trying fruitless rescue boots the better | 05:02 |
nemo | I mean, only sheer bullheadeness made me try manually typing in contents of configfile after attempting the configfile command | 05:03 |
DashiePie | hi nemo | 05:39 |
nemo | rrq: any news on "fixits" ? was going to extend my mitigation to warning coworker who also uses devuan | 17:03 |
fsmithred | nemo, did you try removing grub-efi-amd64-signed? Just keep the unsigned version. That alone will probably fix it. (It did for me in two cases) | 17:25 |
nemo | fsmithred: oh. I had not tried that yet. | 17:27 |
nemo | fsmithred: so this *is* related to the boothole mitigations? | 17:27 |
fsmithred | the what? | 17:27 |
nemo | 23:42 < nemo> rrq: is this related to the boothole vulnerability fixes? | 17:28 |
nemo | 23:48 < nemo> https://www.debian.org/security/2020-GRUB-UEFI-SecureBoot/ that is | 17:28 |
fsmithred | I'm talking about the new version of grub thta does not boot | 17:28 |
nemo | yes. I know | 17:28 |
nemo | I was curious as to why they had done this | 17:28 |
nemo | I'm trying your suggestion now | 17:28 |
fsmithred | I'm curious as to how it affect those who claim they are using grub-pc | 17:28 |
nemo | fsmithred: after removing that package still see: | 17:29 |
nemo | # strings grubx64.efi | grep debian | 17:29 |
nemo | /EFI/debian | 17:29 |
nemo | I'll see if that actually means anything after reboot though | 17:30 |
nemo | fsmithred: should I have done a grub update too? | 17:30 |
fsmithred | maybe | 17:30 |
fsmithred | or dpkg-reconfigure grub | 17:30 |
nemo | fsmithred: my non-UEFI machine does not seem to have any issues booting though | 17:30 |
fsmithred | same here with legacy bios. | 17:30 |
fsmithred | seems fine | 17:30 |
nemo | no change in that "strings" after dpkg-reconfigure grub-efi | 17:31 |
nemo | gonna try an update-grub | 17:31 |
fsmithred | maybe grub-install first | 17:31 |
nemo | fsmithred: that did it | 17:31 |
nemo | fsmithred: strings is now clean | 17:31 |
fsmithred | cool | 17:31 |
fsmithred | that won't work if you use secure boot | 17:32 |
nemo | fsmithred: ok. so I have a nicer mitigation than "manually copy something over" to recommend to people | 17:32 |
nemo | fsmithred: yeah, not doing that anyway | 17:32 |
nemo | fsmithred: this machine is inside my house, and if anyone breaks in to haxor it I have far far far bigger problems | 17:32 |
fsmithred | yeah, I understand | 17:32 |
fsmithred | I have a sword for such events | 17:33 |
nemo | hee | 17:33 |
nemo | fsmithred: I never did progress very far in iaido or in tameshigiri practice. | 17:33 |
nemo | just enough to probably not slice my own fingers off | 17:34 |
fsmithred | good start | 17:34 |
fsmithred | try three-section staff. There's no way to learn it without clobbering yourself. | 17:34 |
fsmithred | I sure hope we don't have to fork grub | 17:35 |
nemo | I've done a fair amount of naginata. and a few lessons of bojutsu 'cause my old kendo sensei did that class after kendo | 17:36 |
nemo | that's limit of my stick stuff | 17:36 |
nemo | fsmithred: I wonder what other debian derivatives are doing | 17:36 |
nemo | fsmithred: you guys might want to at least do a blog announcement on the 2 mitigations for people who want to get ahead of this | 17:37 |
fsmithred | we have a blog? | 17:37 |
nemo | ummm site announce page. dunno what you call that 😝 | 17:37 |
nemo | # strings grubx64.efi | grep debian | 17:38 |
nemo | /EFI/debian | 17:38 |
nemo | oups | 17:38 |
nemo | mkdir /boot/efi/EFI/debian;cp /boot/efi/EFI/devuan/grub.cfg /boot/efi/EFI/debian/ | apt remove grub-efi-amd64-signed;grub-install;update-grub | 17:38 |
nemo | https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/devuan-announce | 17:39 |
fsmithred | oh, I didn't even bother with the debian dir | 17:39 |
* fsmithred is still looking up japanese words | 17:39 | |
nemo | fsmithred: well. first one was recommended by rrq and would work with secure boot presumably | 17:39 |
nemo | 2nd one would be cleaner but would not | 17:39 |
nemo | and I guess a quick fix would be you guys hacking in a script modification to do the first one on every grub update | 17:40 |
nemo | https://dev1galaxy.org/viewforum.php?id=12 here too | 17:40 |
nemo | (places to warn people) | 17:40 |
nemo | APic: you're on every channel I'm on? | 17:47 |
APic | Could be | 17:48 |
nemo | 😝 | 17:48 |
APic | ☺ | 17:48 |
tuxd3v | does any one knows the package name for the ascii cam? | 18:17 |
tuxd3v | the One jaromil were working on :) | 18:18 |
tuxd3v | hasciicam | 18:19 |
tuxd3v | :) | 18:19 |
tuxd3v | does anyonhe managed to have it working? | 18:25 |
tuxd3v | I am getting: | 18:25 |
tuxd3v | https://paste.debian.net/1189503/ | 18:26 |
nemo | fsmithred: https://old.reddit.com/r/debian/comments/lkeogh/devuan_31_released_debian_fork_now_offers_runit/gnxzbq9/ | 18:31 |
nemo | fsmithred: is emorrp1 correct? he's insisting I shouldn't be bothering with devuan | 18:31 |
nemo | for me you guys were protecting me from random package breakages | 18:31 |
nemo | like tomcat | 18:31 |
fsmithred | who what? | 18:31 |
nemo | fellow in that reddit comment | 18:32 |
nemo | https://old.reddit.com/r/debian/comments/lkeogh/devuan_31_released_debian_fork_now_offers_runit/gnje12e/ | 18:32 |
* fsmithred stops reading about japanese female warriors | 18:32 | |
nemo | he's in #libregamenight telling me that Devuan offers "nothing new" that they have "given up on a fork" and all developers focus on "contributing to upstream Debian" | 18:32 |
nemo | and. I'm open to this possibility | 18:32 |
nemo | forks are tiresome | 18:32 |
nemo | I just don't want to get screwed on a key update | 18:32 |
fsmithred | wtf? We have not given up. | 18:32 |
fsmithred | We have pushed some changes upstream. | 18:33 |
nemo | fsmithred: well. lemme dump history of the chat | 18:33 |
fsmithred | We believe everyone will benefit if debian and devuan cooperate with each other | 18:33 |
nemo | I may be misinterpreting him | 18:33 |
nemo | my understanding was always that Devuan was focused on trying to stay close to upstream debian in terms of resources and maintainability | 18:33 |
fsmithred | our goal is to provide debian without systemd | 18:34 |
fsmithred | so yeah, we try not to change too much | 18:34 |
fsmithred | what does "nothing new" mean? | 18:35 |
nemo | https://m8y.org/tmp/emorrp1.txt | 18:36 |
nemo | fsmithred: I could simply be arguing from ignorance here | 18:36 |
nemo | but I'm open to using upstream debian as he pushes here and in his reddit posts. but at present it seems risky | 18:36 |
nemo | w/ chance of random strips that Devuan at least tries to protect me from | 18:37 |
nemo | but since he was speaking for Devuan devs, I figured I'd ask you whether he was blowing smoke, since he's not here. | 18:37 |
Tenkawa | imho. if an app/game needs to be infrastructure centric... there are bigger issues | 18:37 |
Tenkawa | infrastructure being systemd vs sysvinit | 18:37 |
Tenkawa | in this case | 18:38 |
nemo | there was no reason to delete the tomcat script | 18:38 |
nemo | of all the apps under debian, tomcat, as basically java VM, was the most-standalone | 18:38 |
nemo | server apps | 18:38 |
nemo | but apparently, doing so does not violate the debian vote according to him | 18:38 |
nemo | so what I don't see is... if a functioning script in a major package can be deleted for no reason, with no repercussions, and get pushed to stable. | 18:39 |
nemo | then in what way does the vote mean anything | 18:39 |
nemo | and in what way can I count on Debian's sysv guarantees | 18:39 |
Tenkawa | nemo: which group are we talking that wants to "vote"? | 18:39 |
nemo | Tenkawa: the Debian vote on retaining support for sysv | 18:40 |
nemo | Tenkawa: the one heavily quoted by him in the chat above | 18:40 |
fsmithred | last Technical Committe vote | 18:40 |
Tenkawa | that's just the way they are moving | 18:40 |
fsmithred | the one with five choices to drop support for sysvinit and one or two to keep it | 18:40 |
Tenkawa | I disagree with it myself | 18:40 |
fsmithred | my numbers may be off | 18:40 |
nemo | Tenkawa: that's fine... what I'm trying to understand is emorrp1 seems to be simultaneously arguing that deleting sysv from packages is fine, and does not violate the vote | 18:40 |
nemo | and also simultaneously, that Debian is actively supporting sysv, and Devuan serves no purpose | 18:41 |
nemo | as a user, I'd be happier with a unified Debian. it's easier for me, no randomly breaking grub for example | 18:41 |
fsmithred | anyway, as I understand it, you can now have debian without systemd and without devuan, because of elogind, which debian got from us. | 18:41 |
nemo | but... I don't see how I could trust it not to screw me tomorrow | 18:41 |
Tenkawa | it serves no purpose "to them" | 18:41 |
nemo | fsmithred: yeah, that's nice of them, (and of you) but if they have no guarantess of not pushing breakage to stable... | 18:41 |
fsmithred | nemo, we are not closing up shop yet. | 18:41 |
nemo | good! | 18:42 |
nemo | 'cause I would be very nervous every time I ran apt update on debian | 18:42 |
fsmithred | they need us | 18:42 |
fsmithred | to be a thorn in their side | 18:42 |
nemo | Are his comments largely correct though? in the 2 reddit posts linked? (top comments, short to read) | 18:42 |
nemo | fsmithred: 😃 | 18:42 |
fsmithred | I did not read all his comments | 18:42 |
Tenkawa | nemo: let me read it for a sec | 18:43 |
Tenkawa | I havent read it yet | 18:43 |
fsmithred | but he does not speak for any devuan devs that I know | 18:43 |
fsmithred | and I think I know them all | 18:43 |
nemo | Tenkawa: skimming the discussion in #libregamenight would be appreciated too | 18:43 |
nemo | Tenkawa: I realise it is a frivolous game channel. but this all shocked me. and he sounds like a debian-ite | 18:43 |
nemo | https://old.reddit.com/r/debian/comments/lkeogh/devuan_31_released_debian_fork_now_offers_runit/gnxzbq9/ https://old.reddit.com/r/debian/comments/lkeogh/devuan_31_released_debian_fork_now_offers_runit/gnje12e/ https://m8y.org/tmp/emorrp1.txt | 18:43 |
nemo | the 3 links rejoined | 18:43 |
Tenkawa | you are talking about emorrp1 right? | 18:44 |
Tenkawa | his opinions? | 18:45 |
fsmithred | 13:08 < emorrp1> what do you mean? Devuan is basically defunct, the work is being done inside debian proper these days | 18:45 |
Tenkawa | yeah | 18:45 |
Tenkawa | he's just ranting | 18:45 |
fsmithred | ^^^ absolutley false statement I just posted | 18:46 |
nemo | yes. that kind of thing. I was shocked, but also trying to be open to the possibility that I should investigate using Debian directly | 18:46 |
nemo | I just didn't trust them | 18:46 |
fsmithred | I wish we did not have to keep forking packages | 18:46 |
fsmithred | I wish we really did not have to exist, but in fact we do. | 18:46 |
fsmithred | anyway, this is not a support discussion | 18:47 |
Tenkawa | nod | 18:47 |
nemo | fsmithred: well. it was | 18:47 |
nemo | fsmithred: I was honestly wondering if Debian was safe to switch back to, and if his set of scripts for "making Debian work like Devuan" was an accurate reflection | 18:47 |
nemo | I was not trying to start an argument, just wondering if he was right, and it was similar/same | 18:48 |
fsmithred | um... | 18:48 |
DashiePie | hi nemo | 18:48 |
nemo | hi DashiePie | 18:48 |
nemo | fsmithred: if so, I was literally going to try switching one of my sets of apt sources back on a non-critical devuan to initiate process | 18:48 |
fsmithred | if he's not rebuilding packages to remove dependency on systemd, then I guess he has systemd installed, like mxlinux has | 18:48 |
nemo | fsmithred: ok. that sounds rather useless | 18:48 |
fsmithred | dpkg -l |grep devuan | 18:49 |
fsmithred | will give you an idea of what packages we forked | 18:49 |
Tenkawa | rather dangerous to try to go backwards too | 18:49 |
nemo | fsmithred: that is quite a lot. but his claim was it had all been reintegrated upstream ☺ | 18:50 |
nemo | that was the surprising bit to me. so I was like... huh... maybe I should re-examine the... 10 machines I currently have on devuan | 18:50 |
fsmithred | no it hasn't. We still have to fork packages. | 18:50 |
fsmithred | some debian packages now require systemd|elogind | 18:51 |
fsmithred | but not all | 18:52 |
nemo | s/10/11/ | 18:52 |
nemo | fsmithred: ok. good to know. IRC is a place of random smoke blowing, but he sounded savvy | 18:52 |
nemo | shall not worry about it | 18:52 |
fsmithred | similar discussion happened on the forum recently | 18:52 |
fsmithred | https://dev1galaxy.org/viewtopic.php?id=4145 | 18:53 |
nemo | fsmithred: ah. links to the reddit thread above. which was mostly him | 18:54 |
nemo | thanks. will read through | 18:54 |
tuxd3v | any one knows about a camera application that can do more than 640x480? | 19:13 |
tuxd3v | cheese limits me to 640x480 | 19:14 |
nemo | O_o | 19:14 |
nemo | seriously? | 19:14 |
Tenkawa | stop getting that fake stuff | 19:14 |
Tenkawa | lol | 19:14 |
tuxd3v | well the box advertize FullHD 1080P @30fps | 19:15 |
Tenkawa | but hmm... I wonder if you dont have rights to the right /dev/* | 19:15 |
tuxd3v | both are in the video group | 19:15 |
Tenkawa | tuxd3v: do you have the right access to /dev/video* | 19:15 |
Tenkawa | I know that can burn you | 19:15 |
tuxd3v | at least to /dev/video0 yes | 19:16 |
Tenkawa | well darn | 19:16 |
tuxd3v | but to video1 I really don't know | 19:16 |
tuxd3v | does you guys get bigger resolutions on cheese? | 19:18 |
tuxd3v | the max to choose of cheese for me is 640x480 puff | 19:24 |
tuxd3v | 2 years waiting for a webcam and shows up this s*t | 19:25 |
nemo | umm | 19:29 |
nemo | fine. hang on | 19:29 |
nemo | let me install cheese | 19:29 |
nemo | tbh hadn't really needed anything but firefox for video up until now | 19:29 |
fsmithred | tuxd3v, will vlc do what you want? | 19:42 |
tuxd3v | fsmithred, good idea :) | 19:42 |
tuxd3v | with cheese is to forget :( | 19:42 |
tuxd3v | this is the information I could get from it till now: https://paste.debian.net/1189519/ | 19:47 |
nemo | tuxd3v: I'm getting a LOT more than 640x480 in cheese | 19:54 |
nemo | one moment | 19:54 |
nemo | tuxd3v: 1280x720 | 19:55 |
tuxd3v | ho my god.. | 19:56 |
tuxd3v | so its a fault from my webcam..damm | 19:56 |
nemo | *shrug* | 19:56 |
nemo | or how it exposes itself and how cheese is parsing that | 19:56 |
nemo | or like webcam having low res vid and high res static or... | 19:56 |
nemo | dunno | 19:56 |
nemo | Bus 001 Device 006: ID 1b3f:1167 Generalplus Technology Inc. WEB CAM | 19:57 |
nemo | what I'm using | 19:57 |
nemo | just some cheapo knockoff thing. seems to work well... once or twice a month it screws up gamma and I have to unplug and replug USB | 19:57 |
nemo | but apart from that | 19:57 |
tuxd3v | wait... wait... smoke is on the horizon | 19:58 |
nemo | mic and vid seem fine | 19:58 |
tuxd3v | do you see now there a 1280*1080 ? https://paste.debian.net/1189520/ | 19:59 |
tuxd3v | lets test | 19:59 |
tuxd3v | :) | 19:59 |
nemo | oh look. the matricites are back | 20:00 |
DPA | Does anyone know what could cause apt-get upgrade and apt-get dist-upgrade to disagree like this: https://pastebin.com/HRryueHC | 20:04 |
buZz | tuxd3v: mplayer -vf screenshot tv:// | 20:04 |
buZz | ^ can do any resolution | 20:04 |
buZz | press S for a photo | 20:04 |
mason | DPA: Could you use bpaste.net or termbin.com or something that doesn't want quite so much javascript? | 20:05 |
DPA | https://bpa.st/DKTA | 20:06 |
mason | DPA: Interesting. I assume you've run update again once or twice to rule out a race condition on update...? | 20:07 |
DPA | Yes | 20:08 |
mason | DPA: Can you share apt info meson | grep Version | nc termbin.com 9999 ? | 20:09 |
mason | and what version is installed now? | 20:09 |
DPA | Version: 0.56.1-1~bpo10+1 | 20:09 |
mason | Oh... Backports. | 20:10 |
mason | DPA: Did you explicitly pull that from backports? Anyway, from there I'd see what uninstalling it would try to drag with it, and reinstall with newer stuff if you explicitly want it. | 20:11 |
DPA | Yes, I think I installed it when I needed a newer meson version to build mesa. I probably don't need the newer version anymore now though. | 20:12 |
mason | It'll tell you. | 20:14 |
DPA | Oh, now I see, it wanted a newer ninja-build version. Looks like new bpo meson would now need bpo ninja-build, and I had regular ninja-build installed. | 20:17 |
DPA | I now removed bpo meson and installed regular meson again for now. I could probably install from bpo again too, it should figure the deps out if I tell it to take stuff from backports, but I don't need it right now anyway. | 20:19 |
mason | You're better off using the smallest possible set from backports generally. | 20:20 |
DPA | I tend to need some quiet low level stuff from there. For example, qemu-user-static, I can't bootstrap chimaera or bullseye with the regular one. | 20:25 |
DPA | For chimaera, I even had to take debootstrap directly from chimaera because backports was too old. And mkfs.f2fs from f2fs-tools was missing some options I needed. | 20:25 |
DPA | There are probably some other things I don't remember right now too. | 20:25 |
DPA | Maybe I should just switch to chimaera, it runs well on some other systems I have. (But those aren't regular desktops) | 20:27 |
buZz | are they S/390 machines? | 20:29 |
DPA | No, two arm64 machines (a smartphone and a devkit), and some lxc containers on x86_64. | 20:30 |
buZz | ah, pretty regular stuff | 20:30 |
buZz | too bad | 20:30 |
buZz | i was hoping for something exotic | 20:31 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!