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
Redacted
Forum Novice
Forum  Novice
Posts: 79
Joined: Sat Apr 29, 2017 6:53 am

Re: MX Software inclusion

#21 Post by Redacted » Fri Jul 06, 2018 8:39 am

HessenZone wrote:
Fri Jul 06, 2018 8:19 am
So directing people to do something "undesireable" which may also be time consuming, is not the proper way to help someone fix a problem.
I personally am sick and tired of your opinions being presented as fact, no matter in what incarnation you come to this forum. This repetitive "do it my way because I know what is best" is pathetic and childish beyond description.
Please stop.
MX 17.1

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

Re: MX Software inclusion

#22 Post by dolphin_oracle » Fri Jul 06, 2018 8:53 am

Move along folks, move along...

TBF, selecting the locale preferences at live boot has long been our standard. We take advantage of the antiX live-usb system to let folks adjust all sorts of stuff before install. then, unlike debian or the 'buntus, we install the running live system rather than a pre-canned image. But that sometimes means that the way to do things in MX and antiX is different from other distros. And that's a good thing.

One can also do a "sudo update-locale" and change as well. the change would take effect after a login/logout.

Firefox/thunderbird had some issues after we released due to upstream changes, but those are resolved now AFAIK.

But we are always looking for comments on user experience, and these have been noted for the future.

Getting back to the main topic of this thread would be an excellent idea.

That's the last word.
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
Stevo
Forum Veteran
Forum Veteran
Posts: 15801
Joined: Fri Dec 15, 2006 8:07 pm

Re: MX Software inclusion

#23 Post by Stevo » Fri Jul 06, 2018 1:26 pm

I believe the GIMP 2.10 upgrade issues were due to to the Debian packaging system not automatically depending on the latest babl and gegl libraries that it was built against--not a problem upstream, where they remove the older versions of those, but exposed here where we can have multiple versions. However, I thought I fixed those...let me know if they're not! No update process is going to magically be problem-free.

VLC 3.X...well, Debian updated to it in Stretch, so it's their baby now. I will say most of the problems seem to be it now expecting to get a fully modern openGL video output, but that can be adjusted in the settings to use X11 or XV outputs. Plus we have plenty of other options if you just want a video player.

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

Re: MX Software inclusion

#24 Post by MisterZ » Fri Jul 06, 2018 1:37 pm

Hello Folks

I srarted the discussion here with my end-user concerns regarding inclusion of certain packages being placed in Test Repos, one of which (Openshot 2.4.2) i found too buggy to really be of much use. If you installed the version from the MX stable package browser, stay with it! That being said, it's important to note that, yes, some people like to try out the "latest and greatest" software, but new users (beginners) should be careful with the Test Repo unless they know what they are doing, why they install these, and are ready to report in a comprehensive manner any related bugs.

If you are not ready to go this route then I still believe the use of AppImages (albeit they are not available for everything under the sun!) is a good, easy-to-manage option.

Getting back to my example of the latest Openshot-testing, Stevo is way ahead of the game since the version he uploaded is superior to even that in Debian Sid. The app is ongoing by its lead developer and there will come a day soon when even Openshot 2.4.2 will become obsolete ... BThW, Gimp just posted a point update for their 2.10 series!

All this to say that I have to back-pedal on some of my earlier (mis) understandings about the facility of Test Repos as they serve the next MX stable release Package Installer Browser. The choice of apps is totally at the discretion of the Packagers/Developers and thus far everything they place in the basic extra packages installer is extremely tight-knit for folks to get the best experience from MX! I think that I get the picture regarding the Test Repos as well. Although it is nowhere EXPLICITLY stated, these future stable packages are meant to eliminate the need for the end-user to dabble in (dangerous) ppa-additions, 3rd-party .debs, etc., when a new MX release comes out. Someone correct me if I'm wrong?

Finally. regarding the other topic I brought up ... ease of localization ... I still believe a tool for post-installation addition of languages would be a boon for folks (world-wide) needing a multilingual interface.

Hope all this helps put the topic back on track!

All the best

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

Re: MX Software inclusion

#25 Post by asqwerth » Fri Jul 06, 2018 1:49 pm

They aren't "future" packages for next release of MX.

