Live data from Hacker News

Winding down my Debian involvement

michael.stapelberg.ch

171–180 of 238 posts

Re: Winding down my Debian involvement

#171
post #139

Earlier quoted context omitted.

The move to GitLab was a glimmer of hope that one day I'll be able to help contribute to the project which I'm a heavy user. I wish they went all in and used GitLab Issues for bugs and GitLab CI/CD to auto-build packages for both validation and pushing new packages into the Debian repositories.

I'm not following the situation but what's stopping them from improving their packaging system, except for being complicated?

If the systemd discussion has taught me anything about Debian governance, getting everyone to agree is going to be a pain. Far easier to let it be.

Re: Winding down my Debian involvement

#172

Earlier quoted context omitted.

And unlike most distros which were around back then, Debian is still here today, so it must be good for something . That said, I agree anything Debian (and thus Ubuntu too) and FSF feels awkwardly baroque to work with these days. Old email-based systems, bickering over politics and minor issues rather than the subject at hand, for weeks or months... and no standard CI?!? With all that I too find myself spending my ti…

What is the problem with old email-based systems? This is an honest question.

For FSF and Emacs all bugs, discussions and contribution are handled through email.

Sending patch-files by email and then having to discuss/defend your patch for weeks, only to have to create and send a new one, leaving receivers to diff patch-files to see what is different...

Let’s just say in 2019 you expect something a little more sophisticated to be available to make your contribution easier.

Re: Winding down my Debian involvement

#173

I've been using Debian for over 10 years and I still love it as a user. But as a developer, I find it extremely frustrating. I've several times attempted to figure out how to package my open-source projects [1] [2] for Debian but the process is a nightmare. As I understand it, I first have to find someone with appropriate privileges to mentor me. I should be able to just submit a potential package for review. Then th…

Why not using CMake/cpack? It can generate 100% valid Debian packages and you don't need to do a C++ project, but you can package whatever you want.

I hadn't heard of cpack - it seems like there's not that many projects using it. Do you have any examples? Do the packages pass lintian checks?

Re: Winding down my Debian involvement

#174
post #79
post #21

Earlier quoted context omitted.

Better have fewer high quality bug reports than more low quality reports. The latter just teaches you to ignore them.

It's not just about "low quality" bug reports. The entire system is baroque and messy to use even for experts. I've been using it for 2+ decades now. As a maintainer, I frequently needed to change bug tickets. Tags, versions, dependencies, and other details. All need doing through the control@ email interface. Changes can take over half an hour to be processed and acknowledged. It's inefficient and tedious, and prone…

Why download the mbox? Don't bugnumber@bugs.debian.org work?

Re: Winding down my Debian involvement

#175
I have a naive question (I'm a long time Debian user, but never really tried to contribute): why isn't all the Debian in a single git repository? I'm not suggesting to vendor all the third party code but only all the packaging information, like, say, libreelec does (and I assume many others)

Re: Winding down my Debian involvement

#176
post #49

Earlier quoted context omitted.

> but random strangers not being allowed to push updates to my operating system in 5.34 seconds doesn’t sound all bad. To me. So that's what the frustrating to maintainers crumbling infrastructure and crappy tooling are for. Now it all makes sense! Actually, I'd very much prefer quickly pushed updates in case of severe security issues. Debian had lots of really ancient packages with problems in "stable" last time I l…

If there's a severe security issue, Debian will quickly push an update containing a backported version of the fix, assuming you have the debian-security repository enabled (which you should). Just because the version number on the package is old doesn't mean it's insecure. https://www.debian.org/security/faq#oldversion

The problem is: what defines a security issue. A developer (more often then not) doesn't know if a fixed bug could have lead to a security issue.

Re: Winding down my Debian involvement

#177
post #42

Earlier quoted context omitted.

You should try patching Debian packages. I too am an outsider, but I have had to modify Debian and it's brutal; every package is different and the number of entry points into the tooling is mind boggling. I have bugs I've never filed over years because I don't understand the particular packages process.

I'm sure it's true, all I'm saying is that if you reach the point of walking away, just walk away. A list of grievances at that point is just going to be seen as a parting shot rather than having any real chance of motivating change.

I think posting publicly has the advantage that other projects can cite this when having discussions of how to set up their infrastructure.

Re: Winding down my Debian involvement

#178
> Gmane used to paper over this issue, but Gmane’s availability over the last few years has been spotty, to say the least (it is down as I write this).

The Gmane web interface is not just down but shut down for good: https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/com...

So this issue won't get better without Debian doing something themselves.

Re: Winding down my Debian involvement

#179

I've been using Debian for over 10 years and I still love it as a user. But as a developer, I find it extremely frustrating. I've several times attempted to figure out how to package my open-source projects [1] [2] for Debian but the process is a nightmare. As I understand it, I first have to find someone with appropriate privileges to mentor me. I should be able to just submit a potential package for review. Then th…

> Then there is a ton of documentation on creating packages but which 300 page guide is the right one to use is unclear. And which set of packaging tools should I use? I've run into the same problems, though I've only wanted to build packages for my own use, or company-internal use. I think I've understood now how packaging is supposed to work, and have written a guide, shameless plug: http://leanpub.com/debian/c/hn…

> feedback would be appreciated

I'm just looking through it, for me looking through the epub version the layout is broken (at least viewing using Adobe Digital Editions), apparently every time there's a yellow block with code.

"1.1 Target Audience and Prerequisites" is the first example but I keep finding more.

Re: Winding down my Debian involvement

#180
post #138
post #110

Earlier quoted context omitted.

Try macports for a BSD style packaging for the mac.

What's the advantage of using macports over Homebrew?

For example proper runtime dependency management?

Try updating a single homebrew package to a new major version and watch the other homebrew packages depending on it breaking.

To be fair, that's not a problem unique to homebrew. Gentoo used to break runtime dependencies, too. Although that was a long time ago. Nowadays libs used by other programs are preserved and only deleted when all dependencies have been updated, so breakage no longer occurrs.

Post reply on HN