00:07:47kansei- (kansei) joins
00:08:10kansei quits [Ping timeout: 250 seconds]
00:45:36<Webuser603791>I think I've narrowed down the spurious restarts to whenever all ongoing tasks are uploads. Is there a way to entirely disable the auto-restart feature? I think I can live without it.
01:32:08Webuser682964 joins
01:32:54<Webuser682964>hey all. is there a channel for issues noticed in the log?
01:53:01Webuser682964 quits [Client Quit]
04:04:20razul27 quits [Ping timeout: 250 seconds]
04:12:25razul27 joins
05:19:59<ATWF_notcarl>I am noting that ipv6 only hosts are... severely crippled with the current version. This is primarily a dns issue, which can be worked around...
05:27:08<ATWF_notcarl>but working around it may cause problems for public nat64 providers.
05:41:24sec^nd quits [Remote host closed the connection]
05:41:38sec^nd (second) joins
05:57:11JayEmbee quits [Ping timeout: 260 seconds]
05:58:47JayEmbee (JayEmbee) joins
06:59:21Meli (Meli) joins
07:07:11Meli quits [Ping timeout: 260 seconds]
07:09:39Meli (Meli) joins
07:11:17BornOn420 quits [Remote host closed the connection]
07:11:37BornOn420 (BornOn420) joins
07:23:01nulldata quits [Quit: Ping timeout (120 seconds)]
07:23:49nulldata (nulldata) joins
08:18:12<@JAA>ATWF_notcarl: IPv6-only hosts aren't very useful currently. A good chunk of the internet, including of the sites we're archiving, e.g. GitHub and various .gov/.mil sites, is still IPv4-only. So we need workers with IPv4 connectivity, generally.
08:19:31<@JAA>So them being crippled isn't necessarily a bad thing. Maybe we should explicitly check for that and deliberately/entirely break them. (Cc arkiver)
08:20:13<@JAA>Probably on a per-project basis.
08:22:26makeworld quits [Ping timeout: 260 seconds]
08:25:41makeworld joins
09:15:30nulldata quits [Client Quit]
09:16:14nulldata (nulldata) joins
09:39:59<@arkiver>JAA: agreed
09:40:24<@arkiver>i may be good indeed to disallow ipv4-only on #// for example
09:40:27<@arkiver>what do you think?
09:47:10<@JAA>arkiver: Disallow IPv6-only, you mean? Or actually perhaps both, i.e. require dual stack.
09:49:59<@arkiver>i'm not sure yet about requiring both
09:50:05<@arkiver>but at least disallow ipv6 only yes
09:50:32<@arkiver>can do some tests actually when the project is running well, so see how much ipv6-only stuff actually makes it through
09:50:38<@arkiver>by queuing a few custom ones myself
10:59:38thenes quits [Remote host closed the connection]
10:59:59thenes (thenes) joins
11:00:01Bleo18260072271962345 quits [Quit: The Lounge - https://thelounge.chat]
11:02:49Bleo18260072271962345 joins
13:02:52FiTheArchiver joins
13:18:55Cysioland quits [Remote host closed the connection]
13:19:17Cysioland (Cysioland) joins
13:29:19daniel joins
13:30:18daniel is now known as RJHacker41985
13:35:40<RJHacker41985>Hi everybody! I'm writing to ask about whether it would be possible to plan out / develop some changes so that archiving (or project) warriors could be implemeted in a non-Seesaw framework. If the scripts were implemented in something like Go, deployment would be much easier (moving a binary in and running it vs. needing Docker). This could greatly increase the accessibility of running warriors and the number of volunteer machines. Has this path
13:35:40<RJHacker41985>been proposed already? What cons would it have?
14:11:31BornOn420 quits [Remote host closed the connection]
14:11:45BornOn420 (BornOn420) joins
14:26:04<TheTechRobo>The current system works, that's the key. A new system would take a lot of extra work for not much benefit
14:26:20<TheTechRobo>Requiring docker is a Good Thing anyway for data integrity reasons
14:37:47th3z0l4 joins
14:38:12JayEmbee quits [Quit: WeeChat 2.3]
14:39:16th3z0l4_ quits [Ping timeout: 260 seconds]
15:01:21<RJHacker41985>That is a really fair point, thanks for your response!
17:19:11daniel joins
17:20:12daniel is now known as RJHacker61765
17:20:51RJHacker41985 quits [Ping timeout: 260 seconds]
17:25:41RJHacker61765 leaves
23:22:11simon816 quits [Quit: ZNC 1.9.1 - https://znc.in]
23:30:51simon816 (simon816) joins