Focal Testing of Kubuntu 20.04 LTS

[kubicle]

Even github can be setup for automatic building and releasing various methods of distributing (deb, rpm, appimage etc) that a particular project may need without much continued effort for the dev (there would be some as the project changes and the setup needs to be changed accordingly and the initial outlay of effort, but in between it's fairly stable and automatic).

Absolutely. But the issue is not really about providing (automatically or not) built binary packages (which isn't too hard to accomplish), this is not really quite the same effort as providing detailed building instructions for every distribution imaginable, finding out which packages need to be installed in every distribution, and making sure the packages in distributions are not too new or old that your software is actually able to build on these, and do this 24/7 to the end of days while constantly rewriting your readme.txt for all of the changes (and to do this for the maybe 20 users who are actually building it from source themselves is a massive waste of effort).

Otherwise I do not disagree with you.

[WWDERW]

Absolutely. But the issue is not really about providing (automatically or not) built binary packages (which isn't too hard to accomplish), this is not really quite the same effort as providing detailed building instructions for every distribution imaginable, finding out which packages need to be installed in every distribution, and making sure the packages in distributions are not too new or old that your software is actually able to build on these, and do this 24/7 to the end of days while constantly rewriting your readme.txt for all of the changes (and to do this for the maybe 20 users who are actually building it from source themselves is a massive waste of effort).

Otherwise I do not disagree with you.

Providing automatic builds would, in my mind, make the need for detailed build instructions moot. There might be some differences between master and this or that pull request, but I wouldn't consider that something worry about. Certainly not for the "normies" that might otherwise need that extra help with regard to the build instructions.

[kubicle]

Providing automatic builds would, in my mind, make the need for detailed build instructions moot

I do not disagree. But I'll remind you that the statement that started this discussion was that (paraphrasing):
"The RULE is that *All developers* should put detailed instructions (in the every piece of software they develop) *in the README.TXT* that tells me what packages I need to install on my distribution to build their software".
And all I have tried to do is explain why that isn't a rule, or at least not one that makes any sense from any productivity-perspective.

[GreyGeek]

...

I can definitely see both sides to this (and I have developed software as well, although some people would probably call it lazy developing as it is with the Electron framework and not plain jane C++ or similar). And there is for sure a difference in the naming schema of packages between distros (one package that I get for mapping my drives on ubuntu its "x"-common and on say Arch it's "x"-utils.

I haven't coded a line since I retired in 2008, but before then I was using Kate and Kdb to develop client-server applications that would eventually be compiled on a WinX box and put on a WinX server, running against an Oracle db. Since I was using the Qt API I would use the Qt Designer to build wysiwyg windows and dialogs, but everything else was written using Kate. If anyone wants to call that "lazy" programming they'll have to show me their equivalent code written in ASM, or "better" yet, machine language.

**wanders off to look up the Electron framework ...

[WWDERW]

I do not disagree. But I'll remind you that the statement that started this discussion was that (paraphrasing):
"The RULE is that *All developers* should put detailed instructions (in the every piece of software they develop) *in the README.TXT* that tells me what packages I need to install on my distribution to build their software".

No, not even all developers. I would say that if the developers meet 2 criteria they should have automatic builds available in the repo of their software:

1. They want their software to reach the widest audience. In other words, they just didn't develop the software to scratch an itch and they released it hoping that others could benefit from it. They really wanted a high adoption.

and

2. There aren't compiled versions of their software in the repos of a distro. While yes, the repos may be outdated depending on the distro, they are still there.

If both of those conditions are met, then I would say something needs to be on there. That's just me. If it's not, I just move on.

Oh, I should also mention those that want to have a commercial, but open source product, I wouldn't fault them for having a less in the build documentation and/or releases in the repo. That would defeat the purpose and I could understand why they would want to do that. While open source doesn't in of itself mean free as in cost as well. A lot of people seem to forget that as well. It all depends on what the developer is trying to accomplish with it.

**wanders off to look up the Electron framework ...

It's essentially using web technologies to create hybrid cross platform apps. Biggest downside is that it depends on Chromium (and node.js) and that adds a lot of "heaviness" to the apps, although not on par with Snaps unless some of the JS coding is wonky (typically the person depends on JS more and not using CSS as much as they could have and that adds bloat).

Etcher, Atom, Slack, WhatsApp are well known electron apps.

[GreyGeek]

After reading some Electron info and watching some introductory tutorials the big difference I see between using Electron and the Qt API is that one can create proprietary binary applications using Electron, but to do that using Qt API one must buy a license, which costs $459/mo/seat. ($5,508/yr/seat). For the lone coder operating on a shoestring budget that Qt entry cost is a huge entry barrier. For a corporate developer, with sales in the 100K units or higher, not so much.

Before I settled on Qt I had tried several other dev tools. Those that were component based (Boa-Constructor, Eclipse, etc.) gave me problems with updating when the component versions were not synced. Electron is based on several components. Does one encounter problems upgrading to new releases?

[kubicle]

which costs $459/mo/seat. ($5,508/yr/seat). For the lone coder operating on a shoestring budget that Qt entry cost is a huge entry barrier.

A lone coder (or a small company) on a shoestring budget can get a commercial license for 499$/year in 2020. And Qt is also available under the LGPL, so you can use the libraries for free in proprietary software as long as you abide by the LGPL (dynamically linking to Qt is fine under the LGPL, for example)

[WWDERW]

Does one encounter problems upgrading to new releases?

I can't speak for everyone that use that framework, but I haven't had a problem with it. I actually like it quite a bit. Some don't and I can see why they wouldn't, but I like it.

Some things I do release open source, some I keep closed. Depends on what it is.

[rec9140]

Missing Firmware error

From the initial install and the latest 400+ updates.. I get this:

essing triggers for initramfs-tools (0.133ubuntu14) ...
update-initramfs: Generating /boot/initrd.img-5.4.0-12-generic
W: Possible missing firmware /lib/firmware/amdgpu/navi12_gpu_info.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/renoir_gpu_info.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_gpu_info.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_asd.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_sos.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_asd.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_sos.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/vega20_ta.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/renoir_asd.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/renoir_rlc.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/renoir_mec2.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/renoir_mec.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/renoir_me.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/renoir_pfp.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/renoir_ce.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_rlc.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_mec2.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_mec.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_rlc.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_mec2.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_mec.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_me.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_pfp.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_ce.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/renoir_sdma.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_sdma.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_sdma1.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_sdma.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi10_mes.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_vcn.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/renoir_vcn.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_vcn.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_smc.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_smc.bin for module amdgpu

Yes, aware its alpha release.. I fully expect this to resolve itself in the near future.. but do I need to dig deeper and pull stuff out of linux-firmware.git etc.. or sit tight??

Things seem to be working fine.. This is a Motile (Tadofung OEM for slimemart) M142 Ryzen R 3500 4 Core laptop.. it was a deal at $400 put about $100 into and it will be 32GB and 500GB as a second drive...so again. pleased with it and 20.04 as it goes... right now...

Any one else with similar setups See this??

Just like to prepare for further digger or if I should dig further now...

[claydoh]

From the initial install and the latest 400+ updates.. I get this:

essing triggers for initramfs-tools (0.133ubuntu14) ...
update-initramfs: Generating /boot/initrd.img-5.4.0-12-generic
W: Possible missing firmware /lib/firmware/amdgpu/navi12_gpu_info.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/renoir_gpu_info.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_gpu_info.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_asd.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_sos.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_asd.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_sos.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/vega20_ta.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/renoir_asd.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/renoir_rlc.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/renoir_mec2.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/renoir_mec.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/renoir_me.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/renoir_pfp.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/renoir_ce.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_rlc.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_mec2.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_mec.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_rlc.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_mec2.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_mec.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_me.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_pfp.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_ce.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/renoir_sdma.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_sdma.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_sdma1.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_sdma.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi10_mes.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_vcn.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/renoir_vcn.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_vcn.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_smc.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_smc.bin for module amdgpu

Yes, aware its alpha release.. I fully expect this to resolve itself in the near future.. but do I need to dig deeper and pull stuff out of linux-firmware.git etc.. or sit tight??

Things seem to be working fine.. This is a Motile (Tadofung OEM for slimemart) M142 Ryzen R 3500 4 Core laptop.. it was a deal at $400 put about $100 into and it will be 32GB and 500GB as a second drive...so again. pleased with it and 20.04 as it goes... right now...

Any one else with similar setups See this??

Just like to prepare for further digger or if I should dig further now...

This is only a warning, and only matters if you have one of the AMD graphics cards listed in them. This new kernel probably needs some tweaks to add all the devices, or to find the modules to correct the warning. Usually it only list a small number with a new kernel (if any), but this one may have added support for a bunch of AMD cards, or something.

These only matter if you have an actual issue,

[rec9140]

So just what are the roles of user and developer in re distribution?

We do prefer that when expressing views and opinions we aren't 'loud or forceful'. We do welcome discussions. We are tolerant of others points of view. What we find problematic is providing qualified answers to questions and then being told the answer isn't satisfactory or to ones liking. "You can please all of the people some of the time, or some of the people all of the time, but you can't please all of the people all of the time." If that isn't a core tenant of programming, it should be.

I find the answer wholly unsatisfactory and disagree because of that dissatisfaction.

Let me give you an analogy in a part of my field... CPR.. I just tell you that you give compression's, and breathing as part of it. Leave at that. Mic drop. Class over. Now some EMT/PM|FF-EMT|PM shows up does what ever they feel like in regards to compression/breathing.. patient dies...You want to be part of that lawsuits? We already had basically something similar in re fire suppression.. with a death.

So basically I as a developer just post up the source and go have fun?

Users are left to dredge through source and make errors to find libs/dependencies?

Really thats the path to source distribution?

I'll give you an example of something of mine... it uses Python.. it requires some libs which I don't know that are distributed as the base in any distro.. I know at least in Debian/*buntu land they are not...but it seems like over time the "base" of this and some other stuff has changed and is no longer there.. How do I know... read on...

Now this really is only shared amongst some specialized users but they sill needed to know

sudo pip thislib etc.

So as I hinted at earlier how do I know the base has changed? The stuff was written for Python based on x distro.. its subsequently been used on x,y,z which are LATER versions of the Debian/*buntu based.. and some could run, some couldn't .

Why? MISSING LIBS!

So once I gave them all the readme.txt that says do: sudo pip libs

Poof errors Gone!

Lesson learned.. give users the info they need to use my stuff.

Some in y had the libs needed, z didn't.. Its sort of like ifconfig in 20.04 and even in 18.04 (I think) why in the planet would such a BASIC tool not be included?? Same with the base of an LXC container.. why would something so basic not be included? I just bang my head and scream when I run into this. Hence why we have to make an image after we do all this to install. (No I don't subscribe to the keep it small ISO collective, never have. 4GB DVD fill'r up!)

So I'd really like to get an honest answer of what the roles of users v. devs is in specifically in source based distribution models...

Cause let me tell you what I am reading..

Here is the source.. deal with it! Just figure it out.

I've gotten that on some stuff.. Not even the ./configure... or even just make and go.. just Here's the source! bye!

So users coming to the support forum of that software flooding it asking how to compile? You'd rather get that? Than take some time and look hey we installed a,b,c,1,2,3 and tell the users in the readme.txt? Thats such an onerous burden to go you need these packages?

So I have to be a C coder to use x software to figure out the make errors so I know what to install?

Well how about then we require BSEE's to use a cell phone. As that is exactly what you are advocating. Sort of do it like Amateur Radio before the Tech license change. Ask questions on the signals, draw a block diagram on the basics of the operation, maybe even for good measure we institute a 10WPM Morse requirement for a cell phone. Its not a phone its a radio which just makes convenient "autopatches."

I'll give you another example of a very sharp cookie.. this is ONE GUY developing some SDR software.. it uses java... The nightmare of getting that to run on Linux for the average user was a nightmare.. What did this ONE GUY do to cut off the support nightmare? All you have to do now is.. unzip it.. cd into a spot (clearly outlined) and then do ./sdrsoftware and it runs! Why? This sharp cookie includes the JVM needed for the software to run..

and no that is not advancing the snaps etc. plan... One guy figured out that to eliminate 99% of the install issues was a simple option to add to build in the JVM.. now all you have do is give them an archive of it.. The other part of this is clear and complete instructions. One guy doing that on something that is a hobby after a real job.

So my original question stands.. outline what role the user and the developer plays in this model?

[claydoh]

We are beating dead horses here, and straying way more off topic than even my extremely laid back attitude towards it will allow.

Closing this.
Apologies to the OP, you can start a new topic, this was getting long all on its own.

As to the the difference of opinion, y'all can also start a new thread, disagree with each other, not change anyone's mind, and raise y'alls blood pressure over there