| emanuel | https://mxtoolbox.com/SuperTool.aspx?action=blacklist%3amx1.emanuel-loos.eu&run=toolpage | 00:01 |
|---|---|---|
| rwp | The people who are needed to understand and deal with this are not online at the moment. Please have patience and stay connected and I am sure things will be understood and resolved when they do come online and look at the problem. | 00:15 |
| rrq | emanuel: did you add a web link and/or adescription? | 00:15 |
| emanuel | Great, thanks! I should mention, I tried registering again with the same usernames a few times, because it did not work. | 00:16 |
| emanuel | *with the same username and email ("EmanuelLoos", "mail@emanuel-loos.eu") | 00:17 |
| rrq | I've cleared your username + email for another try, but the spammer hammer has a number of words it doesn;t like | 00:17 |
| emanuel | Words? | 00:18 |
| rrq | the exact reason was emailed to bgstack15 who's (I guess) rejuvenating at the moment | 00:18 |
| rrq | yes.. spammers like to advertise in the descripton + url | 00:19 |
| emanuel | What would it check for words? You mean parts of the email address? It did send me a confirmation email. | 00:19 |
| rrq | if you paste yours somewhere I could have a look and maybe teach the spammer hammer something | 00:20 |
| rrq | your description | 00:20 |
| emanuel | which description do you mean? I was not asked for a description upon registering. | 00:22 |
| emanuel | I just filled out this form: https://git.devuan.org/user/sign_up | 00:22 |
| rrq | and you didn't set url and description later? | 00:23 |
| rrq | profile stuff | 00:23 |
| emanuel | The account got deleted after a few minutes. There was no time to do that. | 00:24 |
| emanuel | Should I try again and add a description within these few minutes? | 00:25 |
| rrq | no doesn;t need desription... something else; hmm maybe we need to wait for bgstack15 to check the spammer hammer report | 00:26 |
| emanuel | The link from the first confirmation mail was not used, because I opened it on my phone without knowing that it would ask me for my password again. | 00:28 |
| emanuel | After opening it on my phone it was unusable on the Devuan desktop: "Dein Bestätigungs-Code ist ungültig oder abgelaufen." (it was invalid) | 00:29 |
| rrq | ah. maybe that was enough to triggere the spammer hammer ... your login details are now cleared so maybe it works if you try again | 00:31 |
| emanuel | Great, I'll try, thanks! | 00:31 |
| emanuel | Last time I also forked a repository to create a pull request. Could that be the reason? | 00:34 |
| emanuel | This one: https://git.devuan.org/devuan/unattended-upgrades | 00:34 |
| rrq | no, would be due to the second registration while the first was unfinsihed | 00:35 |
| emanuel | Account got deleted again. | 00:35 |
| emanuel | I did not do anything with it this time, except search for "unattended-upgrades" and view the repository. | 00:36 |
| rrq | hmm.. yes I see now; the hammer doesn't like the "-" in your email domain ... give me a sec. | 00:37 |
| rrq | sorry about that. it should be better now, if you try yet again. | 00:38 |
| emanuel | Tried again, let#s wait and see. | 00:40 |
| emanuel | Why would a "-" in an email domain have something to do with spam? | 00:41 |
| rrq | in this case it was a bug; "-" is an allowed domain character; the particular spam rule verifies that the registration domain is acceptable | 00:44 |
| emanuel | I see. For now it seems to work, thanks. I was able to create the pull request again: https://git.devuan.org/devuan/unattended-upgrades/pulls/2 | 00:47 |
| emanuel | By the way, who reviews and merges these? | 00:48 |
| rrq | the package maintaner(s) .. mostly LeePen I think | 00:49 |
| fsmithred | emanuel, as I mentioned before, we no longer fork that package | 00:50 |
| fsmithred | so any merge request would need to be made to debian | 00:50 |
| emanuel | Oh, I see. But it is a Devuan-specific change. | 00:51 |
| rrq | hmm .. is unattended-upgrades still forked? | 00:51 |
| rrq | (sorry I'm slow) | 00:52 |
| fsmithred | not in chimaera or excalibur/ceres | 00:52 |
| fsmithred | probably not in daedalus too, but that's not enabled here. | 00:52 |
| rrq | right; not since "ascii" | 00:53 |
| fsmithred | that seems so long ago... | 00:53 |
| fsmithred | emanuel, what kind of change? | 00:54 |
| fsmithred | (I guess I could look at the diff you linked) | 00:54 |
| rrq | the fork was dropped since it was merely "branding" and not for "systemd avoidance" ... due to too few maintainers | 00:58 |
| fsmithred | I've never used unattended-upgrades | 00:59 |
| emanuel | changing "beowulf" to "daedalus" (being the current stable release) in the configuration file as it is a hassle to change it to the current release everytime you install it. | 00:59 |
| fsmithred | it doesn't use sources.list? | 00:59 |
| rrq | emanuel: you could step in as maintainer for it if you like | 01:00 |
| emanuel | There is a configuration file at /etc/apt/apt.conf.d/50unattended-upgrades defining which repos should be updated automatically. By default only scurity updates. | 01:01 |
| rrq | get in touch with LeePen on #devuan-dev for that | 01:01 |
| rrq | though he's in UK so probably asleep right now | 01:03 |
| emanuel | Is it still forked or does it come from debian? | 01:04 |
| emanuel | Because this repo seems to include Devuan support as well. | 01:05 |
| emanuel | https://github.com/mvo5/unattended-upgrades | 01:05 |
| rrq | the daedalus version is 2.9.1+nmu3 ... so it's not a forked package | 01:05 |
| fsmithred | github? | 01:06 |
| emanuel | Yes: https://qa.debian.org/cgi-bin/vcswatch?package=unattended-upgrades | 01:07 |
| emanuel | The Debian version uses: "${distro_codename}" That seems smart. Would that work for Devuan just like that as well? | 01:09 |
| rrq | the +nmu3 part indicates that the version is a non-maintaner update; apparently not really maintaned by debian (either) | 01:09 |
| rrq | hmm but there is a 2.11 in excalibur | 01:10 |
| emanuel | The package probably does not need to change much. And after being configured correctly it works just fine. Though it needs cron and doesn't install cron automatically when installed. | 01:13 |
| emanuel | * change much in newer releases | 01:14 |
| rrq | hmmm 2.11 has "Devuan Developers" as maintainer | 01:14 |
| rrq | with Vcs-Git: https://github.com/mvo5/unattended-upgrades.git | 01:16 |
| rrq | that's quite bad QA by debian | 01:16 |
| rrq | I don't think we want microsoft hosted source | 01:16 |
| rrq | Original-Maintainer: Michael Vogt <mvo@debian.org> | 01:17 |
| emanuel | I don#t think Debian source should be hosted my Microsof either. | 01:19 |
| emanuel | *don't *Microsoft | 01:20 |
| rrq | debian supposedly keeps source at https://salsa.debian.org/ | 01:20 |
| emanuel | That's where I searched first: https://salsa.debian.org/public?name=unattended-upgrades | 01:21 |
| rrq | but that non-maintainer update seems to have passed through the QA | 01:21 |
| emanuel | There's only a 4-year old mirror of https://github.com/rbalint/unattended-upgrades over there. | 01:21 |
| rrq | yes; and it's a rather significant package security-wise | 01:22 |
| emanuel | It is i nice package, though. And it still works well. | 01:22 |
| rrq | I wish we had someone stepping up to maintain a devuan fork | 01:22 |
| fsmithred | I downloaded and unpacked 2.11 - there's no changelog, the files are dated may 26 | 01:23 |
| fsmithred | control file says devuan developers | 01:24 |
| fsmithred | but there's no suites/unstable branch on git.devuan.org | 01:24 |
| rrq | yeah I guess Michael Vogt has picked up good stuff and focussed on the functionality more than formalia | 01:26 |
| rrq | usually one would give credit though | 01:27 |
| emanuel | I don't think I could maintain the C code: https://git.devuan.org/devuan/unattended-upgrades/src/branch/master/unattended-upgrade | 01:29 |
| fsmithred | another option is to make a package that does a dpkg-divert to replace the config file | 01:30 |
| fsmithred | but then you have to know to install that package | 01:30 |
| rrq | there's no C code in 2.11 .. a bit of py instead; and it seems to facitiltate various distros | 01:31 |
| rrq | but some systemd infection | 01:34 |
| emanuel | I'm not sure, I'm not that good at coding. On the other hand, if the package works fine after having no maintiner for so long, perhaps there's not much that needs to be changed in the code? | 01:35 |
| rrq | yeah I think it might need a bit of coding skill. don't feel pushed into it. | 01:42 |
| emanuel | Sorry, I was mistaken: It was python in the other versions as well. | 01:42 |
| emanuel | Will the package be kept, even thoug it has no maintainer? | 01:44 |
| rrq | maybe provide your patch as a a bug report to bugs.debian.org; the package does include a Devuan "module" so it should be acceptable. | 01:44 |
| rrq | but check out 2.11 first | 01:45 |
| emanuel | https://qa.debian.org/popcon.php?package=unattended-upgrades | 01:45 |
| emanuel | Where is 2.11? | 01:45 |
| emanuel | You mean on github? | 01:45 |
| emanuel | Or the old salsa mirror? | 01:45 |
| rrq | https://pkginfo.devuan.org/cgi-bin/package-query.html?c=package&q=unattended-upgrades=2.11 | 01:46 |
| rrq | you can download that package via the filename link | 01:47 |
| rrq | it's dependencies seem fine on daedalus | 01:47 |
| rrq | its | 01:48 |
| onefang | Since one of my TODO's for apt-panopticon is to do a deep dive into various bits apt source code, to see if there's anything tricksy they do I might need to test for ... I'm likely to see things I want to fix, ... but I just don't have time to take over unattended-upgrades, which I don't use. Then you mentioned Python, one of my least favourite languages. lol | 01:48 |
| emanuel | it says: // "o=Devuan,n=beowulf"; | 01:49 |
| * rrq biab | 01:49 | |
| emanuel | Why does no one use automatic (security-)updates? | 01:51 |
| emanuel | Even the installer asks the user if they should be activated. If the user answers yes, this package gets installed. | 01:52 |
| onefang | As an experienced sysadmin, my habit is to let others try updates first, and update things on my time. | 01:52 |
| emanuel | Even security updetes? | 01:52 |
| onefang | So what if the security update goes wrong just after I went to bed? | 01:53 |
| emanuel | That never happened to me. On the stable release, packages usually have been tested for a long time before being added to the package repos. | 01:55 |
| onefang | I'd rather test it on a non production system first, then decide when it's time to update servers and stuff. SErver might be too busy for an update to that part right now. | 01:55 |
| onefang | So, in short, I know what I'm doing and decide to do it manually, coz that's better for me. | 01:56 |
| onefang | For many others automated updates might be good. | 01:57 |
| emanuel | I guess the impact of an update going wrong also depends on what the server is doing. With a small private server, I could live with it not working over night. With a huge online service the priprities might be different. | 01:58 |
| onefang | Exactly. | 01:58 |
| onefang | So I set aside a certain time of the day for doing maintenance on my virtual world server, coz I know that's it's least busy period. Don't want to pull the virtual world out from anyone suddenly. | 02:01 |
| emanuel | I also might not ssh into it for a week (as long as it works).But it needs to stay secure, so I use unattended-upgrades. Thera are also many devuan LXC containers on there, which all need their own updates. | 02:01 |
| onefang | I use the Debian Security RSS feed to let me know when security updates are available, and have cron jobs emailing me about updates available. Though in my case, since I regularly check apt-panopticon, I'll tend to notice an update arriving by seeing all the mirrors updating to it eventually. | 02:10 |
| onefang | Ordinary users might just want to get their updates dealt with automatically though. Something they don't need to think about. | 02:12 |
| emanuel | By the way, If an unattended upgrade fails, the packages are just kept back: https://paste.debian.net/1334972/ | 02:13 |
| emanuel | login and psswd faailed and were kept back for me tu aupdate them manually with apt upgrade. | 02:14 |
| emanuel | just now | 02:15 |
| emanuel | I had no problem updating them manually. | 02:15 |
| emanuel | The package should have some kind of stronger depandancy on cron, though. It is easy to forget installing cron and wonder why unattended-upgrades are not working. | 02:19 |
| emanuel | The failed unattended upgrade was on testing, by the way. | 02:20 |
| emanuel | LookupError: unknown encoding: idna | 02:57 |
| emanuel | seems to be an error in unattended-uphrades, though- | 02:58 |
| emanuel | unattended-upgrades can be manually runt using: unattended-upgrade -d | 03:01 |
| emanuel | to get a debug log, that's what I did. | 03:02 |
| onefang | Gotta reboot after this upgrade, so BRB. | 13:27 |
| systemdlete | Hmm. Back in the old days, I could install "beep" and then I could call "beep" from a script, or the cmd line directly, and it worked. It beeped. Wow. Simple. | 22:40 |
| systemdlete | Nowadays, you have to create a udev rule, a user group, add users to the group, and probably login again to the console to get this working? | 22:41 |
| systemdlete | So I have to do handsprings and headstands to do what used to be... simple. | 22:41 |
| onefang | That'll be why I've been working on my aataaj.lua script, making it simpler. | 22:42 |
| systemdlete | I guess the issue is that the installer scripts for the beep package can't tell where a distro's udev rules directory is, at least from reading the PERMISSSIONS.md file on this. But wouldn't there be sort of a standard set of directories to look in, and if the installer still can't find it, say so and quit? | 22:43 |
| systemdlete | thanks onefang. | 22:43 |
| gnarface | worked for me on daedalus... | 22:43 |
| onefang | Though I haven't investigated beep yet. | 22:43 |
| gnarface | didn't have to do any udev rule tweaking | 22:43 |
| rrq | may need to load pcspkr | 22:44 |
| gnarface | not that i recall anyway | 22:44 |
| onefang | Beep is just an ALSA thing? | 22:44 |
| systemdlete | Look, I totally get that we need security. But this seems like the lamest of all things to me. Yes, distros vary but this sort of procedure is kind of normal I think | 22:44 |
| gnarface | pcspkr is loaded here | 22:44 |
| systemdlete | rrq: Could be, but then it should be part of the dependencies and install process. | 22:44 |
| systemdlete | (script) | 22:44 |
| rrq | that's for beeping with the PC speaker .. there's also an option to "beep" via sound card | 22:45 |
| systemdlete | pcspkr is loaded here too | 22:45 |
| rrq | I've forgotten the module name | 22:45 |
| systemdlete | is it still possible to send a ^G (bell) to the console? | 22:45 |
| systemdlete | or a vtty? | 22:46 |
| systemdlete | (use to work back in the day) | 22:46 |
| rrq | should work on console | 22:46 |
| rrq | not sure about terminal emulators | 22:47 |
| onefang | Beeping via PC speaker wont work here, there isn't one, though there is a socket to plug one in. Doing anything via the sound card is problematic on my desktop with 13 of them. Hence why I'm writing aataaj.lua to search for and attach everything properly. | 22:47 |
| systemdlete | egads | 22:48 |
| onefang | 4 on the motherboard, 6 on the graphics card, neither of which I bought for sound, that's what the 3 USB sound devices are for. | 22:48 |
| rrq | might be snd-pcsp | 22:49 |
| systemdlete | root is not allowed to beep for security reasons, per the same md file | 22:49 |
| systemdlete | but | 22:49 |
| rrq | has "index" parameter for selecting soundcard | 22:50 |
| onefang | After starting on this script, I'm finding out graphics cards tend to be like that, more audio devices than they should have. | 22:50 |
| systemdlete | needrestart beeps happily | 22:50 |
| systemdlete | (run as root!) | 22:50 |
| onefang | "index" usually means the ALSA index for that sound device, in your .asoundrc file index refers to the order in that file. | 22:50 |
| systemdlete | I guess needrestart is recognized for access to the output device somehow | 22:51 |
| systemdlete | I don't mind configuring beep, per the .md file instructions for a system, but having to do this on every system will be a pain | 22:53 |
| Xenguy | FWIW one of my laptops used to beep annoyingly often, and I was able to turn that off in the BIOS settings somewhere | 22:54 |
| Xenguy | PCs should be seen and not heard = ) | 22:54 |
| rwp | Humorously I always blacklist pcspkr and snd_pcsp in order to prevent any beeping from happening. | 22:56 |
| onefang | This is why I did track down which of my graphics cards 6 audio devices is actually connected to my only monitor with speakers. I route notification sounds to that monitor. xscreensaver turns that monitor off when it blanks. No notification sounds while I sleep. B-) | 22:56 |
| rrq | hmm snd-pcsp is a sound card for playback on the PC speaker; not a PC speaker emulation via sound card | 22:56 |
| onefang | Ah, maybe I should install that for my aataaj.lua testing? I don't usually coz of the lack of said speaker. Give my desktop 14 sound devices. lol | 22:58 |
| systemdlete | Is there a TLDR file for linux sound, as opposed to the 12-volume set we are ordinarily forced to read to use simple stuff these days? Just asking | 22:58 |
| onefang | Once aataaj.lua is more mature, my answer would be "install and run it, if you need more details, read it". | 22:59 |
| systemdlete | It's getting to the point where one almost needs a PhD to configure anything nowadays. | 22:59 |
| systemdlete | onefang, does it know how to safely escape, in case of an emergency landing? | 23:00 |
| * systemdlete has been watching too many episodes of Mayday | 23:00 | |
| Xenguy | In my experience, such as it is, sound has always been a bit of a shit-show in *nix | 23:00 |
| onefang | Too early in the morning for me to decipher that. lol | 23:00 |
| systemdlete | Xenguy, yup. | 23:00 |
| systemdlete | I think Xenguy just died and his brain spilled a core dump. | 23:01 |
| Xenguy | Having said that, I have never needed to modify the stock DE sound settings, which is to say that PA seems to work fine for my simple needs (knock on wood) | 23:01 |
| Xenguy | "Not dead yet" | 23:01 |
| onefang | Having spent far too much time trying to get my script to get ALSA to behave, I keep thinking "this is why people keep putting more and different layers on top" ALSA is sucky when you try to delve deeply. | 23:02 |
| systemdlete | phew! Good thing too, Xenguy I was getting worried | 23:02 |
| Xenguy | Never fear, underdog is here! But I digress | 23:03 |
| systemdlete | (one of my favorite cartoons) | 23:03 |
| n4dir | fun fact: until at least last year #ardour usually said to just use alsa | 23:04 |
| n4dir | i'd probably just stick to alsa if it wasn't for certain things i do | 23:04 |
| onefang | Then fsmithred asked me to help out with his "speak as early as possible in the boot process" request, which fit into what I was doing. So now I have two goals, tame ALSA and tame JACK. JACK is currently tamed, ALSA is stil putting up a fight, but I almost got it sorted. | 23:05 |
| systemdlete | doesn't JACK use ALSA eventually? | 23:06 |
| onefang | Note that in my case pulse and pipe are not even installed, that's how I "tame" them. B-) | 23:06 |
| systemdlete | I mean, depends on | 23:07 |
| onefang | Yes, as daoes everything else. | 23:07 |
| Xenguy | My goal with sound is: do nothing | 23:09 |
| systemdlete | onefang, I am willing to try out your script (when it's ready) on my test systems. I have hardware and VM hosts | 23:10 |
| Xenguy | If it ain't broke, and all that rot | 23:10 |
| systemdlete | I still believe, however, there needs to be a way to uninstall it if a user wants to | 23:10 |
| onefang | My goal with aataaj.lua is to help others do nothing. B-) | 23:10 |
| * systemdlete likes doing nothing | 23:10 | |
| systemdlete | <3 | 23:10 |
| n4dir | i kinda got used to jack, so i see no good reason to test pipewire | 23:11 |
| systemdlete | I don't know jack | 23:11 |
| systemdlete | :D | 23:11 |
| onefang | Well one of the things it's trying to tame is multiple sound devices, qemu doesn't allow that, I tried. Dunno about the other VM systems. | 23:11 |
| n4dir | systemdlete: i am pretty sure that if you don't do audio-production, it is pointless | 23:12 |
| n4dir | and even for that ... | 23:12 |
| onefang | All working and no playing sounds makes JACK a dull protocol. B-) | 23:12 |
| systemdlete | does JACK work with JILL? | 23:12 |
| n4dir | lost | 23:13 |
| systemdlete | nvm | 23:13 |
| onefang | JACK is basically the music production type layer on top of ALSA. Works great for that sort of thing. | 23:13 |
| systemdlete | joke fail | 23:13 |
| onefang | And since I also do music production... | 23:13 |
| rrq | what do you mean with "qemu doesn't allow that"? | 23:14 |
| rrq | doesn;t allow multiple emulated sound cards? | 23:14 |
| onefang | qemu doesn't allow more than a single sound device. It has a few you can use, but only one at a time. | 23:14 |
| rrq | hmm there may be a qemy version code involved, since it has config for both guest sound cards and host sound cards associations | 23:15 |
| onefang | Though with some work I might be able to hook up a bunch of USB devices, but I just wanted to start testing on real hardware. | 23:15 |
| rrq | "it" = qemu 7++ | 23:16 |
| onefang | In my case, whatever qemu is installed on Daedalus. | 23:16 |
| rrq | not that I have explored it much, but qemu takes device parameters and has guest vs host setups like all other devices | 23:17 |
| systemdlete | What is needrestart using to make beep? | 23:18 |
| systemdlete | it works, even inside VMs | 23:18 |
| onefang | I script my qemu, avoiding libvirt and friends. That's exactly what I did when testing under qemu. | 23:18 |
| n4dir | as i use qemu very seldom i just go for aqemu. | 23:19 |
| rrq | systemdlete: check with strace .. I'd guess on ioctls | 23:19 |
| onefang | During early development work, sometimes it's better to just give up on some problematic side issue that isn't your main concern, and do something else. I'll get back to VMs later, real hardware is more important. | 23:19 |
| systemdlete | I can live without beep. | 23:20 |
| n4dir | what you need it for, btw? | 23:20 |
| onefang | So struggling with trying to get qemu to let my test on multiple audio devices wasn't getting anywhere, but testing on real hardware with real multiple devices did get me further. | 23:21 |
| systemdlete | I wanted to have a script ring the bell | 23:21 |
| systemdlete | or beep | 23:21 |
| systemdlete | I guess I could run a short soundfile that makes beep sound | 23:21 |
| systemdlete | but that seems clumsy | 23:21 |
| n4dir | systemdlete: i had problems on the laptop, and the guy in offtopic told me as troubleshoot to run speaker-test (of which i never heard). | 23:21 |
| n4dir | no idea if that might be a workaround for you | 23:21 |
| systemdlete | I've tried that in the past. And actually, onlinemictest.com has a speaker test, and I get sound from that. | 23:22 |
| systemdlete | All I was looking for was a short, sweet little "beep" | 23:22 |
| systemdlete | or "boop" | 23:23 |
| systemdlete | and I can get sound from aplay | 23:23 |
| onefang | My console "beep" is a ping sound, other notifications have other sounds. | 23:23 |
| n4dir | speaker-test sounds just like white-noise | 23:23 |
| n4dir | there is interesting stuff, beep like, in /usr/share/sounds/freedesktop | 23:26 |
| n4dir | probably know that alreaday | 23:26 |
| systemdlete | do kernel packages (headers, image) take a loooooooong time in your qemu VMs? I find they take an eternity in my VMs (and my vbox is configured for KVM as the virtualizer). | 23:27 |
| onefang | Take a loooooong time to do what? | 23:27 |
| systemdlete | I've straced dpkg process and it is calling the rename() system call zillions of times | 23:28 |
| systemdlete | install, sorry | 23:28 |
| n4dir | didn't realize that | 23:28 |
| systemdlete | best way to play oga files n4dir? | 23:28 |
| systemdlete | aplay makes bad noise | 23:28 |
| onefang | I write my own mmdebstrap scripts for installing the OS on qemu. I don't time individual package installs. | 23:29 |
| n4dir | yeah, i wouldn't know. I played it with mocp for a quick test | 23:29 |
| onefang | I do note that one thing that does take up excessive time is the several times it creates the initramfs. No idea why it does that when I start installing desktop packages. lol | 23:30 |
| systemdlete | onefang, maybe for the DM? | 23:30 |
| onefang | Doesn't run out of initramfs. | 23:31 |
| systemdlete | and, yes, I found that too. I keep 3 most recent kernels and it can take a long time to run initramfs | 23:31 |
| systemdlete | ok, thanks all. bbl need to reboot some systems... | 23:34 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!