While they are newer versions of packages - or packages not found in Debian repos at all - the packages in MX Test Repo have been put together to be compatible with current Debian Stretch, not Debian Buster (future stable).

But you are right that the hope is that end users do not dabble in potentially conflicting Ubuntu packages from PPAs nor directly install packages from Debian Testing/Sid that are indeed for future Debian Stable.
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
Stevo
Forum Veteran
Forum Veteran
Posts: 15801
Joined: Fri Dec 15, 2006 8:07 pm

Re: MX Software inclusion

#26 Post by Stevo » Fri Jul 06, 2018 2:28 pm

About the new GIMP 2.10.4 release that was mentioned: I managed to leapfrog Debian and most other distros, and we now have it in our test repo. It wasn't a simple port..it required a newer babl and gegl that aren't in Debian either, and also some updating of debian/.symbol files, since new symbols turned up with the new releases. Luckily, the error messages from the failed builds guided me to what needed to be fixed.

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

Re: MX Software inclusion

#27 Post by MisterZ » Fri Jul 06, 2018 2:38 pm

@ asqwerth

Thank you for the clarification! I do then agree with you regarding fast-and-furious packages placed in Test ... wondering why then? if many pkgs will never see the light of day. One of my fundamental concerns regarding all of this hard work and effort from the MX Devs stems from the fact that MX is such a wonderful Distro coming from such a small community and the question always in the back of my mind has been the longevity and long-term viability of the project ... I would like to see it become THE Debian-based distro for many future years. Obviously this requires some hard-thinking on what should be time-efficient priority. Guess I'll just have to continue advocating for users to remember to offer donations to their favorite Distro (or App for that matter).

Again some clarification when you have the time ...

Meanwhile, when it comes to folks that I install for, tweak, and encourage to use MX, I'll simply explain to them the various extra package installation options to use (briefly, of course) and which to be careful with or not use at all.

Thanks again ...

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

Re: MX Software inclusion

#28 Post by dolphin_oracle » Fri Jul 06, 2018 3:32 pm

MisterZ wrote:
Fri Jul 06, 2018 2:38 pm
@ asqwerth

Thank you for the clarification! I do then agree with you regarding fast-and-furious packages placed in Test ... wondering why then? if many pkgs will never see the light of day. One of my fundamental concerns regarding all of this hard work and effort from the MX Devs stems from the fact that MX is such a wonderful Distro coming from such a small community and the question always in the back of my mind has been the longevity and long-term viability of the project ... I would like to see it become THE Debian-based distro for many future years. Obviously this requires some hard-thinking on what should be time-efficient priority. Guess I'll just have to continue advocating for users to remember to offer donations to their favorite Distro (or App for that matter).

Again some clarification when you have the time ...

Meanwhile, when it comes to folks that I install for, tweak, and encourage to use MX, I'll simply explain to them the various extra package installation options to use (briefly, of course) and which to be careful with or not use at all.

Thanks again ...

clarification: some packages will make it to main, but keeping them sequestered in "Test" keeps us from breaking the rest of the system willy-nilly while still allowing folks that want or need some later versioned package easy access. Since one of the main gripes folks have with debian is "out-dated packages", our Test repo becomes an attractive option at times.

As to priorities and time management... we have in fact chosen to develop only an Xfce based iso for this very reason. Not only is Xfce a good choice,both in terms of stablity and function, but by not trying to customize and support every DE out there, we can focus energies on our mx-tools, artwork, and packaging of newer apps. We also are trying to contribute more back to the antiX mothership.

