From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 06 14:41:51 2021 Received: (at submit) by debbugs.gnu.org; 6 Jan 2021 19:41:52 +0000 Received: from localhost ([127.0.0.1]:45622 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kxEgp-0001Iv-FD for submit@debbugs.gnu.org; Wed, 06 Jan 2021 14:41:51 -0500 Received: from lists.gnu.org ([209.51.188.17]:42166) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kxEgo-0001Io-13 for submit@debbugs.gnu.org; Wed, 06 Jan 2021 14:41:50 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:39946) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kxEgn-0005de-Pm for guix-patches@gnu.org; Wed, 06 Jan 2021 14:41:49 -0500 Received: from dd26836.kasserver.com ([85.13.145.193]:35380) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kxEgi-0006pb-Pe; Wed, 06 Jan 2021 14:41:46 -0500 Received: from localhost (80-110-127-104.cgn.dynamic.surfer.at [80.110.127.104]) by dd26836.kasserver.com (Postfix) with ESMTPSA id B8C183365398; Wed, 6 Jan 2021 20:41:39 +0100 (CET) Date: Wed, 6 Jan 2021 20:41:34 +0100 From: Danny Milosavljevic Subject: kernel-module-configuration-service for configuring kernel parameters Message-ID: <20210106204134.38e83db4@scratchpost.org> In-Reply-To: <6wemXB-PfHUqbuVr5-XRf0-tY4cKGGtKiUqrZPrIZYXoBw17L3xRuZrGOJQfTo5PKfFNCM8KyRTllidoc7asPE2x98BTiJSPVR7OSjxCuw8=@protonmail.com> References: <6wemXB-PfHUqbuVr5-XRf0-tY4cKGGtKiUqrZPrIZYXoBw17L3xRuZrGOJQfTo5PKfFNCM8KyRTllidoc7asPE2x98BTiJSPVR7OSjxCuw8=@protonmail.com> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/xXlbAOfUGZoWGj8WvcLyYPd"; protocol="application/pgp-signature"; micalg=pgp-sha512 Received-SPF: none client-ip=85.13.145.193; envelope-from=dannym@scratchpost.org; helo=dd26836.kasserver.com X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.1 (-) X-Debbugs-Envelope-To: submit Cc: raid5atemyhomework , ludo@gnu.org, raid5atemyhomework via Guix-patches via , "45692@debbugs.gnu.org" <45692@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) --Sig_/xXlbAOfUGZoWGj8WvcLyYPd Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi raid5atemyhomework, Hi everyone, @raid5atemyhomework, thanks for all the patches! On Wed, 06 Jan 2021 15:57:19 +0000 raid5atemyhomework via Guix-patches via wrote: > +@item @code{options} (default: @code{'()}) > +A list of string options to pass as options to the ZFS module. > +These will be put in a @file{/etc/modprobe.d/zfs.conf} file, > +for example setting this to @code{'("zfs_admin_snapshot=3D1" > +"zfs_trim_extent_bytes_min=3D0")} will create the following file: Sure, but it would be better to create a way to configure those module para= meters in Guix in a declarative way, first. Your new kernel-loadable-module-service-type would be a good template to write a kernel-module-configuration-service that can be extended by other services. The latter should allow users to parametrize the kernel in general via the operating-system form, and also allow services to extend such configuration (with merging, and conflict detection). It would be used: (1) To declaratively specify the contents of something like /etc/modprobe.d= . It shouldn't even be called "/etc/modprobe.d"--it should also be in the sto= re instead. This directory is only useful for non-Linux-builtins. (2) If the "module" is built-in then the kernel command line must get the options instead. (in fact, it works as a kernel command line option also if it's a loadable module--so not sure we need /etc/modprobe.d at all--at least at first. But there's probably a maximal length for the kernel comma= nd line that we could exceed if we did that long term) I know it's annoying that Guix doesn't have this facility already, but the time to introduce an interface for /etc/modprobe.d and the kernel command line for builtin modules is before other services introduce their own ad hoc way to create /etc/modprobe.d--like this tries to do here. See also https://issues.guix.info/issue/42193 for an earlier attempt (which is already very far--but it has a bug somewhere). There's also already a kernel profile thing like you wrote in that patchset. (Note that I would prefer there not to be a "LOAD?" in there because it confuses loading the module (which is usually NOT started by user space but by the kernel on its own) and confguring the module (which has to be done by user space because it's specifying policy, not mechanism)) Also, because the kernel usually loads loadable modules on its own (potenti= ally really early), /etc/modprobe.d has to be preset and known to the modprobe executable VERY EARLY (via environment variable MODPROBE_OPTIONS--see=20 gnu/services.scm %modprobe-wrapper). It is totally possible that some modules in the initrd need options, too (see load-linux-modules-from-directory for where this would need to go). load-linux-module/fd already accepts options and flags--but both are not gi= ven on the call. For this, part of future kernel-module-configuration entries (the ones needed for modules in the initrd) should be copied into the initr= d, too. Then there's the handoff between initrd and main system. It would be bad if the kernel tried and succeeded to load a module that is not in the initrd just before the modprobe.d directory is set up (because it would be loaded without passing the options the user configured)--so that needs to be avoid= ed. @ludo: Could you help here? > +@example > +options zfs zfs_admin_snapshot=3D1 zfs_trim_extent_bytes_min=3D0 Note: This can be usefully put in a modprobe.d-like directory if zfs is a module,= but not if it's built into the kernel. But it can be put into the kernel comma= nd line in both cases. But I guess the ZFS Linux kernel module can't be built-in into the kernel anyway. But that's a special case--in general, it's very much possible to make modu= les built-in. > + ;; You'd think we could've used kernel-module-loade= r-service-type, Definitely. > + ;; but the kernel-module-loader shepherd service is= dependent on > + ;; file-systems,=20 Yes--but why is that dependent on 'file-systems ? Is it because it needs /p= roc ? Or is it an oversight ? I would prefer to get rid of this dependency and t= hen use kernel-module-loader-service-type. Also, this manual loading of kernel modules is not supposed to be the way to do things in Linux. That a kernel module was compiled as a module is an *implementation detail*--so Linux should (and usually does) automatically load kernel modules the first time a device for them is accessed (after all, how would user space know whether something is compiled as a module or built-in--that would be too much to ask). Linux is not a microkernel, so the kind of modularily modprobe.d suggests exists does not in fact exist in kernel space--even though Linux does a good job faking it: modprobe.d contains: * "alias": a feature to configure aliases, with wildcards (only one level of aliases allowed!) * "options" per module (also works for aliases with wildcards! That will be "fun" to map to Guix) * "install" in order to run some custom executable instead of loading the module. * "remove" in order to run some custom executable instead of unloading the module. * "blacklist" to ignore specific internal aliases of a module (that does not do what one would intuitively think!). If the file name of the regular file under /etc/modprobe.d is not used for anything, then we can just have one file /gnu/store/*modprobe.d/guix.conf in total in there. Then there are sysctl kernel parameters--but those Guix already exposes via sysctl-service-type. But those should also be made able to be extended by other services, and merge conflicts should be handled. For example, use= rs often set net.ipv4.ip_forward=3D1 (for example via sysctl). Thank you for all your effort to make ZFS work nicely in Guix. --Sig_/xXlbAOfUGZoWGj8WvcLyYPd Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl/2Em4ACgkQ5xo1VCww uqX7VQf/bHxCWBZt0FXRb5E0zvb0AZVwMPajkYvOBjfXJC+XcMbgjP3FKNW7VLGK FakRsyWnVX6gtFPxUDImjnCIGcY5LGYuaHxnDR4CTqzDBb06LRAMeJ1YTIyr+j+S ZO17TG4hZa+xWLqM6MUpfEwuc1I/b5o9oN39XJJLJAWJOdXMi2ZGwOKY8dpYhaDw zDPoOb3xHj9oDyXyWjOfb/8VK8bF8+L9Fzy3Bjt2WiG58j5jXpkYz9ZQe3zA1hbH zwFmmKqkFbL2gFhTxGWuQrp6x29T60lzBwUcjG58waCQee23TVFR9K/v7fvjrBal kHMS+9/Dc8FBIdzlHAbxj8/74qYkUQ== =nYdc -----END PGP SIGNATURE----- --Sig_/xXlbAOfUGZoWGj8WvcLyYPd-- From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 06 19:04:16 2021 Received: (at submit) by debbugs.gnu.org; 7 Jan 2021 00:04:16 +0000 Received: from localhost ([127.0.0.1]:45916 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kxIml-0007pL-KF for submit@debbugs.gnu.org; Wed, 06 Jan 2021 19:04:15 -0500 Received: from lists.gnu.org ([209.51.188.17]:32792) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kxImk-0007pE-BS for submit@debbugs.gnu.org; Wed, 06 Jan 2021 19:04:14 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:54282) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kxImj-0007NT-1J for guix-patches@gnu.org; Wed, 06 Jan 2021 19:04:14 -0500 Received: from mail-40135.protonmail.ch ([185.70.40.135]:47327) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kxIme-0004eO-1G for guix-patches@gnu.org; Wed, 06 Jan 2021 19:04:12 -0500 Date: Thu, 07 Jan 2021 00:04:02 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1609977844; bh=d3Ry/xjDaP+dE6gE2ujwfTaJHs3PWHZ1uPkKd4mERVY=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=movietufHyBuzlxm4+HNuyzY07Jp8L1HSwhvFyHXR6tDIX58we/ica2El8hg0Oe8o yh6EiwnKBdBCUk0WSewdsHp7vN/Tgv8HvEqRxYG0dHmyUP33cyxQKAyXbT4H9ktTV7 7OJkgTlWw0KYS+gNcCRO5M2eTKxJWwZdpfrgY0tE= To: Danny Milosavljevic From: raid5atemyhomework Subject: Re: kernel-module-configuration-service for configuring kernel parameters Message-ID: In-Reply-To: <20210106204134.38e83db4@scratchpost.org> References: <6wemXB-PfHUqbuVr5-XRf0-tY4cKGGtKiUqrZPrIZYXoBw17L3xRuZrGOJQfTo5PKfFNCM8KyRTllidoc7asPE2x98BTiJSPVR7OSjxCuw8=@protonmail.com> <20210106204134.38e83db4@scratchpost.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch Received-SPF: pass client-ip=185.70.40.135; envelope-from=raid5atemyhomework@protonmail.com; helo=mail-40135.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit Cc: "ludo@gnu.org" , raid5atemyhomework via Guix-patches via , "45692@debbugs.gnu.org" <45692@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: raid5atemyhomework Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Hello Danny, > See also https://issues.guix.info/issue/42193 for an earlier attempt (whi= ch > is already very far--but it has a bug somewhere). There's also already a > kernel profile thing like you wrote in that patchset. > (Note that I would prefer there not to be a "LOAD?" in there because it > confuses loading the module (which is usually NOT started by user space > but by the kernel on its own) and confguring the module (which has to be > done by user space because it's specifying policy, not mechanism)) Looks like that patchset was merged in, so basically I can just depend on t= hat? So the first patch in this patchset would be dropped? > But I guess the ZFS Linux kernel module can't be built-in into the kernel > anyway. > > But that's a special case--in general, it's very much possible to make mo= dules > built-in. ZFS *can* be built-in to the kernel, Ubuntu does it. You can't distribute i= t like that (Ubuntu distributes it like that but presumably they have enoug= h lawyers to muddy the waters so that they can get away with it), but as th= e documentation in this patch notes: the user has every right to do whateve= r they want on the machine they own, including build a Linux kernel that ha= s ZFS built-in and run it, they just can't make that version available to s= omebody else. So to go whole-hog, we would have a service that replaces the kernel packag= e and inserts kernel module sources in-tree somehow, then compiles Linux-li= bre on the user's machine. That would probably be a lot more painful to ins= tall ZFS with (the user has to recompile the whole kernel at each update of= either kernel or ZFS, whereas with a kernel module the user has to recompi= le just the kernel module), so maybe kernel module is still better overall. > > - ;; You'd think we could've used kernel-module-l= oader-service-type, > > > > > > Definitely. > > > - ;; but the kernel-module-loader shepherd servic= e is dependent on > > > > > > - ;; file-systems, > > > > > > Yes--but why is that dependent on 'file-systems ? Is it because it needs = /proc ? > Or is it an oversight ? I would prefer to get rid of this dependency and = then > use kernel-module-loader-service-type. Dunno --- one VM I tested, I removed the `zfs-scan-automount` shepherd serv= ice from the `file-systems` target, and the VM still wouldn't boot, claimin= g a stack overflow (the same error which I got when I was still trying to u= se kernel-module-loader-service-type here). Or maybe I just got confused w= ith which VM was which, testing VMs wasn't a stress-free vacation. I just = want ZFS, because MD RAID5 ate my homework, this is getting tiresome... One thing I notice about `kernel-module-loader-service-type` is that it's n= ot instantiated in essential services, or indeed anywhere in Guix. A few s= ervices *do* extend it. But my **very rough** understanding is that if you= 're going to extend a service, it had better be instantiated *once* in the = list of services. In particular I note that the documentation for `kernel-module-loader-servi= ce-type` shows an example where it uses `service` to program the `kernel-mo= dule-loader-service-type`, not `simple-service`. This suggests to me that = `kernel-module-loader-service-type` is broken because it's not in the list = of essential services but is extensible. Maybe. It's designed as an exten= sible service, but isn't instantiated at default. Maybe that's what really= bit me and not the shepherd circular dependency loop? *shrug* > > Also, this manual loading of kernel modules is not supposed to be the way= to > do things in Linux. That a kernel module was compiled as a module is > an implementation detail--so Linux should (and usually does) automaticall= y > load kernel modules the first time a device for them is accessed (after a= ll, > how would user space know whether something is compiled as a module or > built-in--that would be too much to ask). So how do I get ZFS loaded? Note that the devices it targets are block devi= ces and it needs to scan for block devices that are formatted for ZFS. Do = other filesystems have some autoload rule? Thanks raid5atemyhomework From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 10 10:47:37 2021 Received: (at control) by debbugs.gnu.org; 10 Feb 2021 15:47:37 +0000 Received: from localhost ([127.0.0.1]:56944 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l9riL-0005i4-JM for submit@debbugs.gnu.org; Wed, 10 Feb 2021 10:47:37 -0500 Received: from eggs.gnu.org ([209.51.188.92]:40212) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l9riK-0005hq-SC for control@debbugs.gnu.org; Wed, 10 Feb 2021 10:47:37 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:45655) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l9riF-0007aK-KR for control@debbugs.gnu.org; Wed, 10 Feb 2021 10:47:31 -0500 Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=43368 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1l9riE-0000l8-Vx for control@debbugs.gnu.org; Wed, 10 Feb 2021 10:47:31 -0500 Date: Wed, 10 Feb 2021 16:47:29 +0100 Message-Id: <87y2fv6i26.fsf@gnu.org> To: control@debbugs.gnu.org From: =?utf-8?Q?Ludovic_Court=C3=A8s?= Subject: control message for bug #45692 MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) merge 45692 45703 quit From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 10 10:48:02 2021 Received: (at control) by debbugs.gnu.org; 10 Feb 2021 15:48:02 +0000 Received: from localhost ([127.0.0.1]:56947 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l9rij-0005il-T4 for submit@debbugs.gnu.org; Wed, 10 Feb 2021 10:48:02 -0500 Received: from eggs.gnu.org ([209.51.188.92]:40306) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l9rii-0005iT-Gb for control@debbugs.gnu.org; Wed, 10 Feb 2021 10:48:00 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:45659) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l9rid-0007jf-9N for control@debbugs.gnu.org; Wed, 10 Feb 2021 10:47:55 -0500 Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=43372 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1l9ric-0000li-SD for control@debbugs.gnu.org; Wed, 10 Feb 2021 10:47:55 -0500 Date: Wed, 10 Feb 2021 16:47:53 +0100 Message-Id: <87wnvf6i1i.fsf@gnu.org> To: control@debbugs.gnu.org From: =?utf-8?Q?Ludovic_Court=C3=A8s?= Subject: control message for bug #45692 MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) merge 45692 45643 quit From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 19 10:38:03 2022 Received: (at control) by debbugs.gnu.org; 19 Mar 2022 14:38:03 +0000 Received: from localhost ([127.0.0.1]:60263 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nVaDT-0000BP-5o for submit@debbugs.gnu.org; Sat, 19 Mar 2022 10:38:03 -0400 Received: from mail-40132.protonmail.ch ([185.70.40.132]:62128) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nVaDQ-0000Av-Q8 for control@debbugs.gnu.org; Sat, 19 Mar 2022 10:38:01 -0400 Date: Sat, 19 Mar 2022 14:37:47 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1647700674; bh=G+fVaO46J5cR3sxO/M4UcdCh44JO7Am1a/9860Om1mw=; h=Date:To:From:Reply-To:Subject:Message-ID:From:To:Cc:Date:Subject: Reply-To:Feedback-ID:Message-ID; b=iTiQYdoUtd0YzPNhiZadpyOucvwn2lx2YWM5MYukICQSCXPqk7l07XodKcN5u+WXu o50OtgddEIZ+wMgV45lub0GO3FSsH0YJgXC69r0meudXPrOdkD/+x2GB+HsJwpLseZ r4ug/wnEULeXV6u93/6XUQSuF+ZbyvNnISymQJYYmumeCEfDSnZMhZ3l62th3gqCq3 i04AQigS9umKtzEO/Oq5EJZOViKoFxhde6+29Y+QIWPF4KefN751VKr+2mzRWb4469 aSPxvfMzpZXb+92m/Ap6UtTDqHkMGrt3mV1LGpPPxIwcj6CspZNNhdSZYqVmSm5HTv c/9wBXU7pccCQ== To: "control@debbugs.gnu.org" From: raid5atemyhomework Subject: (No Subject) Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: close 45692 quit No point: nobody will review or merge anyway. Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 2.0 SLIGHTLY_BAD_SUBJECT Subject contains something slightly spammy 0.0 RCVD_IN_MSPIKE_H5 RBL: Excellent reputation (+5) [185.70.40.132 listed in wl.mailspike.net] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raid5atemyhomework[at]protonmail.com) 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders -0.0 T_SCC_BODY_TEXT_LINE No description available. X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: raid5atemyhomework Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) close 45692 quit No point: nobody will review or merge anyway. From unknown Mon Jun 23 09:40:06 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 17 Apr 2022 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator