kyrofa

Joined 9 years ago

Karma

447

Submissions

161

Member since

Apr 5

kyrofa is a husband, father of seven, roboticist, and a prolific open source software developer. Contributor to Ubuntu, Nextcloud, versions 1 and 2 of the Robot Operating System (ROS), as well as the snapcraft CLI and snapd, two key technologies behind snaps and Ubuntu Core.

kyrofa's day job is at Miriam Technologies, a software consulting company. In the past he's worked as a staff engineer for Canonical (the company that publishes Ubuntu), and as a roboticist for the US Department of Defense.

View on Hacker News

Recent submissions

Comment · 17 days ago

Open models are just as quick to refuse to do stuff, in my experience.

How to Use RubyGems Trusted Publishing with Semantic Release kyrofa.com

3 kyrofa 1 month ago 0 comments

Comment · 2 months ago

To be clear, I'm not trying to argue or disagree with you. I agree that PPAs are a fine option. I'm not trying to disparage them, I'm trying to explain the reasoning behind my suggestion: PPAs enforce a number of requirements that exist for a reason, but that can be a challenge to meet depending on the project. The biggest example is that of source packages. I don't mean "your source needs to be open" (which of course this project is), but rather "your software needs to be built on Launchpad infrastructure." If you take a look at the existing CI the maintainer has in place to build the binary deb, you'll see what I mean: https://github.com/sinelaw/fresh/blob/master/.github/workflo... . The maintainer already has this, and it would need to be completely re-done to make it work in Launchpad, and the amount of work might be quite significant. A standalone Debian repo can just have binary debs, i.e. the work that has already been done can continue being used.

Thus my recommendation for aptly/reprepro: it's a more natural extension of what the project already has in place rather than a "you should do this instead."

Comment · 2 months ago

Yeah, the one thing you're missing is getting into the users' `apt update`/`apt upgrade` flow, right? This will get you there without needing to change the Debian package you already create (although you can ship different ones this way if e.g. older Ubuntu/Debian distros require it and you want to support them).

Comment · 2 months ago

Of course. Needing to ship a source package (as PPAs require) may actually complicate things, though.

Comment · 2 months ago

Oof, yeah that's painful. I'm impressed you've gone to these lengths, most maintainers don't do that. They generally rely on the folks who want to use the software packaging it for their distros. Obviously there's a bit of a chicken and egg problem there, though, if you care about getting your software in front of users.

For the Debian situation specifically:

> It would've been nice if there was a quick serverless solution where you could just say a URL to look for newer versions of a single package, and both apt and dnf would remember that and update a package.

Have you considered just hosting your own Debian repo? It's basically what you're looking for here. You don't need more infrastructure, either, you can host them straight in github pages with aptly or reprepro or something, and drop new releases in there from CI.

Comment · 3 months ago

My wife is a professional photographer and Darktable is a critical part of her editing workflow. It's a truly outstanding piece of software.