Welcome!
Important information
-- Spectre and Meltdown vulnerabilities
-- Change in MX sources

News
-- MX Linux on social media: here
-- Mepis support still here

Current releases
-- MX-17.1 Final release info here
-- antiX-17 release info here

New users
-- Please read this first, and don't forget to add system and hardware information to posts!
-- Here are the Forum Rules

MX Software inclusion

Discussion about the MEPIS Community's Repo.
Message
Author
User avatar
MisterZ
Forum Novice
Forum  Novice
Posts: 27
Joined: Thu Dec 15, 2016 1:42 am

MX Software inclusion

#1 Post by MisterZ » Wed Jul 04, 2018 10:26 pm

Just my two-cents ...

Been using MX since version 16 ... excellent OS!!! Been watching the app requests and new pkg development for inclusion in the Test Repos ... there seems to be a rush to include new apps for testing that, personally, I feel are a waste of time, energy, and resources. Case in point: Openshot ... total waste ... always crashes, can't get rid of inline HELP (checkboxes don't work), full of bugs ... why bother? The old stock stable version has always worked a charm for years ... never any problems for simple video creation and editing. It's cases like this where users should simply download AppImages if they wish to experiment with the latest and greatest. (Forget Flatpaks and Snaps>systemd). I use a number of AppImage and am very pleased since they don't integrate their content into the system and therefore easy to use or remove.

So this is my point: I am an advanced Linux user for nearly 15 years and the way I see it you folks have created the finest Debian-based system to date, so why in the world would you tempt newbies to try installing a plethora of latest apps that could, in some cases, bork their system? Why not concentrate on developing tools to extend the user base? Another case in point: Localization. It takes TWO logins to change the system language ... see for yourselves! ... why not work on stuff like this to make language changes more efficient and user-friendly (e.g. Xubuntu "Settings Manager-> Language Support" ... completely downloads the necessary binaries to fill the language requirements, including any KDE apps you may have installed!).

To my mind, and for the aforementioned reason, these things should be priorities .. to continue tweaking Debian, making MX a robust internationally-renowned OS ... Please!

Thanks for hearing me out and, if interested, I have created a brief guide on how to manage and menu-integrate AppImages ... let me know where I could post it?

Cheers

User avatar
stsoh
Forum Regular
Forum Regular
Posts: 390
Joined: Sun Aug 20, 2017 10:11 am

Re: Packages being worked on by the Repo Team

#2 Post by stsoh » Wed Jul 04, 2018 10:42 pm

it so happen, i've been using openshot 1.4.3 to do simple cut n joint my videos. it haven't crash on my old system, not even one time. what is trash to u, may not be trash to others. in fact, it's a gem to someone else, so if u don't like, don't use. :p

ps:
i tried kdenlive video editor and it crash my old system, so this must be trash too.
MX-17.1_x64 Horizon, G41M-P33 Combo(MS-7592), Pentium E5400 (min/max: 1203/2700 MHz), 8Gb RAM (800 MT/s),
Intel 4 Series Integrated Graphics, Realtek PCIe Fast RTL8101/2/6E, PCI Gigabit RTL8169 Ethernets.

User avatar
MisterZ
Forum Novice
Forum  Novice
Posts: 27
Joined: Thu Dec 15, 2016 1:42 am

Re: Packages being worked on by the Repo Team

#3 Post by MisterZ » Wed Jul 04, 2018 10:54 pm

Hello stsoh
I use it too ... Openshot 1.4.3 ... that's what I mean by "The old stock stable version has always worked a charm for years .." in my post. I am speaking about the new vesion 2.4.2 that is in Testing repos ... this is an example of an app that is not mature enough for people to try out, get frustrated with, etc. Yes, the old one you and I have been using is the best! Hope this clears things up ...

User avatar
MisterZ
Forum Novice
Forum  Novice
Posts: 27
Joined: Thu Dec 15, 2016 1:42 am

Packages being worked on by the Repo Team

#4 Post by MisterZ » Wed Jul 04, 2018 11:14 pm

Just my two-cents ...

Been using MX since version 16 ... excellent OS!!! Been watching the app requests and new pkg development for inclusion in the Test Repos ... there seems to be a rush to include new apps for testing that, personally, I feel are a waste of time, energy, and resources. Case in point: Openshot 2.4.2 ... total waste ... always crashes, hangs, can't get rid of inline HELP (checkboxes don't work), full of bugs ... why bother? The old stock stable version (1.4.3) has always worked a charm for years ... never any problems for simple video creation and editing. It's cases like this where users should simply download AppImages if they wish to experiment with the latest and greatest. (Forget Flatpaks and Snaps>systemd). I use a number of AppImages and am very pleased since they don't integrate their content into the system and therefore easy to use or remove.

