Re: [Mageia-dev] Monitoring of new GNOME/upstream releases
On Fri, 24 Jun 2011, Olav Vitters wrote: Does Mageia monitor upstream releases and how? This as I noticed that the new Metacity release (2.34.1) is not yet in Cauldron. GNOME has a ftp-release-list mailing list[1]. It sends out notices when new modules are released. It has X- headers for easy parsing. Only thing that has to be taken into account is that it could take 5min before modules can be downloaded (ftp.gnome.org is a mirror, it is not the place where releases are done). We have http://check.mageia.org/updates.html - it's not perfect but what we currently really lack is a maintainer database. This is needed to know where update notices should be sent. I made a list of gnome packages that should probably be updated (to a 3.0.x release). Metacity was not yet on there so I added it: accerciser banshee cheese epiphany-extensions ? evince - in progress gconf-editor ? gedit gnome-games gnome-packagekit gnome-themes gnome-user-docs libwnck ? metacity (2.34.1) mousetweaks orca totem Christiaan
Re: [Mageia-dev] [RPM] cauldron core/release gnutls-2.12.7-1.mga2
Le mardi 21 juin 2011 12:31:26, Mageia Team a écrit : Name: gnutls Relocations: (not relocatable) Version : 2.12.7Vendor: Mageia.Org Release : 1.mga2Build Date: Tue Jun 21 17:26:30 2011 Install Date: (not installed) Build Host: ecosse Group : System/Libraries Source RPM: (none) Size: 7163819 License: GPLv2+ and LGPLv2+ Signature : (none) Packager: Mageia Team http://www.mageia.org URL : http://www.gnutls.org Summary : Library providing a secure layer (SSL) Description : GnuTLS is a project that aims to develop a library which provides a secure layer, over a reliable transport layer. fwang fwang 2.12.7-1.mga2: + Revision: 111574 - new verison 2.12.7 (nettle based) Could you have a look to gnutls telepathy-gabble / salut ? Since the upgrade to 2.12.7 we're facing again this bug https://bugs.freedesktop.org/show_bug.cgi?id=29364 with in the telepathy log this error : on_connection_ready: got error: WOCKY_CONNECTOR_ERROR_TLS_SESSION_FAILED (#7): TLS handshake error: -59: GNUTLS_E_INTERNAL_ERROR Reverting to the gnutls available in mageia 1 fix that. -- Balcaen John Jabber ID: mik...@jabber.littleboboy.net
Re: [Mageia-dev] Proposal of a backporting process
- I am not sure on this part, but basically, we have 2 choices : - the packager take the cauldron package and push to backport testing - the packager move the cauldron package in svn to backport, and there send it to backport testing. copy i believe. IIUC we should branch cauldron into stable relases for that package, but what happens if the package already exists? I mean foo 1.0.0 is in stable, a foo 1.1.0 is required and could be backported into stable branch... we have two foo programs with their own story. WDYT ? I like the second option, but in such a way we should provide upgrades from a stable with backports, since they follow a good feedback policy before going to stable. I understand QA and sysadmins are not overloaded, but there's not so much difference between updates and backports then... -- Angelo signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] Update of backport, policy proposal
Le vendredi 24 juin 2011 02:15:03, Michael Scherer a écrit : 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. I have always used backports in a total way : if I want latest software against stability, I take them all. Think about little dependencies that still exist (vlc + ffmpeg, etc). So I would say Mageia has two update modes : - end user (security) mode (updates) - power user (let's try everything) mode (updates+backports) Each user will recognise himself in one of the two modes.
Re: [Mageia-dev] Monitoring of new GNOME/upstream releases
On Fri, Jun 24, 2011 at 11:46:59AM +0200, Michael Scherer wrote: Now, if you want to create a notification system for that, feel free. The software can be found on ouri.zarb.og, the documentation is minimal, this is perl. You can however get test result in txt format, html, or anything, and thus a tool to send notification ( and more important, a tool to configure notification ) can be constructed upon that. Thanks for the pointer. Already noticed a few things: 1. It uses the LATEST-IS files and there was a bug with that and not everything has been fixed atm (is fixed for new stuff) 2. It uses http://fr2.rpmfind.net/linux/gnome.org/sources instead of either http://ftp.gnome.org/pub/GNOME/sources (primary mirror) or http://download.gnome.org/ (currently just redirects to primary mirror, long term goal is having it redirect to closest mirror). Didn't fully analyse yet, but noticed it uses a database, so think I'll need to make two things: - script to process live update messages (ftp-release-list in case of GNOME) - script to notify people (either immediately or when youri runs from cron) + setting in database which ensures the announce only goes out once I'll try to work on this. How would the maintainer data be stored btw? Should it be a config file that a script generates, LDAP? Also: is a maintainer always the same for all branches? e.g. if someone maintainers metacity, that person is responsible for Cauldron, stable releases, backports, etc (some distributions differ on this)? -- Regards, Olav
Re: [Mageia-dev] Update of backport, policy proposal
Le 24/06/2011 13:42, Wolfgang Bornath a écrit : 2011/6/24 José Jorgejjo...@free.fr: Le vendredi 24 juin 2011 02:15:03, Michael Scherer a écrit : 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. I have always used backports in a total way : if I want latest software against stability, I take them all. Think about little dependencies that still exist (vlc + ffmpeg, etc). So I would say Mageia has two update modes : - end user (security) mode (updates) - power user (let's try everything) mode (updates+backports) Each user will recognise himself in one of the two modes.la So, where do I find myself in this scenario? I do not use backports in general, they are disabled. A new version of foo is coming in in cauldron and I want to use it in Mageia 1. A friendly packager builds a backport of this new version of foo for Mageia 1. I enable backports, do urpmi foo and I get the version from backports including dependencies. After that I disable backports. This is the way backports have been used by many users in Mandriva. And (BTW) this is the exact meaning of the word, a version is backported from a newer distrib-version or cooker/cauldron to an older distrib-version or current stable version. I use a few backported package on a Mdv install (please, don't lapidate me, I have 2 mageia cauldron at home). To easily update them, I have made a small and ugly bash script. It can propably being optimised, clean, etc. I run it manually times to times . Regards [jehane@mdvbox]$ cat update-backports.sh #!/bin/bash # Add here your package, for each repository # Main backports package pkge_main=firefox # Contrib backports package pkge_contrib=fusioninventory-agent; echo Script for updating package present in non-activated repositery echo Only for distribution using urpmi echo echo List of checked package echo $pkge_main echo $pkge_contrib echo # Must be launch as root if [ $UID -ne 0 ]; then echo Need to be root exit $E_NOTROOT fi # Updating repos echo Updating backports repository urpmi.update Main Backports urpmi.update Contrib Backports echo Updating package for package in `echo $pkge_main` ; do urpmi --searchmedi Main Backports $package done for package in `echo $pkge_contrib` ; do urpmi --searchmedia Contrib Backports $package done -- Marianne Lombard (Jehane) Mageia User - Mageia french translation team Inside every fat girl, there is a thin girl waiting to get out (and a lot of chocolate) - Terry Pratchett
Re: [Mageia-dev] Backports policy proposal
On Friday, 24 June 2011 08:30:15 Maarten Vanraes wrote: Op vrijdag 24 juni 2011 02:10:14 schreef Michael Scherer: [...] 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. [..] This seems hard to enforce... i can imagine if you make backport, it has essentially the same version as in cauldron, i can think that there is a few spec file changes that are only for backports, Why should it need spec file changes? and thus the release becomes newer than the one in cauldron If it requires spec file changes, why should cauldron not get a new release that includes the changes? Sorry, but a number of my packages were regularly backported, and I never needed cooker to be older ... Regards, Buchan
Re: [Mageia-dev] Backports policy proposal
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 ? Also, I don't see the advantage in preventing backports during freeze. The backports are re-allowed soon anyway, and the upgradeability goes away anyway. -- Anssi Hannula
Re: [Mageia-dev] [RPM] cauldron core/release gnutls-2.12.7-1.mga2
Le vendredi 24 juin 2011 07:35:46, Balcaen John a écrit : Le mardi 21 juin 2011 12:31:26, Mageia Team a écrit : Name: gnutls Relocations: (not relocatable) Version : 2.12.7Vendor: Mageia.Org Release : 1.mga2Build Date: Tue Jun 21 17:26:30 2011 Install Date: (not installed) Build Host: ecosse Group : System/Libraries Source RPM: (none) Size: 7163819 License: GPLv2+ and LGPLv2+ Signature : (none) Packager: Mageia Team http://www.mageia.org URL : http://www.gnutls.org Summary : Library providing a secure layer (SSL) Description : GnuTLS is a project that aims to develop a library which provides a secure layer, over a reliable transport layer. fwang fwang 2.12.7-1.mga2: + Revision: 111574 - new verison 2.12.7 (nettle based) Could you have a look to gnutls telepathy-gabble / salut ? Since the upgrade to 2.12.7 we're facing again this bug https://bugs.freedesktop.org/show_bug.cgi?id=29364 with in the telepathy log this error : on_connection_ready: got error: WOCKY_CONNECTOR_ERROR_TLS_SESSION_FAILED (#7): TLS handshake error: -59: GNUTLS_E_INTERNAL_ERROR After a second look it seems related to the use of libnettle. Reverting to libcrypt (adding --with-libgcrypt switch to configure) fix it. I also use a patch from fedora to skip dsa test ( cf http://pkgs.fedoraproject.org/gitweb/?p=gnutls.git;a=blob;f=gnutls-2.12.7-dsa- skiptests.patch;h=64fa2245c104356cefc0ad784777feff7e972dc6;hb=9aec8097dd3829afcbd75ed8a83176248cef6b43 ) to allow the build . -- Balcaen John Jabber ID: mik...@jabber.littleboboy.net
Re: [Mageia-dev] Proposal of a backporting process
Michael Scherer a écrit : ... - Someone request a backport ... - a packager decide to do it. ... - I am not sure on this part, but basically, we have 2 choices : - the packager take the cauldron package and push to backport testing - the packager move the cauldron package in svn to backport, and there send it to backport testing. Proposal 1 mean less work duplication, but proposal 2 let us do more customization. ... This way : - packages are not sent untested, thus raising confidence in backports - the QA should not be overloaded, and can focus on updates - sysadmins are not overloaded - people requesting backport see how QA work, and are involved into the distribution as testers, thus creating a much healthier discussion with packagers, and creating more incentive to help. And since they request the package, they will be motivated to test more than stuff they do not use. WDYT ? Overall I think that it is an excellent approach, for the reasons given. I don't yet understand the difference between proposal 1 and 2, so for the moment I don't have a preference. Even though bugzilla might seem a bit cumbersome for requesting backports, otherwise I think that it is an excellent tool for this purpose. We could perhaps have some sort of shortcut for filing backport requests. -- André
Re: [Mageia-dev] Proposal of a backporting process
On 24 June 2011 02:09, Michael Scherer m...@zarb.org wrote: Hi, as said in the thread of firefox 5, and in the meeting of packager sooner this week, this is the first mail about backports ( on 3 ). So here is the proposal of a process, based on the feedback of people, and the idea of some packagers ( mainly stormi ). - Someone request a backport ( by bugzilla, by madb, by a email, by taking a packager family in hostage, whatever ). I would prefer use bugzilla but this may not be very user friendly, or too heavy. How would the packager get notified of backports requests via madb? Would you elaborate on how bugzilla is heavy for a backports request? - a packager decide to do it. Based on the policy ( outlined in another mail ), and maybe seeing with the maintainer first about that for non trivial applications, the backport can be done, or not. The criterias for being backported or not are not important to the process, just assume that they exist for now ( and look at next mail ). So based on criteria, someone say it can be backported, so I do it. [...] - I am not sure on this part, but basically, we have 2 choices : - the packager take the cauldron package and push to backport testing - the packager move the cauldron package in svn to backport, and there send it to backport testing. Proposal 1 mean less work duplication, but proposal 2 let us do more customization. Option 1 doesn't only mean not duplicating work, but also that the the spec in backports svn isn't ever out-dated; the only reason I see a package being in stable distro SVN is if it's in /release|updates, not backports... if the package doesn't build, the packager fix ( or drop the idea if this requires too much work ) - the packager send requesting feedback about the backport from the people who requested it, and test it as well. Probably off-topic, but how will that work with madb? i.e. how will the maintainer get the feedback? - based on feedback ( ie if the package work or if the packager is confident ), the packager decide to move it to backport for everybody, using some stuff similar to rpmctl ( the tool we used to move package at Mandriva ). The tool would also send notifications. The packager decides to move it and he has the necessary privileges to do so? or will he have to request someone from another team to move it? - if the package doesn't work, he either fix, or drop the backport idea. If he fix, we go back on testing, if he drop, we remove the rpm ( with a automated cleaning of rpm after 1 or 2 months ). [..] If the packager drop the backport, it should be notified to the requester ( hence the use of bugzilla, or a more suitable tool ) Agreed. This way : - packages are not sent untested, thus raising confidence in backports How many times did backports breaks a user's whole installation? 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? - the QA should not be overloaded, and can focus on updates - sysadmins are not overloaded - people requesting backport see how QA work, and are involved into the distribution as testers, thus creating a much healthier discussion with packagers, and creating more incentive to help. And since they request the package, they will be motivated to test more than stuff they do not use. WDYT ? -- Michael Scherer -- Ahmad Samir
Re: [Mageia-dev] Backports policy proposal
Michael Scherer a écrit : so : - cannot be backported if this is not a leaf package, will be revised later - cannot be backported if the maintainer say no, but we assume he say yes by default - cannot be backported if it impact the dependency tree too much ( Obsoletes, Provides, etc ) - cannot be backported if the package was just created and is thus basically untested in cauldron What about corner cases where a potential backport is incompatible with changes introduced in cauldron ? Should we leave such packages to third parties ? (I would tend to say yes.) - must not prevent upgrade to next release I can see where a backport could be a more recent version than in cauldron for the moment. Since that could make the newer version available to users somewhat sooner. Although by release, cauldron should have at least as recent a version. Or should we prohibit this ? (I'm thinking of cases where more recent versions are expected for cauldron before release.) - strict requires between backported packages, in order to make sure they can be cherrypicked ( ie, someone enable backports, install, remove backports ) It would be best if one can select individual backports without activating the backports repositories, as is now the case. So only the brave (wanting all backports) need activate the backports repositories. Agree with everything, except as noted. It might be useful to list major packages that should never be backported. I like the idea of tagging backports in the package name, as well as in the package database. (I'd like the database to retain all the source repositories of installed packages.) -- André
Re: [Mageia-dev] Update of backport, policy proposal
Michael Scherer a écrit : Hi, The last mail from the backport trilogy. And like all good trilogy, that's where the suspens is present ( as for the 1 and 2 part, you know there is another episode ) This mail is about handling update on the backport repository. Either new version, or bugfix, or security upgrade. Everybody was focused on should we do patch, or should we do more backport issue, but the real problem is not really here. First, we have to decide what kind of update do we want to see, among the 3 types : - bugfixes - security bug fixes, - new version Then as we want to have working backports, I think we need to do test, like we do for normal backports, or updates. This mean someone need to test, besides the packagers. For the first one, we can assume that if there is a bug, someone will fill it. Then we can assign it to the one that backported to fix the packages, and ask the reporter to test. For the 3rd one, I guess we can use the same as 1st one. If no one ask, do nothing. If someone ask, do the same as others backports, and erase the previous one. For the 2nd one, it all depend on how we find out about security issues. A tool like the one used by debian/ubuntu that check for each package if the version is vulnerable or not could help packager to know if a backport requires a fix or not, like this is done for the others packages. However, this mean that someone will have to check if the bug is fixed, and the question is who ( and I do not have a answer that I find good enough yet ). This could even be more tricky if we consider that this can be a version upgrade, and a security fix. Even if we trust the upstream to fix the security issue, we still want to have it working. But besides this question, there is a more important problem. If we think that some packages updates are important enough to be sent to user without them asking for explicitly, we cannot let people pick only some packages on demand by disabling backports. Either backports source is enabled in urpmi, and this would mean that backports are treated like update from a user point of view, or the backports are enabled on demand, meaning that the user is on his own. Again, I do not have much ideas. A solution would be to have something like portaudit ( http://www.freshports.org/ports-mgmt/portaudit ). So people would be warned if the backport is insecure, or could be upgraded ( even for a new version ). I guess we should however psuh people to run the latest backport, whatever the reason, to avoid headaches when bug are reported. Another solution would be to patch urpmi to do a special type of update, ie it would only update packages from backports if they come from backports. Not really clean, IMHO. 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. -- André
Re: [Mageia-dev] Update of backport, policy proposal
ignore previous message -- I pushed the wrong button -- André
Re: [Mageia-dev] Update of backport, policy proposal
Michael Scherer a écrit : This mail is about handling update on the backport repository. Either new version, or bugfix, or security upgrade. Everybody was focused on should we do patch, or should we do more backport issue, but the real problem is not really here. First, we have to decide what kind of update do we want to see, among the 3 types : - bugfixes - security bug fixes, - new version For bugfixes and new versions, that are not known to have security implications, let's treat them essentially as new backports. If the bug were locally reported, the reporter would be involved in the testing. Such updates would be installed as any other backport. However I would favour notifying those who have installed previous versions of these backports, of the availability of newer versions. Maybe even having a backports updates category. (But not to be installed automatically by default.) For security issues, I'm not sure that it is important how we find out. As far as responsibility, I think the main responibility should be by the packager, but it could be useful for the security team to monitor it, to find an alternate packager if necessary. (Presumably from those who have tested or installed the package.) (I don't know who monitors security issues now, I just assume the security team.) However I think that such packages should be tested as normally for backports, and then treated as security updates, to be automatically applied. This is because those who have installed the backport in question have decided to accept a higher degree of risk. However a security issue can be a much greater risk, and is something that is normally resolved automatically. So by installing a security bug fix automatically for a backport, we are essentially maintaining the level of risk already assumed by the user. In summary : In terms of testing, I see all backport updates as following the same process as for the initial backports. (As outlined by misc in another thread.) For non-security updates, I see essentially the same installation process as for initial backports. Adding some form of notification to those who have installed a previous version of the backport in question. For security updates, I see automatic installation as with any security update. The treatment of these updates would depend on what is installed on the user's system, and not what repositories are selected. In terms of monitoring security issues, why not use the same as for other packages ? my 2 cents :) -- André
