Re: [Mageia-dev] Backports policy clarification (and discussion)
Angelo Naselli a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 09/06/2012 20:38, Sander Lepik ha scritto: I see backports as the way to get some new stuff from cauldron before cauldron is fully stable. There is no point to backport from cauldron to n-2 (mga1 at the moment). If the user wants so much newer stuff s/he better upgrade to latest stable. There could be no point now -and maybe for you-, but it could be in future or for sombody who does not want to update to mga2 yet (kmail2, akonadi, kwallet issues) and want to get some leaf packages for his/her needs (firefox, mondevelop, ...). If we allow bp, and i'm in favor of that, we must consider all the possible cases, and must be able to upgrade to next mgaX without issues due to bp imho. +1 Angelo -- André
Re: [Mageia-dev] Backports policy clarification (and discussion)
Thomas Backlund a écrit : 09.06.2012 13:29, andre999 skrev: OK. To backport from Cauldron to mga1, we have to backport from Cauldron to mga2, (bumping the revision in cauldron to ensure that is is higher), then backport from mga2 to mga1, ensuring that the revision is lower in mga1 than in mga2.(e.g. revision x.1 in cauldron, x.0.1 in mga2, x.0.0.1 in mga1) Pretty straight forward. Not needed as 1.mgaX> 1.mga3> 1.mga2> 1.mga1 I was thinking of available packages changing between mga1 and mga2, but if the backport is installed (with whatever requires being installed), these requires wouldn't (or shouldn't) be removed with a release update from mga1 to mga2. But what do we do if a package required for installing the backport in mga1 is not available due to conflicts in mga2 ? Do we assume that the conflicting package in mga2 has the appropriate provides, or even can provide the required function ? Or do we try to detect such situations and remove the backport in question ? If we make a point of making a backport for mga2 (or upgrade if it doesn't have to be a backport in mga2), then this problem would already be resolved. Of course, most of the time this wouldn't be a problem, and we could check for requires that are not available in mga2. Another thing that we should verify is the version specified for requires. That is very likely to change between release versions. Maybe a rule that the requires specified for the backport in the target release should be compatible with Cauldron. That is, that all packages required for the backport in the target release are provided in Cauldron (either by provides or the specific package), and that the versions specified - if any - are compatible with the versions available in Cauldron (and of course the target release). This should ensure that the requires would be available in any interim releases. - Cherry-picking refers to the users' option to install a backport, which has nothing to do with the packaging itself. Oh but it has _everything_ to do with packaging... in order for cherrypicking to work, the deps must be stricter so that any deps in backports gets selected along with the package the user is selecting. I was assuming that the requires would be well defined for a backport, as they should be for any package. It would be nice to have a tool to check for dependancies, if there isn't one already. To avoid overlooking something because the test systems have some of the dependancies already installed. Particularly since QA would be less implicated in the testing. -- Thomas -- André
Re: [Mageia-dev] Crashes with Firefox 13 + Flash (inc. fix)
2012/6/9 Colin Guthrie : > Hi, > > Just in case others are experiencing this, I've noticed recently that > since Cauldron went to Firefox 13 I've seen frequent crashes, most often > when interacting with Flash. > > After getting annoyed enough about it today, I did some digging, got a > (rubbish but mildly usable) backtrace and managed to do some educated > Googling. > > I ended up finding this: > https://bugzilla.novell.com/show_bug.cgi?id=759123 > > The suggested solution of installing lib64proxy-webkit and removing > lib64proxy-mozjs did the trick. Firefox has been much more stable. > > Just thought I'd share this with others should they also be suffering > the same problem. > > Depending on how widespread the problem is, we should maybe consider > adding conflicts to firefox package on lib*proxy-mozjs. > > All the best > > Col > > -- > > Colin Guthrie > colin(at)mageia.org > http://colin.guthr.ie/ > > Day Job: > Tribalogic Limited http://www.tribalogic.net/ > Open Source: > Mageia Contributor http://www.mageia.org/ > PulseAudio Hacker http://www.pulseaudio.org/ > Trac Hacker http://trac.edgewall.org/ > Thanks :)
[Mageia-dev] Crashes with Firefox 13 + Flash (inc. fix)
Hi, Just in case others are experiencing this, I've noticed recently that since Cauldron went to Firefox 13 I've seen frequent crashes, most often when interacting with Flash. After getting annoyed enough about it today, I did some digging, got a (rubbish but mildly usable) backtrace and managed to do some educated Googling. I ended up finding this: https://bugzilla.novell.com/show_bug.cgi?id=759123 The suggested solution of installing lib64proxy-webkit and removing lib64proxy-mozjs did the trick. Firefox has been much more stable. Just thought I'd share this with others should they also be suffering the same problem. Depending on how widespread the problem is, we should maybe consider adding conflicts to firefox package on lib*proxy-mozjs. All the best Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] Proposed Feature:Backports_update_applet
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 09/06/2012 22:53, andre999 ha scritto: > - Just marking all backport repos as update repos is almost enough > to solve the problem, in terms of the tools installing the > backports. Great idea ! We just have to tweak the tools so that a > backport is only installed as an update of a backport. e.g. as update repository. great, at least someone got my point, i think i have said that in the beginning of this thread or the related one for mgaupdate... > - using "bp" in the file name is nice and short, and definitively > marks it as a backport for the tools, and for the user once > installed. (I would put it in the revision field.) I like this > approach, as it doesn't matter from where the package is installed; > it will always be recognized as a backport. I'm not a rpm macro guru, but i think we should change mkrel for that and we should also manage bpmga1, bpmga2, etc. So I can't see why, since a bpmgaX package could always be uploaded without respecting any upgradable rules... -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/Tu74ACgkQqEs9DA4DquCBkACbBkHUqbBw9LK+VZeodz8FXDXl +PQAn3hPA4DNcnaFiTDIVNAnCRuvL79E =yhli -END PGP SIGNATURE-
Re: [Mageia-dev] Proposed Feature:Backports_update_applet
blind Pete a écrit : Samuel Verschelde wrote: Following Backports opening due soon, and since our policy is that backports are supported (security, bugfix), we need a way to push backport updates for users who installed backports. Otherwise, we can't really say that we're providing security updates to our backports. My feature proposal is to implement something similar to what mgaonline + MageiaUpdate does for updates, but for backports, with some changes due to the fact that users will rarely want that "all" packages on the system be updated from backports when the backports media are activated. https://wiki.mageia.org/en/Feature:Backports_update_applet I don't think I can do the dev myself. I can work on more detailed specifications with a developer though. Samuel There are a multiple ways that this problem could be handled. Yours is one. Samuel's way: Need "something" to know that a backport package has been installed, to remember that fact, and to do an extra backport update search when looking for updates. It would need to keep working if the user changed desktop environments, or even stopped used a desktop and just used the command line. Does mgaonline do this? There could be room to improve that. If it can be detected that a backport package has been installed (or less efficiently, detect that a backports repository has been activated) set up a cron job (or reconfigure mgaonline) and leave it like that for the life of the installation. Geeks way: Only use urpmi as a command line tool and edit urpmi.cfg with vi. When activating a backports repository mark it as an update repository. Then update with "urpmi --excludemedia [backport media, ...]" accepting all suggestions, followed by "urpmi --auto-select" and look at what is offered before accepting. My suggestion: Add "bp" to the package name and have separate backports update repositories. Users would then be able to cherry pick from backports and updates should _just work_ without extra intervention. The only difficulty that I can think of is, when a backport (or backport update) package is pushed to updates. It would not be necessary to do a real update but the rpm database should be updated such that version N-bp supersedes version N. (And the N-bp packages should be removed from the repositories.) Can anyone see any holes in the logic? What would be easiest to implement? You got me thinking :) - Just marking all backport repos as update repos is almost enough to solve the problem, in terms of the tools installing the backports. Great idea ! We just have to tweak the tools so that a backport is only installed as an update of a backport. - Note that we should allow a non-backport to replace a backport, as will likely be encountered in a release update. If the versioning is properly done (according to established packaging policy), a non-backport in a newer release will have a higher version number, thus replacing the backport. - Functioning as an update, it would only replace already installed backports, once the tools are appropriately adjusted. - As with any update repo, one could always explicitly install a backport which is not already installed. No special treatment is required for this. - using "bp" in the file name is nice and short, and definitively marks it as a backport for the tools, and for the user once installed. (I would put it in the revision field.) I like this approach, as it doesn't matter from where the package is installed; it will always be recognized as a backport. So I'm suggesting a variation of the last 2 solutions. I think that this would be relatively easy to implement. The trick is to find the right place in the code for the tweaks. (tv could probably do it really fast.) -- André
Re: [Mageia-dev] Backports policy clarification (and discussion)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 09/06/2012 20:38, Sander Lepik ha scritto: > I see backports as the way to get some new stuff from cauldron > before cauldron is fully stable. There is no point to backport from > cauldron to n-2 (mga1 at the moment). If the user wants so much > newer stuff s/he better upgrade to latest stable. There could be no point now -and maybe for you-, but it could be in future or for sombody who does not want to update to mga2 yet (kmail2, akonadi, kwallet issues) and want to get some leaf packages for his/her needs (firefox, mondevelop, ...). If we allow bp, and i'm in favor of that, we must consider all the possible cases, and must be able to upgrade to next mgaX without issues due to bp imho. > Cherry-picking for me means that i can upgrade some packages from > backports and then disable the repo. After that i'm still able to > upgrade to fully stable next release (w/o backports). I understood that also, and it should work exactly as we are using XXX_testing for some packages, if bp is approved must work as expected and allow either upgrade or disabling bp. Angelo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/TpUoACgkQqEs9DA4DquAScQCgjj/0Q+vVQsh5otO60oP+nvpo WC8AnjCPUJi0BaJvDJ6R2+GQhZRS36dY =/ukV -END PGP SIGNATURE-
Re: [Mageia-dev] Backports policy clarification (and discussion)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 09/06/2012 12:39, Thomas Backlund ha scritto: >> OK. To backport from Cauldron to mga1, we have to backport from >> >>> Cauldron to mga2, (bumping the revision in cauldron to ensure >>> that is is higher), then backport from mga2 to mga1, ensuring >>> that the revision is lower in mga1 than in mga2.(e.g. >>> revision x.1 in cauldron, x.0.1 in mga2, x.0.0.1 in mga1) >>> Pretty straight forward. >>> > Not needed as 1.mgaX > 1.mga3 > 1.mga2 > 1.mga1 > IIUC the only problem is when in the above situation we have 1.1.mga1 for any reasons (bug fixing for instance, maybe not needed in any mgaX > mga1). I believe in that situation who makes the bug-fixing has to work on other back-ports/updates because in mgaX > mga1 that package could be in core and not in bp. ANgelo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/To1UACgkQqEs9DA4DquCUaACZAbWbqiAWkJ+XYZNXgop/jKz4 IukAoLhCfKvT488tdSia/L/c5HM3gy1N =CRDk -END PGP SIGNATURE-
Re: [Mageia-dev] Backports policy clarification (and discussion)
09.06.2012 13:29, andre999 kirjutas: > OK. To backport from Cauldron to mga1, we have to backport from Cauldron to > mga2, > (bumping the revision in cauldron to ensure that is is higher), then backport > from mga2 to > mga1, ensuring that the revision is lower in mga1 than in mga2.(e.g. > revision x.1 in > cauldron, x.0.1 in mga2, x.0.0.1 in mga1) Pretty straight forward. > > - Cherry-picking refers to the users' option to install a backport, which has > nothing to > do with the packaging itself. > > - Ensure that upgrades never fail : Properly packaged, there is no reason > why any > available backports will not install properly, as long as the tools are > appropriately > adjusted. Backports should install just as reliably as regular updates. > Of course, if a particular backport or update is not available, it won't > install. > Packages requiring it should not install either, which may not always be the > case now. > (This should be verified - for backports and updates.) I see backports as the way to get some new stuff from cauldron before cauldron is fully stable. There is no point to backport from cauldron to n-2 (mga1 at the moment). If the user wants so much newer stuff s/he better upgrade to latest stable. To not fail upgrade you must make sure that n-1 backports are not newer than n +n's updates. You can't enable backports repo at upgrade time or it would upgrade all possible packages from backports repo. I'm quite sure most users don't want that to happen! Cherry-picking for me means that i can upgrade some packages from backports and then disable the repo. After that i'm still able to upgrade to fully stable next release (w/o backports). -- Sander
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release viewvc-1.1.13-2.mga3
On 9 June 2012 18:10, zezinho wrote: > zezinho 0:1.1.13-2.mga3: > + Revision: 258863 > - add a suggests for python-svn, as it does not work on svn repos without it As most people would use SVN these days, I think it's better to usee a require instead
Re: [Mageia-dev] mentors + apprentices
On Tue, 05 Jun 2012 04:26:20 -0400 andre999 wrote: > Hi everyone, > > Since my last post, we have 2 new apprentice candidates looking for a mentor. > > simplew (Pedro), who is a longtime user of various rpm-based distros, is most > interested in Gnome and KDE packages. As you have probably noticed, he has > already been struggling with packaging on his own. His languages are en, pt, > and es. > > agron (Agron Selimaj), an mdv powerpack user since 2006, has skills in C++, > debugging, patch review, and rpm building, and is interested in focusing on > essential packages. > > Others have expressed interest in becoming packagers, but I have yet to > confirm > their interest. > > You can find more details at: > https://wiki.mageia.org/en/Becoming_a_Mageia_Packager#Packager_apprentice_candidates > > Mentors, let me know who you take on, and I'll update the tables for you. > And if you feel that you can take on another apprentice, don't hesitate to > post > to this thread. I'm willing to take on another apprentice as long as they can speak English or Hebrew. Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ Understand what Open Source is - http://shlom.in/oss-fs No one knows all of Perl. Not even Larry Wall. Except Chuck Norris, who knows all of Perl 5, Perl 6, and can answer questions about the design of Perl 7. Please reply to list if it's a mailing list post - http://shlom.in/reply .
Re: [Mageia-dev] Don't get it -
On Sat, 2012-06-09 at 15:32 +0200, Guillaume Rousse wrote: > Le 09/06/2012 15:24, Robert Fox a écrit : > > Error: There has been an error. > > Error running /home/rfox/newshosting-1.2.1/newshosting.sh : > > /home/rfox/newshosting-1.2.1/newshosting: error while loading shared > > libraries: > > libgthread-2.0.so.0: cannot open shared object file: No such file or > > directory > > Press [Enter] to continue : > > > > [rfox@foxbase Downloads]$ locate libgthread-2.0.so.0 > > /lib64/libgthread-2.0.so.0 > > /lib64/libgthread-2.0.so.0.3200.3 > > [rfox@foxbase Downloads]$ > > > > So why is it not finding it when it clearly exists? > Probably because of an architecture mismatch (32 vs 64 bits). > Strange - I installed this on another Cauldron running system (one that I kept upgrading from Mageia 1 to Cauldron) - and it worked even though it was a 64bit install. Now I find out that there are several missing 32bit libraries like libglib2.0_0, libfontconfig1, libXrender, libsm6, libXext6, etc. I don't recall having to install them on the other system to get it to work under a 64bit Mageia. Odd. Thanks - got it to work . . .
Re: [Mageia-dev] Don't get it -
Le 09/06/2012 15:24, Robert Fox a écrit : Error: There has been an error. Error running /home/rfox/newshosting-1.2.1/newshosting.sh : /home/rfox/newshosting-1.2.1/newshosting: error while loading shared libraries: libgthread-2.0.so.0: cannot open shared object file: No such file or directory Press [Enter] to continue : [rfox@foxbase Downloads]$ locate libgthread-2.0.so.0 /lib64/libgthread-2.0.so.0 /lib64/libgthread-2.0.so.0.3200.3 [rfox@foxbase Downloads]$ So why is it not finding it when it clearly exists? Probably because of an architecture mismatch (32 vs 64 bits). -- The bullet that is forgotten while installing an antenna systems will always be at the base of the antenna, and discovered at 5pm on a Friday after the tower crew has left -- Murphy's Laws of Broadcast Engineering n°7
Re: [Mageia-dev] Don't get it -
On Sat, Jun 9, 2012 at 2:24 PM, Robert Fox wrote: > I have a newly installed Mageia 2 box which I then updated to Cauldron - > > When I try to install the Newshosting client (which worked before) - I > get the following: > > > [rfox@foxbase Downloads]$ ./newshosting-1.2.1-linux-installer.run > > Welcome to the Newshosting Setup Wizard. > > > Please specify the directory where Newshosting will be installed. > > Installation Directory [/home/rfox/newshosting-1.2.1]: > > > Setup is now ready to begin installing Newshosting on your computer. > > Do you want to continue? [Y/n]: > > > Please wait while Setup installs Newshosting on your computer. > > Installing > 0% __ 50% __ 100% > # > > > Setup has finished installing Newshosting on your computer. > > Do you want to launch Newshosting now? [Y/n]: > > > Error: There has been an error. > Error running /home/rfox/newshosting-1.2.1/newshosting.sh : > /home/rfox/newshosting-1.2.1/newshosting: error while loading shared > libraries: > libgthread-2.0.so.0: cannot open shared object file: No such file or > directory > Press [Enter] to continue : > > [rfox@foxbase Downloads]$ locate libgthread-2.0.so.0 > /lib64/libgthread-2.0.so.0 > /lib64/libgthread-2.0.so.0.3200.3 > [rfox@foxbase Downloads]$ > > So why is it not finding it when it clearly exists? Random thought: It may want the 32 bits version
[Mageia-dev] Don't get it -
I have a newly installed Mageia 2 box which I then updated to Cauldron - When I try to install the Newshosting client (which worked before) - I get the following: [rfox@foxbase Downloads]$ ./newshosting-1.2.1-linux-installer.run Welcome to the Newshosting Setup Wizard. Please specify the directory where Newshosting will be installed. Installation Directory [/home/rfox/newshosting-1.2.1]: Setup is now ready to begin installing Newshosting on your computer. Do you want to continue? [Y/n]: Please wait while Setup installs Newshosting on your computer. Installing 0% __ 50% __ 100% # Setup has finished installing Newshosting on your computer. Do you want to launch Newshosting now? [Y/n]: Error: There has been an error. Error running /home/rfox/newshosting-1.2.1/newshosting.sh : /home/rfox/newshosting-1.2.1/newshosting: error while loading shared libraries: libgthread-2.0.so.0: cannot open shared object file: No such file or directory Press [Enter] to continue : [rfox@foxbase Downloads]$ locate libgthread-2.0.so.0 /lib64/libgthread-2.0.so.0 /lib64/libgthread-2.0.so.0.3200.3 [rfox@foxbase Downloads]$ So why is it not finding it when it clearly exists? Any help would be welcome.
Re: [Mageia-dev] Backports policy clarification (and discussion)
09.06.2012 13:29, andre999 skrev: > OK. To backport from Cauldron to mga1, we have to backport from > Cauldron to mga2, (bumping the revision in cauldron to ensure that is is > higher), then backport from mga2 to mga1, ensuring that the revision is > lower in mga1 than in mga2.(e.g. revision x.1 in cauldron, x.0.1 in > mga2, x.0.0.1 in mga1) Pretty straight forward. > Not needed as 1.mgaX > 1.mga3 > 1.mga2 > 1.mga1 > - Cherry-picking refers to the users' option to install a backport, > which has nothing to do with the packaging itself. > Oh but it has _everything_ to do with packaging... in order for cherrypicking to work, the deps must be stricter so that any deps in backports gets selected along with the package the user is selecting. -- Thomas
Re: [Mageia-dev] Backports policy clarification (and discussion)
Sander Lepik a écrit : 08.06.2012 11:38, Samuel Verschelde kirjutas: I re-read the backports policy, and there's a part I think needs to be pointed out before people start to backport packages. "We need to ensure that upgrades never fail: cauldron must always have a higher version/release than in stable releases." This statement is true, but implies more than what it says. It means that we can't backport a package for Mageia 1 with a higher version than what we have in Mageia 2 release (and updates?) media. And this, until we are able to take backports into account during upgrades. Example : - Mageia 2 has wesnoth 1.10.2 in core/release - Mageia 1 can't get a higher version in its backports media Do you all agree with my understanding of the policy ? This is a serious limitation to our ability to backport to Mageia (n-1) and even to our ability to provide security fixes to backports there (will not prevent it, but will prevent to do it by a version upgrade, which is the common way to fix that kind of issue in backports). Maybe we shouldn't open backports for Mageia 1, and make sure upgrade to Mageia 3 can take backports from Mageia 2 into account so that backports to Mageia 2 are not stopped when Mageia 3 is released. Then we'll be safe. Samuel I reread the backports policy and there are two lines that make backporting from cauldron to mga1 impossible: * Backports can be cherry-picked (ie, enable backports, install, disable backports). * We need to ensure that upgrades never fail In this regard we can support backports only with new version that is lower than the one on next release. If we want to enable backports for mga1 we can backport only from mga2. Not from cauldron. This way we can submit updates by submitting new backport into mga1 backports repo (users would still have to update manually AFAIK). Any objections? OK. To backport from Cauldron to mga1, we have to backport from Cauldron to mga2, (bumping the revision in cauldron to ensure that is is higher), then backport from mga2 to mga1, ensuring that the revision is lower in mga1 than in mga2.(e.g. revision x.1 in cauldron, x.0.1 in mga2, x.0.0.1 in mga1) Pretty straight forward. - Cherry-picking refers to the users' option to install a backport, which has nothing to do with the packaging itself. - Ensure that upgrades never fail : Properly packaged, there is no reason why any available backports will not install properly, as long as the tools are appropriately adjusted. Backports should install just as reliably as regular updates. Of course, if a particular backport or update is not available, it won't install. Packages requiring it should not install either, which may not always be the case now. (This should be verified - for backports and updates.) -- Sander -- André
Re: [Mageia-dev] Backports policy clarification (and discussion)
blind Pete a écrit : Samuel Verschelde wrote: Le vendredi 8 juin 2012 20:20:54, David W. Hodgins a écrit : On Fri, 08 Jun 2012 10:22:41 -0400, Samuel Verschelde wrote: I think you missed my point. If Mageia 1 "backports" has higher versions than Mageia 2 "release" (not backports), upgrade can fail because currently our tools do not take backports from the target release (mageia 2) into account when upgrading a distro. In the upgrade from Mandriva 2010.2 to Mageia 1, it was made clear, that upgrading from a system with 2010.2 Backports was not supported. It may work, but was not recommended. I think we should keep the same policy for the upgrade from Mageia 1 to 2. I.E. Don't use backports if you are planning on later doing an upgrade, rather then a clean install. That way, Mageia 1 users who want firefox 13 can get it, without us having to replace the Mageia 2 iso images with an upgraded installer, that will keep backports enabled for 2, if it was enabled for 1. Current tools will correctly update backports much of the time. (From my experience.) The tools just need to be reworked somewhat to ensure that backports are updated correctly all of the time. Regards, Dave Hodgins Again, this is not the policy we adopted. When we defined the backports policy (together, although it seems most people are just discovering it now) we said that we didn't want to have backports that don't work, break a system, or prevent upgrade. However, I think that for DVD upgrade without internet access this is a sensible option. But the upgrader should detect the situation itself, not hope that the user will read somewhere in the release notes that it's not supported. No, just include Cauldron's backport repositories (disabled by default) inside the DVD iso. Upgrade to the release version, if possible. If that is not possible, upgrade to the version in backports. Cauldron's backport repos will always be empty. If you introduce a new package, or a new version of an existing package to Cauldron, it is not, by definition, a backport. Even though the same version (not counting the revision) may be a backport for previous releases. So if we do a release update to the latest release, backports will be replaced by regular packages except in those cases where a newer version has been introduced into Cauldron. And if we update to Cauldron, all backports will be replaced by regular packages -- according to our backport policy. And there should be a way for those who have internet access to upgrade online *with* backports too. True, to allow the user to do the release upgrade in one step. Samuel Effectively during release updates, we have to treat backports as updates to installed backports. Because dependancies may differ between releases for the backport, installed backports will always have to be updated. However many users are in a situation where they cannot do online updates when installing a release update, (That is my situation.) So they have to do updates as a separate step. This means that in would be prudent to always treat backports as updates to installed backports, even if not doing a release update. If all backports packages are tagged as backports (in the file name), it will be relatively easy for the tools to recognize and appropriately treat backports. We have to avoid backports of packages that could make the system unbootable, or the major desktops unstartable, but note that this is already more than covered in the backport policy, under "packages scope". In sum, as long as our tools can clearly identify backports, it should be easy to adapt them to properly treat backports. So I think the policy should be changed to always tag backports in the revision part of the file name to facilitate recognition of backports, such as is usually done for "tainted" packages, and sometimes for "nonfree" Maybe to facilitate keeping backports up to date, we should ensure that rpmdrake (and the other tools) include backports in the security and bugfix options. This may already be the case. (While still treating them as backports.) -- André
Re: [Mageia-dev] Backports policy clarification (and discussion)
Sander Lepik wrote: > 09.06.2012 10:06, blind Pete kirjutas: >> andre999 wrote: >> >> [snip] >>> I see your point. >>> In most cases, a backport for mga1 would be essentially identical for >>> mga2 (except package file name and corresponding changes in the spec >>> file). It would only differ if dependancies differ, which I suspect is >>> unlikely for wesnoth or most other games, for example. >>> So this means that for a backport to mga1, we should first do one to >>> mga2. >> [snip] >> >> No. Cauldron then mga2 then mga1. >> > Well, you can't do backport for mga2 if you don't have new version in > cauldron ;) Just trying to be complete. This is the sort of situation where incompleteness becomes ambiguity which becomes a bug. -- blind Pete Sig goes here...
Re: [Mageia-dev] Backports policy clarification (and discussion)
08.06.2012 11:38, Samuel Verschelde kirjutas: > I re-read the backports policy, and there's a part I think needs to be > pointed > out before people start to backport packages. > > "We need to ensure that upgrades never fail: cauldron must always have a > higher version/release than in stable releases." > > This statement is true, but implies more than what it says. It means that we > can't backport a package for Mageia 1 with a higher version than what we have > in Mageia 2 release (and updates?) media. And this, until we are able to take > backports into account during upgrades. > > Example : > - Mageia 2 has wesnoth 1.10.2 in core/release > - Mageia 1 can't get a higher version in its backports media > > Do you all agree with my understanding of the policy ? > > This is a serious limitation to our ability to backport to Mageia (n-1) and > even to our ability to provide security fixes to backports there (will not > prevent it, but will prevent to do it by a version upgrade, which is the > common way to fix that kind of issue in backports). > > Maybe we shouldn't open backports for Mageia 1, and make sure upgrade to > Mageia 3 can take backports from Mageia 2 into account so that backports to > Mageia 2 are not stopped when Mageia 3 is released. Then we'll be safe. > > Samuel I reread the backports policy and there are two lines that make backporting from cauldron to mga1 impossible: * Backports can be cherry-picked (ie, enable backports, install, disable backports). * We need to ensure that upgrades never fail In this regard we can support backports only with new version that is lower than the one on next release. If we want to enable backports for mga1 we can backport only from mga2. Not from cauldron. This way we can submit updates by submitting new backport into mga1 backports repo (users would still have to update manually AFAIK). Any objections? -- Sander
Re: [Mageia-dev] coreutils runuser pam config (aka cyrus-imapd refuses to start on mga2).
08.06.2012 11:54, Colin Guthrie skrev: > @tmb: ping! As you are maintainer I don't want to push this without your > ACK. > > Col > Sorry for missing this earlier. Looks good to me, so "ACK" :) -- Thomas > 'Twas brillig, and Colin Guthrie at 04/06/12 10:50 did gyre and gimble: >> Hi, >> >> After upgrading one of my machines to Mageia 2 I noticed an error >> running cyrus imapd. >> >> In the systemd version it runs a file before executing the daemon: >> /usr/lib/cyrus-imapd/cyr_systemd_helper start >> >> This script (stolen from fedora) uses the "runuser" command from >> coreutils. While I'm not sure I fully appreciate the difference between >> runuser vs. "su -c" we do provide the utility, and thus IMO it should work! >> >> I've applied the same pam configs as fedora use to our coreutils package >> here: >> >> Can someone review? I've tested that that putting these files on my mga2 >> box makes cyrus-imapd run fine. >> >> So if this is OK, it needs to be pushed as an update to Mga2. I'll do >> that once the maintainer (tmb) ACKs it. > > >
Re: [Mageia-dev] Backports policy clarification (and discussion)
09.06.2012 10:06, blind Pete kirjutas: > andre999 wrote: > > [snip] >> I see your point. >> In most cases, a backport for mga1 would be essentially identical for >> mga2 (except package file name and corresponding changes in the spec >> file). It would only differ if dependancies differ, which I suspect is >> unlikely for wesnoth or most other games, for example. >> So this means that for a backport to mga1, we should first do one to mga2. > [snip] > > No. Cauldron then mga2 then mga1. > Well, you can't do backport for mga2 if you don't have new version in cauldron ;) -- Sander
Re: [Mageia-dev] Backports policy clarification (and discussion)
Samuel Verschelde wrote: > Le vendredi 8 juin 2012 20:20:54, David W. Hodgins a écrit : >> On Fri, 08 Jun 2012 10:22:41 -0400, Samuel Verschelde >> > wrote: >> > I think you missed my point. If Mageia 1 "backports" has higher >> > versions than Mageia 2 "release" (not backports), upgrade can fail >> > because currently our tools do not take backports from the target >> > release (mageia 2) into account when upgrading a distro. >> >> In the upgrade from Mandriva 2010.2 to Mageia 1, it was made clear, that >> upgrading from a system with 2010.2 Backports was not supported. It may >> work, but was not recommended. >> >> I think we should keep the same policy for the upgrade from Mageia 1 to >> 2. >> I.E. Don't use backports if you are planning on later doing an upgrade, >> rather then a clean install. >> >> That way, Mageia 1 users who want firefox 13 can get it, without us >> having to replace the Mageia 2 iso images with an upgraded installer, >> that will keep backports enabled for 2, if it was enabled for 1. >> >> Regards, Dave Hodgins > > Again, this is not the policy we adopted. When we defined the backports > policy (together, although it seems most people are just discovering it > now) we said that we didn't want to have backports that don't work, break > a system, or prevent upgrade. > > However, I think that for DVD upgrade without internet access this is a > sensible option. But the upgrader should detect the situation itself, not > hope that the user will read somewhere in the release notes that it's not > supported. No, just include Cauldron's backport repositories (disabled by default) inside the DVD iso. Upgrade to the release version, if possible. If that is not possible, upgrade to the version in backports. > And there should be a way for those who have internet access to upgrade > online *with* backports too. > > Samuel -- blind Pete Sig goes here...
Re: [Mageia-dev] Backports policy clarification (and discussion)
AL13N wrote: > Op vrijdag 8 juni 2012 20:40:04 schreef Samuel Verschelde: >> Le vendredi 8 juin 2012 16:58:24, andre999 a écrit : > [...] >> > But wouldn't current tools update backports if backports are active ? >> >> No, they wouldn't :) > > but isn't this a bug? just like nonfree/tainted... etc... Yes. For a workaround add "update" to /etc/urpmi/urpmi.cfg backports section. > code to detect what you had and use it for next upgrade, would be good. > but that would not be easy, unless we just keep it simple and fallback if > people don't have a standard layout. > > In any case, > > Stormi: what is your suggestion to change in the backport policy? or do > you think we can keep it, but we'd need alot more effort for some > "features"? -- blind Pete Sig goes here...
Re: [Mageia-dev] Backports policy clarification (and discussion)
Samuel Verschelde wrote: > I re-read the backports policy, and there's a part I think needs to be > pointed out before people start to backport packages. I haven't, so if I get things badly wrong don't hesitate to tell me. > "We need to ensure that upgrades never fail: cauldron must always have a > higher version/release than in stable releases." > > This statement is true, but implies more than what it says. It means that > we can't backport a package for Mageia 1 with a higher version than what > we have in Mageia 2 release (and updates?) media. And this, until we are > able to take backports into account during upgrades. > > Example : > - Mageia 2 has wesnoth 1.10.2 in core/release > - Mageia 1 can't get a higher version in its backports media > > Do you all agree with my understanding of the policy ? No. Well assuming that the backports policy is sane, then no. - Mageia 1 can not get a higher version into _updates_ until the new version (or an even higher one) has made its way into Mageia 2 _updates_. - Mageia 1 can not get a higher version into _backports_ until the new version (or an even higher one) has made its way into Mageia 2 _backports_. > This is a serious limitation to our ability to backport to Mageia (n-1) > and even to our ability to provide security fixes to backports there (will > not prevent it, but will prevent to do it by a version upgrade, which is > the common way to fix that kind of issue in backports). I don't see it. Most backports will have a version not higher than the which is provided by the next release and so will just not be a problem. Even in the *very* strange situation that the back ported package has a version number that is higher than that of the next release it is workable, all that is needed is the requirement that backports are not made available to release N before they are made available to release N+1 (Cauldron counts as a release) and that backport media be available at upgrade time. > Maybe we shouldn't open backports for Mageia 1, and make sure upgrade to > Mageia 3 can take backports from Mageia 2 into account so that backports > to Mageia 2 are not stopped when Mageia 3 is released. Then we'll be safe. > > Samuel Extreme hypothetical example: Cauldron Core has long term support FF 29 and Cauldron Backports has this week's official release of FF 41. Mageia 5 gets released with Core and Core Backports. Sensible users get the long term support version. Insane fools who are trying to use the notoriously broken FF 35 get FF 41 (which is broken in a different way). -- blind Pete Sig goes here...
Re: [Mageia-dev] Backports policy clarification (and discussion)
andre999 wrote: [snip] > I see your point. > In most cases, a backport for mga1 would be essentially identical for > mga2 (except package file name and corresponding changes in the spec > file). It would only differ if dependancies differ, which I suspect is > unlikely for wesnoth or most other games, for example. > So this means that for a backport to mga1, we should first do one to mga2. [snip] No. Cauldron then mga2 then mga1. -- blind Pete Sig goes here...
