!VDkVpTIBBGpmIsMKTP:matrix.org

Development (linux-surface)

48 Members
Development for Linux on Microsoft Surface | https://github.com/linux-surface/linux-surface10 Servers

Load older messages


SenderMessageTime
27 Feb 2024
@qzed:matrix.orgqzed it does create a separate commit, but rebase --autosquash picks it up 22:33:15
@tmsp:matrix.orgDorian Stoll because if I have history A -> B -> C, I can't squash C into A because it depends on B 22:33:23
@tmsp:matrix.orgDorian Stoll (which is also what we do by splitting comments into patchsets) 22:33:43
@tmsp:matrix.orgDorian Stoll The other solution is that we carefully craft the camera patch to not depend on the ipts patch even though both modify the same file 22:34:14
@qzed:matrix.orgqzeddepends on what C does specifically and how much it changes... if there's a conflict you can still resolve it manually22:34:24
@qzed:matrix.orgqzedwhich you'd have to do once, and then it should be fine again22:34:38
@tmsp:matrix.orgDorian Stoll thats the patch that I mean btw: https://github.com/linux-surface/kernel/commit/eb19f5e13f14a8973920d406125f205945558fb9 22:35:35
@tmsp:matrix.orgDorian Stoll its full of ipts stuff because both essentially do the same 22:35:46
@qzed:matrix.orgqzedI still thing that it should be possible to address this just like a merge conflict during rebase22:37:38
@qzed:matrix.orgqzedI know it's annoying, but you have to do it basically only once... and the alternative is that we just rebase everything all the time, which I feel like might just be more confusing down the line when we try to look back and figure out what we've done half a year later22:38:37
@tmsp:matrix.orgDorian Stoll yeah, true 22:39:08
@qzed:matrix.orgqzedmain reason why I'd like to keep the history as-is (inside the major version devel branches) is so that we have some clues as to what we did22:40:15
@qzed:matrix.orgqzedand for each new major version we can start fresh with a cleaned up version22:41:36
9 Mar 2024
@tmsp:matrix.orgDorian Stoll qzed: something to consider: when should we stop building our debian packages on ubuntu 20.04? when 24.04 comes out? 20:56:35
@qzed:matrix.orgqzedhmm, good question20:57:00
16 Mar 2024
@tmsp:matrix.orgDorian Stoll qzed Are you already working on 6.8? 20:52:05
@tmsp:matrix.orgDorian Stoll Planned to do the rebase right now but figured I would ask so we don't step on each others toes 20:52:21
@qzed:matrix.orgqzedhaven't started yet20:52:31
@qzed:matrix.orgqzedhad it planned for later this evening or tomorrow, but if you're already on it feel free to do it20:53:30
@tmsp:matrix.orgDorian Stoll I'll do it 20:57:34
@qzed:matrix.orgqzedthanks!20:58:32
@tmsp:matrix.orgDorian Stoll Side note: Idk when or why that changed, but at this point git clone is a pretty good stress test for the surface xD 21:37:24
@tmsp:matrix.orgDorian Stoll Pushed the updates and launched some test builds 21:54:43
@qzed:matrix.orgqzednice21:56:47
@tmsp:matrix.orgDorian Stoll Do we remove the 6.1 patches since 6.6 is the new LTS? 21:57:41
17 Mar 2024
@qzed:matrix.orgqzedIf Arch already switched I think we can remove them 07:21:51
@tmsp:matrix.orgDorian Stoll Had to drop the old anbox patches we applied to the debian builds because they would no longer build 11:33:12
@tmsp:matrix.orgDorian Stoll And then decided to just put all the binder stuff into vmlinux so that we dont need any hacks to make it build as a module 11:34:18
@qzed:matrix.orgqzedI usually just check if they updated those patches and pull in the new ones from https://salsa.debian.org/kernel-team/linux/-/tree/master/debian/patches/debian13:18:11
@tmsp:matrix.orgDorian Stoll Ah, I just checked the ubuntu packages 13:18:57

There are no newer messages yet.


Back to Room ListRoom Version: 6