Re: [Mageia-dev] Update of backport, policy proposal
Someone install version 1.0 from release. So far, so good, but he hear that 1.1 is out, and he install it from backport ( after requesting ). He is satisfied, then the developers of our voip software decide to create a version 2.0, with a completely new interface but the ui is yet unfinished and untranslated, so our user cannot use it. Yet, someone request a backport, and let's assume we do it. With our current scheme, our user will not be affected and he doesn't want to upgrade. So he keep the version 1.1. A security issue is discovered, in 1.X and 2.X. 1.0-2 is sent to release update, with security fix. 2.1 is sent to backport, as the packager follow the list. What should be done for the user : Force upgrade to the next major release ? Ask him to revert to release update ? Tell him this is not supported ? Or maybe we should not have upgraded to 2.0 if we knew that current user would refuse it ? This is exactly why I am against backports. If I am not wrong, Fedora would have pushed 1.1, and therefore 1.1-2 into the regular updates, and 2.0 and therefore 2.1 would rather qualify for the next release of the distro. Of course, another possibility would be to have in backports (or in the regular updates) both mypackage-1.1-2 and mypackage2-2.1-1. Major updates (such as from 1.x to 2.x) would probably ask for changing the base name of the package, so that different versions could coexist in the repo. I really believe that Linux distro maintainers are too narrow-minded. Maybe version 1.1.x of a package brings very few changes against 1.0.x. At the same time, version 1.0.20 of some other package might bring disruptive changes as compared to 1.0.19. It all depends of the upstream developer! So this should be a case-by-case analysis of what can be updated and what must be backported -- because I see that Mandriva's tradition of backporting is going to last in Mageia too. Think of Firefox 5.0. It's rather a 4.0.2. So f* with the version number, check rather the importance of the actual changes in the software! Cheers, R-C aka beranger
Re: [Mageia-dev] Update of backport, policy proposal
A short reality check from userside: If foo-1.0 is in Mageia 1 and foo-1.1 is released upstream - foo-1.1 will likely be integrated in Cauldron very soon after - users will request to have foo-1.1 in Mageia 1 - if Mageia will not provide it then there will soon be local repositories where local packagers will do a backport for their friends. This may not be what Mageia backport policy will allow but we can not avoid people doing and using this, no matter how many warning signs we will publish. This has to be taken into account here. When a policy is found it has to be communicated very well, especially if that policy means that the user can not have foo-1.1 in his stable Mageia 1. This is important because former Mandriva users were used to get almost all new versions backported, if not officially then in 3rd party repos like MIB or MUD. -- wobo
Re: [Mageia-dev] Proposal of a backporting process
Op zondag 26 juni 2011 00:16:59 schreef Michael Scherer: [...] we always say that backports should mainly be cherry picked, but not enabled all the time... so how does installing a new version of e.g. wine break the user's system when he can easily back out that rpm? I a not sure that most people realize they can revert. Maybe a easier interface to do that could be offered ( along maybe with a tool that send feedback on why it did downgrade it ? ). that's not a bad idea, what is the best way to revert? is that with --old- package ? what if the package has been removed on mirrors? (ie: due to more recent updates)
Re: [Mageia-dev] Update of backport, policy proposal
2011/6/26 Wolfgang Bornath molc...@googlemail.com: A short reality check from userside: If foo-1.0 is in Mageia 1 and foo-1.1 is released upstream - foo-1.1 will likely be integrated in Cauldron very soon after - users will request to have foo-1.1 in Mageia 1 - if Mageia will not provide it then there will soon be local repositories where local packagers will do a backport for their friends. This may not be what Mageia backport policy will allow but we can not avoid people doing and using this, no matter how many warning signs we will publish. This has to be taken into account here. When a policy is found it has to be communicated very well, especially if that policy means that the user can not have foo-1.1 in his stable Mageia 1. This is important because former Mandriva users were used to get almost all new versions backported, if not officially then in 3rd party repos like MIB or MUD. -- wobo Hi. I'm following this threat from the very beginning. While reading, i feel i'm reading a Mandriva Cooker mailing list posts. As a community distro, why Mageia developers still think like a Mandriva employee? Why backports and why so many policies, like a commercial enterprise distro? I mean, Mageia do not have paid developers to work on packages all the time. Also Mageia do not have so many packagers like Fedora or Ubuntu, So, why make so many things so hard? As wobo mentioned, people like latest and greatest software. I think, except a few users will use unofficial 3rd party repos to get latest software. While i was maintaining MVT (Mandriva Turkiye) repository, our users asked for GNOME 2.32 while Mandriva have GNOME 2.30 on official release. Personally i always hate the backports structure and policy. It confuses minds. Why Mageia need a backports repo, i really do not understand. Stability and bug free releases are of course a must. But it needs developers dedicated to work, almost paid developers. If a software do not related with core system, like vlc, it should included updates repo. Let upstream fix bugs and security issues. If a packager catchs a bug he should send a patch to upstream and wait for a new release. Otherwise, it is not packaging it is coding, which many potential packgers will avoid to contribute. Look at Debian and Arch Linux who haven't any paid developers but community distros. Stable Debian releases provide software from a century ago for the sake of stability. Arch provides latest software including core system and occaionally have breakages. I think Mageia should be between two of them. Release latest software in updates for non core system and libs, keep core system stable. Remove this backports thingy. My 2 cents...
Re: [Mageia-dev] Proposal of a backporting process
I a not sure that most people realize they can revert. Maybe a easier interface to do that could be offered ( along maybe with a tool that send feedback on why it did downgrade it ? ). that's not a bad idea, what is the best way to revert? is that with --old- package ? Maybe I'm stupid, but rpmdrake does not have any option to downgrade a package. To my knowledge, the only GUI in this world that has such an option (in a menu) is Synaptic, but Synaptic itself ceases to be the default GUI package manager in *buntu 11.11. And man urpmi does not assist the user into downgrading a package. Frankly, I don't know how to protect a package from being updated, the way I can do it with yum (or the way I can hold a package with dpkg, aptitude or dselect). Of course, I am not that familiar with Mageia (or Mandriva), or rather I treated Mageia (and Mandriva) as distros where I should use the GUI tools or the default options of the CLI tools and not bother much -- otherwise, why using mga/mdv and not something else? R-C aka beranger
Re: [Mageia-dev] Update of backport, policy proposal
Le dimanche 26 juin 2011 à 11:49 +0300, Sander Lepik a écrit : 24.06.2011 03:15, Michael Scherer kirjutas: Hi, [ ... ] Last solution, declare that cherry picking is not supported, or that people are on their own, and explain the reason. However, people have been asking this, and recommend this. This would also be against a goal of having confidence in the backports. Again, and as said in the title, this is a proposal so feel free to comment. Reading comments here and knowing that our QA team is in trouble already - i don't see how would QA handle backports. I can also see that there might come time when backports are unpatched and thus unsecure. At what point is QA team mentioned in the process ( which is in another thread ) ? -- Michael Scherer
Re: [Mageia-dev] Update of backport, policy proposal
On Sun, Jun 26, 2011 at 10:58 AM, atilla ontas tarakbu...@gmail.com wrote: Hi. I'm following this threat from the very beginning. While reading, i feel i'm reading a Mandriva Cooker mailing list posts. As a community distro, why Mageia developers still think like a Mandriva employee? Why backports and why so many policies, like a commercial enterprise distro? I mean, Mageia do not have paid developers to work on packages all the time. Also Mageia do not have so many packagers like Fedora or Ubuntu, So, why make so many things so hard? As wobo mentioned, people like latest and greatest software. I think, except a few users will use unofficial 3rd party repos to get latest software. While i was maintaining MVT (Mandriva Turkiye) repository, our users asked for GNOME 2.32 while Mandriva have GNOME 2.30 on official release. Personally i always hate the backports structure and policy. It confuses minds. Why Mageia need a backports repo, i really do not understand. Stability and bug free releases are of course a must. But it needs developers dedicated to work, almost paid developers. If a software do not related with core system, like vlc, it should included updates repo. Let upstream fix bugs and security issues. If a packager catchs a bug he should send a patch to upstream and wait for a new release. Otherwise, it is not packaging it is coding, which many potential packgers will avoid to contribute. +1 I also see no usage of backports. I'm someone quite new to Mandriva/Mageia so I wouldn't know what backports are for (Ubuntu has nothing like this, Fedora too) so why backport? Look at Debian and Arch Linux who haven't any paid developers but community distros. Stable Debian releases provide software from a century ago for the sake of stability. Arch provides latest software including core system and occaionally have breakages. I think Mageia should be between two of them. Release latest software in updates for non core system and libs, keep core system stable. Remove this backports thingy. My 2 cents... This approach looks quite good, but the new software should be tested quite good so the system will not break. Sure core system won't break with this approach but what about the other software? -- Mit freundlichen Grüßen Greetings Daniel Kreuter
Re: [Mageia-dev] Proposal of a backporting process
26.06.2011 12:35, Michael Scherer kirjutas: urpme package; urpmi package That's not so easy if something depends on that package. How hard is it to implement rpm's --oldpackage to urpmi? I really don't know but i hope it's nothing too hard. -- Sander
Re: [Mageia-dev] Proposal of a backporting process
Op zondag 26 juni 2011 12:10:14 schreef Sander Lepik: 26.06.2011 12:35, Michael Scherer kirjutas: urpme package; urpmi package That's not so easy if something depends on that package. How hard is it to implement rpm's --oldpackage to urpmi? I really don't know but i hope it's nothing too hard. that is exactly what i meant, sometimes these can be big dependencies, and i've used once or twice --oldpackage in rpm i guess some extra work could be wanted to have this in urpmi and possibly rpmdrake
Re: [Mageia-dev] Update of backport, policy proposal
Le dimanche 26 juin 2011 à 11:58 +0300, atilla ontas a écrit : 2011/6/26 Wolfgang Bornath molc...@googlemail.com: A short reality check from userside: If foo-1.0 is in Mageia 1 and foo-1.1 is released upstream - foo-1.1 will likely be integrated in Cauldron very soon after - users will request to have foo-1.1 in Mageia 1 - if Mageia will not provide it then there will soon be local repositories where local packagers will do a backport for their friends. This may not be what Mageia backport policy will allow but we can not avoid people doing and using this, no matter how many warning signs we will publish. This has to be taken into account here. When a policy is found it has to be communicated very well, especially if that policy means that the user can not have foo-1.1 in his stable Mageia 1. This is important because former Mandriva users were used to get almost all new versions backported, if not officially then in 3rd party repos like MIB or MUD. -- wobo Hi. I'm following this threat from the very beginning. While reading, i feel i'm reading a Mandriva Cooker mailing list posts. As a community distro, why Mageia developers still think like a Mandriva employee? Why backports and why so many policies, like a commercial enterprise distro? I mean, Mageia do not have paid developers to work on packages all the time. Also Mageia do not have so many packagers like Fedora or Ubuntu, So, why make so many things so hard? If you adequate commercial distro == policy, then I think you missed some steps. Just look at the number of packaging policy on Debian and Fedora. For debian start at http://www.debian.org/doc/debian-policy/ ( and various sub policy : http://www.debian.org/doc/packaging-manuals/ , not to count others that you can find on subteam such as http://pkg-haskell.alioth.debian.org/haskell-policy/ ). For Fedora, just look at : http://fedoraproject.org/wiki/Category:Packaging_guidelines We have open processes and not free-for-all because : - we can be sure that everybody do the same thing and know what can be done or not, ie, work like a community. - we can direct newcomers to the our standard, as telling you will discover by yourself would be quite unfriendly to them. This is therefor required for and by growth. - a goal of a distribution is to have a coherent set of packages ( other wise, we , and to have that, we need to have a coherent set of rules, so they can inter-operate. - we want to set proper expectations. Expectations of those that use the system, because they have the guarantee of stability, or of having newer rpms. Expectation of the packager, because he know what can be done and would fail. As wobo mentioned, people like latest and greatest software. I think, except a few users will use unofficial 3rd party repos to get latest software. While i was maintaining MVT (Mandriva Turkiye) repository, our users asked for GNOME 2.32 while Mandriva have GNOME 2.30 on official release. And others people mentioned that people want also stable software and do not want changes. But as I said, what people want is not as important than what we can do, and so the decision is in the end of those that do the work rather than what people want, because if no one does the work, nothing happen. Personally i always hate the backports structure and policy. It confuses minds. Why Mageia need a backports repo, i really do not understand. Stability and bug free releases are of course a must. But it needs developers dedicated to work, almost paid developers. If a software do not related with core system, like vlc, it should included updates repo. Let upstream fix bugs and security issues. So what you suggest is do like arch ? And when upstream is unable to reproduce the issue ( because he doesn't run the same distribution than the users that report ), what should be done ? If a packager catchs a bug he should send a patch to upstream and wait for a new release. Otherwise, it is not packaging it is coding, which many potential packgers will avoid to contribute. Sending a patch is coding. In fact, the more complex part is not to send a email with the file attached, it is to write the patch. And once you have the patch, it is trivial to apply it to the rpm. So the alternative is either we try to fixng for the bug ( which several packagers are perfectly able to do ), or we wait until it is fixed ( which is usually unsatisfying for the users as some of them will see this as the packager refused to listen to me and fix the bug ). Look at Debian and Arch Linux who haven't any paid developers but community distros. Stable Debian releases provide software from a century ago for the sake of stability. Do not exaggerate. Software in Debian were perfectly fine when they were out, ( usually 1 to 2 year ago ), and now, they are from a century ago ? And as lebahron noted in another thread, several people want stable release. Look
Re: [Mageia-dev] [RPM] cauldron core/release scourge-data-0.21.1-2.mga2
On Sun, Jun 26, 2011 at 1:06 PM, Pascal Terjan pter...@gmail.com wrote: On Wed, Jun 22, 2011 at 10:24, Mageia Team buildsystem-dae...@mageia.org wrote: Name : scourge-data Relocations: (not relocatable) Version : 0.21.1 Vendor: Mageia.Org Release : 2.mga2 Build Date: Wed Jun 22 10:14:40 2011 Install Date: (not installed) Build Host: ecosse Group : Games/Adventure Source RPM: (none) Size : 127698329 License: GPLv2+ Signature : (none) Packager : Mageia Team http://www.mageia.org URL : http://scourgeweb.org/ Summary : Data files for Scourge roguelike game Description : Data files for Scourge roguelike game. zezinho zezinho 0.21.1-2.mga2: + Revision: 111772 - imported package scourge-data This package requires scourge, which is not in the repository yes but it doesn't buidld see : http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20110625200829.dmorgan.valstar.19853/log/scourge-0.21.1-2.mga2/build.0.20110625200903.log
Re: [Mageia-dev] Update of backport, policy proposal
Le dimanche 26 juin 2011 à 11:43 +0200, Daniel Kreuter a écrit : On Sun, Jun 26, 2011 at 10:58 AM, atilla ontas tarakbu...@gmail.com wrote: Hi. I'm following this threat from the very beginning. While reading, i feel i'm reading a Mandriva Cooker mailing list posts. As a community distro, why Mageia developers still think like a Mandriva employee? Why backports and why so many policies, like a commercial enterprise distro? I mean, Mageia do not have paid developers to work on packages all the time. Also Mageia do not have so many packagers like Fedora or Ubuntu, So, why make so many things so hard? As wobo mentioned, people like latest and greatest software. I think, except a few users will use unofficial 3rd party repos to get latest software. While i was maintaining MVT (Mandriva Turkiye) repository, our users asked for GNOME 2.32 while Mandriva have GNOME 2.30 on official release. Personally i always hate the backports structure and policy. It confuses minds. Why Mageia need a backports repo, i really do not understand. Stability and bug free releases are of course a must. But it needs developers dedicated to work, almost paid developers. If a software do not related with core system, like vlc, it should included updates repo. Let upstream fix bugs and security issues. If a packager catchs a bug he should send a patch to upstream and wait for a new release. Otherwise, it is not packaging it is coding, which many potential packgers will avoid to contribute. +1 I also see no usage of backports. I'm someone quite new to Mandriva/Mageia so I wouldn't know what backports are for (Ubuntu has nothing like this, Fedora too) so why backport? It was already explained why in another thread, and this was also answered in the various thread about mirror layout, on the Mandriva page about it on the wiki, on the mailling list at that time, and on various others documentation sources. I really do not have the luxury to explain from scratch everything, so please look at the archive of the ml. And speaking of Ubuntu, there is : https://help.ubuntu.com/community/UbuntuBackports ( or http://wiki.debian.org/Backports for Debian, or the proposal ( that stalled, as said in another thread ) for Fedora : https://fedorahosted.org/fesco/ticket/515 , due to http://fedoraproject.org/wiki/Stable_release_updates_vision ) -- Michael Scherer
Re: [Mageia-dev] Proposal of a backporting process
Le dimanche 26 juin 2011 à 13:10 +0300, Sander Lepik a écrit : 26.06.2011 12:35, Michael Scherer kirjutas: urpme package; urpmi package That's not so easy if something depends on that package. How hard is it to implement rpm's --oldpackage to urpmi? I really don't know but i hope it's nothing too hard. See the thread about policy, and the part about only packages that nothing requires should be backported. Regarding the rollback ( because, that's how it is called ), there is a lot of conference dedicated on this topic, the latest one being that http://www.slideshare.net/johngt/improving-rollback-in-linux-via-dsl-approach-distributing , just before the one I gave about mageia at FOSDEM. You can also take a look at the mancoosi research project, read the discussion over that at cooker@ ( somewhere around http://lists.mandriva.com/cooker/2010-11/msg00401.php ), and read the rest of the thread where it was already proposed : http://www.mageia.org/pipermail/mageia-dev/20101008/001021.html ( point 4 ). -- Michael Scherer
Re: [Mageia-dev] Update of backport, policy proposal
2011/6/26 Michael Scherer m...@zarb.org: Le dimanche 26 juin 2011 à 11:58 +0300, atilla ontas a écrit : 2011/6/26 Wolfgang Bornath molc...@googlemail.com: A short reality check from userside: If foo-1.0 is in Mageia 1 and foo-1.1 is released upstream - foo-1.1 will likely be integrated in Cauldron very soon after - users will request to have foo-1.1 in Mageia 1 - if Mageia will not provide it then there will soon be local repositories where local packagers will do a backport for their friends. This may not be what Mageia backport policy will allow but we can not avoid people doing and using this, no matter how many warning signs we will publish. This has to be taken into account here. When a policy is found it has to be communicated very well, especially if that policy means that the user can not have foo-1.1 in his stable Mageia 1. This is important because former Mandriva users were used to get almost all new versions backported, if not officially then in 3rd party repos like MIB or MUD. -- wobo As wobo mentioned, people like latest and greatest software. I think, except a few users will use unofficial 3rd party repos to get latest software. While i was maintaining MVT (Mandriva Turkiye) repository, our users asked for GNOME 2.32 while Mandriva have GNOME 2.30 on official release. And others people mentioned that people want also stable software and do not want changes. But as I said, what people want is not as important than what we can do, and so the decision is in the end of those that do the work rather than what people want, because if no one does the work, nothing happen. Well, in principle this is correct, not in this case as I have explained as a very common example. You can decide whatever you want, if a user wants a certain package and his friend will pack it for him and puts it up on a server, publishing the existence - then you will see what happens. You know by experience how popular such 3rd-party repos can become (see MIB, MUD), just because somebody had a different view than the official view. In short: no matter what is more important or not, you have to find a compromise between the (understandable) search for optimal workflow, security on one side and the real world of the users on the other. I think, the key here is non-technical communication of the circumstances, like why we can't have foo 1.2 as backport from Cauldron to Mageia 1. -- wobo
Re: [Mageia-dev] Update of backport, policy proposal
Le dimanche 26 juin 2011 à 14:49 +0200, Wolfgang Bornath a écrit : 2011/6/26 Michael Scherer m...@zarb.org: Le dimanche 26 juin 2011 à 11:58 +0300, atilla ontas a écrit : 2011/6/26 Wolfgang Bornath molc...@googlemail.com: A short reality check from userside: If foo-1.0 is in Mageia 1 and foo-1.1 is released upstream - foo-1.1 will likely be integrated in Cauldron very soon after - users will request to have foo-1.1 in Mageia 1 - if Mageia will not provide it then there will soon be local repositories where local packagers will do a backport for their friends. This may not be what Mageia backport policy will allow but we can not avoid people doing and using this, no matter how many warning signs we will publish. This has to be taken into account here. When a policy is found it has to be communicated very well, especially if that policy means that the user can not have foo-1.1 in his stable Mageia 1. This is important because former Mandriva users were used to get almost all new versions backported, if not officially then in 3rd party repos like MIB or MUD. -- wobo As wobo mentioned, people like latest and greatest software. I think, except a few users will use unofficial 3rd party repos to get latest software. While i was maintaining MVT (Mandriva Turkiye) repository, our users asked for GNOME 2.32 while Mandriva have GNOME 2.30 on official release. And others people mentioned that people want also stable software and do not want changes. But as I said, what people want is not as important than what we can do, and so the decision is in the end of those that do the work rather than what people want, because if no one does the work, nothing happen. Well, in principle this is correct, not in this case as I have explained as a very common example. You can decide whatever you want, if a user wants a certain package and his friend will pack it for him and puts it up on a server, publishing the existence - then you will see what happens. You know by experience how popular such 3rd-party repos can become (see MIB, MUD), just because somebody had a different view than the official view. Then someone did it the job. Maybe not correctly from a technical point of view, with all the problem this can create ( lack of audit and reproductability, as I seen while trying to understand MIB stuff, non integration with the rest of the distribution, since this requires to type command line etc, breakage of stuff like upgrade of version ), but still did the work. Of course, most of the time, that's not sustainable, but who really care about that... In short: no matter what is more important or not, you have to find a compromise between the (understandable) search for optimal workflow, security on one side and the real world of the users on the other. Can people please stop saying that users are living in the real world, as this logically imply that others ( ie, us, for whatever that mean ) are not ? Optimal workflow is solving a real problem for ressources, with impact on the distribution. Security is a real problem too. That's not because some people do not see a problem that it doesn't existe or that it is a fake one. -- Michael Scherer
Re: [Mageia-dev] Update of backport, policy proposal
2011/6/26 Michael Scherer m...@zarb.org: Can people please stop saying that users are living in the real world, as this logically imply that others ( ie, us, for whatever that mean ) are not ? LOL! I did not expect that you take the single word over the expression. When I set you, me, whoever, in difference to the real world it is meant as the technical discussion under the hood vs the practical daily usage of the system by a non-technical user. A difference which is real. Hopefully this is clearer now. -- wobo
Re: [Mageia-dev] [RPM] cauldron core/release scourge-data-0.21.1-2.mga2
Le dimanche 26 juin 2011 13:17:27, Dexter Morgan a écrit : This package requires scourge, which is not in the repository yes but it doesn't buidld see : http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/201106252 00829.dmorgan.valstar.19853/log/scourge-0.21.1-2.mga2/build.0.2011062520090 3.log It build on i586, not in x86_64. I asked for help here, and made a bug report https://bugs.mageia.org/show_bug.cgi?id=1901
Re: [Mageia-dev] Backports policy proposal
On 26.06.2011 01:34, Michael Scherer wrote: Le vendredi 24 juin 2011 à 17:33 +0300, Anssi Hannula a écrit : On 24.06.2011 03:10, Michael Scherer wrote: Another rule that we could add is that cauldron should always be newer than backports, in order to ensure upgradability. The same goes for n-2 and n-1 release. While this seems innocent, do not forget this will have a impact when we do the version freeze. So this will prevent backporting anything to mga1 if it is not in mga2 release/updates ? That's a good question but yes, I would consider such policy. Ie, do backport only for the latest supported release. This will essentially prevent backporting anything to mga1 after mga2 release. :/ -- Anssi Hannula
Re: [Mageia-dev] Backports policy proposal
In data domenica 26 giugno 2011 00:43:22, Michael Scherer ha scritto: Le samedi 25 juin 2011 à 15:05 +0200, Angelo Naselli a écrit : In data venerdì 24 giugno 2011 02:10:14, Michael Scherer ha scritto: - cannot be backported if the package was just created and is thus basically untested in cauldron Well even if i could agree with that, i cannot see how can we ensure that a 2-3 weeks presence in cauldron means that the package has been tested by someone... we can only suppose to... a 0 week presence basically mean no test, so it can only improve the chance of being tested. Agree, but the same chance as we put in backport_testing - or what name is- first. -- Angelo signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] Backports policy proposal
Le dimanche 26 juin 2011 à 18:00 +0300, Anssi Hannula a écrit : On 26.06.2011 01:34, Michael Scherer wrote: Le vendredi 24 juin 2011 à 17:33 +0300, Anssi Hannula a écrit : On 24.06.2011 03:10, Michael Scherer wrote: Another rule that we could add is that cauldron should always be newer than backports, in order to ensure upgradability. The same goes for n-2 and n-1 release. While this seems innocent, do not forget this will have a impact when we do the version freeze. So this will prevent backporting anything to mga1 if it is not in mga2 release/updates ? That's a good question but yes, I would consider such policy. Ie, do backport only for the latest supported release. This will essentially prevent backporting anything to mga1 after mga2 release. :/ Yes, that's explicitly the problem. Now, maybe we could say if you use backports on version N after the release of N+1, then mgaonline will no longer work. Provided we find a user friendly way to warn users, we can maybe find something. But again, it is either the backports or the upgrade. And people do have expressed to have both : - reinstalling at every release is hard and annoying, why not do like Ubuntu and Debian ? - We want newer software, why not provides newer version ? So we either need a way to solve the dilemma, or at least, a way to clearly explain the impact to people. I think I may have a idea that would solve this issue and the one of update, but I need to think a little bit before proposing it ( especially since I suffer from common cold, maybe my idea is completely rubbish ). -- Michael Scherer
Re: [Mageia-dev] Update of backport, policy proposal
Well, in principle this is correct, not in this case as I have explained as a very common example. You can decide whatever you want, if a user wants a certain package and his friend will pack it for him and puts it up on a server, publishing the existence - then you will see what happens. You know by experience how popular such 3rd-party repos can become (see MIB, MUD), just because somebody had a different view than the official view. In short: no matter what is more important or not, you have to find a compromise between the (understandable) search for optimal workflow, security on one side and the real world of the users on the other. I think, the key here is non-technical communication of the circumstances, like why we can't have foo 1.2 as backport from Cauldron to Mageia 1. Well I'm one who backports what he needs, doesn't mean all, just what needs. I always enable backports, and i know often how to go on if a backport was broken. That's not a point though. I can't see why people that want last release of all must trust 3rd-party repos and do not mageia(or mandriva) backport one... it's really hard to me. I think we can, as said by someone, release all as updates, but we can also consider to have a tested and reliable backport repository (call as you wish maybe next or after :) ) but the real concept to me is that we should have the availability to get new sw or version of a sw in a repository that could be different than updates, *could* because case by case we could consider to add them in updates and in any case that should be reliable, no breakages, no regressions. We talked about patches, and sometime we could patch sw, but sometime it's hard, and updates with an upgrade of such a sw should be the best thing to do. Cheers, -- Angelo signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] autologin + consolekit
'Twas brillig, and Colin Guthrie at 14/06/11 09:07 did gyre and gimble: 'Twas brillig, and Colin Guthrie at 12/06/11 23:45 did gyre and gimble: Hi, The autologin package is broken due to the fact that it doesn't connect to consolekit and thus the user who is automatically logged in doesn't get any permissions etc. I've fixed this by changing the autologin pam.d definition to include login rather than system-auth. login adds the optional session module for pam_ck_connector. But I'm not sure whether this makes sense, or whether we should just add the ck_connector to the autologin pam.d definition itself. There may be other login systems that have similar problems (e.g. the autologin features of gdm or slim etc) but I've not tested. Any thoughts. Does anyone know what the right way to fix the above is? I'd like to issue an update when appropriate to take care of this. Ping!! Col -- Colin Guthrie mageia(at)colin.guthr.ie 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] [114150] downgrade to Version: 1
On Sun, Jun 26, 2011 at 9:15 PM, r...@mageia.org wrote: Revision 114150 Author spuhler Date 2011-06-26 21:14:59 +0200 (Sun, 26 Jun 2011) Log Message downgrade to Version: 1 add subrel 1 for mga 1 updates why do you add subrel in cauldron ?
Re: [Mageia-dev] [114173] added define subrel 1 to submit to Mageia1 updates
On Sun, Jun 26, 2011 at 9:34 PM, r...@mageia.org wrote: Revision 114173 Author spuhler Date 2011-06-26 21:34:20 +0200 (Sun, 26 Jun 2011) Log Message added define subrel 1 to submit to Mageia1 updates Please modify in the update/1 tree for updates not in the cauldron one
Re: [Mageia-dev] Updates process is now available
On Tuesday, June 21, 2011 09:57:22 am Damien Lallement wrote: Hello all, security, qa and sysadmin team worked on the qa/updates process to provide updates as soon as possible. All is now ready (boklm is finalizing a scrip to move updates from testing to updates). This script will be uses by security team members and a few QA people to push updates. You can now read: - http://www.mageia.org/wiki/doku.php?id=updates_policy - http://www.mageia.org/wiki/doku.php?id=qa_updates A new ML has been created: qa-b...@ml.mageia.org. It will receive all the updates requests and will be the main QA contact for bugzilla. You can join it if you want to be part of the QA people working on updates (security or not). A saved search has been added to bugzilla to catch all updates waiting for QA validation: https://bugs.mageia.org/buglist.cgi?cmdtype=runnamednamedcmd=Updates%20wai ting%20for%20QA For more info, please ask here on on #mageia-dev or #mageia-qa Let's go to work on updates! This seems not to be working for me. I am getting an error: error: command failed: ssh pkgsubmit.mageia.org /usr/local/bin/submit_package -t 1 --define sid=9ed21bb1-462a-4c5b-9fa3-78e433ccc363 --define section=core/updates_testing -r 114150 svn+ssh://svn.mageia.org/svn/packages/cauldron/kolab-webadmin error: svn+ssh://svn.mageia.org/svn/packages/cauldron/kolab-webadmin is not allowed for this target (BTW on the web page it shows as -define section = instead of --define section) -- Thomas
Re: [Mageia-dev] Updates process is now available
On Sun, Jun 26, 2011 at 9:39 PM, Thomas Spuhler tho...@btspuhler.com wrote: On Tuesday, June 21, 2011 09:57:22 am Damien Lallement wrote: Hello all, security, qa and sysadmin team worked on the qa/updates process to provide updates as soon as possible. All is now ready (boklm is finalizing a scrip to move updates from testing to updates). This script will be uses by security team members and a few QA people to push updates. You can now read: - http://www.mageia.org/wiki/doku.php?id=updates_policy - http://www.mageia.org/wiki/doku.php?id=qa_updates A new ML has been created: qa-b...@ml.mageia.org. It will receive all the updates requests and will be the main QA contact for bugzilla. You can join it if you want to be part of the QA people working on updates (security or not). A saved search has been added to bugzilla to catch all updates waiting for QA validation: https://bugs.mageia.org/buglist.cgi?cmdtype=runnamednamedcmd=Updates%20wai ting%20for%20QA For more info, please ask here on on #mageia-dev or #mageia-qa Let's go to work on updates! This seems not to be working for me. I am getting an error: error: command failed: ssh pkgsubmit.mageia.org /usr/local/bin/submit_package -t 1 --define sid=9ed21bb1-462a-4c5b-9fa3-78e433ccc363 --define section=core/updates_testing -r 114150 svn+ssh://svn.mageia.org/svn/packages/cauldron/kolab-webadmin error: svn+ssh://svn.mageia.org/svn/packages/cauldron/kolab-webadmin is not allowed for this target (BTW on the web page it shows as -define section = instead of --define section) -- Thomas because you need to modify on the update branch of the SVN mgarepo -d 1 kolab-webadmin
Re: [Mageia-dev] [114173] added define subrel 1 to submit to Mageia1 updates
On Mon, Jun 27, 2011 at 12:59 AM, Thomas Spuhler tho...@btspuhler.com wrote: On Sunday, June 26, 2011 12:37:29 pm Dexter Morgan wrote: On Sun, Jun 26, 2011 at 9:34 PM, r...@mageia.org wrote: Revision 114173 Author spuhler Date 2011-06-26 21:34:20 +0200 (Sun, 26 Jun 2011) Log Message added define subrel 1 to submit to Mageia1 updates Please modify in the update/1 tree for updates not in the cauldron one Did I do better now? -- Thomas now this is perfect :) ( btw have you removed subrel from the cauldron tree ? )
Re: [Mageia-dev] [114173] added define subrel 1 to submit to Mageia1 updates
On Sunday, June 26, 2011 04:24:26 pm Dexter Morgan wrote: On Mon, Jun 27, 2011 at 12:59 AM, Thomas Spuhler tho...@btspuhler.com wrote: On Sunday, June 26, 2011 12:37:29 pm Dexter Morgan wrote: On Sun, Jun 26, 2011 at 9:34 PM, r...@mageia.org wrote: Revision 114173 Author spuhler Date 2011-06-26 21:34:20 +0200 (Sun, 26 Jun 2011) Log Message added define subrel 1 to submit to Mageia1 updates Please modify in the update/1 tree for updates not in the cauldron one Did I do better now? -- Thomas now this is perfect :) ( btw have you removed subrel from the cauldron tree ? ) yep -- Thomas
Re: [Mageia-dev] Updates going to Release?
On 27 June 2011 03:11, David W. Hodgins davidwhodg...@gmail.com wrote: On my Mageia 1 install ... urpmi --auto-select --resume --noclean To satisfy dependencies, the following packages are going to be installed: Package Version Release Arch (medium Core Release) libxine1 1.1.19 5.mga1 i586 (medium Tainted Release) libvlc-devel 1.1.9 4.mga1.taint i586 I thought updates, and new programs would go to Core Updates, and Tainted updates, not Release. That way the release synthesis.hdlist.cz wouldn't get changed. Regards, Dave Hodgins vlc-1.1.9-4.mga1.tainted existed in the tainted/release repo before Mageia 1 was ever released, so it's not an update. Tainted packages have a higher EVR than core ones (vlc-1.1.9-4.mga1.i586 vs. vlc-1.1.9-4.mga1.tainted.i586), hence urpmi proposed to replace vlc from core by vlc from tainted. -- Ahmad Samir
