[Mageia-dev] Discrepancy between /etc/version and /etc/release - which one for MIRRORLIST
Hi, after some discussion in the German forums, I saw, that there are discrepancies between /etc/version and /etc/release, both coming from the mageia-release-common-1-2.mga1 package. While /etc/release calls my system -- Mageia release 1 (Official) for i586 -- it is called -- 1 2 cauldron -- by /etc/version. Which one of those defines the branch used by MIRRORLIST and shouldn't both of those be telling my the same thing? Oliver
Re: [Mageia-dev] Discrepancy between /etc/version and /etc/release - which one for MIRRORLIST
On Wed, 08 Jun 2011, Oliver Burger wrote:
Hi,
after some discussion in the German forums, I saw, that there are
discrepancies between /etc/version and /etc/release, both coming from
the mageia-release-common-1-2.mga1 package.
While /etc/release calls my system
--
Mageia release 1 (Official) for i586
--
it is called
--
1 2 cauldron
--
by /etc/version.
In mageia-release package :
echo %{version} %{rel} %{distname} $RPM_BUILD_ROOT/etc/version
So /etc/version contains both the version and release of mageia-release
package. But maybe there is a problem with %{distname}.
[Mageia-dev] Tonight's meeting
Hi there Now that release is out, let restart our weekly meetings on #mageia-dev at 19h UTC. Here are the topics: - short review of Mageia 1 launch - organize post-portem for packagers team - start brainstorm on release cycle - relaunch mentoring As usual feel free to comment or propose any other topic Cheers -- Anne http://www.mageia.org
[Mageia-dev] Finalizing update process
Hi there We have some stuff to complete here: http://mageia.org/wiki/doku.php?id=security http://mageia.org/wiki/doku.php?id=securityCan we spend the 2 or 3 coming days to finalize it and start updates submits? Cheers -- Anne http://www.mageia.org
Re: [Mageia-dev] Looking for a mentor
Hi Matteo, can you please answer to mailing list instead to the sender, other people can hardly follow the thread otherwise :) Thanks Angelo signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] Discrepancy between /etc/version and /etc/release - which one for MIRRORLIST
On 08/06/11 08:42, Oliver Burger wrote: Hi, after some discussion in the German forums, I saw, that there are discrepancies between /etc/version and /etc/release, both coming from the mageia-release-common-1-2.mga1 package. While /etc/release calls my system -- Mageia release 1 (Official) for i586 -- it is called -- 1 2 cauldron -- by /etc/version. Which one of those defines the branch used by MIRRORLIST I thought that /etc/product.id was used. Jim
Re: [Mageia-dev] Tonight's meeting
2011/6/8 Anne nicolas enn...@mageia.org Hi there Now that release is out, let restart our weekly meetings on #mageia-dev at 19h UTC. Here are the topics: - short review of Mageia 1 launch - organize post-portem for packagers team - start brainstorm on release cycle - relaunch mentoring adding - start and organize discussions about first technical specifications As usual feel free to comment or propose any other topic Cheers -- Anne http://www.mageia.org -- Anne http://www.mageia.org
Re: [Mageia-dev] Finalizing update process
Le mercredi 08 juin 2011 à 10:40 +0200, Anne nicolas a écrit : Hi there We have some stuff to complete here: http://mageia.org/wiki/doku.php?id=security http://mageia.org/wiki/doku.php?id=securityCan we spend the 2 or 3 coming days to finalize it and start updates submits? Pascal is working on this. So here is a proposal : - anybody can submit a package to updates_testing. - once submitted to testing, it should ask to QA to test, along with : - a reason for the update ( likely bug number ) - potentially a priority ( ie, if this is just a translation update or a urgent 0 day exploit ) - a way to test the bug and see it is fixed - text for the update - qa validate the update ( with process to define ) - someone move the package from updates_testing to testing - the bug is closed - a announce is sent ( on various medias to be defined ), with the text of update So the points are : - no update can be uploaded without QA validation - QA manage the checks, and so will requires help ( hence the security team or any packager can help, provided they know how to do QA ) -- Michael Scherer
Re: [Mageia-dev] Finalizing update process
On 8 June 2011 18:44, Michael Scherer m...@zarb.org wrote: Le mercredi 08 juin 2011 à 10:40 +0200, Anne nicolas a écrit : Hi there We have some stuff to complete here: http://mageia.org/wiki/doku.php?id=security http://mageia.org/wiki/doku.php?id=securityCan we spend the 2 or 3 coming days to finalize it and start updates submits? Pascal is working on this. So here is a proposal : - anybody can submit a package to updates_testing. - once submitted to testing, it should ask to QA to test, along with : - a reason for the update ( likely bug number ) - potentially a priority ( ie, if this is just a translation update or a urgent 0 day exploit ) - a way to test the bug and see it is fixed - text for the update - qa validate the update ( with process to define ) - someone move the package from updates_testing to testing Isn't it cleaner to rebuild when submitting to */updates? instead of moving. - the bug is closed - a announce is sent ( on various medias to be defined ), with the text of update So the points are : - no update can be uploaded without QA validation - QA manage the checks, and so will requires help ( hence the security team or any packager can help, provided they know how to do QA ) -- Michael Scherer -- Ahmad Samir
Re: [Mageia-dev] Finalizing update process
On Wed, 8 Jun 2011, Michael Scherer wrote: Le mercredi 08 juin 2011 à 10:40 +0200, Anne nicolas a écrit : Hi there We have some stuff to complete here: http://mageia.org/wiki/doku.php?id=security http://mageia.org/wiki/doku.php?id=securityCan we spend the 2 or 3 coming days to finalize it and start updates submits? Pascal is working on this. So here is a proposal : - anybody can submit a package to updates_testing. - once submitted to testing, it should ask to QA to test, along with : - a reason for the update ( likely bug number ) - potentially a priority ( ie, if this is just a translation update or a urgent 0 day exploit ) - a way to test the bug and see it is fixed - text for the update - qa validate the update ( with process to define ) - someone move the package from updates_testing to testing Someone from security (stable updates) team I guess? - the bug is closed - a announce is sent ( on various medias to be defined ), with the text of update So who decides to reject an update and at what point? According to your proposal, either QA people decide this or they waste time on updates that later get rejected. So the points are : - no update can be uploaded without QA validation What does 'QA validation' mean exactly, can only certain people do it...? - QA manage the checks, and so will requires help ( hence the security team or any packager can help, provided they know how to do QA ) So a packager wants to fix a bug in package that is not very visible, sends it to QA, then has to test it anyway? I'm not sure what you're saying here. Christiaan
Re: [Mageia-dev] Finalizing update process
On 8 June 2011 19:39, Ahmad Samir ahmadsamir3...@gmail.com wrote: On 8 June 2011 18:57, Christiaan Welvaart c...@daneel.dyndns.org wrote: On Wed, 8 Jun 2011, Michael Scherer wrote: Le mercredi 08 juin 2011 à 10:40 +0200, Anne nicolas a écrit : Hi there We have some stuff to complete here: http://mageia.org/wiki/doku.php?id=security http://mageia.org/wiki/doku.php?id=securityCan we spend the 2 or 3 coming days to finalize it and start updates submits? Pascal is working on this. So here is a proposal : - anybody can submit a package to updates_testing. - once submitted to testing, it should ask to QA to test, along with : - a reason for the update ( likely bug number ) - potentially a priority ( ie, if this is just a translation update or a urgent 0 day exploit ) - a way to test the bug and see it is fixed - text for the update - qa validate the update ( with process to define ) - someone move the package from updates_testing to testing Someone from security (stable updates) team I guess? - the bug is closed - a announce is sent ( on various medias to be defined ), with the text of update So who decides to reject an update and at what point? According to your proposal, either QA people decide this or they waste time on updates that later get rejected. IMHO, rejection reasons: - The sec team doesn't think the update fixes a serious security vulnerability; so it's not updates but backports - The QA team couldn't validate, i.e. using the test case in the bug report, their test results didn't show that the bug is fixed Adding to this: - the bug is fixed, but it caused regressions somewhere else in the package itself, or in packages depending on it. So the points are : - no update can be uploaded without QA validation What does 'QA validation' mean exactly, can only certain people do it...? IIUC, QA validation is that they use the test case given in the report; an example of a test case: - install package foo-1mga1 from */release - do foo bar, notice the app crashes - install the fixed package foo-1.1mga1 from */updates_testing - test again, the bug should be fixed if any of these steps fail, then it's not gonna get pushed as an update. And it should be the QA team doing the validation, i.e. experienced devs/packagers in the that team. - QA manage the checks, and so will requires help ( hence the security team or any packager can help, provided they know how to do QA ) So a packager wants to fix a bug in package that is not very visible, sends it to QA, then has to test it anyway? I'm not sure what you're saying here. Not the packager committing the fix, (if he doesn't think it's fixed he won't ask for an update to begin with). But the QA team, this team could/should have packagers in it. Christiaan -- Ahmad Samir -- Ahmad Samir
Re: [Mageia-dev] Discrepancy between /etc/version and /etc/release - which one for MIRRORLIST
On 8 June 2011 14:10, James Kerr j...@jkerr82508.free-online.co.uk wrote: On 08/06/11 08:42, Oliver Burger wrote: Hi, after some discussion in the German forums, I saw, that there are discrepancies between /etc/version and /etc/release, both coming from the mageia-release-common-1-2.mga1 package. While /etc/release calls my system -- Mageia release 1 (Official) for i586 -- it is called -- 1 2 cauldron -- by /etc/version. Which one of those defines the branch used by MIRRORLIST I thought that /etc/product.id was used. Jim AFAIK, yes, /etc/product.id is what urpmi uses to parse the MIRRORLIST parameters. -- Ahmad Samir
Re: [Mageia-dev] Finalizing update process
Le mercredi 8 juin 2011 19:39:55, Ahmad Samir a écrit : IMHO, rejection reasons: - The sec team doesn't think the update fixes a serious security vulnerability; so it's not updates but backports What about bugfix updates ? I guess fixing a bug is a valid reason for an update, like it was in Mandriva's updates. Regards Samuel
Re: [Mageia-dev] Finalizing update process
On 8 June 2011 21:45, Samuel Verschelde sto...@laposte.net wrote: Le mercredi 8 juin 2011 19:39:55, Ahmad Samir a écrit : IMHO, rejection reasons: - The sec team doesn't think the update fixes a serious security vulnerability; so it's not updates but backports What about bugfix updates ? I guess fixing a bug is a valid reason for an update, like it was in Mandriva's updates. Regards Samuel Right, I probably phrased that one wrongly; I meant: fixes a serious bug, e.g. crashing, segfaulting -- Ahmad Samir
[Mageia-dev] mageia sound task
after 6 month of pausing this topic I would like to reactivate it. Now that release 1 is out it might be woth for further toughts and a lot of fun work :) http://www.mageia.org/wiki/doku.php?id=soundstudio I didn't rest thinking on this idea: my latest idea is to mame a bash-script with dialog to configure proaudio on mageia. Join if you like and share your ideas :) Greetings from belgium, sascha
Re: [Mageia-dev] mageia sound task
Le mercredi 8 juin 2011 22:28:30, Sascha Schneider a écrit : my latest idea is to mame a bash-script with dialog to configure proaudio on mageia. What do you mean by 'configure proaudio'? I think the only needed thing is pasuspender jackd to use proaudio tools.
Re: [Mageia-dev] mageia sound task
Hi Jose, I meant .. configure mageia to use this distro for professional audio stuff, like ardour, qtractor, qmidiarp 2011/6/8 José Jorge jjo...@free.fr: Le mercredi 8 juin 2011 22:28:30, Sascha Schneider a écrit : my latest idea is to mame a bash-script with dialog to configure proaudio on mageia. What do you mean by 'configure proaudio'? I think the only needed thing is pasuspender jackd to use proaudio tools.
Re: [Mageia-dev] Finalizing update process
Le mercredi 08 juin 2011 à 19:48 +0300, Ahmad Samir a écrit : On 8 June 2011 18:44, Michael Scherer m...@zarb.org wrote: Le mercredi 08 juin 2011 à 10:40 +0200, Anne nicolas a écrit : Hi there We have some stuff to complete here: http://mageia.org/wiki/doku.php?id=security http://mageia.org/wiki/doku.php?id=securityCan we spend the 2 or 3 coming days to finalize it and start updates submits? Pascal is working on this. So here is a proposal : - anybody can submit a package to updates_testing. - once submitted to testing, it should ask to QA to test, along with : - a reason for the update ( likely bug number ) - potentially a priority ( ie, if this is just a translation update or a urgent 0 day exploit ) - a way to test the bug and see it is fixed - text for the update - qa validate the update ( with process to define ) - someone move the package from updates_testing to testing Isn't it cleaner to rebuild when submitting to */updates? instead of moving. Well, that depend on the way package is built. In fact, it should not matter much, as we should not do a change that could break a existing software in update, and so this should be the same in updates_testing ( ie, they should be the same wrto ABI ) But that's also why I ask here :) -- Michael Scherer
Re: [Mageia-dev] Finalizing update process
On 06/08/2011 05:31 PM, Michael Scherer wrote: Le mercredi 08 juin 2011 à 19:48 +0300, Ahmad Samir a écrit : On 8 June 2011 18:44, Michael Schererm...@zarb.org wrote: Le mercredi 08 juin 2011 à 10:40 +0200, Anne nicolas a écrit : Hi there We have some stuff to complete here: http://mageia.org/wiki/doku.php?id=security http://mageia.org/wiki/doku.php?id=securityCan we spend the 2 or 3 coming days to finalize it and start updates submits? Pascal is working on this. So here is a proposal : - anybody can submit a package to updates_testing. - once submitted to testing, it should ask to QA to test, along with : - a reason for the update ( likely bug number ) - potentially a priority ( ie, if this is just a translation update or a urgent 0 day exploit ) - a way to test the bug and see it is fixed - text for the update - qa validate the update ( with process to define ) - someone move the package from updates_testing to testing Isn't it cleaner to rebuild when submitting to */updates? instead of moving. Well, that depend on the way package is built. In fact, it should not matter much, as we should not do a change that could break a existing software in update, and so this should be the same in updates_testing ( ie, they should be the same wrto ABI ) But that's also why I ask here :) If you're going to rebuild *after* QA, you've just invalidated your QA. (yeah, I know it *should* be the same, but stuff happens) -- Stew Benedict New Tazewell, TN
Re: [Mageia-dev] Finalizing update process
On 8 June 2011 23:38, Stew Benedict stewbi...@gmail.com wrote: On 06/08/2011 05:31 PM, Michael Scherer wrote: Le mercredi 08 juin 2011 à 19:48 +0300, Ahmad Samir a écrit : On 8 June 2011 18:44, Michael Schererm...@zarb.org wrote: Le mercredi 08 juin 2011 à 10:40 +0200, Anne nicolas a écrit : Hi there We have some stuff to complete here: http://mageia.org/wiki/doku.php?id=security http://mageia.org/wiki/doku.php?id=securityCan we spend the 2 or 3 coming days to finalize it and start updates submits? Pascal is working on this. So here is a proposal : - anybody can submit a package to updates_testing. - once submitted to testing, it should ask to QA to test, along with : - a reason for the update ( likely bug number ) - potentially a priority ( ie, if this is just a translation update or a urgent 0 day exploit ) - a way to test the bug and see it is fixed - text for the update - qa validate the update ( with process to define ) - someone move the package from updates_testing to testing Isn't it cleaner to rebuild when submitting to */updates? instead of moving. Well, that depend on the way package is built. In fact, it should not matter much, as we should not do a change that could break a existing software in update, and so this should be the same in updates_testing ( ie, they should be the same wrto ABI ) But that's also why I ask here :) If you're going to rebuild *after* QA, you've just invalidated your QA. (yeah, I know it *should* be the same, but stuff happens) You're right (even if that's never happened for 3-4 years in mdv, since sec team rebuilt the packages when pushing to */updates IIRC). -- Stew Benedict New Tazewell, TN -- Ahmad Samir
Re: [Mageia-dev] Finalizing update process
On 8 June 2011 23:40, Anssi Hannula anssi.hann...@iki.fi wrote: On 08.06.2011 23:23, Ahmad Samir wrote: On 8 June 2011 21:45, Samuel Verschelde sto...@laposte.net wrote: Le mercredi 8 juin 2011 19:39:55, Ahmad Samir a écrit : IMHO, rejection reasons: - The sec team doesn't think the update fixes a serious security vulnerability; so it's not updates but backports What about bugfix updates ? I guess fixing a bug is a valid reason for an update, like it was in Mandriva's updates. Regards Samuel Right, I probably phrased that one wrongly; I meant: fixes a serious bug, e.g. crashing, segfaulting I don't think we should exclude non-serious bugs :) Depends, overworking the sec team doesn't look like a good aspect... (that's why I liked contrib in mdv, I could push an update any time, without having to go though the bug report - QA - Sec team loop). (or version updates in some cases, like firefox/opera/flash or updating an rc/beta version to a stable one, and maybe some online games that are useless unless on latest version) I agree, (except for the games part, nowadays if it's less than 4GB it's not really a game). Maybe the sec team should only work on sec fixes, and there should be a sub-group of the sec team that handle the not CVE|crash|segfaulting|buffer-overflow updates. -- Anssi Hannula -- Ahmad Samir
Re: [Mageia-dev] Finalizing update process
Le mercredi 08 juin 2011 à 20:39 +0300, Ahmad Samir a écrit : On 8 June 2011 18:57, Christiaan Welvaart c...@daneel.dyndns.org wrote: So who decides to reject an update and at what point? According to your proposal, either QA people decide this or they waste time on updates that later get rejected. IMHO, rejection reasons: - The sec team doesn't think the update fixes a serious security vulnerability; so it's not updates but backports I would say that there is no version upgrade, unless exception. - The QA team couldn't validate, i.e. using the test case in the bug report, their test results didn't show that the bug is fixed Yup. Or someone detected a regression. ( like 'I installed foo-1.0-1 but it opened a dimensional vortex to hell', as it happened on the QA testing facility of Phobos in Doom ) - QA manage the checks, and so will requires help ( hence the security team or any packager can help, provided they know how to do QA ) So a packager wants to fix a bug in package that is not very visible, sends it to QA, then has to test it anyway? I'm not sure what you're saying here. Not the packager committing the fix, (if he doesn't think it's fixed he won't ask for an update to begin with). Yup :) But the QA team, this team could/should have packagers in it. Or someone could help by doing QA and saying so far, I see no regression, or just saying I see regression before some more experienced QA member do the test. -- Michael Scherer
Re: [Mageia-dev] Finalizing update process
Le mercredi 08 juin 2011 à 18:57 +0200, Christiaan Welvaart a écrit : On Wed, 8 Jun 2011, Michael Scherer wrote: Le mercredi 08 juin 2011 à 10:40 +0200, Anne nicolas a écrit : Hi there We have some stuff to complete here: http://mageia.org/wiki/doku.php?id=security http://mageia.org/wiki/doku.php?id=securityCan we spend the 2 or 3 coming days to finalize it and start updates submits? Pascal is working on this. So here is a proposal : - anybody can submit a package to updates_testing. - once submitted to testing, it should ask to QA to test, along with : - a reason for the update ( likely bug number ) - potentially a priority ( ie, if this is just a translation update or a urgent 0 day exploit ) - a way to test the bug and see it is fixed - text for the update - qa validate the update ( with process to define ) - someone move the package from updates_testing to testing Someone from security (stable updates) team I guess? Someone who type the command would be a admin ( until someone decide to write a script for that, and to plug it to the current restricted shell framework ). Who decide exactly what should og or not is open. IE, that the part of the process to define. -- Michael Scherer
Re: [Mageia-dev] Finalizing update process
Le jeudi 09 juin 2011 à 00:53 +0300, Ahmad Samir a écrit : On 8 June 2011 23:40, Anssi Hannula anssi.hann...@iki.fi wrote: On 08.06.2011 23:23, Ahmad Samir wrote: On 8 June 2011 21:45, Samuel Verschelde sto...@laposte.net wrote: Le mercredi 8 juin 2011 19:39:55, Ahmad Samir a écrit : IMHO, rejection reasons: - The sec team doesn't think the update fixes a serious security vulnerability; so it's not updates but backports What about bugfix updates ? I guess fixing a bug is a valid reason for an update, like it was in Mandriva's updates. Regards Samuel Right, I probably phrased that one wrongly; I meant: fixes a serious bug, e.g. crashing, segfaulting I don't think we should exclude non-serious bugs :) Depends, overworking the sec team doesn't look like a good aspect... (that's why I liked contrib in mdv, I could push an update any time, without having to go though the bug report - QA - Sec team loop). Well, I didn't asked to secteam to do anything except managing the security aspect : - finding CVE - finding patch ( with the help of maintainer ) - finding test and fixes But the building and updating should be done by maintainer, as this would scale better. Let the security team focus on the security aspect, and be there as a help for maintainers and viceversa. We shouldn't overload the secteam, while maintainers are here for that :) One of the problem at Mandriva was that security and stable updates were quite disconnected from maintainers, and so it didn't scale well. It didn't scale because people didn't know security procedure ( it was not part of the expected curriculum of a packager, and often was done without them implied ), it didn't scale because security was only for a restricted set of salaree taking care of everything on separate systems. I think we should focus on having : - a system using already know procedure ( ie regular build system ) - make sure that taking care of update is something done regulary as part as packager duty ( after all, that's the whole part of being maintainer ) (or version updates in some cases, like firefox/opera/flash or updating an rc/beta version to a stable one, and maybe some online games that are useless unless on latest version) I agree, (except for the games part, nowadays if it's less than 4GB it's not really a game). I guess we can start with a list of exception : - stuff that should be updated to latest version, because the security support for older releases ( firefox, chrome ) is too hard - we update to latest version if there is no regression and a strong reason to upgrade ( severe bugfixes, security issue, breakages ). Exception of this category should be very expectional - stuff where there is strict bugfixes only release ( postgresql ), or update to a stable version ( which should be a bugfix only release when compared to beta/rc :) ) - we upgrade to stable ( for rc/beta ) - we do version update if it is bug fixes and if the packager is ok with it ( and if the rules of the bugfix branches are clearly documented ) - everything else - only minimal patches The question of game is still open, ie, should it go in 1st category, or should we have different rules to see what should be there or not ? I guess this would only be for networked game ? Maybe the sec team should only work on sec fixes, and there should be a sub-group of the sec team that handle the not CVE|crash|segfaulting|buffer-overflow updates. segfault, crash are the duty of packager, as well as wrong requires or anything. -- Michael Scherer
Re: [Mageia-dev] Finalizing update process
On 9 June 2011 01:25, Michael Scherer m...@zarb.org wrote: Le jeudi 09 juin 2011 à 00:53 +0300, Ahmad Samir a écrit : On 8 June 2011 23:40, Anssi Hannula anssi.hann...@iki.fi wrote: On 08.06.2011 23:23, Ahmad Samir wrote: On 8 June 2011 21:45, Samuel Verschelde sto...@laposte.net wrote: Le mercredi 8 juin 2011 19:39:55, Ahmad Samir a écrit : IMHO, rejection reasons: - The sec team doesn't think the update fixes a serious security vulnerability; so it's not updates but backports What about bugfix updates ? I guess fixing a bug is a valid reason for an update, like it was in Mandriva's updates. Regards Samuel Right, I probably phrased that one wrongly; I meant: fixes a serious bug, e.g. crashing, segfaulting I don't think we should exclude non-serious bugs :) Depends, overworking the sec team doesn't look like a good aspect... (that's why I liked contrib in mdv, I could push an update any time, without having to go though the bug report - QA - Sec team loop). Well, I didn't asked to secteam to do anything except managing the security aspect : - finding CVE - finding patch ( with the help of maintainer ) - finding test and fixes But the building and updating should be done by maintainer, as this would scale better. Let the security team focus on the security aspect, and be there as a help for maintainers and viceversa. We shouldn't overload the secteam, while maintainers are here for that :) One of the problem at Mandriva was that security and stable updates were quite disconnected from maintainers, and so it didn't scale well. It didn't scale because people didn't know security procedure ( it was not part of the expected curriculum of a packager, and often was done without them implied ), it didn't scale because security was only for a restricted set of salaree taking care of everything on separate systems. I think we should focus on having : - a system using already know procedure ( ie regular build system ) - make sure that taking care of update is something done regulary as part as packager duty ( after all, that's the whole part of being maintainer ) (or version updates in some cases, like firefox/opera/flash or updating an rc/beta version to a stable one, and maybe some online games that are useless unless on latest version) I agree, (except for the games part, nowadays if it's less than 4GB it's not really a game). I guess we can start with a list of exception : - stuff that should be updated to latest version, because the security support for older releases ( firefox, chrome ) is too hard - we update to latest version if there is no regression and a strong reason to upgrade ( severe bugfixes, security issue, breakages ). Exception of this category should be very expectional - stuff where there is strict bugfixes only release ( postgresql ), or update to a stable version ( which should be a bugfix only release when compared to beta/rc :) ) - we upgrade to stable ( for rc/beta ) - we do version update if it is bug fixes and if the packager is ok with it ( and if the rules of the bugfix branches are clearly documented ) - everything else - only minimal patches The question of game is still open, ie, should it go in 1st category, or should we have different rules to see what should be there or not ? I guess this would only be for networked game ? Maybe the sec team should only work on sec fixes, and there should be a sub-group of the sec team that handle the not CVE|crash|segfaulting|buffer-overflow updates. segfault, crash are the duty of packager, as well as wrong requires or anything. -- Michael Scherer Yes, but I was talking about the actual submitting to */release, not fixing the package itself. IIUC the submission rights will be restricted to the Sec team. -- Ahmad Samir
Re: [Mageia-dev] mageia sound task
On Wed, 8 Jun 2011, Sascha Schneider wrote: Now that release 1 is out it might be woth for further toughts and a lot of fun work :) http://www.mageia.org/wiki/doku.php?id=soundstudio I didn't rest thinking on this idea: my latest idea is to mame a bash-script with dialog to configure proaudio on mageia. Much of what is done in the script can also be done in a package (task-sound-studio?) and then it would be reversible because that's policy for packages. Wouldn't that be better and easier to use? For example instead of adding lines to rc.local a new soundstudio initscript can be installed. Adding a specific user to groups may not be possible in a package, however. Christiaan
Re: [Mageia-dev] Finalizing update process
Le jeudi 09 juin 2011 à 02:40 +0300, Ahmad Samir a écrit : Yes, but I was talking about the actual submitting to */release, not fixing the package itself. IIUC the submission rights will be restricted to the Sec team. Sorry to be picky, but there is no submit to */release, it is frozen. And in my proposition, there is also no submit to */update, there is a move from */updates_testing. So for managing the submit to updates_testing and the whole process, I think it should be open to any packagers. It should be maintainers responsibility to do the update ( prepare, do a test build, check, submit ), even if secteam members could be proactive for that. But the process should not be restricted to them, or it will not scale ( and given we want to have bugfixes updates, it wouldn't make much sense to call the team like this ). Since ensuring that a update is a minimal change is (to me) a quality issue, I propose to add to the QA list of things to check before refusing a update : it doesn't fullfill the requirement of minimal changes ( with exceptions But that requires QA people to have minimal packaging notions, which could be a problem :/ Again, nothing prevent people from the secteam to also be part of the QA team. -- Michael Scherer
Re: [Mageia-dev] kdegraphics4 commits [102171]
Le mercredi 8 juin 2011 21:48:25, vous avez écrit : Revision: 102171 Author: ze Date: 2011-06-09 02:48:25 +0200 (Thu, 09 Jun 2011) Log Message: --- - add dependency needed by kgamma build - add missing versioning in main package require Modified Paths: -- cauldron/kdegraphics4/current/SPECS/kdegraphics4.spec Modified: cauldron/kdegraphics4/current/SPECS/kdegraphics4.spec === --- cauldron/kdegraphics4/current/SPECS/kdegraphics4.spec 2011-06-09 00:33:15 UTC (rev 102170) +++ cauldron/kdegraphics4/current/SPECS/kdegraphics4.spec 2011-06-09 00:48:25 UTC (rev 102171) @@ -42,9 +42,9 @@ BuildRequires: djvulibre-devel BuildRequires: ebook-tools-devel BuildRequires: libxt-devel +BuildRequires: libxxf86vm-devel This buildrequires is already pulled during deps installed, why adding it again ? +Requires: %name-core = %epoch:%version -Requires: %name-core Well maybe it would have been better to remove this requires since this package is just empty only have suggests for packages which are already requiring the %name-core package... -- Balcaen John Jabber ID: mik...@jabber.littleboboy.net
Re: [Mageia-dev] mageia sound task
'Twas brillig, and Christiaan Welvaart at 09/06/11 00:46 did gyre and gimble: For example instead of adding lines to rc.local a new soundstudio initscript can be installed. As we'll be switching to systemd, an initscript is probably not the way to go. A systemd unit however would be good :D Adding a specific user to groups may not be possible in a package, however. What do you need to add users to groups for these days? Can jack not use rtkit to get realtime privs? Or is there other group membership stuff that is desirable? 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] [RPM] cauldron core/release libgdata-0.7.1-1.mga2
Le mercredi 8 juin 2011 16:52:16, Mageia Team a écrit : Name: libgdata Relocations: (not relocatable) Version : 0.7.1 Vendor: Mageia.Org [...] dmorgan dmorgan 0.7.1-1.mga2: + Revision: 102030 - New version 0.7.1 There's a file conflict : Installation failed: file /usr/lib64/girepository-1.0/GData-0.0.typelib from install of lib64gdata10-0.7.1-1.mga2.x86_64 conflicts with file from package lib64gdata7-0.6.6-1.mga1.x86_64 Installation failed:file /usr/lib64/girepository-1.0/GData-0.0.typelib from install of lib64gdata10-0.7.1-1.mga2.x86_64 conflicts with file from package lib64gdata7-0.6.6-1.mga1.x86_64 Maybe this file should not be in the versionned library package ? -- Balcaen John Jabber ID: mik...@jabber.littleboboy.net
Re: [Mageia-dev] [RPM] cauldron core/release libcanberra-0.27-2.mga2
On 8 June 2011 09:20, Mageia Team buildsystem-dae...@mageia.org wrote: Name : libcanberra Relocations: (not relocatable) Version : 0.27 Vendor: Mageia.Org Release : 2.mga2 Build Date: Wed Jun 8 09:16:17 2011 Install Date: (not installed) Build Host: ecosse Group : Sound Source RPM: (none) Size : 504482 License: LGPLv2+ Signature : (none) Packager : Mageia Team http://www.mageia.org URL : http://0pointer.de/lennart/projects/libcanberra/ Summary : XDG compliant sound event library Description : A small and lightweight implementation of the XDG Sound Theme Specification (http://0pointer.de/public/sound-theme-spec.html). dmorgan dmorgan 0.27-2.mga2: + Revision: 101746 - Enable gtk3 part The -devel sub-package now requires lib*canberra-gtk30, which means gtk+3.0-devel is pulled in any chroot that has BR canberra-gtk-devel, I am not sure it'll have any effect on the built packages, but it doesn't look right having both gtk+2.0 and gtk+3.0 -devel in the same chroot... -- Ahmad Samir
Re: [Mageia-dev] Finalizing update process
On 09.06.2011 02:25, Michael Scherer wrote: I guess we can start with a list of exception : - stuff that should be updated to latest version, because the security support for older releases ( firefox, chrome ) is too hard - we update to latest version if there is no regression and a strong reason to upgrade ( severe bugfixes, security issue, breakages ). Exception of this category should be very expectional - stuff where there is strict bugfixes only release ( postgresql ), or update to a stable version ( which should be a bugfix only release when compared to beta/rc :) ) - we upgrade to stable ( for rc/beta ) - we do version update if it is bug fixes and if the packager is ok with it ( and if the rules of the bugfix branches are clearly documented ) - everything else - only minimal patches The question of game is still open, ie, should it go in 1st category, or should we have different rules to see what should be there or not ? I guess this would only be for networked game ? Yes. Note that this applies to some other software that communicates with outside systems as well, e.g. subdownloader. Maybe also Vuze if the content delivery system requires a version update. Maybe the correct phrasing would be something like: - Packages where some functions no longer work due to remote server changes, requiring a newer version of the package. -- Anssi Hannula
Re: [Mageia-dev] automatic chroot install using urpmi
On Thu, 2011-06-09 at 05:47 +0200, Bruno Cornec wrote: Vasiliy G Tolstov said on Wed, Jun 08, 2011 at 04:26:35PM +0400: Thank's for answer. Very well. If i use basesystem-minimal and append grub systemd ntpd openssh-server and kernel, does that system can boot-up ? You may want to look at rpmbootstrap, which was working fine for mdv2010.2 and thus should easily work for mageia 1 as well. (part of project-builder.org), this tools creates operational chroot for RPM based distros, similar to debbootstrap and better than rinse or mock , as being multi distro (fedora, rhel, opensuse, mdv, mageia, ...) I use it to create the chroots (VEs) needed by project-builder.org to build its packages, zhen not using VMs. HTH, Bruno. Thank you, Bruno. I'm try look ad it.
