On Thu, Jan 31, 2019 at 02:02:34 -0500, Mark H Weaver wrote: > reopen 34176 > thanks > > Hi Mike, > > Mike Gerwitz writes: > >> On Tue, Jan 29, 2019 at 07:14:15 -0500, Mike Gerwitz wrote: >>> reopen 34176 >>> thanks >> >> I guess I don't have permission to do this, since nothing happened. Can >> someone do this for me? > > No permission is needed, but it must be sent to the correct address. It > must be sent to . I add that address to the > BCC header when including such commands. Ah, that explains it. I saw control@debbugs.gnu.org in the debbugs documentation, but looking at past commands on this list (e.g. from you), I didn't see it CC'd, so I thought maybe it wasn't necessary. >> Alternatively, if this seems outside the scope of something we'd want to >> track in Guix, just leave it closed. > > I'm glad to have it in our tracker. Thanks. Hopefully it won't persist for too long. > FWIW, unless someone has a better idea, my recommendation would be to do > a binary search on the kernel versions, to find which version introduced > the problem. That's what I was going to do originally, except I hadn't had the time to research the best way of doing this in Guix. I did see a kernel system configuration option, but I thought that looked more like specifying Linux or Hurd (the default value is `LINUX-LIBRE'), not the specific kernel version. What's the proper way to go about doing this on GuixSD? Sorry if that's clearly documented and I just missed it. > If 4.18.20 works and 4.19 fails, then it will probably be necessary to > do a "git bisect" on the upstream kernel git repository between those > two versions, to find the commit that introduced the problem. If it > comes to this, let me know and I'll help you find a way to do this > efficiently. This is another situation where my unfamiliarity with Guix is the difficult part. I'm comfortable compiling Linux, but I'd need to figure out how to actually boot to it. -- Mike Gerwitz