{"slug": "quiltops-continuous-packaging-for-your-patches", "title": "QuiltOps – Continuous packaging for your patches", "summary": "QuiltOps, a new infrastructure tool for maintaining user-customized patches against upstream Debian packages, has been launched by an individual developer. It automatically builds patches, publishes them to a personal apt repository, and keeps them building against new upstream releases. The developer believes AI will make software more horizontal, enabling more people to customize their own software stacks.", "body_md": "Continuous packaging for your patches.\n\n*\nsexy robot AI voice: *QuiltOps is a platform for pushing the envelope of distributed development back towards the user. Everyone can fork. Almost nobody 1 can maintain a fork. QuiltOps fixes that.\n\nbut seriously, QuiltOps is an infrastructure tool for maintaining user customized patches against upstream Debian packages.\n\nYou write patches. QuiltOps builds them, publishes them to a personal apt repo, and keeps them building against new upstream releases automatically.\n\nIt is not an AI product. You write the patches however you want. Crafted by hand, with AI, or by bribing someone. This system exists to ensure your patches stay deployed alongside upstream code automatically and to give a good framework for doing it.\n\nIn some ways I consider this the antithesis of new-fangled \"skip the lessons we learned and invent our own package manager\" I see with NPM and others. Instead we are going to lean into, and respect and trust our beloved system maintainers, and instead of having boatloads of binaries in /home/, we're gonna ship them like real packages.\n\nMy bet: AI is going to make software much more horizontal. Less cathederal and more bazaar. It's something a lot more will people actually do.\n\nHey Claude - can you update xpdf to support pdf2teletubby?\n\nSure, theres the patch.\n\nRight now, programming is rapidly becoming not expert work. Soon we could all be running (i think this unironically) practically our own distros if we want. Total customization of the stack.\n\nI really feel that one positive thing AI can do is drive labor costs down enough to allow personal choice in the software we use. We have open source software, but it's channelized and controlled by a few companies who fund projects! That might change too!\n\nAI can simply One Shot a lot of small problems i have. Like reading unfamiliar codebases, finding the relevant function, and writing the delta. The gap between \"I want bash to do X\" and \"here's a patch\" is shrinking fast. When that gap closes, a lot more people are going to start customizing their software - but we don't have a great wrapper for it yet.\n\nThe part that doesn't get easier is everything after. How many 'forks' exist on github but people havent had time to maintain, or worse, are being used in production with bugs? How much code have we lost out because of that? Do forks really help us? I don't know. Does everyone want to use shitlab? I don't know.\n\nBuilding the package. Getting it on your machine or out to the fleet. Keeping it there when upstream ships a security fix.\n\nThat's an infrastructure problem, not an AI problem I needed a way to solve it now\n\nQuiltOps is that little bit of software infrastructure i need . built now, for the world where i am right about my bet.\n\nPatches, quilt, apt repos, it's all already there for a discerning individual with the time to play. This isn't novel technology. QuiltOps is to patches what GitHub is to git: the same underlying thing, minus the part where you spend your afternoon writing glue scripts and repenting to mechanical overlords.\n\nI keep... hundreds of patches around. Hundreds of source repos that aren't even patches, just git checkouts. I use this software every day. Over the years the list has gotten enormous. quilt is great, actually, so much of this already exists, serving repos, building packages, getting packages from upstream. it's stuff that exists in bits and pieces. Launchpad's been around forever. There's very competent tooling from debian for building packages, now i want the full package cycle.\n\nSo my goal with this is really selfish, part of my bet coming true, that i can write a standalone service for myself just to manage my own patches... but why not share it? or make it 'realer'. Maybe you will have a patch you manage on quiltops of my quiltops package.\n\nOne inspiring source for me is /n/contrib. After Plan9 gained a following, or maybe before, but after there stopped being upstream, the plan9 universe folded and folded. There were distributions of One (Ants), distributions of some (9front), distributions of none (9legacy?)... I don't know but the point is you had a place you could share your patches and code with other people but everyone was kind of manually pulling patches in or doing what they wanted. Plan9's code base is small enough that you can hack on it with a bit of C and shell skills (rc) and get very far. Most plan9 setups I know are part of a diaspora, and almost all are customized in one way or another.\n\nAnother source of inspiration are the dedicated individuals and maintainers who we owe our lives and at least some of our hearts to. I am inspired by Launchpad, AUR user packages, the OpenSUSE build system, Copr, etc.\n\nPortage basically has a very similar feature for user patches, but hey - thats gentoo for you. I want that but for binary packages and automated builds and some tooling. thats all!\n\nShould we start writing tons of AI generated, or user generated, or whatever, patches for other systems, it might be quite nice if we could share them. I think quiltops could be used to do that if we can share our patches into O.P.P. its like /n/contrib but Other.Peoples.Patches. Anyway its kind of an idea of where this could go. You could pull other patch sets in and roll them on top of your own, and still be getting upstream changes\n\nwithout quiltops:\n\nwith quiltops:\n\nI worked at a place that used debian on a fleet of servers. We also had many packages we wrote and maintained and distributed. But we also had some that were upstream+patches. With the rate of 0days hitting, I feel like this type of tooling could be useful. I also know hosting your own debian repos can be a slight pain in the but and you end up writing plenty of glue to get that up, running, and lights on.\n\nWhen you run a custom package today, you are making a silent tradeoff: your modification or upstream's fixes. Most people quietly fall behind.\n\nQuiltOps watches the Debian package index. When upstream ships a new version — a CVE patch, a bug fix, anything — QuiltOps rebuilds your package against it automatically.\n\nIf the patch applies cleanly, you hear nothing. Your apt repo just has a new version. If it does not apply, you get an email with the full build log. Your old version stays live until the new one builds clean.\n\n```\nDay 0     you push 0001-sqlite-history.patch for bash\n          QuiltOps builds bash_5.2-3+qo1, publishes to your apt repo\n\nDay 83    Debian ships bash 5.2-4 (CVE fix)\n          QuiltOps detects new version, enqueues rebuild automatically\n\nDay 83    patch applied clean, bash_5.2-4+qo1 published\n+5min     you hear nothing; apt upgrade gets you the fix\n```\n\n`qo push`\n\ntriggers a build. The server fetches upstream, applies your patches, and runs dpkg-buildpackage.\n\n``` php\n$ qo init\n-> created quiltops.yml, patches/, CLAUDE.md\n\n$ qo build bash\n-> fetching bash 5.2-3 from bookworm...\n-> applying 0001-sqlite-history.patch...\n-> built bash_5.2-3+qo1_amd64.deb\n\n$ qo install bash\n-> dpkg -i bash_5.2-3+qo1_amd64.deb\n\n$ qo push\n-> pushed . build queued on quiltops.dev\n\n$ qo status\nbash    [ok]  5.2-3   built 2h ago\ni3      [!!]  4.3-2   patch failed -- run 'qo log i3' to see why\nxpdf    [ok]  3.04-3  built 1d ago\npackages/\n  bash/\n    quiltops.yml        # upstream source, suite, patch list\n    patches/\n      0001-sqlite-history.patch\n  i3/\n    quiltops.yml\n    patches/\n      0001-ewmh-desktop-window-type.patch\nquiltops.yml            # repo-level config\nCLAUDE.md               # AI context for patch rebasing\n```\n\nThe starter repo ships a CLAUDE.md that gives >your AI tools< enough context to fix a failed patch immediately. No I dont have any funding and im not putting my credit card on anthropic for you. Your inference needed — you bring your own AI.\n\n`qo push`\n\nis a git push in a trench coat.| Plan | Price | Notes |\n|---|---|---|\n| Self-Hosted | Free | Full source, bring your own compute, unlimited packages |\n| Hosted | Free? | I can't imagine someone would pay for this! maybe! |\n| Team (hosted) | TBD | Would anyone actually pay for this? If so,\n|\n\nquiltops.dev —\n[source](404.html) —\nIRC: #quiltops on libera.chat", "url": "https://wpnews.pro/news/quiltops-continuous-packaging-for-your-patches", "canonical_source": "https://quiltops.dev/", "published_at": "2026-08-09 23:30:32+00:00", "updated_at": "2026-08-10 00:05:05.687809+00:00", "lang": "en", "topics": ["developer-tools", "ai-infrastructure"], "entities": ["QuiltOps", "Debian", "GitHub", "Launchpad", "Plan9"], "alternates": {"html": "https://wpnews.pro/news/quiltops-continuous-packaging-for-your-patches", "markdown": "https://wpnews.pro/news/quiltops-continuous-packaging-for-your-patches.md", "text": "https://wpnews.pro/news/quiltops-continuous-packaging-for-your-patches.txt", "jsonld": "https://wpnews.pro/news/quiltops-continuous-packaging-for-your-patches.jsonld"}}