| rrq | CALL FOR TESTERS: if you run startx as non-root, using daedalus and ceres, you are invited to test the devuan/experimental build and send feedback to LeePen or rrq .. it's a version that is happy about VT switching (supported by either seatd or elogind), but we want more confirming tests. | 00:17 |
|---|---|---|
| rwp | rrq, What specific package list needs to be installed from experimental in order to participate in this testing? | 00:22 |
| rrq | xserver-xorg-core and (dependecncy) xserver-xorg-common | 00:30 |
| rrq | with seource.list line added, it'd be: apt-get install -t experimental xserver-xorg-core | 00:31 |
| rrq | the sources.list line is: deb http://deb.devuan.org/devuan experimental main | 00:31 |
| rrq | with source.list line added, it'd be: apt-get install --no-install-recommends -t experimental xserver-xorg-core | 00:33 |
| rrq | (I forgot about recommends; may apt setup avoids them by default) | 00:34 |
| rrq | and oops, remember "apt-get update" after changing soruces.list | 00:36 |
| rwp | Awesome! I'll queue it up for trying out. I start X by logging into the vt console then running xinit, since I have my own .xinitrc file. | 01:06 |
| rrq | thanks. yes as its a central piece in a system, it's very good to get it confirmed in many settings before adding it into the release | 01:40 |
| FatPhil | woh - I've lost my virtual terminals, my monitor gets no signal at all. X seems to be fine though. | 10:41 |
| FatPhil | not strictly true - my X on vt12 is working fine, my X on vt7 is also blank - theoretically it should be showing an xdm login prompt presently | 10:43 |
| DelTomix | Devuan? | 10:43 |
| DelTomix | I mean Daedalus sorry | 10:44 |
| FatPhil | beowulf | 10:44 |
| DelTomix | is it the VT switching bug? | 10:44 |
| FatPhil | I've not encountered that before | 10:46 |
| DelTomix | I wouldn't expect it to be relevant to Beowulf but maybe - depending on if you are tracking backports for kernel | 10:47 |
| DelTomix | probably something else | 10:50 |
| sfox | what is a daedalus? | 10:51 |
| DelTomix | Daedalus is the name of the current release | 10:52 |
| DelTomix | (the current release of Devuan that is) | 10:53 |
| DelTomix | sfox: https://www.devuan.org/os/releases | 10:55 |
| FatPhil | I do have beowulf-backports, but I have not installed any updates for many months, nor rebooted | 10:56 |
| sfox | at least were not naming them after toy story characters https://vid.puffyan.us/watch?v=kjKuMCJqdW4 | 10:59 |
| DelTomix | can you relate the problem's occurrence to a recent change? | 11:00 |
| sfox | Not sure if it's realated but I get framebuffer init error messages in dmesg with the new release, but the framebuffer still works | 11:02 |
| FatPhil | I've not used vts for many months. the only oddness that happened was that my firefox got stuck in an uninterruptible sleep - maybe my chips are rotting? | 11:02 |
| sfox | there's definitely been changes to the kernel's framebuffer code | 11:04 |
| sfox | if you don't have ecc bitflips are a real thing that does happen. gpus don't have ecc | 11:04 |
| FatPhil | nothing recent in dmesg apart from CPU temperature messages | 11:04 |
| DelTomix | I doubt that if it was working before. could be lots of software related things. if you started having hardware issues they would likely begin showing up when its running hot - or maybe overclocking if you are doing any of that | 11:06 |
| DelTomix | cpu temperature messages? | 11:07 |
| FatPhil | "core" and "package" ones, yes. but they seem to go back to normal quickly. rather bizarre that that's the only stuff in the logs for days | 11:09 |
| DelTomix | you might have some information in xorg logs in your home directory, in ~/.local/share/xorg/ they might give a clue or maybe /var/log/xdm.log (I don't run xdm myself ) | 11:12 |
| FatPhil | what's most annoying is that in the killing of firefox, when I started it again it had forgotten all my tabs. at that point, I had well over 100, and relied on it not forgetting them | 11:12 |
| FatPhil | I can provoke a "pam_authenticate failure: Authentication failure" log to appear in xdm.log by pressing return twice in the blank vt7, so xdm is alive and asking for username and password | 11:19 |
| FatPhil | I guess I could try with real creds | 11:19 |
| FatPhil | woh - a dwm has appeared! (my window manager) | 11:19 |
| FatPhil | Aha - I've worked it out! | 11:21 |
| FatPhil | This is a small notebook, and the lid's closed - I was only looking at the second (big) monitor. Presumably everything was appearing just fine on the lappy screen itself. | 11:22 |
| FatPhil | this particular X session on vt12 has xrandr doing mirroring of the screens | 11:22 |
| DelTomix | ah I see! all is good then? | 11:24 |
| FatPhil | looks like it | 11:26 |
| FatPhil | is there a way of mirroring output from the console vts too? | 11:26 |
| DelTomix | not that I know of - I've never used randr for anything other than X monitors/modes | 11:27 |
| onefang | FatPhil: When in X I get my monitors showing separate stuff, when I switch to one of the VTs, they both mirror the VT. Don't think I did anything special. | 11:56 |
| FatPhil | onefang: it might be that your external monitor was present at boot time - mine wasn't | 11:58 |
| henrix | I've a question regarding running excalibur: is it correct to say there's no security repository for it? IIRC debian used not to have it for testing as well, but it seems to have now | 12:16 |
| * henrix couldn't find any mention to this, other than security not being mentioned here: https://www.devuan.org/os/packages | 12:18 | |
| onefang | Yep, both monitors are there during boot time. | 12:21 |
| onefang | This is not a laptop, so both are "external" monitors. | 12:21 |
| e54 | Hello all, stumbled upon devuan recently. Cool, didn't know it was a thing. A side from init is there anything that seperates it from debian? | 18:11 |
| rwp | Hello e54. By intention Devuan is Debian but Debian without systemd. Debian removed a freedom from the user to use the system without systemd. Devuan returns that freedom to the user. | 18:20 |
| rwp | Except for a list of packages in Devuan which required a fork to accomplish that goal all of the other packages are verbatim from Debian. | 18:21 |
| golinux | There is also a banned package list that is uninstallable | 18:33 |
| golinux | https://pkgmaster.devuan.org/bannedpackages.txt | 18:34 |
| e54 | rwp: Thanks. Got that. Saw the banned list. I was just wondering if any other undocumented differences | 19:05 |
| e54 | golinux: thanks | 19:05 |
| golinux | You can search for packages here: https://pkginfo.devuan.org/cgi-bin/policy-query.html | 19:07 |
| * golinux goes off to b'fast | 19:07 | |
| e54 | I have Openbsd and Devuan dual booting. Is there a benifit to using default init (using Runit at moment) | 19:08 |
| e54 | let me take back that question. I will research myself. That was kinda a personel preferance question. | 19:10 |
| bUst4gr0 | hey Lo | 22:40 |
| bUst4gr0 | is there an irc or something for gnuinos ? | 22:40 |
| bUst4gr0 | i wanted to ask for eventual cryptsetup and wiregaurd replacement as there aren't in the repos | 22:41 |
| bUst4gr0 | wireguard * | 22:41 |
| * gnarface doesn't know | 22:42 | |
| gnarface | bUst4gr0: it's not exactly on-topic here, but i think the maintainer does hang out here sometimes, so join #devuan-offtopic and stick around | 22:43 |
| rwp | I don't know either. And it is unfortunate that https://gnuinos.org/ does not say anything about it either. They should have more information there. | 22:43 |
| bUst4gr0 | ok, thks for your answers guyz | 22:48 |
| bUst4gr0 | have a nice time | 22:48 |
| TDRR | Hey. A couple things. How do I switch to tracking testing here? Exactly the same as in Debian? | 22:49 |
| gnarface | TDRR: yea, it's called "excalibur" here | 22:50 |
| TDRR | And I notice Debian and Devuan seem to consume 200MB more RAM than any other distro I've tried. Why is this? Any way I can track it here? | 22:50 |
| TDRR | gnarface: ah yeah that's exactly what I was looking to know. Thanks! | 22:50 |
| TDRR | Also I meant "any way I can track it down". | 22:51 |
| gnarface | TDRR: i assume it's because their stock kernel has drivers included for nearly everything | 22:51 |
| gnarface | and devuan x86 builds use the exact same debian kernel packages | 22:51 |
| TDRR | Ah makes sense. Can't do much about it beyond compiling my own kernel, right? | 22:51 |
| gnarface | not really, but the process is more tedious than complex | 22:51 |
| gnarface | hmm, well, you can try changing a value in the initrd config from MODULES=all or MODULES=most to MODULES=dep | 22:52 |
| gnarface | not sure it'll help much though | 22:52 |
| gnarface | best way is to just rebuild for only what you need | 22:52 |
| TDRR | What does `dep` do exactly? | 22:52 |
| gnarface | basically it tries to only create the initrd.img with drivers it detects your system needing | 22:53 |
| TDRR | And yeah I'll give it a shot. Was mostly asking just in case it was an easy fix, but I don't want to spend the time compiling my own kernel and then doing it every time I want to update it lol (mostly because my CPU isn't very good). | 22:53 |
| gnarface | so you'd change it to MODULES=dep in /etc/initramfs-tools/initramfs.conf then re-run "update-initramfs -u" | 22:54 |
| gnarface | but there's both a risk that it'll still include too many as well as be missing some, ymmv | 22:54 |
| TDRR | I imagine most of the time I should be able to still just boot to the terminal and revert it if anything goes wrong right? | 22:55 |
| gnarface | well, you might want to make sure you have a spare boot disk like some live image or even just the installer still just in case it goes really sideways | 22:55 |
| TDRR | Yeah I have a laptop I can set that up from so hopefully it should be fine. | 22:55 |
| TDRR | Thanks. | 22:56 |
| gnarface | if you have multiple kernels installed they'll all have their own initrd.img, so you can run update-initramfs on just one of them if you're paying attention, then if it doesn't work you can still in theory boot the old kernel.... | 22:56 |
| gnarface | ... i would have told him, if he hadn't ejected so fast | 22:56 |
| rwp | I don't think I would recompile my kernel for 200MB of savings. Not on any x86 or amd64 architecture system. And arm, riscv, others on small memory systems are already optimized further. | 22:59 |
| gnarface | i guess i haven't lately, but i might do it to change CONFIG_HZ and related settings, then disable a bunch of useless drivers while i was at it | 23:01 |
| rwp | Aren't most of those modules anyway? In which case they won't consume memory unless they are loaded and active. | 23:01 |
| TDRR | That worked *perfectly*! RAM usage is now exactly in line with Manjaro and such. | 23:03 |
| TDRR | Thank you so much. I had stopped using Devuan on my lower end netbook exactly due to this, but now I can go back and switch that to Devuan too. | 23:04 |
| gnarface | rwp: i think there's a boatload of stuff that's got ambiguous detection methods so it gets loaded "just in case" and i'm not sure but the entire initrd.img itself might carry an implicit footprint regardless of what's actually used in it | 23:05 |
| gnarface | (and i dunno, i've been told that unused ones should get out of the way for used ones when necessary, but i can also sympathize with just being offended at "free -mt" reporting massively more used ram than the previous release and just wanting it changed either way) | 23:07 |
| TDRR | I'm not sure if it mattered but Debian 12 did feel noticeably more sluggish on said netbook. | 23:08 |
| gnarface | TDRR: glad it worked for you. i assume the default just changed to increase hardware compatibility, since "dep" isn't always accurate enough to actually work, but i'm pretty sure if you install in expert mode it'll ask you during the install process | 23:08 |
| TDRR | Also I forgot, do I have to remove -updates and -security for Excalibur? | 23:09 |
| gnarface | TDRR: yes | 23:09 |
| gnarface | well, i dunno if "have to" is correct, but they won't be populated so they'll probably just throw errors | 23:09 |
| TDRR | Yeah I got reminded of that since they did throw errors. | 23:09 |
| TDRR | ``` | 23:10 |
| TDRR | Some packages could not be installed. This may mean that you have | 23:10 |
| TDRR | requested an impossible situation or if you are using the unstable | 23:10 |
| TDRR | distribution that some required packages have not yet been created | 23:10 |
| TDRR | or been moved out of Incoming. | 23:10 |
| TDRR | The following information may help to resolve the situation: | 23:10 |
| TDRR | The following packages have unmet dependencies: | 23:10 |
| TDRR | gnustep-base-runtime : Depends: gnustep-base-common (= 1.29.0-6) but 1.28.1+really1.28.0-5 is to be installed | 23:10 |
| TDRR | libgnustep-base1.29 : Depends: gnustep-base-common (= 1.29.0-6) but 1.28.1+really1.28.0-5 is to be installed | 23:10 |
| TDRR | ``` | 23:10 |
| TDRR | Hm? | 23:10 |
| gnarface | did you have stuff from 3rd party repos or different release versions? | 23:10 |
| gnarface | this is the type of error caused by repo/distro/version mixing | 23:11 |
| gnarface | hmm, or maybe it's just a dumb chosen version. maybe just force it | 23:12 |
| gnarface | yea, just force it | 23:12 |
| gnarface | your intent is to upgrade to excalibur, right? try "apt-get install gnustep-base-common=1.29.0-6" | 23:13 |
| gnarface | or maybe "apt-get --allow-downgrades install gnustep-base-common=1.29.0-6" | 23:13 |
| gnarface | (it's not actually a downgrade but the poor choice of calling the daedalus version 1.28.1+really1.28.0-5 makes apt's dumb string sorting algorithm think it's a later version than 1.29.0-6 | 23:14 |
| gnarface | ) | 23:14 |
| gnarface | such are the types of indignities one must suffer when updating to a fresh testing release | 23:16 |
| TDRR | Alright, thanks. | 23:21 |
| TDRR | I could also just switch to tracking the next release to avoid reinstalling, right? | 23:21 |
| gnarface | isn't that what you're trying to do right now? | 23:22 |
| gnarface | yes, it should work but sometimes one has to manage version conflicts manually | 23:22 |
| henrix | gnarface: re. running excalibur: isn't there an 'excalibur-security' repository, or security is only handled in stable (daedalus)? | 23:41 |
| henrix | (Sorry for targetting the question at you, but I've asked this earlier and got no answer...) | 23:41 |
| gnarface | henrix: yes, just like in debian, testing and unstable don't have "security" or "updates" | 23:42 |
| henrix | gnarface: ok, thanks for confirming that. (Although I *think* debian now has testing-security, but I may be wrong) | 23:42 |
| gnarface | henrix: i think they add -security and -updates to testing briefly before it becomes the new stable, but they're typically empty during that time | 23:43 |
| gnarface | rest assured though, most the stuff that ends up in -security and -updates on stable is stuff that was tested directly in testing and unstable first | 23:43 |
| henrix | ah, ok. That might be it then. Yeah, I was running debian testing for a few years anyway. and I'll probably upgrade daedalus soon too | 23:45 |
| gnarface | if debian has decided to include testing-security all the time it's a new change i hadn't heard of | 23:46 |
| henrix | well, I really don't know if they did that. I just remember seeing something about that in their wiki some time ago | 23:49 |
| * henrix goes search for that | 23:49 | |
| henrix | Ah, that was easy: https://wiki.debian.org/DebianTesting | 23:50 |
| henrix | anyway, I'm not running debian for a while now so I don't know if that works. But I'll probably upgrade to excalibur anyway ;-) | 23:50 |
| * henrix heads to bed now. Thanks gnarface | 23:52 | |
| gnarface | hmm, looks like according to that they are recommending you use "-security" on testing | 23:53 |
| gnarface | that's news to me, though it's not clear to me if that's relevant outside of near release times | 23:54 |
| gnarface | you'd have to test it and see what's there currently | 23:54 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!