| ShorTie | blaaa, gpg: key 94532124541922FB: new key but contains no user ID - skipped | 00:41 |
|---|---|---|
| ShorTie | how do i add this ?? gpg -v --recv-keys 0x94532124541922FB | 00:42 |
| rrq | old key | 02:37 |
| rrq | try: gpg --keyserver keys.gnupg.net --search-keys BB23C00C61FC752C | 02:37 |
| rrq | or add to your system using: apt-get install devuan-keyring | 02:38 |
| ShorTie | Thankz | 02:50 |
| systemdlete | So, fsmithred: After hours of tinkering and learning s**t I never realized before, I figured out that renaming the S0 scripts in /etc/rc2.d did not change the ordering of the scripts. I had to add haveged to the depends list in the LSB of the dovecot script. Now everything works as expected; no hang anymore. But what about those S* and K* scripts -- do those still apply? I looked at the support scripts for init, but I am | 03:07 |
| systemdlete | still not clear on this. | 03:07 |
| systemdlete | Also, one must re-enable the service so that the /etc/init/.depend.* files get updated. Otherwise, the dependency/ordering does not change | 03:08 |
| fsmithred | systemdlete, you now know a lot more about it than I do | 03:10 |
| systemdlete | all of this is, of course, in addition to those changes I had to make to haveged to make THAT work | 03:10 |
| systemdlete | :P | 03:10 |
| systemdlete | that doesn't make me feel any better | 03:10 |
| fsmithred | what do you do to re-enable the service? | 03:11 |
| ullet | i thought the numbering of the scripts determined order :" | 03:11 |
| systemdlete | service <svcname> disable/enable | 03:11 |
| fsmithred | so did I | 03:11 |
| systemdlete | so did I | 03:11 |
| systemdlete | maybe they still do, if insserv is not installed | 03:12 |
| systemdlete | which is perfect, because that further confuses and obstructs | 03:12 |
| systemdlete | (in addition to none of this being very well doc'd) | 03:12 |
| systemdlete | s/obstructs/obscures/, sorry | 03:13 |
| rrq | "man insserv" is a reasnable start point | 03:17 |
| onefang | If I recall correctly, according to the LSB standard, init is supposed to order the startups based on the dependencies stated in the startup scripts. | 03:17 |
| systemdlete | rrq: If one knows to read it, yes. | 03:17 |
| onefang | I wrote an LSB compliant init many many years ago. lol | 03:18 |
| systemdlete | onefang: Yes, for LSB-based systems. But not necessarily for others like s6 and systemd and many others. | 03:18 |
| systemdlete | These scripts are expected to continue working for any distro | 03:18 |
| systemdlete | Or, at least, most users do | 03:19 |
| systemdlete | probably do | 03:19 |
| onefang | You where talking about LSB SYSV init scripts, so that's what I mentioned. I know the others work differently. | 03:21 |
| gnarface | last i checked they still worked for me here, override the LSB headers, but generate warnings | 03:21 |
| systemdlete | onefang: Sorry, just saying | 03:21 |
| systemdlete | that's all | 03:21 |
| systemdlete | hey, gnarface! Nice to see you poke your head in here | 03:23 |
| systemdlete | do you have insserv and startpar installed? That seems to make the difference | 03:23 |
| systemdlete | and are we talking ascii or beowulf (I'm currently looking at beowulf) | 03:23 |
| sauron- | me too | 03:24 |
| sauron- | reading the release notes | 03:24 |
| systemdlete | oh yes the release notes. Always forgetting those! | 03:24 |
| sauron- | https://files.devuan.org/devuan_beowulf/Release_notes.txt | 03:24 |
| systemdlete | I don't see anything related to the init system. Did I miss? | 03:27 |
| fsmithred | nope | 03:27 |
| fsmithred | there's nothing about init system in release notes. Maybe mention of openrc. | 03:27 |
| systemdlete | no, not that either | 03:28 |
| gnarface | systemdlete: uh, yes to insserv and startpar, but no to beowulf. actually only tested symlink overrides on ascii and ceres. also, i recall some package upgrade rewriting them all, so double check they're how you left them | 03:29 |
| rrq | I can't find a documentation path down from the functional level ("man init") down to administration level ("man update-rc.d") .. but debian seems keen on removing all man pages anyhow :( | 03:32 |
| rrq | I've got some installed eventually as I found thepackages they are "hidden" in | 03:34 |
| systemdlete | gnarface: You say you have insserv and startpar on your ascii install, but you are able to change ordering with the file names in /etc/rc?.d/* | 03:36 |
| systemdlete | I was unable to. I could ONLY do it by adding the dep explicitly in the LSB block of dovecot. | 03:37 |
| systemdlete | and then disabling and re-enabling the service. | 03:37 |
| systemdlete | Of course, I have not really tinkered much with the service deps on ascii, so maybe that works differently. If it does, we might add those to the release notes for beowulf. | 03:38 |
| gnarface | systemdlete: wait, did you say this was using sysvinit | 03:40 |
| gnarface | ? | 03:40 |
| systemdlete | Uh... I think so... ?? | 03:40 |
| systemdlete | as opposed to? | 03:40 |
| gnarface | i dunno openrc | 03:40 |
| gnarface | also, i think i only tested it for disabling scripts (changing the S to K) | 03:41 |
| systemdlete | sysv-rc | 03:41 |
| gnarface | upgrading openssh-server i think was the culprit for redrawing them all to match the LSB headers again | 03:42 |
| gnarface | other packages might do the same though | 03:42 |
| systemdlete | These scripts have to work for any init system. Otherwise, someone will crow when they can't automate startup and shutdown of their favorite daemons and services. Only fair enough I think. | 03:43 |
| systemdlete | fsmithred, others: Another problem is that some of the scripts don't issue messages upon startup and shutdown. I had to add my own (log_daemon_msg) so that I could debug these issues. | 03:46 |
| systemdlete | It would also be nice if these got logged to a file in /var/log | 03:47 |
| systemdlete | I mean, we have dmesg for the kernel. Seems like we could have something like that for any given init system, a general facility. | 03:47 |
| rrq | bootlogd ? | 03:50 |
| systemdlete | ah. ty | 03:51 |
| systemdlete | but that will only log messages from log_daemon_msg, right? | 03:51 |
| rrq | "Bootlogd works by redirecting the console output from the console device." | 03:53 |
| systemdlete | huh. So what happens to the console messages? Do they disappear? | 03:53 |
| rrq | copied | 03:53 |
| rrq | https://manpages.debian.org/jessie/bootlogd/bootlogd.8.en.html | 03:54 |
| systemdlete | to me, "redirected" and "copied" are not quite identical | 03:54 |
| systemdlete | (yeah, looking at that man page too) | 03:54 |
| systemdlete | their bad, not yours | 03:54 |
| rrq | wow I found "testing" has "readbootlog - show contents of the boot log, stripping away control characters" ... maybe it's on the verge of becoming a binary log file | 04:01 |
| systemdlete | I think that just refers to the tputs output (colors) | 04:03 |
| systemdlete | No, I am looking at /var/log/boot and it is a simple ascii file | 04:03 |
| rrq | ah, yes, those are important in a log file | 04:03 |
| systemdlete | agreed... but then the facility would have to be far smarter to log just the plain ascii chars | 04:04 |
| systemdlete | which it could do, but that would add more overhead and that would not work well for embedded linux apps like routers and stuff where they try hard to keep the footprint tiny | 04:04 |
| systemdlete | I think what I'd rather see is for the /lib/lsb functions to NOT insert that stuff in the output. plain monochrome output is sufficient for most things in the boot I think. Is there a reason color is really needed, other than to look cool? | 04:05 |
| systemdlete | but this is getting a little OT maybe | 04:06 |
| systemdlete | I hear you, rrq. I don't disagree really | 04:06 |
| systemdlete | and thanks for the tickler re bootlogd. I comletely forgot about that. | 04:07 |
| systemdlete | actually, an init logger could just print a message saying the name of the service and disposition, OK or Fail | 04:10 |
| systemdlete | if more info is needed, maybe a loglevel would be appropriate | 04:11 |
| systemdlete | fsmithred: The haveged bug is known by debian, so I guess no need for a bug report. But what about the dovecot dependency on haveged for doveconf? And if so, where should I log the bug? | 04:16 |
| fsmithred | that would be with debian, too. We don't touch dovecot. | 04:17 |
| systemdlete | ok, thanks | 04:17 |
| fsmithred | btw, live-config scripts do exactly the kind of reporting you want. | 04:17 |
| fsmithred | oh, it's not in the scripts themselves. | 04:19 |
| gnarface | i was gonna say, isn't that really up to the logging daemon? rsyslogd by default but that's not a strict requirement afaik | 04:20 |
| systemdlete | fsmithred: Unless we are talking about LSB, then it is. | 04:21 |
| systemdlete | (and how I fixed it here for beowulf) | 04:21 |
| systemdlete | Also, will debian care? It doesn't support or deter from systemd | 04:22 |
| fsmithred | they're allowed to support other init systems if they want to | 04:23 |
| fsmithred | ymmv | 04:23 |
| systemdlete | they? Debian packagers? | 04:23 |
| fsmithred | yeah | 04:23 |
| systemdlete | that's a great policy. | 04:23 |
| systemdlete | complete init freedom. | 04:23 |
| * systemdlete bangs head against hard surface | 04:24 | |
| systemdlete | this is why I thought, maybe it would be better to bring these problems to the direct attention of those projects | 04:24 |
| gnarface | systemdlete: right idea, wrong person's head | 04:25 |
| fsmithred | lol | 04:25 |
| systemdlete | volunteers? | 04:25 |
| fsmithred | debian has accepted patches from devuan, so there's always the possibility that you'll get a positive response | 04:26 |
| systemdlete | Am I submitting a patch? | 04:26 |
| fsmithred | telling them what you did to get it to work is almost as good | 04:26 |
| systemdlete | so, I give them the secret recipe. | 04:27 |
| systemdlete | "insert word at line x in file y" | 04:27 |
| systemdlete | OK, whatever. | 04:27 |
| fsmithred | and if they can do that without breaking anything, it might actually get done | 04:27 |
| systemdlete | So live-config is another boot system? | 04:28 |
| systemdlete | Or another layer on top of existing? | 04:28 |
| fsmithred | live-boot and live-config are used in live-CD | 04:28 |
| fsmithred | scripts to start the system | 04:29 |
| systemdlete | Isn't that the same thing? | 04:29 |
| systemdlete | I'm reading http://manpages.ubuntu.com/manpages/precise/man7/live-config.7.html | 04:29 |
| fsmithred | for a special purpose | 04:29 |
| systemdlete | ? | 04:29 |
| fsmithred | here's an example: http://distro.ibiblio.org/refracta/files/extra_packages/1159-openssh-entropy | 04:32 |
| fsmithred | I guess a layer on top is best description | 04:33 |
| systemdlete | so you still need sysvinit or openrc or the like? | 04:34 |
| systemdlete | that link will not open in my browser, btw | 04:35 |
| systemdlete | it's a text file | 04:37 |
| systemdlete | nvm | 04:37 |
| fsmithred | yes, you need a whole system | 04:40 |
| systemdlete | natch. | 04:41 |
| fsmithred | each one that runs creates a state file, and some other script lists the state files in a log file, so you can check to see what ran or not. | 04:43 |
| systemdlete | interesting. | 04:44 |
| systemdlete | It sounds a bit like what systemd was trying to do | 04:44 |
| systemdlete | a little bit | 04:44 |
| systemdlete | let me ask this: Could live-config someday replace the current boot scripts? I mean, as an alaternative to openrc sysvinit etc | 04:46 |
| systemdlete | It seems like another boot system to me, just providing more options (linux boot cmd line most notably) | 04:46 |
| fsmithred | no, the live config scripts will start the normal init scripts | 04:48 |
| systemdlete | oh | 04:48 |
| fsmithred | you can choose which ones run or not in the boot command | 04:48 |
| systemdlete | so, another layer | 04:48 |
| fsmithred | yeah | 04:48 |
| systemdlete | front-end, whatever | 04:48 |
| systemdlete | ok | 04:48 |
| systemdlete | :) | 04:48 |
| fsmithred | to set up the read-only system that gets unpacked from a squashfs | 04:49 |
| fsmithred | back in the old days, you could fit an entire operating system on one CD | 04:49 |
| systemdlete | On a couple floppies | 04:49 |
| fsmithred | yeah, I remember | 04:50 |
| systemdlete | yep | 04:50 |
| fsmithred | sleep time here. see you later | 04:51 |
| systemdlete | night, thanks for help | 04:51 |
| bleb | hey friends | 05:18 |
| bleb | is there a guide to enabling wpa_supplicant in devuan? | 05:18 |
| bleb | i have the default xfce install with wicd now but i want to switch | 05:18 |
| bleb | by the way where should i look for documentation of how to use sysvinit? | 05:30 |
| mason | bleb: I'm a fan of ifupdown, or nmcli if you want something that does more for you. | 05:31 |
| bleb | nmcli is network manager isn't it | 05:31 |
| mason | Yes. | 05:32 |
| bleb | and ifupdown is its own thing? | 05:32 |
| bleb | or does it use wpa_supplicant? | 05:32 |
| mason | Yes. It's the tradition Debian network management - /etc/network/interfaces | 05:32 |
| mason | Both use that. | 05:32 |
| bleb | how do i configure ifupdown? | 05:33 |
| bleb | first i will have to disable wicd obviously | 05:33 |
| mason | https://wiki.debian.org/NetworkConfiguration talks about it - example at the bottom | 05:33 |
| mason | There's also https://wiki.debian.org/WiFi/HowToUse | 05:34 |
| bleb | to disable wicd i guess i would do: mv /etc/rc3.d/S04wicd /etc/rc3.d/K04wicd && update-rc.d | 05:35 |
| bleb | at least thats what /etc/rc3.d/README seems to instruct | 05:35 |
| mason | update-rc.d is a better too to use - it'll handle the links for you | 05:35 |
| bleb | if i set things up with ifupdown, will i be able to configure wpa_supplicant with wpa_cli? | 05:37 |
| bleb | also, that debian page says to do sudo systemctl reenable wpa_supplicant.service | 05:38 |
| bleb | obviously there must be a devuan equivalent but i see no wpa_supplicant service in /etc/init.d | 05:38 |
| bleb | can't find any guidance on the googles | 05:43 |
| bleb | i'll have to come back to this tomorrow | 05:43 |
| bleb | night | 05:43 |
| mason | bleb: Ah, sorry, was AFKish. In general ifupdown smooths all of it over, so you just specify config in /etc/network/interfaces. You can also configure wpa_supplicant.conf manually, but it's not quite as sleek. | 06:00 |
| mason | bleb: I'll give you a complete example next time you ping me. | 06:01 |
| mason | Or maybe when I'm done with my current project. | 06:01 |
| bleb | mason: it "smooths it over" meaning you can't use wpa_cli? | 06:10 |
| bleb | normally when connecting to a new network (on void) i would use "scan_results", "add_network", "set_network", and "enable_network" | 06:11 |
| mason | bleb: Ah, you're there. I've never actually used wpa_cli. | 06:13 |
| bleb | then how do you scan and pick a network to connect to | 06:13 |
| mason | iwlist IIRC | 06:13 |
| mason | or iwconfig list? Not remembering. | 06:15 |
| mason | Firing up my laptop for the complete example. I assume I have ifupdown configured. If not I can swap it over easily enough to test what I believe to be the correct config - mostly just wpa-ssid and wpa-psk | 06:16 |
| mason | bleb: yar: https://bpaste.net/QKIA | 06:18 |
| mason | No explicit config of wpa_supplicant.conf needed. That said, if you like it you can just configure wpa_supplicant.conf and do things manually. | 06:19 |
| bleb | okay | 06:22 |
| bleb | but then to switch my network i need to be root and edit /etc/network/interfaces? | 06:23 |
| mason | bleb: No, you can have multiple networks defined using something akin to aliases. Let me find an example. | 06:23 |
| mason | bleb: Here: https://manpages.debian.org/jessie/ifupdown/interfaces.5.en.html | 06:24 |
| mason | mapping is what you want | 06:25 |
| mason | so, you say: ifup wlan0=home | 06:25 |
| mason | for example | 06:25 |
| bleb | is there any way to do it without root? | 06:32 |
| mason | Hm, maybe if your user is in the netdev group. | 06:32 |
| mason | Setting up new interfaces, you want to be root. Choosing and connecting, netdev ought to do it. | 06:33 |
| bleb | ok cool | 06:33 |
| bleb | thanks for the help | 06:33 |
| mason | Try it. I tend to just be root for these things, and I tend to hardwire wireless networks. | 06:33 |
| mason | too inconvenient typing =location | 06:34 |
| mason | And I tend to use NetworkManager (for nmcli and nmtui) on systems that'll see lots of different networks. | 06:34 |
| ullet | thank you so much, devuan creators. thankyou. so. much. | 10:53 |
| ullet | it is better to light a single candle than to curse the darkness | 10:54 |
| Joril | Well said! :D | 11:01 |
| ullet | hey Joril - i managed to convert ubuntu to devuan on one of my devices without rebooting. I should have taken notes on what i did. | 11:06 |
| ullet | Now i either have to do that again on a different device, or create a devuan image with kernel and dtd for the board | 11:07 |
| ullet | not sure with fork in the road to take | 11:07 |
| openbsdtai123 | hi, is there a mini usb pendrive with just Grub2 for rescue ? | 12:28 |
| djph | openbsdtai123: not that I'm aware. I think ... oh, what was it called ... superrescuecd was pretty close to that though | 12:28 |
| openbsdtai123 | I installed using debootstrap with live. but now I have no longer my usb boot grub scnadisk pendrive :* | 12:29 |
| djph | oops :( | 12:30 |
| openbsdtai123 | I guess lilo + slackware on sda2 will save me :) I have still my rescue usbpend of slackware. I did put vmlinuz/initrd.img on /boot of sda2, then I run frrom slackware lilo with proper lilo.conf and it just runs. Now debian is up, lilo is really best. old stuffs are good. | 12:36 |
| openbsdtai123 | lilo works very well. Quite better management of mbr actually. | 12:39 |
| openbsdtai123 | lilo needs no perl into your deb package. would be nice that lilo package of debian is fixed. | 12:40 |
| MinceR | openbsdtai123: there's Super Grub2 Disk | 12:44 |
| openbsdtai123 | thank you very much | 12:48 |
| openbsdtai123 | so far, I put lilo with slackware, if I have time I will make a boot grub and a boot grub lilo disks. | 12:49 |
| openbsdtai123 | sda1 openbsd, sda2 slackware lilo, sda3 devuan i386, all is up and running! issue solved. | 12:49 |
| abcab | does lilo still work? | 12:52 |
| openbsdtai123 | lilo is likely the best. there is too elilo. like syslinux works fine. | 12:53 |
| abcab | take a look at fsmithred's refracta2usb | 12:55 |
| ham5urg | I have edited https://git.devuan.org/gregolsen/lxc-devuan/tree/master/ to support beowulf in LXC. Should I send it to the LXC-guys? | 12:59 |
| xinomilo | so debian deprecated clipit, and made it depend on diodon, which also brings zeitgeist (daemon) in, as another dependency.. mess. | 13:28 |
| xinomilo | ceres users will see a message on upgrade | 13:29 |
| xinomilo | btw, diodon doesn't work at all here. | 13:34 |
| fsmithred | openbsdtai123, there's a live-usb image with grub and all four devuan-live isos here: https://get.refracta.org/files/dev1usb/ | 13:49 |
| openbsdtai123 | would it be possible to have the classic vi + less in the base system? this is more important to have fundaments on Unix, kept as long as possible. | 17:03 |
| nemo | openbsdtai123: huh. don't you get that if you add console tools? | 17:05 |
| nemo | openbsdtai123: seems like it would make more sense to check console tools by default in the installer. | 17:05 |
| openbsdtai123 | there arent in the live desktop i386 live ascii, maybe vi and less will be back in beowulf live? | 17:10 |
| nemo | ah... totally unfamiliar with the live desktop | 17:22 |
| nemo | openbsdtai123: maybe fsmithred here knows more, he's the one who always helped me with the ISOs | 17:23 |
| fsmithred | checking... | 17:23 |
| fsmithred | less should be there | 17:24 |
| fsmithred | vim-tiny gets installed by default, I think | 17:24 |
| openbsdtai123 | I am sorry, but I like vi and less. I use mostly command line. :( | 17:29 |
| fsmithred | I can't believe that less isn't there | 17:29 |
| fsmithred | i386 ascii 2.1 desktop-live? | 17:29 |
| openbsdtai123 | yeahp | 17:30 |
| fsmithred | booting now to check | 17:30 |
| fsmithred | less works | 17:30 |
| openbsdtai123 | I will have to check too... | 17:31 |
| openbsdtai123 | here my file: bf3e1b44461f0610ce4d83a70449bad3 devuan_ascii_2.1_i386_desktop-live.iso | 17:31 |
| fsmithred | check sha256sum on the iso to make sure it downloaded correctly | 17:31 |
| abcab | heh ends in bad3 | 17:31 |
| fsmithred | and it doesn't look familiar | 17:32 |
| fsmithred | I will consider adding vim. I like it better, too. It does add a few MB to the iso, but that might not matter now. Nothing fits on CD anymore. | 17:34 |
| fsmithred | well, minimal-live does. | 17:34 |
| openbsdtai123 | ahh ok, less is desktop live, in ubuntu desktop not, less is not in default debootstrap method. | 17:43 |
| openbsdtai123 | vi : vi is nowhere. it is teh compiled tiny and default vim. vi (original is very small and it would have its place). | 17:44 |
| fsmithred | no, less comes with standard system utilities, which are not required | 17:45 |
| openbsdtai123 | less is in all bsd by default. | 17:45 |
| fsmithred | linux still uses more | 17:46 |
| fsmithred | and maybe w3m | 17:46 |
| fsmithred | probably not in the installer, though | 17:46 |
| openbsdtai123 | I remember "more" in DOS. Did the real Unix have "less" e.g. v5,6,7 ? | 17:46 |
| fsmithred | I have no idea. | 17:47 |
| ullet | it had 'more' | 17:51 |
| onefang | Oh, toybox doesn't have a Debian package, though busybox does, and often ends up installed by default. | 17:53 |
| onefang | Sorry, wrong channel. lol | 17:54 |
| trouble_upd | hello all | 18:15 |
| golinux | Just ask | 18:16 |
| trouble_upd | lol ok | 18:16 |
| trouble_upd | I tried updating ascii to beo .. followed the guide on https://beta.devuan.org/os/documentation/dev1fanboy/en/upgrade-to-beowulf all worked fine except courier-pop-ssl | 18:17 |
| trouble_upd | if I start it I get an error ./courier-pop-ssl: 23: .: Can't open /usr/lib/courier/init-d-script-courier | 18:18 |
| trouble_upd | neither the script nor the directory exists | 18:18 |
| trouble_upd | any chance that i can downgrade my beowulf courier packages to the ascii ones ? | 18:38 |
| gnarface | probably, but i wouldn't recommend it | 18:40 |
| gnarface | maybe try just robbing that missing file from the ascii package | 18:40 |
| gnarface | or see if it is provided by other packages | 18:42 |
| gnarface | here it looks like it is part of courier-base | 18:44 |
| gnarface | make sure you have that package and that it installed properly | 18:44 |
| gnarface | (apt-get --reinstall install courier-base) | 18:44 |
| trouble_upd | trying now | 18:44 |
| gnarface | any luck, trouble_upd? | 18:54 |
| trouble_upd | no neither start/stop nor status gives any output | 18:58 |
| gnarface | hmmm | 19:00 |
| trouble_upd | something else .. i try using dovecot now but run into wierd trouble again lol | 19:01 |
| trouble_upd | Unpacking dovecot-core (1:2.3.4.1-5+deb10u1) over (1:2.3.4.1-5+deb10u1) ... | 19:01 |
| trouble_upd | Setting up sa-compile (3.4.2-1+deb10u2) ... | 19:01 |
| trouble_upd | Running sa-compile (may take a long time) | 19:01 |
| trouble_upd | chmod: changing permissions of '/var/lib/spamassassin/compiled/5.024/3.004002/auto/Mail/SpamAssassin/CompiledRegexps/body_0/body_0.so': Operation not permitted | 19:01 |
| trouble_upd | chmod: changing permissions of '/var/lib/spamassassin/compiled/5.024/3.004002/Mail/SpamAssassin/CompiledRegexps/body_0.pm': Operation not permitted | 19:01 |
| gnarface | trouble_upd: this is starting to look like your system didn't fully complete the upgrade | 19:02 |
| gnarface | trouble_upd: before you upgraded it to beowulf, had you used any ascii-backports packages, or any other packages from outside of ascii itself? | 19:05 |
| gnarface | let's keep it in the channel, trouble_upd. nobody else can learn anything from us having a private conversation about this. | 19:10 |
| trouble_upd | sure | 19:10 |
| gnarface | this might just be because your key is too old > pop3-login: Error: Failed to initialize SSL server context: Can't load DH parameters: error:1408518A:SSL routines:ssl3_ctx_ctrl:dh key too small | 19:11 |
| trouble_upd | ok so the spamass error could be fixed by removing old files in /var/lib/spamass | 19:11 |
| gnarface | there is a way to make it generate fresh rules | 19:11 |
| gnarface | i'm assuming the format probably changed between releases | 19:11 |
| trouble_upd | says its too small .... | 19:11 |
| gnarface | yes, it says it's too small, but sometimes all they change is the minimum length | 19:12 |
| gnarface | just make a new one with the beowulf versions of the tools and it should work | 19:12 |
| gnarface | if not, you'll have to just take it at face value and manually create a longer one | 19:12 |
| gnarface | (but usually when they change the minimum, the tools get updated too) | 19:13 |
| trouble_upd | doveconf: Warning: please set ssl_dh=</etc/dovecot/dh.pem | 19:13 |
| trouble_upd | doveconf: Warning: You can generate it with: dd if=/var/lib/dovecot/ssl-parameters.dat bs=1 skip=88 | openssl dhparam -inform der > /etc/dovecot/dh.pem | 19:13 |
| trouble_upd | guess dd didnt change :) | 19:14 |
| gnarface | well, that's not how i would have generated a diffie-helfman key but do whatever their instructions say | 19:15 |
| trouble_upd | same msg about key to short in dovecot.log .. how would you create it | 19:16 |
| gnarface | would have stolen it from the openssl setup :-p | 19:17 |
| gnarface | er, openvpn i mean | 19:17 |
| gnarface | hmmm | 19:17 |
| gnarface | when it says the key is too short, is it just a warning though? | 19:17 |
| gnarface | does it still start anyway | 19:17 |
| gnarface | ? | 19:17 |
| trouble_upd | no an error ... error:1408518A:SSL routines:ssl3_ctx_ctrl:dh key too small | 19:17 |
| openbsdtai123 | ullet: this is actually why I prefer to compile most debian software from source, to be sure that the machine runs well. This is why debian and devuan need a package management from source like PKGSRC or similar. | 19:18 |
| trouble_upd | but it starts yes | 19:18 |
| gnarface | trouble_upd: how long is the key it creates? | 19:19 |
| gnarface | trouble_upd: heh, yea, pretty sure the minimum length is supposed to be 1024 for that one. | 19:22 |
| gnarface | max might be 2048? not sure | 19:22 |
| gnarface | the openvpn package comes with an example script | 19:23 |
| gnarface | generates a bunch of keys | 19:23 |
| Guest81544 | How can I install userpatches to the Linux kernel on Ascii without stepping on the package manager's toes? | 22:09 |
| gnarface | Guest81544: get the kernel source package, patch it, rebuild it using either the native tools inside it or the kernel-package tool set. after that it's just a question of following the package naming guidelines | 22:11 |
| Guest81544 | do i need to rebuild a new package every time Devuan releases a new kernel that way? | 22:13 |
| Guest81544 | I was hoping for a way to simply add-on the .patch file in addition to Devuan's patches when updates occur like with Portage's /etc/patches/ directory | 22:13 |
| gnarface | no, the kernels aren't rebuilt on the fly. only binaries are installed. if you want to automate that you have to rig it up yourself. if this is an important patch maybe submit it to upstream and they'll include it in their build automation though | 22:14 |
| gnarface | this is different from BSD where patches are distributed as patches | 22:15 |
| gnarface | everything is a pre-built binary package that is built before being put into the repo | 22:15 |
| gnarface | but... there are source packages in the repo too for everything, so actually automating this yourself wouldn't be a huge feat of shell scripting | 22:15 |
| gnarface | oh, but if you name your kernel package correctly, it will neither block new kernels from being installed nor be removed by them | 22:17 |
| gnarface | so that's probably what you want to focus on first | 22:17 |
| gnarface | just making some clean packages that aren't in anything's way | 22:18 |
| gnarface | you'll most likely want to build actually two packages, a linux-image-[arch] package and a linux-headers-[arch] package | 22:18 |
| gnarface | i'm certain debian has some documentation in various states of disrepair | 22:19 |
| gnarface | lemme see what i can find | 22:19 |
| gnarface | gah, everything is too old | 22:20 |
| gnarface | also alot of their stuff focuses on packaging a vanilla kernel for debian, which i'm assuming is actually NOT what you want, right? i'm assuming you want to just add a patch to the existing patches on a distro native kernel, right? | 22:21 |
| gnarface | Guest81544: ^ | 22:22 |
| Guest81544 | gnarface, no, I want the Devuan kernel, I just watch to apply MuQSS patches to it | 22:23 |
| Guest81544 | *want | 22:23 |
| Guest81544 | or correct rather | 22:24 |
| gnarface | Guest81544: yea that shouldn't be too hard on it's own. asking for seamless automation might be a tall order, but just adding a patch and rebuilding is only hard the first time | 22:25 |
| Guest81544 | I guess | 22:25 |
| Guest81544 | I'd probably have to make my own online repo and add it to existing machines if I wanted to manage this across lots of devuans | 22:26 |
| gnarface | uh... well, yea but if you're managing lots of machines you're inevitably gonna need a private repo for a few custom packages, not just this one | 22:27 |
| gnarface | like i said, if it's something important it might be worth trying to get the patch accepted upstream (at Debian, i mean. Devuan just uses all Debian kernels for x86) | 22:28 |
| gnarface | i mean, you don't really want all your public-facing production servers rocking a compiler so they can all re-build the same kernel in parallel every time it's trivially updated, right? | 22:31 |
| gnarface | that's just a waste of electricity | 22:31 |
| gnarface | Guest81544: do you want me to help you walk through the build process? | 22:34 |
| Guest81544 | just linking me to some documentation on the matter would be better | 22:37 |
| gnarface | well, i thought so but there's a problem with that | 22:37 |
| gnarface | https://www.debian.org/doc/manuals/maint-guide/ | 22:37 |
| gnarface | because here's the documentation | 22:37 |
| gnarface | and now that i'm looking at it, i realize it's missing important steps for a kernel build | 22:37 |
| ullet | has anyone made a devuan image for the Khadas VIM3? :) | 22:38 |
| gnarface | ... and the stuff that does specifically mention the kernel build is hopelessly out of date | 22:38 |
| gnarface | so i realize i've pulled divergent info together to make it work for me, and it really might be easier if i just walk you through it | 22:38 |
| gnarface | but suit yourself | 22:38 |
| ullet | they should make it a wiki maybe | 22:39 |
| gnarface | the best advice i can give you is that while the built-in build scripts are helpful when they work right, make-kpkg is, despite many sources to the contrary, NOT deprecated, and Debian has no say in that | 22:39 |
| gnarface | so i would say, follow the NMG for patching but use make-kpkg for building still | 22:40 |
| gnarface | i can't find a single piece of documentation that melds those two halves of the approach together | 22:40 |
| gnarface | (where i ran into the problem that needed make-kpkg still was in adding the linux-vservers patch to the kernel, at which point i discovered that the built-in build scripts didn't fully support the entire range of valid Debian kernel package names, and were therefore allergic to the patches, but make-kpkg still came through for me) | 22:44 |
| gnarface | (that was a couple releases ago now though so YMMV) | 22:44 |
| ullet | /4 | 22:45 |
| Guest81544 | ok | 23:12 |
| Guest81544 | gnarface, I'll accept your offer to guide | 23:12 |
| Guest81544 | but I also want to ask, has anyone ported a gtk2 version of thunar yet to beowulf? | 23:12 |
| Guest81544 | the gtk3 version is very difficult to use and the searing white is hurting my eyes | 23:13 |
| Guest81544 | it's also slower | 23:13 |
| gnarface | Guest81544: you're using amd64, right? | 23:13 |
| ullet | i have dark thunar | 23:14 |
| ullet | 1.8.9 | 23:14 |
| gnarface | Guest81544: if so, and assuming your sources.list is correct, start with "apt-get update && apt-get build-essential && apt-get build-dep linux-image-amd64" | 23:15 |
| Guest81544 | yes amd64 | 23:15 |
| gnarface | Guest81544: lemme know when you've made it that far | 23:15 |
| gnarface | Guest81544: that middle command might actually be "apt-get install build-essential" but it should be obvious | 23:18 |
| gnarface | Guest81544: yea, sorry that's actually "apt-get install build-essential" | 23:18 |
| gnarface | there will probably be a lot of packages if you haven't done this before | 23:18 |
| gnarface | and you'll need all this stuff regardless of whose build instructions you follow next | 23:19 |
| Guest81544 | ok | 23:22 |
| gnarface | after that it should be "apt-get source linux-image-amd64" but you might have to name a specific kernel package instead like linux-image-5.6.0-1-amd64 | 23:25 |
| gnarface | from there it should unpack the kernel in a subdirectory and apply a bunch of patches | 23:25 |
| gnarface | after that, *only* follow the dquilt patch application stuff from this page, ignoring all the stuff about updating the source from an upstream tarball: https://www.debian.org/doc/manuals/maint-guide/update.en.html | 23:27 |
| gnarface | then let me know when you've got that far | 23:28 |
| gnarface | at that point you should have your own patch added to the stack of existing packages | 23:28 |
| gnarface | and you should be ready to build it, and multiple approaches MAY work, (including the ones on that page) but as i've mentioned before, i've had best luck with make-kpkg, not documented here | 23:29 |
| gnarface | (*own patch added to the stack of existing patches i meant to type, sorry for any confusion) | 23:30 |
| gnarface | Guest81544: lemme know when you're there or if you have any questions on the way. i'm assuming you're still downloading compiler stuff... | 23:45 |
| Guest81544 | gnarface, it's downloaded linux-latest-105+deb10u3 | 23:46 |
| Guest81544 | I thought linux 4.19 was beowulf | 23:46 |
| Guest81544 | not linux 5 | 23:46 |
| Guest81544 | oh nvm | 23:46 |
| Guest81544 | it's right | 23:46 |
| Guest81544 | gnarface, please hold on a second. I'm not familiar with dquilt. I thought this was just going to be as simple as patch 0001-muqss.patch | 23:48 |
| gnarface | Guest81544: yea, unfortunately you gotta add the patch in with the others with dquilt and use dch to add a changelog entry to correspond to it | 23:54 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!