| mtnman | helo. is it worth filing a bug against a devuan irc client package that instructs to join #debian? | 01:39 |
|---|---|---|
| golinux | It would be worth it for you to fix the text and rebuild the package. ;) | 01:42 |
| Xenguy | mtnman: If you can't fix it yourself, you should file a bug report, yup | 01:47 |
| mtnman | thanks Xenguy. i suppose i could patch it. | 02:07 |
| Xenguy | Bug reporting is incredibly useful | 02:07 |
| mtnman | almost as useful as patching, i suppose.... | 02:07 |
| mtnman | and submitting it, that is. | 02:08 |
| golinux | Problem is that there are quite a few instances like that and a low priority in the scheme of things | 02:10 |
| golinux | No not as useful. Priority is so low, it may never get done | 02:10 |
| golinux | unless someone steps up who thinks it's important. | 02:11 |
| golinux | Doesn't hurt to report of course. | 02:11 |
| mtnman | this is obvioulsly a low priority bug. i did not want to waste anyone's time if it is deemed unimportant. | 02:17 |
| golinux | Doesn't hurt to have it there but requires someone to fork and maintain that pkg from release to release. | 02:18 |
| golinux | Like the printouts in cups referring the Debian. | 02:19 |
| golinux | Is it worth forking all of cups for that cosmetic correction? | 02:19 |
| mtnman | i haven't run cups on devuan, but that is certainly a similar situation. | 02:20 |
| mtnman | i suppose it could become an issue if people started showing up on #debian and asking questions about devuan. | 02:22 |
| Xenguy | hehe | 02:29 |
| Xenguy | I'm sure they would be amused by that | 02:29 |
| mtnman | i've seen plenty of people get abused for asking about unbuntu, etc... | 02:30 |
| Xenguy | But strictly speaking it's a question for #devuan | 02:30 |
| Xenguy | Well yeah, wrong channel, etc. | 02:30 |
| Xenguy | golinux: There's probably a way to solve the issue programmatically | 02:32 |
| Xenguy | But what priority, yes | 02:32 |
| mtnman | perhaps a special priority could be created for such cases. | 02:32 |
| Xenguy | notabug-wontfix | 02:33 |
| mtnman | heh | 02:34 |
| golinux | It's been discussed but again low priority. | 02:55 |
| golinux | Xenguy: Feel free to step up and create the program to do that. | 02:56 |
| Xenguy | golinux: Of course, that is the FOSS way | 02:57 |
| Xenguy | I do not disagree | 02:57 |
| Xenguy | It seems to me it might be a simple search and replace... but how that fits into a build system, I'm not sure at all | 02:58 |
| Xenguy | I'm not factoring in any copyright considerations either | 02:59 |
| onefang | If it's a default config change, then that's the sort of thing devuan-sanity is for. I think that's the name. | 06:49 |
| onefang | I just got home, and mtnman, who asked the question, is long gone. | 06:51 |
| golinux | Was devuan-sanity ever realized and implemented? I don't remember much ever happening with it beyond wishful thinking. | 07:37 |
| rrq | there is a devuan-sanity in experimental/main .. version 0.0.1 | 08:01 |
| KatolaZ | onefang: you here? | 09:45 |
| * _moep_ waves KatolaZ | 10:10 | |
| KatolaZ | hi _moep_ | 10:13 |
| KatolaZ | o/ | 10:13 |
| * onefang wakes from my nap and waves at KatolaZ. | 10:46 | |
| KatolaZ | hi onefang | 10:50 |
| KatolaZ | onefang: did you have any chance to have a look at the link issues on the package mirror? | 10:59 |
| onefang | I recall you mentioned you had sent me an email about it, but I don't recall getting that email. I was gonna search through my emails to see if I had just missed it later in the week. | 11:01 |
| onefang | I'm almost caught up on my life after the disruptions. lol | 11:02 |
| KatolaZ | onefang: dunno if I sent you an email | 11:02 |
| KatolaZ | the thing is that symlinks seem to not be working on the package mirror hosted at sledjahmr.org | 11:03 |
| onefang | Can you give me an example? | 11:03 |
| KatolaZ | onefang: just try to replace "ascii" with "stable" in any link | 11:03 |
| KatolaZ | hold on | 11:03 |
| KatolaZ | curl -L -f --header "Host: deb.devuan.org" http://37.220.36.58/merged/dists/stable-security/Release | 11:04 |
| KatolaZ | gives a forbidden | 11:04 |
| KatolaZ | while | 11:04 |
| KatolaZ | curl -L -f --header "Host: deb.devuan.org" http://37.220.36.58/merged/dists/ascii-security/Release | 11:04 |
| KatolaZ | works | 11:04 |
| KatolaZ | it's not vital, since Devuan prefers to use codenames, but this would avoid hassles to user who stick to stable/testing/unstable | 11:05 |
| onefang | Hmmm, I have "Options Indexes FollowSymLinks SymLinksIfOwnerMatch" and I recall my rsync cron job chowns everything. | 11:07 |
| KatolaZ | onefang: it does not work, as you can verify by yourself | 11:07 |
| KatolaZ | if you could please have a look that would be much appreciated | 11:07 |
| onefang | I'll look at it in about an hour. I got something to do at 19:30. | 11:07 |
| KatolaZ | np | 11:07 |
| KatolaZ | thanks ;) | 11:07 |
| Centurion_Dan | o/ | 11:26 |
| Centurion_Dan | so... anybody want to write a daemon supervision and watchdog tool using sd-notify data? | 11:27 |
| Centurion_Dan | notify data is provided via an AF_UNIX socket specified by the env variable $NOTIFY_SOCKET and it's format is as per http://man7.org/linux/man-pages/man3/sd_notify.3.html | 11:32 |
| Centurion_Dan | for the basic uses it seems simple enough. | 11:33 |
| Centurion_Dan | having a tool like this would allow devuan-baptise to provide supervised services with near equivalence to how systemd handles it. | 11:34 |
| detha | Centurion_Dan: I could think about that yes | 11:35 |
| Centurion_Dan | that would be awesome ;-) | 11:36 |
| detha | As you say, basically it re-implements systemd without the guff | 11:36 |
| detha | question is, how far does on go with that? Including restarting things when they crash? | 11:38 |
| detha | (note: that opens a whole other can of wurms, because 'Oh. xyzd crashed. Need to restart it. Ehm, what init system is this machine running?' | 11:39 |
| KatolaZ | but do we really need to re-implement systemd? | 11:39 |
| KatolaZ | :\ | 11:39 |
| kilobyte | please please make such restarts exclusively opt-in by the admin, never a package's default | 11:39 |
| KatolaZ | I mean, there are already several process supervision and management systems around | 11:40 |
| detha | Quite so | 11:40 |
| KatolaZ | I understand the usefulness of having a way of "transforming" unit files into initscripts | 11:40 |
| KatolaZ | that would be handy | 11:40 |
| kilobyte | but not having every single bit of systemd's functionality | 11:41 |
| detha | And then there are packages that provide one especially for that package (such as quagga) | 11:41 |
| KatolaZ | moreso, not depending on the systemd API interface | 11:42 |
| KatolaZ | dunno | 11:42 |
| detha | It would be chasing a moving target yes. But so is parsing the systemd unit files | 11:42 |
| KatolaZ | well, less so | 11:43 |
| KatolaZ | at least if you just want to have a basic initscript | 11:43 |
| KatolaZ | some of the functions of systemd are hard/very hard to reproduce without systemd | 11:44 |
| KatolaZ | for instance, daemon restarting is relatively easy | 11:44 |
| detha | phase 1: parse systemd unit file, generate basic initscript from template. I see Centurion_Dan already has an idea for templates. | 11:44 |
| KatolaZ | several checks are not | 11:44 |
| detha | phase 2: see what is inconvenient | 11:45 |
| KatolaZ | e.g., network availability, or DNS resolving | 11:45 |
| KatolaZ | (that's why systemd internalised those services, basically) | 11:45 |
| KatolaZ | gotta go | 11:45 |
| KatolaZ | bbl | 11:45 |
| KatolaZ | o/ | 11:45 |
| detha | fixable with some form of 'provides' | 11:46 |
| Centurion_Dan | we'll deal with the logic of restarting probably as a special command to the init script - so if the service fails then the tool calls the init-script with a command like "service <servicename> failed" and the initscript could have some boiler plate used to handle that case if the config is there. | 11:47 |
| Centurion_Dan | other then that sending those messages to syslog as well would be great. | 11:49 |
| detha | bsd style would be to have restart_xyzd="YES" in /etc/rc.conf, and init scripts just look at that. | 11:49 |
| Centurion_Dan | detha: exactly - but that should be up to the individual daemon - and init system. | 11:50 |
| detha | if one created templated init scripts, they should have something external that the admin can override | 11:51 |
| detha | otherwise one ends up with admin modifying init script, next update comes, modifications are overwritten | 11:52 |
| Centurion_Dan | actually decoding those messages into something legible and sending it to syslog is the first thing to do - then we can start to worry about handling the supervision side of things. | 11:52 |
| Centurion_Dan | detha: we'd probably control that via /etc/default/<servicename> | 11:53 |
| detha | that would work yes | 11:53 |
| Centurion_Dan | and that is also the init independent location for configuration. | 11:54 |
| kilobyte | 0.0 ... but sending log messages anywhere but /dev/null (or devnulljournal, which is effectively the same) would break systemd compatibility! | 11:54 |
| Centurion_Dan | kilobyte: I know it'll hurt Lennarts feelings, but I don't give a fig about systemd compatibility with stupidity in PID1 and Journald | 11:56 |
| kilobyte | that's my point -- any compat should specifically avoid worst parts of systemd even when it means possibly breaking unit file expectations | 11:57 |
| kilobyte | reliable logging, especially one that survives a crash, is vital for any sysadmin or debugging work | 11:58 |
| kilobyte | systemd goes out of its way to tell storage layers that journal files are unimportant | 12:00 |
| kilobyte | (just so it's not a baseless accusation: for example FS_NOCOW_FL code -- it requests to disable safe writes and checksumming) | 12:02 |
| Centurion_Dan | KatolaZ: we can ignore resolverd completely as it's not required - everything should fall back to normal methods - sequencing of services (dependencies etc) will be handled via insserv as normal - so dependencies on network won't matter. | 12:05 |
| onefang | For what it is worth, many years ago I wrote an LSB compliant sysv init from scratch. I could blow the dust off it and add this sort of stuff. | 12:06 |
| Centurion_Dan | handling targets like mounted volumes could be an interesting challenge, but I can't see it being insurmountable. Systemd isn't doing particularly special stuff... it's just doing it in ways that are prone to cause problems... | 12:07 |
| Centurion_Dan | onefang: I've already started with Lydia_K, startmeup util - it generates LSB compliant init scripts with a few input parameters already. | 12:09 |
| Centurion_Dan | And it's also got the beginnings of openrc as an alternative target too. | 12:10 |
| onefang | KatolaZ: I think I solved the link problem, there was an Options that didn't have the symlink stuff hidden in another cotfig file. | 12:10 |
| onefang | If I recall, the main features of mine where full LSB compliance (at the time), dependency tracking, and not caring what language the init scripts where written in. I even had init scripts written in C for the sake of example. But it's been a while, it probably bit rotted. | 12:12 |
| onefang | Wow, SourceForge now adds "Similar Business Software" and thinks JIRA is similar to a sysv init system. lol | 12:16 |
| Centurion_Dan | onefang: here we're sticking to standard scripts using all the builtin boilerplate available. If a packager want | 12:16 |
| Centurion_Dan | to provide an init as C program that's their parogative, but our purpose is to fill the inevitable holes where debian no longer ship init scripts. | 12:17 |
| KatolaZ | Centurion_Dan: that's not gonna happen soon, IMHO | 12:18 |
| KatolaZ | there is still a Policy that requires packages to ship a simple initscript | 12:18 |
| KatolaZ | as long as the policy is there, there is no way the package of a deamon can make it into Debian without a proper initscript | 12:19 |
| onefang | https://sourceforge.net/projects/urunlevel/ for what it's worth. Five years since I last looked at it. Written as a Busybox App, I should probably port it to toybox and offer it to them. | 12:19 |
| Centurion_Dan | KatolaZ: good... that give us a little breathing room... | 12:19 |
| Centurion_Dan | onefang: hmm cvs .... ouch... | 12:21 |
| onefang | Did I mention it was ancient? lol | 12:21 |
| Centurion_Dan | anyway... it's pretty much bed time ;-) | 12:23 |
| * onefang tries to remember what else I said I might do for Devuan. It's time I started writing code again after my big life disrupters. | 12:24 | |
| onefang | KatolaZ: should probably add that link test to the mirrors test script. | 12:30 |
| KatolaZ | yes onefang | 12:34 |
| KatolaZ | but the thing is that we would strongly encourage using codenames | 12:34 |
| KatolaZ | not stable/testing/old-stable | 12:34 |
| KatolaZ | and so on | 12:34 |
| detha | I would, if it just would use versions. Can't be arsed to remember the funny names they give versions across different projects, so 'stable' it is. | 12:43 |
| onefang | We called it ASCII, not ARSED. B-) | 12:44 |
| onefang | And then I just found this - https://henrich-on-debian.blogspot.com/2018/10/how-about-specify-debian-version-in-apt.html | 14:02 |
| arachnopavel | parazyd: speaking of kernels, why is the most recent one in ascii is still 4.9.0-8? Shouldn't it be updated to patch some of the recent cve bugs, at least? | 14:22 |
| parazyd | arachnopavel: Is this about the ARM kernels or the packaged ones? | 14:23 |
| arachnopavel | parazyd: packaged ones. | 14:23 |
| parazyd | That's the latest one | 14:24 |
| parazyd | In Debian, this is. | 14:25 |
| parazyd | 4.9.110 | 14:25 |
| Centurion_Dan | detha you can always use release numbers | 20:46 |
| Centurion_Dan | 1.0, 2.0, 3.0 (although technically unreleased... but again they're symlinks :-) | 20:47 |
| detha | Centurion_Dan: I do, for some things. But it is still an annoyance that for example /etc/debian_version has a sensible '9' in it, and /etc/devuan_version 'ascii'. | 20:54 |
| Centurion_Dan | I do think we should drop the trailing .0 from the version numbers, and /etc/devuan_version should be 9 | 20:56 |
| Centurion_Dan | er 2 for ascii - ie should be a number to be consistent with debian. | 20:56 |
| detha | as far as I know there are no point releases like RHEL/Centos, so yes | 20:57 |
| detha | That is one thing ubuntu got right, eventually. They also started with funny names, but now everybody talks about '16.04' or '18.04' | 20:58 |
| Centurion_Dan | detha: ubuntu has point releases... they just aren't identified as such. All there point releases are the ones not labelled LTS, and point release to point release upgrades are guaranteed to break... | 21:27 |
| detha | Luckily I don't use ubuntu, but yeah. Point releases are odd - RHEL tries very hard /not/ to break things on point releases, but for example openbsd says 'Point release, here is the list of things that is guaranteed to break' | 21:29 |
| detha | (and I just spent the entire weekend un-breaking openbsd 6.3->6.4 on the infra here) | 21:30 |
| Centurion_Dan | detha: debian rarely breaks anything on a point release - the only acceptable reason is where there is a serious security bug involved... | 21:33 |
| detha | Same as redhat. I remember centos around 6.4 or 6.5 spectacularly broke libssl-related things be removing old algorithms | 21:35 |
| Centurion_Dan | redhat/centos have been known to drop the odd update bomb that breaks things too. I recall an instance when they broke some smtp daemon - might've been postfix, anyway not only did redhat customers get effected, but also all the downstream distro's. There was much weeping and gnashing of teeth. In debian however, the bug in the patch got picked up and fixed before the updated package was pushed. | 21:38 |
| detha | yup. they also broke tomcat at some stage. That caused me some grief | 21:42 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!