As far as longevity... as the bard once said, don't call it a comeback, we've been here for years. The community here is older (far older) than the MX distro itself, and is the primary reason the distro exists. MEPIS goes way back into the 2k's and antiX has been doing its thing since at least 2006. Just because people haven't noticed, doesn't mean we ain't been around. (for fun, I looked at my profile...I've been a member here since: Joined:Sun Dec 16, 2007 12:17 pm ).

I don't doubt appimages are nice. I think they are great. I would love one of our (mx+antiX) live-usb creation suite.
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
oops
Forum Regular
Forum Regular
Posts: 208
Joined: Tue Apr 10, 2018 5:07 pm

Re: MX Software inclusion

#29 Post by oops » Fri Jul 06, 2018 8:11 pm

MisterZ wrote:
Fri Jul 06, 2018 2:38 pm
... and the question always in the back of my mind has been the longevity and long-term viability of the project ... I would like to see it become THE Debian-based distro for many future years....
I agree with you, stability, longevity and usability (the user friendly mx-tools, and local language switching ability) are very important and determinant for me too. I think appimage (if images are secure) is a good way to test and try the new versions of softwares without compromising the MX/AntiX OS stability, and has the advantage (and a risque too) of a possible interoperability with some others OS. But for a basic use, I think the stable repository is the best way for stable software versions (I see appimage way mostly as an extra functionality across the multiplatformes and multi-OSes).
$ 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
dreamer
Forum Regular
Forum Regular
Posts: 158
Joined: Sun Oct 15, 2017 11:34 am

Re: MX Software inclusion

#30 Post by dreamer » Fri Jul 06, 2018 9:48 pm

Stevo wrote:
Thu Jul 05, 2018 11:39 pm
I did just set up Gimp 2.10.4 in an independent OBS repo after doing it for our test repo. But we are relying on tester's reports before we think about moving it to main--we won't if anyone has problems with it, so speak up if you do!

https://build.opensuse.org/project/show ... -backports#

XFCE 4.14 isn't even a twinkle in our eyes yet.
The problem with relying on users to test new versions is that only users that would want that new version are going to test it. People (like myself) who would rather not be exposed to backported libs and prefer the Stretch version might actually hope that there is something wrong with the new version that dooms it to eternal life in the test repo. ;) The idea here is that a less modified Stretch base is preferable to newer apps modifying that base. But it could also be that people prefer the older version as newer isn’t always better. Each user has their own preferences which highlights the importance of choice.

Which brings us back to PPAs... openSUSE and Ubuntu have the software flexibility that comes from multiple repos. There is never any discussion what should be in main and what shouldn’t. Main is what Canonical or SUSE think are suitable packages for a stable release (like Debian actually). Newer packages which are not related to security aren’t pushed to main (like Debian again). It’s up to the user to decide what software to update by selecting appropriate repos.

Since all the packaging in MX Linux is handled by a small team there is no need for one hundred different repos. To differentiate between conservative and progressive users only one repo has to be added that sits between test repo and mx main repo. I called this repo “progressive repo”. This repo would shield conservative users from “controversial” updates like DE updates, LO updates and in this case GIMP 2.10 because it depends on a newer/backported system library.

How much work is this and will it work? I don’t know. I’m tossing ideas around, because there are probably enough conservative users that as soon as a new big update arrives there will be a thread on the forum saying: After the latest LO upgrade my settings have changed or this app does no longer work as it used to etc. No big update is problem-free and every update you don’t want is a problem just by itself. Something like GIMP could probably be pinned in Synaptic. LibreOffice might be harder to pin/lock (many packages). In that case it’s probably better to let the update happen and use an older version in AppImage format which can be downloaded directly from LO.

This type of dilemma actually makes me think that bundled applications that aren’t installed (not affecting the system - no root needed) like AppImages are the future. That the same binary can work on many distros is just another benefit. The burden of creating and updating AppImages can be shared by all distros. Stevo’s idea to package AppImages as .debs actually gives us the best of both worlds. Apt gives us easy updates and system integration, while the AppImage format keeps the system free from dependency problems and unaffected by bundled libs inside the AppImage.

Bundled applications might not be the Unix way, but it would allow the newer libfreetype6 to be bundled with Gimp 2.10 and the Stretch base wouldn’t be affected at all. I don’t think the size of AppImages is a problem. If you compare the size of official LO AppImages (English-only and localized versions) I don’t think the size on disk is very different from installed .debs. If there is a size difference that would be explained by the AppImage bundling files that are already present on the system.

Just a thought: Maybe the reason the monolithic Linux kernel is working well is that it is a “bundled app” (using the word “app” very loosely here). Many kernels can be installed side by side and as far as I know installing Linux kernels doesn’t bring dependencies that affect other packages in the distro. Doesn’t Linus take pride in the fact that the Linux kernel is separate from the rest of the system and hasn’t he also made a promise to not break userland with kernel updates/upgrades? To me it seems there is some similarity between the monolithic Linux kernel and monolithic AppImages.

Post Reply

Return to “CR Discussion”