So this is my point: I am an advanced Linux user for nearly 15 years and the way I see it you folks have created the finest Debian-based system to date, so why in the world would you tempt newbies to try installing a plethora of latest apps that could, in some cases, bork their system or simply turn them off from using Linux? Why not concentrate on developing tools to extend the user base? Another case in point: Localization. It takes TWO logins to change the system language ... see for yourselves! ... why not work on stuff like this to make language changes more efficient and user-friendly (e.g. Xubuntu "Settings Manager-> Language Support" ... completely downloads the necessary binaries to fill the language requirements, including any KDE apps you may have installed!).

To my mind, and for the aforementioned reason, these things should be priorities .. to continue tweaking Debian, making MX a robust internationally-renowned OS ... Please!

Thanks for hearing me out. I have created a brief guide on how to manage and menu-integrate AppImages ...

What I do is to create a folder called "CoolApps" in my HOME folder renaming it to make it invisible (.CoolApps). This contains folders of all my AppImages (make sure you right-click the app for permissions to make it executable!). These folders contain the image and an icon (png) for the app (32x32px, which I create myself). Then create a launcher using a basic text editor like this:

[Desktop Entry]
Name=Avidemux
Exec=/home/(your username)/.CoolApps/Avidemux/avidemux_2.7.0.appImage
Icon=/home/(your username)/.CoolApps/Avidemux/Avidemux-logo.png
Terminal=false
Categories=Video;
Comment=Quick video edits

Then save your text file (in the example for Avidemux) as Avidemux.desktop and place it in /home/(user)/.local/share/applications/ ... it will show up after re-login in your specified menu entry ... easy-peasy. (I keep a copy of this text file as a template for creating launchers for other images.)

If a new version of an AppImage becomes available then simply replace the old one in your specific .CoolApps folder, make it executable, then alter the "Exec=" in your launcher (/home/(user)/.local/share/applications/). If you don't like the App or find it buggy, simply delete everything you created and it's gone (delete the .config entry for the App in question as well)!

Never, ever, had any problems with the numerous AppImages I use.

All the best

User avatar
asqwerth
Forum Veteran
Forum Veteran
Posts: 3257
Joined: Sun May 27, 2007 5:37 am

Re: Packages being worked on by the Repo Team

#5 Post by asqwerth » Thu Jul 05, 2018 12:52 am

Welcome, MisterZ and thanks for taking the time to write out your Appimages launcher guide.

I do something similar, saving all the Appimages files in a separate Data partition under Data/Appimages. That way, the same Appimage can be used by all my distros on my multiboot machines (if necessary). I also save copies of any .desktop files that I make in the Data partition folder so that I can copy them into the /.local/share/applications folder of whatever distro needs it.

As for the Repo Packaging Team and requests made of them, sometimes I do wonder whether a particular request is being made just because it appears to be "latest and greatest" version of the package, or whether there is a specific reason the requestor needs the new version over the existing one in the repo.

I'm referring not to those who give reasons in their requests, but those who make terse posts just asking for the package without giving any explanation of what it is and why they need it.

Quite a few of these appear to be newly-registered members or those who hardly/don't post in the forum. And then I wonder whether these are really users of MX or of another Debian-based distro who request said package so they can run it in their own distro without giving back to this community.

Are they taking advantage of how obliging our Packaging Team are?

On the other hand, the team have stated before to trust them to respond to requests as they deem fit.

In any case, I would be guided by Stevo's approach since he is active in Debian's own forums and from what I can see treats his contributions as something for the whole Debian-based community.
Desktop: Intel i5-4460, 16GB RAM, Intel integrated graphics
Clevo N130WU-based Ultrabook: Intel i7-8550U (Kaby Lake R), 16GB RAM, Intel integrated graphics (UEFI)
ASUS X42D laptop: AMD Phenom II, 6GB RAM, Mobility Radeon HD 5400

User avatar
oops
Forum Regular
Forum Regular
Posts: 304
Joined: Tue Apr 10, 2018 5:07 pm

Re: Packages being worked on by the Repo Team

#6 Post by oops » Thu Jul 05, 2018 5:12 am

I like the concept of appImage files too ... but:
The main problem of the appimage files is mostly who build this image?, and is it free of malwares ?
$ inxi -S : System: Host:XEON Kernel: 4.16.0-xeon-01.efi x86_64 bits: 64 Desktop: Xfce 4.12.3 - Distro: MX-17.1_x64 Horizon


User avatar
dolphin_oracle
Forum Veteran
Forum Veteran
Posts: 9309
Joined: Sun Dec 16, 2007 1:17 pm

Re: Packages being worked on by the Repo Team

#7 Post by dolphin_oracle » Thu Jul 05, 2018 7:47 am

Great discussion!

I'm no mod, but please take these discussions to a new thread. This thread is primarily for repo team / package building coordination.

Thanks!
http://www.youtube.com/runwiththedolphin
lenovo ThinkPad T530 - MX-17
lenovo s21e & 100s - antiX-17, MX17(live-usb)
FYI: mx "test" repo is not the same thing as debian testing repo.

