| Summary: | Low-level packages to update for Mageia 6 | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | David Walser <luigiwalser> |
| Component: | RPM Packages | Assignee: | Base system maintainers <basesystem> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | release_blocker | CC: | fri, mageia, mageia, pterjan, thkala, tmb |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | i586 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | CVE: | ||
| Status comment: | David Walser is going to check a last time. | ||
| Attachments: | mgrarepo `svn diff' output to bring LVM2 to version 2.02.154 | ||
|
Description
David Walser
2016-01-18 20:46:02 CET
David Walser
2016-01-18 20:46:33 CET
Blocks:
(none) =>
15527 I forgot to mention that ppl's newest version is 1.1. It looks like cloog/ppl were used by gcc through Mageia 5, but no longer are in Cauldron. Maybe we can just drop them. dracut and kmod are updated now. LVM2 is at version 2.02.154 now. I have been using a build of it on my system for a few days and have encountered no problems, although admittedly it did not have much to do except for assembling my lvmcache volumes on boot. I am attaching a patch to bring the LVM2 package to this version. CC:
(none) =>
thkala Created attachment 7829 [details]
mgrarepo `svn diff' output to bring LVM2 to version 2.02.154
cloog/ppl dropped and replaced by isl. We had the latest upstream until upstream isl released 0.17.1, but the gcc documentation doesn't say whether that one is supported yet, so that can wait for Mageia 7. I believe dracut, kmod, and xfsprogs are currently up to date now. dkms, initscripts, and rpmlint still need some love from Colin or someone. lvm2 suggested update in Comment 3, needs review by Thomas. e2fsprogs 1.43 has two test failures on i586: http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20160521171414.luigiwalser.duvel.11665/log/e2fsprogs-1.43-1.mga6/build.0.20160521171514.log binutils could potentially be updated to 2.26, but I'd expect that to go for Mageia 7 instead. glibc 2.23 would be nice to have for Mageia 6, however. Up to Thomas. Otherwise, we're in good shape. On an related matter i wonder if this old package should be in this list of things to get updated: Bug 16712 - We have libqtkeychain0 version 0.1.0 from 2013, later versions improve KDE5/FC support CC:
(none) =>
fri (In reply to Morgan Leijström from comment #5) > On an related matter i wonder if this old package should be in this list of > things to get updated: > Bug 16712 - We have libqtkeychain0 version 0.1.0 from 2013, later versions > improve KDE5/FC support Please have these kind of packages talked about on Bug 17528 instead. Are there still low-level packages that would be worth upgrading so late in the release process, or can we consider this issue as FIXED/OLD? This could still use a look. I guess we're going with glibc 2.22 for Mageia 6. It looks like initscripts was updated in SVN and then reverted for some reason. kmod 23 just came out, so tmb can decide on that one. lvm2 is updated upstream frequently, so tmb can decide what version to go with. dkms and rpmlint seem unlikely to be updated any time soon. binutils has some security issues (Bug 18987), so something should be done there. I still need to check again for outdated packages, I haven't in over a month. CC'ing Pascal, since Thomas is taking a step back. CC:
(none) =>
pterjan
Rémi Verschelde
2016-09-08 10:06:32 CEST
Assignee:
tmb =>
basesystem Marking as blocker for now, as if we update initscripts or glibc, we'll need to do that before the release. I don't know why tmb decided to stick with 2.22 (probably only he knows) and I also don't know why we didn't follow through with the initscripts update (which apparently had been done in SVN). Priority:
Normal =>
release_blocker Maybe we should bring those points to the dev@ ML to reach a decision quickly whether we want to work on those updates, or consider those frozen for mga6.
Samuel Verschelde
2016-09-12 16:16:09 CEST
Status comment:
(none) =>
If glibc or initscripts will be updated, should be done before release (In reply to David Walser from comment #10) > Marking as blocker for now, as if we update initscripts or glibc, we'll need > to do that before the release. > > I don't know why tmb decided to stick with 2.22 (probably only he knows) and > I also don't know why we didn't follow through with the initscripts update > (which apparently had been done in SVN). Because normally we dont update core packages like glibc/gcc/binutils when we are past distro rebuild as they all tend to give some fun/subtle "hiccups" and we want a stable core... CC:
(none) =>
tmb (In reply to Thomas Backlund from comment #12) > (In reply to David Walser from comment #10) > > Marking as blocker for now, as if we update initscripts or glibc, we'll need > > to do that before the release. > > > > I don't know why tmb decided to stick with 2.22 (probably only he knows) and > > I also don't know why we didn't follow through with the initscripts update > > (which apparently had been done in SVN). > > > Because normally we dont update core packages like glibc/gcc/binutils when > we are past distro rebuild as they all tend to give some fun/subtle > "hiccups" and we want a stable core... Thanks for the comment. With regards to glibc, that definitely makes sense. We never anticipated this development cycle would take this long, and IIRC the mass rebuild was in January, so we *could* do another one, but I don't know that that's desirable. As for initscripts, I would think it would have less of an impact, but people like you and Colin who are more intimately familiar with it would know much better than I would about that.
Samuel Verschelde
2016-09-13 10:38:21 CEST
Status comment:
If glibc or initscripts will be updated, should be done before release =>
If glibc or initscripts will be updated, should be done before release. glibc involves rebuilding the whole distro so not to be done lightly. i don't think we should update initscript this late. Maybe as an update after more testing. So i think we should close this bugreport. CC:
(none) =>
mageia I should check the versions of things again since it has been months. (In reply to David Walser from comment #15) > I should check the versions of things again since it has been months. Please do, we need to close this bug report one way or the other.
Samuel Verschelde
2016-11-08 12:47:33 CET
Status comment:
If glibc or initscripts will be updated, should be done before release. glibc involves rebuilding the whole distro so not to be done lightly. =>
David Walser is going to check a last time. dkms 2.3 debian glibc 2.24 upstream initscripts 9.65/10.0 fedora/upstream rpmlint 1.9 fedora systemd 232 fedora util-linux 2.29 fedora I guess are what would be left on this list at this point (and binutils, but I mentioned earlier we have a security bug filed for that one). They're not going to be updated for Mageia 6, so I guess this is WONTFIX at this point, but it'd be nice to have a Mageia 7 bug for this so hopefully they can be addressed early in the cycle, especially considering things like dkms, initscripts, and rpmlint were not addressed *at all* during the entire Mageia 5 development cycle. We really need those who understand those packages to address those ones. Thanks for the review. It's indeed late for those. Let's indeed create a bug report with Target Milestone "Mageia 7" and high priority. dkms has its own bug report: bug 17198 rpmlint now has one: bug 19777 and initscripts: 19778 and a new tracker to tie them all: 19779 Closing for Mageia 6. Resolution:
(none) =>
FIXED
Samuel Verschelde
2017-01-17 10:29:39 CET
Blocks:
15527 =>
(none) |