| plasma41 | rrq: I'm doing a bit of archaeology. Are the repos from Devuan's old GitLab instance archived somewhere? In a giant tarball, perhaps? | 05:54 |
|---|---|---|
| rrq | the gitlab server image is still around; could be brought up I think, with localnet access | 05:56 |
| rrq | afaik all projects of any sgnificance were transfered to gitea | 05:57 |
| rrq | some personal projects were abandoned by the persons | 05:58 |
| rrq | do you need the image up? | 05:59 |
| Xenguy | plasma41, Not sure if this is helpful: https://www.devuan.org/gitlab-issues/ | 06:15 |
| plasma41 | Xenguy: yes, I'm aware of the issues archive. Unfortunately it doesn't contain any of the code from the archives which is what I'm after. | 06:17 |
| Xenguy | Alas | 06:17 |
| rrq | plasma41: all devuan projects were migrated; some changed name slightly (removing excessive "devuan" from the names) | 06:40 |
| plasma41 | rrq: Unfortunately I was look for the source for blinkdog's old pad reformatter tool which was in a personal repo. | 06:42 |
| plasma41 | golinux found a couple source files on her machine, so I have those now. I don't think they're the full source or the latest version, but they are at least the most important files for whatever version they are. | 06:45 |
| rrq | ok, I'll have a poke to see how far from dead the VM image is... | 06:46 |
| golinux | rrq: the names of the files plasma was asking about are wikify-pad.coffee and listify-pad.coffee from @2017. | 08:02 |
| rrq | yeah; I digged out the old repo for him.. so he'll find his way | 08:04 |
| eleison[m] | I have a bit of a silly question. I have used systemd-free OSs before (gentoo, void, etc) so I haven't come across this one before: I installed Devuan Chimera and tried to install chromium, and for some reason apt said that libsystemd0 had to be removed. I am happy for it to be removed (Though I know it's not a big deal having it) but I am curious to know why it wanted to remove it in the first place. This is not so much a request for support | 12:58 |
| eleison[m] | as a question to know more :) | 12:58 |
| eleison[m] | Could it be that Chromium was bringing with it a version of a service that had been de-systemded and that conflicted with the library? | 12:59 |
| gnarface | eleison[m]: you used the chromium from the devuan repo, right? | 13:15 |
| eleison[m] | Yes | 13:15 |
| gnarface | did you see it perhaps replace it with libelogind0? | 13:16 |
| eleison[m] | Mm I see. To be honest I trusted the process and went ahead regardless :D I was just curious why chromium and not other packages triggered this event, as I installed quite a few packages before. I know chromium is a monster that brings loads of stuff with it, but it still caught my attention | 13:18 |
| gnarface | well libelogind0 is devuan's replacement for the already vestigial libsystemd0 | 13:19 |
| gnarface | it's possible chromium in chimera has been altered to prefer that one, that would just be my guess | 13:19 |
| gnarface | but also i would assume that's because you're using elogind too | 13:20 |
| eleison[m] | Yeah, that's what I suspected :) | 13:20 |
| eleison[m] | Yep, I am | 13:20 |
| gnarface | i would have recommended trying to install it with --no-install-recommends to see if that avoids it, but only if you weren't using elogind already | 13:20 |
| gnarface | well maybe even if you were | 13:20 |
| gnarface | but if you require elogind it would not have helped | 13:21 |
| gnarface | you might not actually require elogind at all, but i think it's a common dependency for some graphical login managers | 13:21 |
| eleison[m] | I only have ratpoison and start with xinit | 13:22 |
| gnarface | oh, well then i'm not sure you need elogind at all | 13:22 |
| eleison[m] | I thought you needed elogind to avoid having to set suid on the X binary? | 13:22 |
| gnarface | uh... well that's not strictly true if you don't rely on giving your window manager's users unprivileged access to the reboot, shutdown, sleep and hibernate functionality | 13:23 |
| eleison[m] | Mmmm I see. Interesting | 13:23 |
| gnarface | you could always execute shutdown by command-line with su or sudo | 13:23 |
| eleison[m] | I always do. I have an aversion for GUIs | 13:24 |
| gnarface | worth noting some commercial video drivers last i checked (nvidia) still do require suid root xor binaries just for working hardware acceleration, but that's a separate issue that doesn't affect all hardware | 13:24 |
| gnarface | *xorg binaries | 13:24 |
| eleison[m] | I use one of those integrated intel HD whatever | 13:24 |
| gnarface | there's 2 drivers that work for those and at least one of them doesn't need to be suid root anymore | 13:24 |
| gnarface | and they're both open source | 13:25 |
| eleison[m] | Does that mean that I can just blast elogind from orbit and go my merry way? :D | 13:25 |
| gnarface | well i did but your mmv | 13:25 |
| gnarface | i think so, yes | 13:25 |
| gnarface | dbus might be harder to get rid of | 13:25 |
| eleison[m] | Yeah, if I am correct firefox wants atk which wants dbus | 13:26 |
| gnarface | but i go without elogind (or any permissions backend) and without avahi-daemon, pulseaudio or portmap | 13:26 |
| eleison[m] | Although in Gentoo I just force-removed dbus and nothing ever broke | 13:26 |
| gnarface | most stuff doesn't use it for anything important | 13:26 |
| gnarface | the only thing i could find firefox actually doing with it that i cared about was auto-setting default mail clients | 13:27 |
| gnarface | i don't think steam will start without it though | 13:28 |
| eleison[m] | One of the funny things of these "services" is how little they actually do | 13:29 |
| eleison[m] | pulseaudio is the easiest to get rid of in my opinion. In practical terms it's only useful if you want to be able to use pavucontrol | 13:29 |
| eleison[m] | If anything it makes audio easier to break, in my experience | 13:30 |
| gnarface | yea that has been my experience too but i recognize the selection bias of their target audience | 13:31 |
| * u4t waves | 13:51 | |
| u4t | is there a way to determine what ./configure flags were used for a given package? | 13:52 |
| eleison[m] | gnarface: I removed elogind and it installed consolekit and a bunch of other stuff | 13:52 |
| eleison[m] | Install: hdparm:amd64 (9.60+ds-1, automatic), libx86-1:amd64 (1.1+ds1-12, automatic), libcgmanager0:amd64 (0.41-2+devuan1, automatic), libpolkit-gobject-consolekit-1-0:amd64 (0.105-31+devuan1, automatic), powermgmt-base:amd64 (1.36, automatic), libck-connector0:amd64 (1.2. | 13:53 |
| eleison[m] | 1-8, automatic), libnih1:amd64 (1.0.3-11, automatic), pm-utils:amd64 (1.4.1-19, automatic), consolekit:amd64 (1.2.1-8, automatic), libnih-dbus1:amd64 (1.0.3-11, automatic), vbetool:amd64 (1.1-5, automatic), ethtool:amd64 (1:5.9-1, automatic), libpam-ck-connector:amd64 (1.2 | 13:53 |
| eleison[m] | .1-8, automatic) | 13:53 |
| eleison[m] | Purge: libpolkit-gobject-elogind-1-0:amd64 (0.105-31+devuan1), elogind:amd64 (246.10-2), libpam-elogind:amd64 (246.10-2) | 13:53 |
| gnarface | apt-cache rdepends elogind | 13:57 |
| gnarface | ? | 13:58 |
| gnarface | or: aptitude why elogind | 13:58 |
| gnarface | eleison[m]: ^ | 13:58 |
| gnarface | or wait, i guess now consolekit | 13:59 |
| gnarface | something you have installed seems to want that functionality or it wouldn't have installed a replacement | 13:59 |
| eleison[m] | xserver-xorg-core Recommends default-logind | logind | 13:59 |
| gnarface | oh it's just recommend | 13:59 |
| gnarface | recommends | 14:00 |
| eleison[m] | Yeah, no biggie | 14:00 |
| gnarface | you can disable that default of including recommends | 14:00 |
| gnarface | in the config or on the command-line | 14:00 |
| eleison[m] | Yeah I know, I just left it because of laziness :D | 14:00 |
| eleison[m] | --no-install-recommends | 14:00 |
| eleison[m] | gnarface: Thanks for your help! | 14:09 |
| gnarface | np | 14:09 |
| eleison[m] | gnarface: What instructions did you follow to be able to launch X without elogind and without SUID? | 15:00 |
| eleison[m] | Here https://www.devuan.org/os/documentation/install-guides/beowulf/Release_notes_beowulf_3.0.0.txt they seem to direct to either elogind or SUID | 15:00 |
| gnarface | eleison[m]: i think you should just have to add yourself to the video group? | 15:11 |
| gnarface | the default changed for some of the drivers | 15:11 |
| gnarface | should just work and log to ~/.local/share/xorg/ now, i think | 15:12 |
| eleison[m] | I added myself to the video and input groups and still nothing... | 15:14 |
| eleison[m] | I mean, it launches the wm without issues, but input doesn't work | 15:14 |
| eleison[m] | I should've probably been more specific before, sorry | 15:14 |
| eleison[m] | I have the feeling that there is a permissions issue somewhere for accessing the hardware | 15:14 |
| gnarface | oh hah | 15:17 |
| gnarface | yea you also have to add yourself to the input group, sorry | 15:17 |
| gnarface | you should probably also add audio and cdrom | 15:17 |
| eleison[m] | I am, still can't use any input devices | 15:18 |
| gnarface | that's weird... no errors in the logs? | 15:18 |
| eleison[m] | Maybe installing xorg without recommends has left out a bit that I need for the input? | 15:18 |
| gnarface | look in the xorg log | 15:18 |
| gnarface | might just be some other missing package | 15:19 |
| gnarface | libinput or something | 15:19 |
| eleison[m] | Ok it works now :) | 15:20 |
| gnarface | hah | 15:20 |
| eleison[m] | I've got the feeling it didn't get the change of groups | 15:21 |
| eleison[m] | Anyway, thank you! | 15:21 |
| gnarface | np | 15:21 |
| gnarface | you do have to log out all the way for group changes to take effect | 15:21 |
| eleison[m] | yeah I have the feeling that was the problem | 15:21 |
| eleison[m] | next stop, removing eudev haha | 15:23 |
| eleison[m] | If I am correct, I can remove it and just create device nodes with mknode as I need them | 15:23 |
| gnarface | yes, that works for most things | 15:52 |
| eleison[m] | Is this something you have done yourself before? RTFMing at the moment | 16:51 |
| fsmithred | I've done it only partially. The live-isos I make have some static devices set up, but I've never removed udev/eudev | 16:54 |
| fsmithred | and I think I did it around 20 years ago in suse, long before udev. | 16:54 |
| eleison[m] | Ah, ok | 16:55 |
| fsmithred | there's also vdev if you want to try an alternative. It's in the gnuinos repo. | 16:55 |
| fsmithred | Gnuinos is a libre respin of devuan. | 16:55 |
| eleison[m] | I had mdev in mind as well, thank you for the suggestion! | 16:55 |
| fsmithred | are you excluding dbus, too? | 16:56 |
| eleison[m] | Yes, I hadn't started to think about that side of things yet, though | 16:56 |
| fsmithred | there's a discussion on the forum about it which links to some lists of packages that don't need dbus | 16:56 |
| eleison[m] | Forgive my ignorance, but I imagine things like dunst won't work without dbus. Is there an alternative? I need to know when my colleagues email me :) | 16:57 |
| fsmithred | you can have a pretty complete desktop if you're selective | 16:57 |
| fsmithred | I don't know dunst | 16:57 |
| eleison[m] | Thanks for that, I will have a look | 16:57 |
| fsmithred | brb | 16:57 |
| eleison[m] | I know there are unix-compliant notification daemons around, I just hadn't thought about how to integrate them with the rest of the setup | 16:58 |
| eleison[m] | I mean, I would like chromium being able to show notifications, and that's about it | 16:58 |
| brocashelm | is there a way to get orphaner to work again past version 1.7.33? | 16:59 |
| mason | brocashelm: What's broken about it in its current form? | 17:00 |
| brocashelm | mason: the current version of deborphan purges deborphan because the dev didn't want to maintain it anymore, but i see no reason to discard it completely as i liked the visual convenience (and gtkorphan hasn't been maintained past jessie IIRC) | 17:01 |
| mason | Wait, deborphan conflicts with orphaner? | 17:02 |
| mason | looking | 17:03 |
| brocashelm | orphaner is a binary provided by deborphan. here's one of the bug reports: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992524 | 17:04 |
| brocashelm | i mentioned this in the channel the other day, but no one got back to me on it. i tried 1.7.33 (to get the binary orphaner back in place), but had an issue with "which" (i modified the script then to "command -v" as per debian's new alteration) and then "tempfile" couldn't be found | 17:06 |
| mason | kk, that bug confirms that it doesn't show up in the change log | 17:07 |
| mason | Um. Alright, never mind, reading the end, the person opening the bug looked at the same change list I did | 17:07 |
| mason | https://metadata.ftp-master.debian.org/changelogs//main/d/deborphan/deborphan_1.7.33_changelog fwiw | 17:08 |
| brocashelm | https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1815276.html | 17:08 |
| brocashelm | this is the one i meant to link | 17:08 |
| mason | ah: https://metadata.ftp-master.debian.org/changelogs//main/d/deborphan/deborphan_1.7.35_changelog | 17:09 |
| mason | They list a bunch of bugs as the reason: (Closes: #972509, #981607, #414865, #395282, #488646, #571105, #617863) | 17:09 |
| Tenkawa | brocashelm: how did you make your new which look? I actually removed which and wrote a new wrapper. | 17:10 |
| Tenkawa | that would probably work better for your temp problem | 17:11 |
| Tenkawa | I used | 17:11 |
| Tenkawa | #!/bin/sh | 17:11 |
| Tenkawa | command -v "$@" | 17:11 |
| Tenkawa | exit 0 | 17:11 |
| Tenkawa | as a /usr/bin/which substitute so old programs could still use it | 17:12 |
| brocashelm | i haven't done that myself. you created a custom which script? | 17:12 |
| brocashelm | interesting | 17:12 |
| Tenkawa | yep | 17:12 |
| brocashelm | i'll actually try that out myself. thanks | 17:12 |
| Tenkawa | np | 17:12 |
| mason | brocashelm: If you do it, might be good to use dpkg-divert so package updates don't clobber your new script. | 17:13 |
| Tenkawa | mason: good point | 17:13 |
| brocashelm | alright | 17:13 |
| Tenkawa | although I think which is now deprecated | 17:13 |
| Tenkawa | which is part of the problem | 17:14 |
| Tenkawa | the last update deprecated it | 17:14 |
| brocashelm | yes, debian deprecated which in favor of command -v | 17:14 |
| Tenkawa | and put that line in the top of the scri[t | 17:14 |
| Tenkawa | er script... quote annoying | 17:14 |
| Tenkawa | it spewed that output like 100 times in my first build | 17:15 |
| Tenkawa | of a image I was working on | 17:15 |
| mason | Wait, they've deprecated which? A tool that's been around for decades? | 17:15 |
| Tenkawa | mason: yep | 17:15 |
| eleison[m] | Same reaction from me. Why?? | 17:15 |
| brocashelm | yeah, that's what i've been saying | 17:15 |
| Tenkawa | they've replaced it with this "command" tool | 17:16 |
| mason | Every day, new sharks to jump. | 17:16 |
| brocashelm | and then with usrmerge in the way | 17:16 |
| Tenkawa | trying to find the "backstory" of what history led to this | 17:17 |
| brocashelm | downgraded deborphan to 1.7.33 and the output is: | 17:18 |
| brocashelm | /usr/sbin/orphaner: 1: tempfile: not found | 17:18 |
| mason | brocashelm: Can you pastebin the script? Is it using mktemp or something? | 17:19 |
| Tenkawa | yeah that looks like a cmd execution | 17:21 |
| brocashelm | when i try to use orphaner | 17:21 |
| brocashelm | mason: https://dpaste.org/cD2o | 17:22 |
| mason | brocashelm: And do you have /bin/tempfile? I'd just hardcode that inside the backticks. | 17:24 |
| mason | If you have /bin/tempfile, say PACKAGES=`/bin/tempfile` | 17:25 |
| mason | If you don't, you can substitute a mktemp invocation. | 17:25 |
| mason | Like: PACKAGES=`/bin/mktemp /tmp/orphan.XXXXXXXX` | 17:26 |
| mason | (literal Xes) | 17:26 |
| mason | And if you have neither tempfile nor mktemp, it's time to back up and head over to Illumos or BSD. :P | 17:27 |
| mason | s/back/pack/ bad typing day | 17:27 |
| brocashelm | then it's time to switch to devuan openbsd | 17:28 |
| brocashelm | i don't have /bin/tempfile, ugh | 17:28 |
| mason | brocashelm: mktemp ought to work fine | 17:28 |
| mason | it's the traditional tool for the purpose | 17:28 |
| Tenkawa | hmm | 17:29 |
| Tenkawa | I dont get that error without either one | 17:29 |
| brocashelm | oh yes i have mktemp | 17:29 |
| mason | Tenkawa: But it's trying to call that. Do you not have that line filling PACKAGES with tempfile output? | 17:29 |
| Tenkawa | I just copied his paste output | 17:30 |
| Tenkawa | what else do I need to stage? | 17:30 |
| mason | brocashelm: There's also TMPFILE=`tempfile` later on that you'll want to fix | 17:30 |
| brocashelm | i see it | 17:31 |
| mason | brocashelm: And whomever wrote that is a bit careless. Random extraneous punctuation. | 17:31 |
| Tenkawa | I created a script to run based on his output.. does he have some env vars I need still? | 17:31 |
| brocashelm | what needs to replace it? | 17:31 |
| Tenkawa | to emulate his test condition? | 17:31 |
| mason | PACKAGES=`/bin/mktemp /tmp/foo.XXXXX` | 17:32 |
| mason | TMPFILE=`/bin/mktemp /tmp/foo.XXXXX` | 17:32 |
| mason | Even better, $() instead of `` but that's more style than anything. Nests. | 17:32 |
| brocashelm | /usr/sbin/orphaner: 372: cannot create : Directory nonexistent | 17:33 |
| brocashelm | /usr/sbin/orphaner: 430: cannot open : No such file | 17:33 |
| brocashelm | /usr/sbin/orphaner: 493: cannot create : Directory nonexistent | 17:33 |
| brocashelm | oh, ok, i see what i did wrong | 17:33 |
| brocashelm | i replaced TMPFILE= with the PACKAGES= | 17:33 |
| mason | Guessing temp instead of tmp? | 17:33 |
| mason | Oh | 17:33 |
| mason | Yeah, one of each. | 17:33 |
| brocashelm | nice, it works! | 17:33 |
| Tenkawa | cool :) | 17:34 |
| mason | Note that there might be other issues. This seems like a script with a whole subscription's worth of issues. | 17:34 |
| Tenkawa | yeah | 17:34 |
| mason | Wow, that comment. "Don't touch the next two lines!" If you ever feel the need to do something like that, just call printf with the hex value of the funny character you want to capture. | 17:35 |
| mason | I think I want to find out who wrote that script so I can PIN all his or her packages. | 17:35 |
| mason | Five people have copyright on that script, and that stuff wasn't fixed. | 17:36 |
| user____ | which webmail system available on devuan is known to work well on Android browsers too? | 18:41 |
| rwp | It's perhaps been missed that tempfile has been removed from Sid/Ceres now. It's gone. (Also, please do not hard code paths eg /bin/mktemp please just use PATH.) | 19:23 |
| rwp | Sid/Ceres flowing into Chimaera has a series of broken bits right now. The removal of tempfile is one of them that broke Xsession and other things. | 19:25 |
| rwp | https://bugs.debian.org/992399 debianutils: removes interface from essential package without proper transiti | 19:26 |
| rwp | Another harsh one is that they moved run-parts and the old hard coded paths to it are now broken. (Please don't use hard coded paths.) | 19:26 |
| rwp | https://bugs.debian.org/992410 move of /bin/run-parts to /usr/bin breaks network with ifup | 19:27 |
| fsmithred | tempfile is still in chimaera and stuff is done flowing automatically from ceres to chimaera. | 19:29 |
| rwp | The rc severity bugs are blocking the flowing? That's what I would expect. | 19:32 |
| rwp | I am running Sid/Ceres on my desktop and a couple of other canary systems and I hit all of those on the day after they were uploaded. | 19:33 |
| mason | rwp: If it was in his PATH then it would have been found, so it explicitly was not in his PATH. | 19:33 |
| mason | rwp: Scripting, it's often a good idea to not assume anything about the user's environment. | 19:33 |
| mason | rwp: This instance demonstrates just this. | 19:33 |
| rwp | I still claim that hard coding the path in something like /bin/mktemp has many problems. Avoid! Avoid! | 19:34 |
| fsmithred | you can set the path in the script. I did that with a couple of them. | 19:34 |
| mason | rwp: What's your better solution for him, since it clearly wasn't in his path, suggesting that /usr/bin/env would also have missed it? | 19:34 |
| rwp | That is exactly the same problem that the current move of run-parts has now tripped over in several places such as ifupdown. | 19:35 |
| mason | rwp: Things shouldn't move once established. | 19:35 |
| fsmithred | is /usr/bin/env getting moved?? | 19:35 |
| rwp | Wasn't the problem that tempfile has been removed from ceres? Since it wasn't found? In that case the better choice was to convert to mktemp. It was orphaner? | 19:36 |
| * rwp goes looking for deborphan bug reports... | 19:36 | |
| rwp | fsmithred, /usr/bin/env can't really ever move ever. Legacy. | 19:36 |
| mason | fsmithred: /usr/bin/env is the common answer for "I don't know where something is but I want to invoke it" among its other tricks. | 19:37 |
| fsmithred | good | 19:37 |
| mason | fsmithred: It's also useful for faking out a service command on systems that lack one. Run something through 'env -i' and you start it with a scrubbed environment. | 19:37 |
| rwp | I see only this one: https://bugs.debian.org/972509 "WARNING: tempfile is deprecated; consider using mktemp instead" marked as fixed in 1.7.34. | 19:37 |
| mason | What's amusing to me is that I've never heard of tempfile(1) before today, and now I learn that it's deprecated. | 19:38 |
| rwp | env became the canonical documentation answer to users where we had no idea what shell they were using. Was it bash? ksh? csh? zsh? | 19:38 |
| rwp | If it was csh or tcsh (which surprisingly many people are still using!) then one can't say "foo=something somecommandhere args" because that fails. | 19:39 |
| fsmithred | good | 19:39 |
| fsmithred | and that brings me to another question | 19:39 |
| rwp | But one can document "env foo=something somecommandhere args" and it will work for all of the shells. | 19:39 |
| fsmithred | if we use 'command -v' instead of which, what does that do to people who aren't using bash. Do other shells have that same builtin? | 19:39 |
| rwp | It's also "a" solution (one of several) for generic OS instructions where the user might be on OpenBSD or one of the other Free Software systems that isn't GNU where things are "different". | 19:40 |
| rwp | For example on HP-UX a non-root user might have had to install bash in /usr/local/bin/bash or $HOME/bin/bash in which case "#!/usr/bin/env bash" works portably across systems where almost nothing else will. | 19:41 |
| mason | fsmithred: command works in dash | 19:41 |
| rwp | fsmithred, As I understand it (I guess I need to go look at some point) POSIX has added that requirement to POSIX sh in the latest revision of it. | 19:42 |
| mason | Not sure where else it might be, but dash and bash are probably the big targets. | 19:42 |
| rwp | Therefore all shells that might be used for /bin/sh must implement it now. | 19:42 |
| rwp | But for example I looked up something and found that 2008 Debian's Policy required it NOT use command -v at that time because it was NOT in the current POSIX revision at that time. | 19:42 |
| rwp | So I presume that this was changed in the recent revision of the standartds. | 19:43 |
| mason | Searching for "command" in the dash man page is unfortunately funny. | 19:44 |
| mason | Ah, got it. Under Builtins. | 19:44 |
| rwp | Definitely in the standard now: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/command.html | 19:46 |
| rwp | Apparently added in the 2008 revision of it. | 19:46 |
| mason | Too new to be worthy of notice. It needs to gather a protective layer of dust before it's worth considering. | 19:47 |
| fsmithred | I've been using 'type -p' in some places. Does the same thing. | 19:47 |
| rwp | Let's trip down memory lane to *before* 2008: https://web.archive.org/web/20081002164531/https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html | 19:47 |
| rwp | "... since command -v, type, and which are not POSIX." | 19:48 |
| rwp | Standards doc on "type" without a "type -p" option required: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/type.html | 19:49 |
| rwp | That makes "type -p" a bash'ism (even if it originated with ksh) | 19:50 |
| fsmithred | thanks. Made a note to change that. | 20:15 |
| fsmithred | afk. bbl. | 20:15 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!