121–130 of 238 posts
I used debian for over 10 years and never managed to contribute anything. 10 Minutes after using homebrew for the first time I sent in a PR to update a package to the latest version and update the built dependencies.
Seems to me like either snap or Homebrew Linux are the way to go. ArchLinux also has a reasonable packaging experience.
Instead, currently, all packages become lint-unclean, all maintainers need to read up on what the new thing is, how it might break, whether/how it affects them, manually run some tests, and finally decide to opt in. This causes a lot of overhead and manually executed mechanical changes across packages. I always wondered if Debian/Ubuntu could benefit from a "monorepo". It seems to work for other distributions, e.g. A…
I don't think it necessarily needs a monorepo, but having every package on Salsa (Debian's GitLab installation) would help.
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've been using Debian / Ubuntu for many years, as much due to inertia and familiarity as anything else. And I have a lot of respect for the project. If I wanted to start being a contributor to a distribution, which one would be the best to dive in to?
I tried to contribute a package to Fedora once upon a time...gave up in frustration after a while since it went nowhere after a bit of hoop jumping.
Earlier quoted context omitted.
Debian hasn't used mailing lists for reporting bugs since the 90s: https://en.wikipedia.org/wiki/Debbugs
Debbugs is basically a mailing list.
The new problem is that new people hate emails. I think the merit of this problem is debatable.
Earlier quoted context omitted.
No, it assumes that quality ratio varies by reporting mechanism. 9 good reports and 1 bad report are better than 18 good reports and 82 bad reports.
That's subjective - I would much rather spend a few minutes sorting out the 82 bad ones than miss 9 good reports. (Actually, I would much rather have 18 good reports and spend several minutes trying to see if there's anything of value in the 82 bad ones: see for instance the high-school kid who found the Apple FaceTime vulnerability and who couldn't figure out how to report it.) One of the principles of the Debian So…
I love Debian as a user. I considered becoming a DM then DD -- I read all the relevant documents and tested water with maintaining a package I used -- but ultimately gave up due to the bureaucracy and politics involved. The last straw was this: https://lwn.net/Articles/704608/
The Arch User Repository ( https://aur.archlinux.org/ ) seems to solve a lot of the collaboration issues. It is pretty painless to create PKGBUILD files to make a package and to upload a new one to the AUR. Most maintainers read the comments and accept patches on a timely manner, and there's even a way to forcibly relinquish a package if a maintainer is AWOL for significant time. On the other side of the spectrum, I'…
Yo! Trusted user from Arch Linux. >On the other side of the spectrum, I've found that the official binary repositories for Arch Linux suffer many of the same issues described in the article for Debian. Patches being ignored and collaboration or involvement being near impossible. Well, we still relay on svn internally so things are complicated to say the least. Even if we had things on git (which we are working on), I…
I'd rather not, the thing in question was around three years ago and I don't think I even have my AUR PKGBUILD for comparison. It wasn't a cry for help, and I'm not naming packages or individuals for a reason. Just voicing some frustration at the process.
Earlier quoted context omitted.
For next time: dpkg -S path/to/file gives the the name of the package containing a file, and dpkg -s package-name gives you the name of the maintainer.
> dpkg -S path/to/file In the case of config files, this only seems to work sometimes -- maybe if it wasn't modified by the user? Or if it came from a package directly, and wasn't generated from its {pre,post}inst scripts? $ dpkg -S /etc/hosts dpkg-query: no path found matching pattern /etc/hosts $ dpkg -S /etc/resolv.conf dpkg-query: no path found matching pattern /etc/resolv.conf $ dpkg -S /etc/bash_completion bash…
Earlier quoted context omitted.
Likewise for the BSD ports. There are advantages to both ways. However, a single repository permits changes to multiple packages in a single change. In Debian, simple transitions which affect multiple packages can take months or even years to fully propagate through the entire system. Not due to technical difficulty, but the logistics of coordinating the change. Debian's approach made sense at the time. Developers wh…
We've had CVS for years.
Earlier quoted context omitted.
Debbugs is basically a mailing list.
The original problem with reporting bugs to a mailing list was mails for many bugs were mixed and you couldn't easily get the state of individual bugs. Debbugs, by automatically creating a new mailing list for individual bugs, does solve this problem admirably. The new problem is that new people hate emails. I think the merit of this problem is debatable.