Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Debian Packages That Need Lovin'

wnpp.debian.net

Post reply on HN
Print view View original

131–140 of 151 posts

Re: Debian Packages That Need Lovin'

#131

Post by qpiox »

rjsw wrote: post #87
qpiox wrote: post #54

Earlier quoted context omitted.

Why would you need a package for Eclipse. Download it is a ZIP, extract it in the location of your choice and run it from there. (Portable app) I have been using it like that almost every day for 15 years now.

Eclipse isn't portable, somebody has to compile it for Linux, it just comes down to whether you want that done by the Eclipse Foundation or Debian people.

The discussion here was about why a debian package for Eclipse is not up to date.

My theory is that it is obviously because there is a way how to run Eclipse, without any issues and without the need of an officially tested debian package, so there is not huge demand.

Re: Debian Packages That Need Lovin'

#132

Post by joana035 »

BiteCode_dev wrote: post #101

Packaging for debian anything non trivial is damn too hard. It took me 5 days to figure out how to package a complete web app with params, upgrades, post install transpiling, db init, etc. And I haven't put that on a private repo yet, it's yet another annoying thing to do. Nothing is well documented, doc is old and confusing, the tooling is archaic and wants to inflict pain (debconf anyone ?), the life cycle of a Deb…

Well, just me finding it a joy to work with? All the dh helpers that basically does the hard work, I just need to update one or two things in control file and that is it.

I have packages closure, Java, python, php, c and very complex piece of software with weird version formats and so far Debian packages cover all those cases for me.

I find that is pretty easy to complain about things we don't know, or rant when frustrated, but after investing a bit o time to learn and understand how it works pays off.

Re: Debian Packages That Need Lovin'

#133

Post by mixedCase »

gautamcgoel wrote: post #100
loudmax wrote: post #66

Earlier quoted context omitted.

I installed Arch Linux on a ThinkPad in 2011 and it's literally running the same OS today, nearly 10 years later. I won't say I've never had anything break, but never anything major like audio or video or wifi. In my experience, Arch is one of the most stable OS's I've seen. But I suspect a lot of it has to do with what you're doing with it. First, ThinkPads are generally well supported in Linux. Also, I've never see…

I've been thinking about leaving Fedora and your comment intrigues me. Does Zoom work well with i3? Can you share your screen? Regarding PulseAudio, I didn't realize Linux users had a choice about whether to use it - is there an alternate audio subsystem available?

You've already been told about ALSA (which Pulse uses and organizes, for its the low-level audio subsystem the kernel offers) and Jack, which specializes in low-latency audio. There's also sndio ported from OpenBSD.

But the one you might want to consider instead is called PipeWire. It implements the ALSA, Pulse and Jack APIs with a single implementation and it's pretty much the future of audio (and video casting) on Linux.

If you're using Wayland, you're already using PipeWire, but likely not for audio. On Fedora you can follow the instructions here https://fedoraproject.org/wiki/Changes/DefaultPipeWire which basically boil down as "uninstall pulse and install these packages" and you'll be using PipeWire for your audio.

I had tried several times to switch to it and it was not ready, but about a week ago I've been able to make the move with no loss in functionality and even got a fix to an old bug that affected my sound card, so at least with version 0.3.22 I can recommend giving it a go. Switching back to Pulse if bugs arise is trivial anyway.

Re: Debian Packages That Need Lovin'

#134

Post by jonathankoren »

notatoad wrote: post #59
jonathankoren wrote: post #53

Looking at orphans by installs and I remember using some of these 20 years ago, but do people even use libgpod and xmms anymore?

that's my first reaction to this list too - is a debian-specific package really providing more value than the effort of maintaining it for a lot of this software? even libgpod and xmms are relatively high-profile examples. i do appreciate being able to apt-get install some obscure package and have often wondered how it's a sustainable system that maintainers are putting in effort to package these things up into a dis…

I wonder if the install base is is so high because 20 years ago some package maintainer decided to put XMMS in a gnome-apps (or whatever) metapackage, and no one removed it.

I don’t even know the last time I found a publicly accessible mp3 url stream, or listened to a local mp3 file. Local files had to be like 10 years ago.

Re: Debian Packages That Need Lovin'

#135

Post by bfrog »

BiteCode_dev wrote: post #101

Packaging for debian anything non trivial is damn too hard. It took me 5 days to figure out how to package a complete web app with params, upgrades, post install transpiling, db init, etc. And I haven't put that on a private repo yet, it's yet another annoying thing to do. Nothing is well documented, doc is old and confusing, the tooling is archaic and wants to inflict pain (debconf anyone ?), the life cycle of a Deb…