User avatar
richb
Administrator
Posts: 17051
Joined: Wed Jul 12, 2006 2:17 pm

Re: Packages being worked on by the Repo Team

#8 Post by richb » Thu Jul 05, 2018 7:49 am

dolphin_oracle wrote:
Thu Jul 05, 2018 7:47 am
Great discussion!

I'm no mod, but please take these discussions to a new thread. This thread is primarily for repo team / package building coordination.

Thanks!
I will try to split them out. Convoluted process.
Forum Rules
Guide - How to Ask for Help

Rich
SSD Production: MX 17.1
AMD A8 7600 FM2+ CPU R7 Graphics, 16 GIG Mem. Three Samsung EVO SSD's 250 GB, 350 GB HD

User avatar
Stevo
Forum Veteran
Forum Veteran
Posts: 16182
Joined: Fri Dec 15, 2006 8:07 pm

Re: MX Software inclusion

#9 Post by Stevo » Thu Jul 05, 2018 1:06 pm

Many people don't like how much more disk space the portable flatpack, snaps, appimages take up...sometimes nearly 100X more, such as 300+ MB versus 5.

Just imagine how big the ISO would be that used portable versions such as snaps for most applications.

And the test repo is for testing. A user can always revert to the stable version if they don't like any new version. We still have GIMP 2.10 in testing because it required updated core libglib2.0 and font rendering libraries, though we haven't had any reports of things going south with those.

Openshot 2.4.2 really didn't require much effort to backport, since I can do it all with pbuilder. Basically just a few minutes of text file edits and moving the finished files around. Most packages aren't that hard at all, once you know the recipes. Some take some more experience--I just did a backport of Buster's budgie-desktop that required several extra modifications. Even if some may consider the backports unnecessary, I have often leveled up my backporting skills by learning how to do these tweaks...backporting the upstream Debian kernel uses most of the same tricks that we learned by backporting the Liquorix kernel earlier, for example.

User avatar
MisterZ
Forum Novice
Forum  Novice
Posts: 27
Joined: Thu Dec 15, 2016 1:42 am

Re: MX Software inclusion

#10 Post by MisterZ » Thu Jul 05, 2018 6:16 pm

I'll try to answer as much as i can in one shot ...

@Stevo
Top-notch, indisputable Linux master, to all of you that don't know that!

(1) I beg to differ with you however regarding your exaggerated
appimages take up...sometimes nearly 100X more, such as 300+ MB versus 5
... I use the following AppImages ... Avidemux, FreeCad, Krita, Mindomo, MuseScore, Stellarium, SynfigStudio ... for a total of 830.7 MB of extra disk space ... next to nothing by today's standards. AppImages are, as you know, self-contained and do not integrate their contents into your system. Once executed, many of them actually ask you if you wish or not to do so ... I always say NO. That is why I posted the Launcher instructions for new users. Compare this to a .deb that extracts itself fully into the system (e.g., Openshot 2.4.2) and forces itself into mimeapps.list. How do you explain to a newbie how to rectify that if they decide to do a revert? Even with a "pristine" installation, I have to clean up and tweak "mime" ...

(Note: @ oops
As long as you download the images from their respective websites, i.e., https://musescore.org for MuseScore, "security" should not be a problem! Always go to the source site no matter what OS you use ...)

(2) No gripes here, Stevo, don't get me wrong. it's just that Linux users need to understand their options and not to depend entirely on hard-working people like yourself and the other MX Developers/Packagers. New users need help, for sure, but why hand it all over on a silver platter? Test Repos is a super idea, BUT ... new users have to jump through hoops to revert back to a stable version. Who's gonna teach them:
sudo apt remove --purge XXX && sudo apt autoremove && sudo aptitude purge ~c
Read, learn, re-read is what I tell those who want to migrate to a Linux OS and to those that I install MX as my preferred and recommended Distro. Folks gotta get their feet wet somewhere along the road. That holds true for any operating system, yet only a small minority do it ... read a Manual?, duh!

(3) I live in a bilingual country (Canada) and my needs and those of my clients are such. Often within one family or group, it becomes necessary to boot into a different language. I set up MX to do so (locale, keyboard, etc.). I know my way around Debian and understand locale generation, choices, all of it. However, as I said in my initial post "Why not concentrate on developing tools to extend the user base? Localization. It takes TWO logins to change the system language ... check it out yourself ... why not work on stuff like this to make language changes more efficient and user-friendly (e.g. Xubuntu "Settings Manager-> Language Support" ... completely downloads the necessary binaries to fill the language requirements, including any KDE apps you may have installed!). Tweaking and making Debian (MX) a joy to use is your life's passion ... keep on tweakin' Stevo!

@asqwerth, dolphin_oracle, richb
Thanks a bunch for re-setting this thread, my initial fault ... sorry for the inconvenience! asqwerth ... great tip on the multi-boot use of AppImages!

Take care folks. Too hot here ... goin' swimming ...

Post Reply

Return to “CR Discussion”