Hello
I've noticed that LMDE has problem with lack of known bug fixes. In normal rolling distro, you have things broken quite often but hopefully fixed quickly too.
Since LMDE is semi-rolling, it is more stable, but unfortunately also fixes can come rarely.
I just wonder if you could differentiate between 'updates' and 'fixes' and push such fixes from debian to lmde more quicky, before next UP arrives.
This wouln't probably make any sense if UP was relased every month, but since it is released not as often, this can be a good idea.
There is usually no problem with living few months with old program version, but it's harder to live with annoying bug.
To minimize additional LMDE team work, It could work in the following way:
- user report his/her problem AND known solution (=fixed package from debian repo) WITH links to get more information (only such detailed reports would be accepted)
- somebody from LMDE team just verifies that such bug was in fact fixed in debian, and it is in fact affecting users and update is pushed to LMDE repo
- no updates/new features allowed, only bugfixes
- just before UP release all fixes are merged with next UP to achieve best stability (if they aren't there already).
To make things more safe, such fixes could be pushed to 'romeo' or something similar, not main repo,
Example (in this case I'm the user who reports a bug):
In UP5, fglrx 12.6-point1 driver is broken. 32-bit apps are simply not working wth OpenGL under 64-bit lmde.
This is known upstream bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683853
And it has been fixed in 12.6-point2 and subsequent releases (resolved bugs - important bugs).
http://bugs.debian.org/cgi-bin/pkgrepor ... ble#_4_3_5
Of course I understand that you don't want to push sid package to LMDE so:
- it could be restricted to testing repo only
- package could be put on "waiting list" and pushed as soon as it reaches testing.
- package could be pushed from sid only if bug is severe, it doesn't require any other updates/dependencies from sid, and works with testing without modifications
What do you think about it? Would it be very hard to maintain? Im talking just about known bug fixes.
No "i want new libreoffice!!!" or "it doesn't work and I dunno why!" complains would be accepted.
I think something should be done with bugfixes, because LMDE is not as stable as Ubuntu based version, yet it receives almost no updates.
Important fixes idea
Forum rules
LMDE 2 has reached end of support as of 1-1-2019
LMDE 2 has reached end of support as of 1-1-2019
Important fixes idea
Last edited by LockBot on Wed Dec 28, 2022 7:16 am, edited 1 time in total.
Reason: Topic automatically closed 6 months after creation. New replies are no longer allowed.
Reason: Topic automatically closed 6 months after creation. New replies are no longer allowed.
Re: Important fixes idea
at the moment just subscribing and watching the community feedback.
Re: Important fixes idea
I'm definitely interested to have more updates coming our way. I think that UP should be confined to mint packages, like cinnamon, mate, etc. but not on debian internals. Those should be pushed more often.
And I would like more up to date libreoffice, firefox, thunderbird. There were several security fixes and no updates were pushed yet.
And I would like more up to date libreoffice, firefox, thunderbird. There were several security fixes and no updates were pushed yet.
Re: Important fixes idea
I think UP is a good system to balance stability and newness. But, probably the incoming repositories had to be updated from Debian incoming in a more regular basis, so testing smaller updates will be easier and UP more frequents.
Re: Important fixes idea
Yeah, it would be very nice. Such fixes would quickly solve some annoying problems like:sobrus wrote:I just wonder if you could differentiate between 'updates' and 'fixes' and push such fixes from debian to lmde more quicky, before next UP arrives.
This wouln't probably make any sense if UP was relased every month, but since it is released not as often, this can be a good idea.
There is usually no problem with living few months with old program version, but it's harder to live with annoying bug.
- totally broken qbittorrent
- sleep mode breakage for nVidia users
- lightdm manual start/stop breakage
- attempting to mount the same tmpfs twice
- just incredibly bad luck (this case is special - just look at the dates! apparently, someone upstream just "likes to move it, move it" )
Also, such a bugfix update may be considered as a partial upgrade. When a new Update Pack is released, it's necessary to make sure there are no upgrade issues for both the users who have any bugfixes installed and the users who haven't any.
Re: Important fixes idea
I'm a Mint/Linux newbie overall and know next to nothing about LMDE in particular (I do run it on an ASUS EeePc which performed flawlessly during a serious flogging on a recent overseas trip) BUT, the reason I was attracted to LMDE in the first place was the idea of never having to do 'fresh' installs.
UPs are a move in the right direction. The major concern for me is not the size of the downloads required after each release. It's the time they take to download (four hours for me for UP5). Additionally, in the case of UP5 it required me to sit in front of the screen and make decisions to keep or change the existing structure and also to ensure GRUB was correctly placed.
In reality, it would have been quicker to do a complete 'fresh' reinstall.
There seems to be a dividing fence here between those who are happy to wait for the complete package and those who would prefer that Mint somehow separate its own changes from those generated by Debian in general. It's just my uninformed non-programmer/developer opinion, of course, but sending through incremental, non-Mint fixes as they occur (provided they don't impact on Mintification) just makes common sense,
And if it makes the whole process quicker and somehow doesn't require me to sit in front of the monitor for several hours, I'd be a very, very much happier user (my wife would thank you too).
UPs are a move in the right direction. The major concern for me is not the size of the downloads required after each release. It's the time they take to download (four hours for me for UP5). Additionally, in the case of UP5 it required me to sit in front of the screen and make decisions to keep or change the existing structure and also to ensure GRUB was correctly placed.
In reality, it would have been quicker to do a complete 'fresh' reinstall.
There seems to be a dividing fence here between those who are happy to wait for the complete package and those who would prefer that Mint somehow separate its own changes from those generated by Debian in general. It's just my uninformed non-programmer/developer opinion, of course, but sending through incremental, non-Mint fixes as they occur (provided they don't impact on Mintification) just makes common sense,
And if it makes the whole process quicker and somehow doesn't require me to sit in front of the monitor for several hours, I'd be a very, very much happier user (my wife would thank you too).
Re: Important fixes idea
Download size can be a problem, yes. But on the other side, you have to do it only once a few months - it is not that bad anyway.
Rolling distros always require fast internet connection. It is how they work. On opensuse tumbleweed you can have something like 300MB updates DAILY.
LMDE is semi rolling, so you have few months of peace after update. This has advantages - and disadvantages of course.
For example - I believe your EeePC has SSD drive. If updates were much frequent, drive wear would be higher. And who needs new libreoffice every week anyway?
Reinstalling is faster if, and only if, your system is 'out-of-the-box' or close to this state.
Once you custiomize your OS, change /etc, write your own scripts, compile own programs - it will be *real* pain. Doing this can take hours, doing it all over again drives crazy. And you will always forget about something.
Rolling distro really helps, I came here from suse and I really hope reinstalling won't be neccesary until I buy new machine.
Questions can be annoying, that's true. But please remember LMDE is not quite "newbie oriented". Your wife would be probably happier with Ubuntu based Mint Main LTS edition.
btw. update is slow mainly because apt-get is slow. Even on SSD. That's why apt-get isn't used during fresh install at all. It's something like cheating - on fresh install files are just copied off dvd rather than istalled from packages.
opensuse's zypper is MUCH faster in this regard, so I think debian package management is to blame.
Rolling distros always require fast internet connection. It is how they work. On opensuse tumbleweed you can have something like 300MB updates DAILY.
LMDE is semi rolling, so you have few months of peace after update. This has advantages - and disadvantages of course.
For example - I believe your EeePC has SSD drive. If updates were much frequent, drive wear would be higher. And who needs new libreoffice every week anyway?
Reinstalling is faster if, and only if, your system is 'out-of-the-box' or close to this state.
Once you custiomize your OS, change /etc, write your own scripts, compile own programs - it will be *real* pain. Doing this can take hours, doing it all over again drives crazy. And you will always forget about something.
Rolling distro really helps, I came here from suse and I really hope reinstalling won't be neccesary until I buy new machine.
Questions can be annoying, that's true. But please remember LMDE is not quite "newbie oriented". Your wife would be probably happier with Ubuntu based Mint Main LTS edition.
btw. update is slow mainly because apt-get is slow. Even on SSD. That's why apt-get isn't used during fresh install at all. It's something like cheating - on fresh install files are just copied off dvd rather than istalled from packages.
opensuse's zypper is MUCH faster in this regard, so I think debian package management is to blame.
Re: Important fixes idea
sobrus wrote:I just wonder if you could differentiate between 'updates' and 'fixes' and push such fixes from debian to lmde more quicky, before next UP arrives.
This wouln't probably make any sense if UP was relased every month, but since it is released not as often, this can be a good idea.
There is usually no problem with living few months with old program version, but it's harder to live with annoying bug.
Ditto and maybe a way for apps from backports (many times there really bug-fixed versions) to get thru.
I would think the 'update (debian) manager would need to change, and a new tag (or existing ) would need to be incorporated some how to automate.
J.Jay
P.S. I would (other may not ) forgo a Upack (or 2) if need extra time (cause size of team ect.) to incorporate something like that. In long run think that would simplify UPack sys (less things to test in Upacks itself)
This wouln't probably make any sense if UP was relased every month, but since it is released not as often, this can be a good idea.
There is usually no problem with living few months with old program version, but it's harder to live with annoying bug.
Ditto and maybe a way for apps from backports (many times there really bug-fixed versions) to get thru.
I would think the 'update (debian) manager would need to change, and a new tag (or existing ) would need to be incorporated some how to automate.
J.Jay
P.S. I would (other may not ) forgo a Upack (or 2) if need extra time (cause size of team ect.) to incorporate something like that. In long run think that would simplify UPack sys (less things to test in Upacks itself)