Creating arch or nix packages is a breeze in comparison. I'd argue nix is what everyone wants whether they know it or not. All this container junk is a recipe for disaster.

Re: Debian Packages That Need Lovin'

#136

Post by slavik81 »

qpiox wrote: post #129
slavik81 wrote: post #89

Earlier quoted context omitted.

That does seem like it would be a sensible way of going about things if I could manage to find a package of modest complexity that is important to me, but under-maintained.

Maintaining a package is not as hard as developing software. You don't need to know algorithms, you don't need to know programming, you just need to know how to start a compiler and packaging software from the command line and read errors from the log. If you are an active developer in the language that is used it will be easier, but you can do it even if you are not. Example. Todays news here, is the latest release…

Thank you. That is useful information.

I'll also have to find something my employer is happy with me working on, but I think you've pretty clearly laid out what I'd be signing up for, and I appreciate it.

Re: Debian Packages That Need Lovin'

#137

Post by loudmax »

gautamcgoel wrote: post #100
loudmax wrote: post #66

Earlier quoted context omitted.

I installed Arch Linux on a ThinkPad in 2011 and it's literally running the same OS today, nearly 10 years later. I won't say I've never had anything break, but never anything major like audio or video or wifi. In my experience, Arch is one of the most stable OS's I've seen. But I suspect a lot of it has to do with what you're doing with it. First, ThinkPads are generally well supported in Linux. Also, I've never see…

I've been thinking about leaving Fedora and your comment intrigues me. Does Zoom work well with i3? Can you share your screen? Regarding PulseAudio, I didn't realize Linux users had a choice about whether to use it - is there an alternate audio subsystem available?

I never had any problem with Zoom on i3, but I never tried to share my screen.

Zoom on sway works, but since sway runs on top of Wayland and Zoom doesn't have the bindings to communicate with Wayland, I'm fairly positive screen sharing would not work. At least, not out of the box ... it might be possible to connect it to some other screen capture process if you're adventurous.

PulseAudio runs on top of ALSA. Traditionally, Linux desktop applications connect with ALSA and you can still manage ALSA directly. More recent applications, such as Zoom, expect to connect with Pulse and don't support connecting directly to ALSA.

From a user perspective, Pulse offers some advantages like being able to manage audio levels for different applications independently. In early releases, Pulse was unstable and difficult to troubleshoot, so it was easier just to use ALSA directly. Pulse has gotten a lot better in recent versions.

Re: Debian Packages That Need Lovin'

#138

Post by [deleted] »

afiori wrote: post #113
cauthon wrote: post #92

Earlier quoted context omitted.

I think of "gatekeeping" as blocking access, especially for something that doesn't have a defined membership, like a fandom. e.g. "you're not a real star wars fan if..." whereas anyone is welcome to contribute to debian, they just have to follow the rules. there's kind of no meaning to the term "gatekeeping" if any organization that has rules to follow counts.

gatekeeping is used as pejorative in those cases, where no gate ought to be. for example in at least one email Linus claims that forbidding C++ in the kernel was also to exclude C++ developers, whether he was right or wrong that is another case of gatekeeping

[deleted]

Re: Debian Packages That Need Lovin'

#139

Post by monoideism »

LordDragonfang wrote: post #91
monoideism wrote: post #84

Earlier quoted context omitted.

Debian is one of the distros that really takes package security seriously, which is a big plus for me. > It comes from an even older gatekeeping around "the Unix way". That's not gatekeeping, that's a very specifically-defined approach to operating systems.

I understand if you're taking issue with the term as a pejorative, but how is purposefully placing barriers for those that don't conform to the "specifically-defined approach" not definitionally gatekeeping?

If you actually believe that, then all software specs are "gatekeeping".

But you do realize that I'm objecting to its use as a pejorative here.

Re: Debian Packages That Need Lovin'

#140

Post by rjsw »

qpiox wrote: post #131
rjsw wrote: post #87

Earlier quoted context omitted.

Eclipse isn't portable, somebody has to compile it for Linux, it just comes down to whether you want that done by the Eclipse Foundation or Debian people.

The discussion here was about why a debian package for Eclipse is not up to date. My theory is that it is obviously because there is a way how to run Eclipse, without any issues and without the need of an officially tested debian package, so there is not huge demand.

That would be fine if Linux preserved backwards compatibility, the glibc version change last year meant that some binary packages no longer run.

Something like Netbeans doesn't need a debian package but Eclipse is split into lots of jar files that each depends on some shared libraries.

Post reply on HN