Re: [Mageia-dev] ANN: version freeze and what it means for Mageia 1 updates
On 12/03/12 09:06, Samuel Verschelde wrote: Samuel "Gives lessons and does nothing" Verschelde Sorry for replying so late. I don't agree with the arithmatic you used here: things like working on madb aren't very visible to others, and your daytime job, looking after your children and other duties you have won't be very visible here, either, but they all require a lot of work (including thinking). You can't count invisible + invisible + invisible + etc. = 0 Anyone who remembers the first of October 2011, when you worked on assigning all those bugs and missed a lot of sleep, knows you're a hard worker. Cheers, Marja
Re: [Mageia-dev] Freeze Push Question: pulseaudio
but considering the lifetime of mga2 I still feel this is the right direction. Col Agreed Mageia 2 will be supported for 18 months. Mageia has a 9 months release cycle (unless delayed for longer). That means Mageia 3 is probably in January or February. However let's take Ubuntu for example it means they will probably have Pulseaudio 2.0 if not in Ubuntu 12.04 in Ubuntu 12.10 probably (or a later version of Pulseaudio) and so quite a bit before Mageia 3. Then for certain people Pulseaudio will seem rather old in Mageia 2, when Ubuntu and other distros are using a later version in their latest final release at the time before Mageia 3 gets released.
[Mageia-dev] Freeze push: kdevplatform4, kdevelop4, kdevelop4-php, kdevelop4-php-docs
Hello, Could somebody push kdevplatform4, kdevelop4, kdevelop4-php, kdevelop4-php-docs into cauldron. We are aiming at 4.3.0 final for mga2, and it got out now. You should push kdevplatform4 at first, wait it finished, then push other packages. Thanks.
Re: [Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia
On Monday, March 12, 2012 03:13:22 PM Kamil Rytarowski wrote: > On 10.03.2012 17:36, Thomas Spuhler wrote: > > Hi! > > > Are we making any progress with this. Currenly Hunspell doesn't work in > > Lyx (error no dictionaries installed and digging through the Hunspell > > spec file it installs a patch and gives the dictionary path as > > /usr/share/dict/ooo: but there is only a one empty file in that > > directory called dictionary.lst > > We are installing the dictionaries into /usr/share/hunspell and symlinks > into /usr/share/myspell > I will have a look. > > > Hunspell works on libreoffice. > > Great! Don't worry, I found the dictionaries. But Lyx doesn't take them. -- Best regards Thomas Spuhler
Re: [Mageia-dev] Pulseaudio push vs version freeze
'Twas brillig, and Anne nicolas at 12/03/12 21:59 did gyre and gimble: > Hi there > > After all discussions about pulseaudio that happened on IRC and on this > mailing-list, we had to take a decision about submitting or not this new > version. Version freeze is a MUST to follow to be able to release > stable. We know it's hard to stop updating software and focus on bug > fixing while development of these softwares do not stop upstream. > > Anyway Colin gave some details about the reasons why we should submit > it. There was discussion during council meeting tonight and finally here > is the plan: pulseaudio is submitted tonight, it will be included in > beta2 and it will be tested until 26/03. Colin will provide > documentation to help tests. If we see regression in between, then it > will be reverted. I just want to follow up Anne's email here. I want to make it clear this I was very much the person pushing for this. Several people are somewhat apprehensive about this (for various values of apprehensive) and I fully appreciate their concerns. By way of reassurance, I would like to describe a little the changes in the upstream version. This release is technically quite small. The number of commits are low generally, but also a high proportion of the commits are related to documentation, tidyups and independent new features (requiring manual activation) rather than changes to current feature set. Where changes to current features do exist, a lot of it relates to two newer APIs/subsystems which are still relatively minor parts: namely the passthrough API and the echo-cancellation subsystem. While these are important parts and will play an increasingly important role moving forward, they are also not part of what I would call the "critical path" of PA usage today. So in terms of changes that are part of that critical path, I'd say two primary changes come into play here: * Alternative Sample Rates * Headphone Jack Detection Both of these are issues that the users have often requested, but it is the latter that is my primary motivation for pushing for this new version to be included. The vast majority of the work has been undertaken by David Henningsson of Canonical. A variation on his patches have been part of Ubuntu for some time and they have offered users this capability for a while now. I would very much like to thank David for his work here. It's been a sorely needed feature and it's been a lot of work and he's done a great job. So the primary things to look out for here are: 1. General regressions. Does something that used to work, now function poorly? I do not expect much here. Things relating to actual quality of the audio should also be reported (in some cases some optimisations might not be working as intended, but this is a relatively simple to fix if it crops up). 2. Do headphones now work correctly? You should now always see a port dropdown in pavucontrol. This was often hidden in the past, but will now be visible. On HDA codecs, does plugging/unplugging headphones now magically switch the port correctly? If not, is it any worse than before? You should have separate volumes for normal usage vs. headphones usage. Depending on hardware you may get a slight blip when plugging in the headphones (e.g. if the speaker volume is loud, and the headphone volume quiet, you might get a very short blast of loud noise when you plug in headphones). Some hardware permits genuinely separate controls for this and avoids this blip. If so, you're lucky. 3. Bluetooth devices. There are a few bluetooth changes. Everything still OK? You will have to add "Enable=Socket" to the [General] section of /etc/bluetooth/audio.conf to get this working, but it should work fine as before. That's all really. As always, please include "pacmd ls" output in any reports. Obviously for minor issues I hope to fix them super quickly, but if any issues come up that cannot be addressed, I can and will revert back to PA 1.1 for mga2. All the best and thank you very much for helping make this a great release. Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] [Freeze] please let in xonotic
Oops, and I hope you can forgive my replying to self and top-posting. Gmail got me again. :o)
Re: [Mageia-dev] [Freeze] please let in xonotic
My point is not about preventing temper tantrums. I'm sure we've all dealt with clerks, support reps and airline employees who treat everyone like a number and are sticklers for the rules. Perhaps too, we've all gotten a warning instead of a deserved traffic ticket or had a late-payment charge forgiven because of a good prior history. All I'm saying is I have no objection to treating people like people and given all that Thierry does for Mageia, I really think he deserves that. On Mon, Mar 12, 2012 at 6:29 PM, Maarten Vanraes wrote: > Op maandag 12 maart 2012 22:02:56 schreef Guillaume Rousse: >> Le 12/03/2012 21:27, Maarten Vanraes a écrit : >> > but we should also try to prevent irritation if it's possible... we're >> > short on contributors and I don't like to decrease motivation... I guess >> > that makes me more lax than others. >> >> OK, I want a new version of cowsay. Right now. Otherwise I'm leaving. >> Far away and forever. > > ok, fine, your point is noted...
Re: [Mageia-dev] Freeze Push Question: pulseaudio
Hi, 'Twas brillig, and Michael Scherer at 12/03/12 21:04 did gyre and gimble: > For the sake of documenting : > > ... > > So for thoses 5 reasons, I would say "no", even if I would rather see > this just for free software advancement. I originally wrote a reply to this that went through and answered the individual points. However, on reflection and re-reading of my replies I felt it was better to just reply generically as I don't want to nit-pick and do a tit-for-tat type reply here as you're points are all valid and well reasoned. Along with the Triage team who do an sterling job, I am the primary person dealing with fallout from audio issues. I obviously take pride in the work I do and I in no way want want to jeopardise the reputations of either Mageia or PulseAudio and as such I will use the revert option without hesitation for rc if I or anyone else genuinely feels that the newer version reflects badly on Mageia. I fully accept the timing sucks here, but considering the lifetime of mga2 I still feel this is the right direction. Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] [Freeze] please let in xonotic
Op maandag 12 maart 2012 22:02:56 schreef Guillaume Rousse: > Le 12/03/2012 21:27, Maarten Vanraes a écrit : > > but we should also try to prevent irritation if it's possible... we're > > short on contributors and I don't like to decrease motivation... I guess > > that makes me more lax than others. > > OK, I want a new version of cowsay. Right now. Otherwise I'm leaving. > Far away and forever. ok, fine, your point is noted...
Re: [Mageia-dev] Freeze Push Question: pulseaudio
On 12/03/12 08:38, Sander Lepik wrote: 12.03.2012 00:32, Colin Guthrie kirjutas: Anyway, this is my justification. I have packages ready to roll. Can this go it? I think it's worth it. Col Working sound is for many users a must have. So if PA 2.0 will get us better support here then i'm all in. No point to wait another year to get this support. Especially if we have upstream with us to fis problems ASAP. -- Sander I agree sound issues can be very annoying for Desktop Linux users to deal with or try and deal with, especially for the less technical. Sound is also one of those area's where people generally expect it to just work on their computer. Newer is not always better, but going by what Colin typed, Pulseaudio 2.0 will be quite a bit better than previous versions. Since Colin works on Pulseaudio upstream, but is also the maintainer for Mageia, and it seems has provided good enough reasons for Mageia 2 to have it, I think yes let's have it in Mageia 2 :). Also the previous version can be reverted to before the release candidate of Mageia 2 quite easily it seems going by the log of the earlier council meeting: http://meetbot.mageia.org/mageia-meeting/2012/mageia-meeting.2012-03-12-20.17.log.html
Re: [Mageia-dev] Can't install nvidia-cuda update
On 03/12/2012 09:30 PM, Dimitri Jakov wrote:
Should be fixed now. Please update and report your experience. Thanks!
Dimitri
In the mirrors there is only new nvidia-cuda-toolkit(-devel) packages,
but still require something not detected:
werewolf:~/in# rpm -U nvidia-cuda-toolkit-4.1.28-3.mga2.nonfree.x86_64.rpm
error: Failed dependencies:
libcuda.so.1()(64bit) is needed by
nvidia-cuda-toolkit-4.1.28-3.mga2.nonfree.x86_64
nvidia-cuda-toolkit = 4.1.28-1.mga2.nonfree is needed by (installed)
nvidia-cuda-toolkit-devel-4.1.28-1.mga2.nonfree.x86_64
werewolf:~/in# rpm -qf /usr/lib64/nvidia-current/libcuda.so.1
nvidia-current-cuda-opencl-295.20-2.mga2.nonfree
werewolf:~/in# rpm -q --provides
nvidia-current-cuda-opencl-295.20-2.mga2.nonfree
nvidia-current-cuda = 295.20-2.mga2.nonfree
nvidia-current-cuda-opencl = 295.20-2.mga2.nonfree
nvidia-current-cuda-opencl(x86-64) = 295.20-2.mga2.nonfree
The latter does not provide libcuda.so.1()(64bit). Should it be automatic
or not, it should show anyways in --provides ?
Perhaps the library location in /usr/lib{64}/nvidia-current makes rpm skip
the automatic provides for libs ?
TIA
--
J.A. Magallon \ Winter is coming...
Re: [Mageia-dev] freeze push: drakx-installer-binaries, drakxtools, drakx-net, then drakx-installer-images drakx-installer-stage2
13.03.2012 00:27, Manuel Hiebel skrev: Le lundi 12 mars 2012 à 21:49 +0100, Thierry Vignaud a écrit : drakx-installer-images: - include more USB host controller modules (mga#4905) (DEPENDS on d-i-binaries) The core on is missing. 1 hour ago drakx-installer-images-1.68-1.mga2 cauldron nonfree/release Just pushed. -- Thomas
Re: [Mageia-dev] freeze push: drakx-installer-binaries, drakxtools, drakx-net, then drakx-installer-images drakx-installer-stage2
Le lundi 12 mars 2012 à 21:49 +0100, Thierry Vignaud a écrit : > drakx-installer-images: > - include more USB host controller modules (mga#4905) > (DEPENDS on d-i-binaries) The core on is missing. 1 hour ago drakx-installer-images-1.68-1.mga2 cauldron nonfree/release
Re: [Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia
On 10.03.2012 17:36, Thomas Spuhler wrote: Hi! Are we making any progress with this. Currenly Hunspell doesn't work in Lyx (error no dictionaries installed and digging through the Hunspell spec file it installs a patch and gives the dictionary path as /usr/share/dict/ooo: but there is only a one empty file in that directory called dictionary.lst We are installing the dictionaries into /usr/share/hunspell and symlinks into /usr/share/myspell I will have a look. Hunspell works on libreoffice. Great!
Re: [Mageia-dev] Freeze Push Question: pulseaudio
Στις Δευτέρα 12 Μάρτιος 2012 22:04:46 Michael Scherer γράψατε: > Le lundi 12 mars 2012 à 17:25 +0200, Anssi Hannula a écrit : > > 12.03.2012 00:32, Colin Guthrie kirjoitti: > > > Hi, > > > > Hi, > > > > > We're aiming to get a PA 2.0 release out very soon (within the next 4 > > > weeks). > > > > > [...] > > > Can this go it? I think it's worth it. > > > > I think pulseaudio is an acceptable candidate for exception here, mainly > > because > > - it fixes some big audio usability issues (that will only affect more > > and more systems during MGA2 lifetime) with the new features, and > > - our package maintainer is the upstream maintainer as well, allowing > > efficient handling of any bugreports. > > > > However, I know I'm probably more lax here than others, so this requires > > the input of other release managers before a decision. > > For the sake of documenting : > > - I have seen that Ubuntu precise still ship 1.1, and they aim for a > much longer support than us ( iirc, 5 years this time ). They also plan > to release 1 week before us : > https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule > > - Fedora, also usually shipping latest version ( or even shipping git > snapshot of the glibc during the freeze ), do not have it in rawhide for > now, and not in Fedora 17. The next release is 1 week after us : > https://fedoraproject.org/wiki/Releases/17/Schedule > > While Ubuntu do not ship kernel 3.3 in Precise ( but have backported the > jack detection stuff ), Fedora 17 does have it. > > So both of them would benefit from shipping PA 2.0 instead of 1.1, and > they didn't chose to do so. They also have likely more people working on > it, and likely a wider array of testers than us. > > However, ubuntu decide to use some kind of patches to PA for the jack > detection part. > > > The next issue I have is that beside adding bug fixes, that's still a > 2.0. While version number are just version number, as said on > http://www.freedesktop.org/wiki/Software/PulseAudio/Notes/1.0 , we do > not have much information on what got changed, and the current page is > rather scarce : > http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer/ReleasePlanning > > So I personally cannot evaluate how disturbing they would be, or what > they would impact. And sorry, I cannot say "yes" if I think I have not > enough information to evaluate. > > That was my 2nd point. > > > The third point is that you say you will revert if there is a problem, > but I would make sure that we clearly define what is a problem in a way > that do not suffer from any problem of interpretation. Because if we are > not clear now, we will just push the discussion to later and that's not > the moment usually. > So I want to make sure that we all fully agree on what would trigger a > reverse before even thinking to say "yes" to the request. Because > despite asking during meeting, not everybody was on the same wavelength > for version freeze, and I see no reason to have the same problem a 2nd > time. And I want to make sure that if we revert, there will be no last > minute negotiation, no matter how harsh would be a revert. > > So i would say 'no' until we have such document. What would be in there > is left open. For example, one of the criteria could be a deadline for > the release of 2.0. If the release slip only of 1 second, that's too > late and we revert. The current target date is 26/03, and we have our > release freeze on 07/04. So I would say that if PA is not released on > 26/03, that's too late. > > Or we can say "if there is 1 bug written as critical on our bugzilla, or > the one of PA and not fixed on XX". Or anything. > > Without clear conditions being agreed first, I would say "no", that's my > 3rd reason. > > > And while I do not doubt this would be really useful for free software > to have a bunch of testers with our users, and that free software > benefit from shipping RC in distribution, I still think that the beta > are here to fix our bugs rather than those of upstream, and that our > users are not guinea pigs for upstream. That's not exactly what we > promised to them, and for that reason alone, I would also say "no" for > now, and that's a 4th reason. > > > Finally, I would like to remind that pulseaudio is basically installed > on every installation besides servers, and is critical to the sound > infrastructure. And so, just for the fact that this is central, it > should not be version upgraded if that was not really planned, just for > a feature, for simple risk prevention. We were praised for being stable > just because we basically did several months of debug, and I think we > should strive to keep that reputation, by reusing the same simple recipe > ( ie, being cautious and do really more test ). Being rock solid stable > is the only thing where we seems to all agree in our previous > discussion. > > > And being central to both KDE and GNOME, it would be present on the
[Mageia-dev] Pulseaudio push vs version freeze
Hi there After all discussions about pulseaudio that happened on IRC and on this mailing-list, we had to take a decision about submitting or not this new version. Version freeze is a MUST to follow to be able to release stable. We know it's hard to stop updating software and focus on bug fixing while development of these softwares do not stop upstream. Anyway Colin gave some details about the reasons why we should submit it. There was discussion during council meeting tonight and finally here is the plan: pulseaudio is submitted tonight, it will be included in beta2 and it will be tested until 26/03. Colin will provide documentation to help tests. If we see regression in between, then it will be reverted. Cheers -- Anne http://www.mageia.org
Re: [Mageia-dev] Fwd: GConf 3.2.5
On Mon, Mar 12, 2012 at 10:09:51PM +0100, Michael Scherer wrote: > Le lundi 12 mars 2012 à 16:04 +0100, Olav Vitters a écrit : > > please submit, I committed all the changes > > Submit what ? Oh, sorry. It is called GConf2, not GConf (I think there is no GConf anymore, maybe it should be renamed). -- Regards, Olav
Re: [Mageia-dev] freeze push: drakx-installer-binaries, drakxtools, drakx-net, then drakx-installer-images drakx-installer-stage2
2012/3/12 Anne nicolas > > > 2012/3/12 Thierry Vignaud > >> Hi >> >> Please push: drakx-installer-binaries, drakx-net & drakxtools. >> > > submitted. In progress > > >> >> then once drakx-installer-binaries & drakx-net are uploaded and in >> hdlists, please upload drakx-installer-images & drakx-installer-stage2 >> > submitted > >> drakxtools: >> - fix mgaapplet crashing on live migration when there's a new major >> version of >> perl (mga#3042) >> - reduce resident memory of net_applet (5Mb aka 11%) & mgapplet (7Mb aka >> 14%) >> - updated translations >> >> drakx-installer-binaries: >> - do not try to load obsolete sqlzma & squashfs_lzma kernel modules >> - recognize c67x00, imx21-hcd, fhci, isp1362-hcd, oxu210hp-hcd & >> renesas-usbhs >> USB host drivers (mga#4905) >> >> drakx-net: >> - adapt to drakxtools-13.92+ API change >> (reduces net_applet resident memory) >> - drakfirewall: list SSL flavor of POP3/IMAP/SMTP ports >> - updated translations >> >> drakx-installer-images: >> - include more USB host controller modules (mga#4905) >> (DEPENDS on d-i-binaries) >> >> drakx-installer-stage2: >> - recognize c67x00, imx21-hcd, fhci, isp1362-hcd, oxu210hp-hcd & >> renesas-usbhs >> USB host drivers (mga#4905) >> - use lxdm for LXDE >> - updated translations >> (DEPENDS on drakx-net & d-i-binaries) >> >> See you >> > > > > -- > Anne > http://www.mageia.org > -- Anne http://www.mageia.org
Re: [Mageia-dev] Fwd: GConf 3.2.5
Le lundi 12 mars 2012 à 16:04 +0100, Olav Vitters a écrit : > please submit, I committed all the changes Submit what ? $ mgarepo submit gconf Fetching revision... error: svn: File not found: revision 223124, path '/cauldron/gconf/current' $ mgarepo submit GConf Fetching revision... error: svn: File not found: revision 223124, path '/cauldron/GConf/current' > (freeze check on submission works nicely btw :P my script commits + > submits in one go, so sysadmins might see some rejected submissions from > my userid) We do not look at the log. ( at least, i do not ) -- Michael Scherer
Re: [Mageia-dev] Package push request: oxygen-gtk and oxygen-gtk3
Le lundi 12 mars 2012 à 22:05 +0100, Manuel Hiebel a écrit : > Le lundi 12 mars 2012 à 16:20 +0100, Thierry Vignaud a écrit : > > On 12 March 2012 16:08, Funda Wang wrote: > > > As oxygen is our default theme for gtk2 and gtk3, I think we should > > > mark these two packages as important packages, and push updated > > > version as soon as possible. Plus, the new versions fixed a nasty bug > > > that it will crash theme selector when changing from oxygen to another > > > theme. See: https://projects.kde.org/news/127 > > > > Actually it makes other program to crash such as net_applet, mgaapplet, ... > > > > So +1 > > + 1 so we can have it in the beta 2 isos Pushed. -- Michael Scherer
Re: [Mageia-dev] Freeze Push Question: pulseaudio
Le lundi 12 mars 2012 à 17:25 +0200, Anssi Hannula a écrit : > 12.03.2012 00:32, Colin Guthrie kirjoitti: > > Hi, > > Hi, > > > We're aiming to get a PA 2.0 release out very soon (within the next 4 > > weeks). > > > [...] > > Can this go it? I think it's worth it. > > I think pulseaudio is an acceptable candidate for exception here, mainly > because > - it fixes some big audio usability issues (that will only affect more > and more systems during MGA2 lifetime) with the new features, and > - our package maintainer is the upstream maintainer as well, allowing > efficient handling of any bugreports. > > However, I know I'm probably more lax here than others, so this requires > the input of other release managers before a decision. For the sake of documenting : - I have seen that Ubuntu precise still ship 1.1, and they aim for a much longer support than us ( iirc, 5 years this time ). They also plan to release 1 week before us : https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule - Fedora, also usually shipping latest version ( or even shipping git snapshot of the glibc during the freeze ), do not have it in rawhide for now, and not in Fedora 17. The next release is 1 week after us : https://fedoraproject.org/wiki/Releases/17/Schedule While Ubuntu do not ship kernel 3.3 in Precise ( but have backported the jack detection stuff ), Fedora 17 does have it. So both of them would benefit from shipping PA 2.0 instead of 1.1, and they didn't chose to do so. They also have likely more people working on it, and likely a wider array of testers than us. However, ubuntu decide to use some kind of patches to PA for the jack detection part. The next issue I have is that beside adding bug fixes, that's still a 2.0. While version number are just version number, as said on http://www.freedesktop.org/wiki/Software/PulseAudio/Notes/1.0 , we do not have much information on what got changed, and the current page is rather scarce : http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer/ReleasePlanning So I personally cannot evaluate how disturbing they would be, or what they would impact. And sorry, I cannot say "yes" if I think I have not enough information to evaluate. That was my 2nd point. The third point is that you say you will revert if there is a problem, but I would make sure that we clearly define what is a problem in a way that do not suffer from any problem of interpretation. Because if we are not clear now, we will just push the discussion to later and that's not the moment usually. So I want to make sure that we all fully agree on what would trigger a reverse before even thinking to say "yes" to the request. Because despite asking during meeting, not everybody was on the same wavelength for version freeze, and I see no reason to have the same problem a 2nd time. And I want to make sure that if we revert, there will be no last minute negotiation, no matter how harsh would be a revert. So i would say 'no' until we have such document. What would be in there is left open. For example, one of the criteria could be a deadline for the release of 2.0. If the release slip only of 1 second, that's too late and we revert. The current target date is 26/03, and we have our release freeze on 07/04. So I would say that if PA is not released on 26/03, that's too late. Or we can say "if there is 1 bug written as critical on our bugzilla, or the one of PA and not fixed on XX". Or anything. Without clear conditions being agreed first, I would say "no", that's my 3rd reason. And while I do not doubt this would be really useful for free software to have a bunch of testers with our users, and that free software benefit from shipping RC in distribution, I still think that the beta are here to fix our bugs rather than those of upstream, and that our users are not guinea pigs for upstream. That's not exactly what we promised to them, and for that reason alone, I would also say "no" for now, and that's a 4th reason. Finally, I would like to remind that pulseaudio is basically installed on every installation besides servers, and is critical to the sound infrastructure. And so, just for the fact that this is central, it should not be version upgraded if that was not really planned, just for a feature, for simple risk prevention. We were praised for being stable just because we basically did several months of debug, and I think we should strive to keep that reputation, by reusing the same simple recipe ( ie, being cautious and do really more test ). Being rock solid stable is the only thing where we seems to all agree in our previous discussion. And being central to both KDE and GNOME, it would be present on the livecd and would not be upgraded and as such, and because some people use them as liveusb ( ie, without any upgrade ), we cannot treat this as "we can upgrade later if it slip", because we cannot for some people. And as a side note, I would also remind that some people ( li
Re: [Mageia-dev] Package push request: oxygen-gtk and oxygen-gtk3
Le lundi 12 mars 2012 à 16:20 +0100, Thierry Vignaud a écrit : > On 12 March 2012 16:08, Funda Wang wrote: > > As oxygen is our default theme for gtk2 and gtk3, I think we should > > mark these two packages as important packages, and push updated > > version as soon as possible. Plus, the new versions fixed a nasty bug > > that it will crash theme selector when changing from oxygen to another > > theme. See: https://projects.kde.org/news/127 > > Actually it makes other program to crash such as net_applet, mgaapplet, ... > > So +1 + 1 so we can have it in the beta 2 isos
Re: [Mageia-dev] [Freeze] please let in xonotic
Le 12/03/2012 21:27, Maarten Vanraes a écrit : but we should also try to prevent irritation if it's possible... we're short on contributors and I don't like to decrease motivation... I guess that makes me more lax than others. OK, I want a new version of cowsay. Right now. Otherwise I'm leaving. Far away and forever. -- BOFH excuse #188: ..disk or the processor is on fire.
Re: [Mageia-dev] freeze push: drakx-installer-binaries, drakxtools, drakx-net, then drakx-installer-images drakx-installer-stage2
2012/3/12 Thierry Vignaud > Hi > > Please push: drakx-installer-binaries, drakx-net & drakxtools. > submitted. In progress > > then once drakx-installer-binaries & drakx-net are uploaded and in > hdlists, please upload drakx-installer-images & drakx-installer-stage2 > > drakxtools: > - fix mgaapplet crashing on live migration when there's a new major > version of > perl (mga#3042) > - reduce resident memory of net_applet (5Mb aka 11%) & mgapplet (7Mb aka > 14%) > - updated translations > > drakx-installer-binaries: > - do not try to load obsolete sqlzma & squashfs_lzma kernel modules > - recognize c67x00, imx21-hcd, fhci, isp1362-hcd, oxu210hp-hcd & > renesas-usbhs > USB host drivers (mga#4905) > > drakx-net: > - adapt to drakxtools-13.92+ API change > (reduces net_applet resident memory) > - drakfirewall: list SSL flavor of POP3/IMAP/SMTP ports > - updated translations > > drakx-installer-images: > - include more USB host controller modules (mga#4905) > (DEPENDS on d-i-binaries) > > drakx-installer-stage2: > - recognize c67x00, imx21-hcd, fhci, isp1362-hcd, oxu210hp-hcd & > renesas-usbhs > USB host drivers (mga#4905) > - use lxdm for LXDE > - updated translations > (DEPENDS on drakx-net & d-i-binaries) > > See you > -- Anne http://www.mageia.org
[Mageia-dev] freeze push: drakx-installer-binaries, drakxtools, drakx-net, then drakx-installer-images drakx-installer-stage2
Hi Please push: drakx-installer-binaries, drakx-net & drakxtools. then once drakx-installer-binaries & drakx-net are uploaded and in hdlists, please upload drakx-installer-images & drakx-installer-stage2 drakxtools: - fix mgaapplet crashing on live migration when there's a new major version of perl (mga#3042) - reduce resident memory of net_applet (5Mb aka 11%) & mgapplet (7Mb aka 14%) - updated translations drakx-installer-binaries: - do not try to load obsolete sqlzma & squashfs_lzma kernel modules - recognize c67x00, imx21-hcd, fhci, isp1362-hcd, oxu210hp-hcd & renesas-usbhs USB host drivers (mga#4905) drakx-net: - adapt to drakxtools-13.92+ API change (reduces net_applet resident memory) - drakfirewall: list SSL flavor of POP3/IMAP/SMTP ports - updated translations drakx-installer-images: - include more USB host controller modules (mga#4905) (DEPENDS on d-i-binaries) drakx-installer-stage2: - recognize c67x00, imx21-hcd, fhci, isp1362-hcd, oxu210hp-hcd & renesas-usbhs USB host drivers (mga#4905) - use lxdm for LXDE - updated translations (DEPENDS on drakx-net & d-i-binaries) See you
Re: [Mageia-dev] [soft-commits] [3428] Get rid of ERR log level
On Mon, Mar 12, 2012 at 20:25, Thierry Vignaud wrote: > On 12 March 2012 19:13, wrote: >> Revision 3428 Author pterjan Date 2012-03-12 19:13:42 +0100 (Mon, 12 Mar >> 2012) >> >> Log Message >> >> Get rid of ERR log level > > renaming ERR as ERROR would be a better log message, wouldn't it? It wouldn't be accurate. Both ERROR and ERR existed, I removed ERR.
Re: [Mageia-dev] Can't install nvidia-cuda update
Should be fixed now. Please update and report your experience. Thanks! Dimitri
Re: [Mageia-dev] [Freeze] please let in xonotic
Op maandag 12 maart 2012 10:56:57 schreef Michael Scherer: > Le lundi 12 mars 2012 à 08:29 +0100, Maarten Vanraes a écrit : > > to get back on topic: perhaps it's not unreasonable to allow a timelimit > > exception, like for instance 3 or 4 days where "i forgot it was freeze or > > didn't make it in time AND it's not likely to mess everything up" kind of > > reason... > > That was already discussed when we discussed the release cycle. And > basically, that would just "let's reduce the freeze by 3/4 days in a > more inefficient way". You just move the bickering at the 3/4 days limit > ( "but it could have bene if I had submitted yesterday" ) instead of the > beggining of the freeze, and you take time to the people who are > submitting, since they get message, have to warn packager about "it > doesn't work" ( as it happened several time last freeze period ). [...] > So next time, maybe we should have a pure good faith based system, [...] > - everybody can do as he see fit I'll take this suggestion as a cynic suggestions and ignore it for now [...] > Patch welcome, but frankly, I think there is a point where the duty of > being informed must be on the packagers. It is rather depressing to > realize that people do not read the announce you send ( and what is more > depressing is the number of those that don't once you start to dig out > ). > > If some people missed the announce, maybe we should ask them "where do > you read information about the project and where don't you read", so we > can identify the communication channel that should be used and those > that shouldn't, as i am not sure that hammering more is the solution. I do understand both your pov, and i do remember that discussion. IMHO: good strict policies are good, and exceptions are exceptions. but we should also try to prevent irritation if it's possible... we're short on contributors and I don't like to decrease motivation... I guess that makes me more lax than others.
Re: [Mageia-dev] [soft-commits] [3428] Get rid of ERR log level
On 12 March 2012 19:13, wrote: > Revision 3428 Author pterjan Date 2012-03-12 19:13:42 +0100 (Mon, 12 Mar > 2012) > > Log Message > > Get rid of ERR log level renaming ERR as ERROR would be a better log message, wouldn't it?
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release task-gnome-3.3.2-8.mga2
On Mon, Mar 12, 2012 at 18:18, Olav Vitters wrote: > On Mon, Mar 12, 2012 at 07:02:25PM +0100, Thierry Vignaud wrote: >> On 12 March 2012 18:57, Olav Vitters wrote: >> > On Mon, Mar 12, 2012 at 06:53:23PM +0100, Thierry Vignaud wrote: >> >> If we want a better GNOME experience, it should be done in task-gnome. >> > >> > I'll just revert and then wontfix the bug. >> >> This is not what I told you. >> I told you that: >> - suggests doesn't garanty it'll land on the install CD >> - it should be in task-gnome > > GNOME *does* call gnome-screenshot (the command). It is not a library so > it is not strictly needed (only if you press Prt Scrn). > > I rather WONTFIX such bugs than spend loads time arguing about that > task-gnome again. It should be a Requires if the code calls it and a feature is broken without it. If it is gnome-shell or gnome-panel which call it, they need to require it.
Re: [Mageia-dev] [Freeze] please let in xonotic
On Mon, Mar 12, 2012 at 18:19, R James wrote: > On Mon, Mar 12, 2012 at 12:19 PM, Anssi Hannula wrote: >> >> Line would have to be drawn somewhere, though (otherwise it would become >> a mess, I guess), and I'm really not sure right now where it should >> exactly be then >> >> >> This is just my opinion, not based on any previous discussion. >> > > (Also in the spirit of just a humble opinion:) > Given Thierry's innumerable contributions and experience, I would > not object in the slightest to an exception made for him. > > We can be confident that the package will be done correctly plus > it will be a nice, easily-installed addition to Mageia. > > Yes, rules need to exist but flexibility is sometimes warranted in > the interest of good will and showing appreciation. Exceptions for some people make no sense. Anyone can update a package to a version with annoying bugs. Exceptions for some low impact packages make more sense, if everyone agrees there is no impact on other packages (and especially on installer or cd/dvd contents which can not be fixed by updates). I don't mind exceptions for low impact packages were people will want the latest version, but then people handling exceptions will spend their time checking if the exceptions for such packages make sense instead of focusing on fixing more important things for the release.
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release task-gnome-3.3.2-8.mga2
On Mon, Mar 12, 2012 at 07:02:25PM +0100, Thierry Vignaud wrote: > On 12 March 2012 18:57, Olav Vitters wrote: > > On Mon, Mar 12, 2012 at 06:53:23PM +0100, Thierry Vignaud wrote: > >> If we want a better GNOME experience, it should be done in task-gnome. > > > > I'll just revert and then wontfix the bug. > > This is not what I told you. > I told you that: > - suggests doesn't garanty it'll land on the install CD > - it should be in task-gnome GNOME *does* call gnome-screenshot (the command). It is not a library so it is not strictly needed (only if you press Prt Scrn). I rather WONTFIX such bugs than spend loads time arguing about that task-gnome again. -- Regards, Olav
Re: [Mageia-dev] [Freeze] please let in xonotic
On Mon, Mar 12, 2012 at 12:19 PM, Anssi Hannula wrote: > > Line would have to be drawn somewhere, though (otherwise it would become > a mess, I guess), and I'm really not sure right now where it should > exactly be then > > > This is just my opinion, not based on any previous discussion. > (Also in the spirit of just a humble opinion:) Given Thierry's innumerable contributions and experience, I would not object in the slightest to an exception made for him. We can be confident that the package will be done correctly plus it will be a nice, easily-installed addition to Mageia. Yes, rules need to exist but flexibility is sometimes warranted in the interest of good will and showing appreciation.
Re: [Mageia-dev] freeze push: rpm-helper
Le 12/03/2012 17:56, Guillaume Rousse a écrit : > The 0.24.7 release just fixes documentation about add_syslog macro, and > drop old sysklogd dead code. pushed -- Anne http://mageia.org
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release task-gnome-3.3.2-8.mga2
On 12 March 2012 18:57, Olav Vitters wrote: > On Mon, Mar 12, 2012 at 06:53:23PM +0100, Thierry Vignaud wrote: >> If we want a better GNOME experience, it should be done in task-gnome. > > I'll just revert and then wontfix the bug. This is not what I told you. I told you that: - suggests doesn't garanty it'll land on the install CD - it should be in task-gnome
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release task-gnome-3.3.2-8.mga2
On Mon, Mar 12, 2012 at 06:53:23PM +0100, Thierry Vignaud wrote: > If we want a better GNOME experience, it should be done in task-gnome. I'll just revert and then wontfix the bug. -- Regards, Olav
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release task-gnome-3.3.2-8.mga2
On 12 March 2012 18:40, Olav Vitters wrote: >> > - ensure gnome-utils is installed (mga#4903) >> >> 1) This is not what you've done. >> What you've done is suggesting many GNOME packages that don't came >> from gnome-utils >> but come from their own SRPMS. > > gnome-utils was split up into various tarballs: > http://live.gnome.org/GnomeUtils > > task-gnome contained only a "Obsoletes: gnome-utils". I replaced it with > suggests for the splitted packages to ensure that gnome-screenshot (the > bug) as well as the other replacements would be installed. > > Or do you mean that above webpage is wrong? Could be, didn't really > check that thoroughly what packages replaced gnome-utils. I means your log messages isn't what you've done. You'ven't add any require or suggest on gnome-utils but on a number of new gnome packages. Your log messages should describe that. not tha >> 2) Also as those are suggests, they'll never end on the install DVD, >> thus defeating >> " ensure gnome-utils is installed" > > I have asked many times about task-gnome and task-gnome-minimal and > everyone has their own definition. I've asked various times if the > "GNOME" option in the installer could please reflect "GNOME", and not > some weird cut-down version of it called "task-gnome-minimal", but > haven't gotten very far with that. I'm not speaking about task-gnome*, I'm writing about the fact you're using suggests tags and thus that those packages will never land on the install DVDs. > I don't want to step on toes and just ignore the "task-gnome-minimal" vs > "task-gnome", etc (I still don't get why we have -minimal; I also don't > see why we have task-gnome though.. seems that not even Nautilus would > be installed), so I added Suggests instead. Again offtopic. > I don't really see any difference between either having the > gnome-screenshot as a Suggests in task-gnome (which the installer > doesn't install, it looks at task-gnome-minimal) or as Suggests in > task-gnome-minimal (which won't end up on the DVD apparently). > If task-gnome-minimal is "not to be touched" and task-gnome is not > installed by the installer.. what am I to do to fix bugs? Suggests seems > like the only option. Furthermore, I've also added a gnome-screenshot > Suggests to gnome-shell. Again this is offtopic, a suggests will just not be present on install DVDs What'more, the logical place is task-gnome*, not gnome-shell. gnome-shell doesn't need this package, it works without. If the GNOME desktop needs it in order to work, then it should be required by task-gnome, not by another gnome-shell. > IMO mga#4903 was an avoidable bug. As bugs are discovered on resulting > dependency problems, I want to fix every case. To me it seems the wrong > way to deal with this, but I rather raise "-minimal" strangeness after > Mageia 2 release so I can point at the resulting bugs. Again my initial message is about that the suggested packages won't ever land on the install DVDs again. And we should stop bloating the net install with suggests at all the stages of the stack. I have to break many suggests (or requires for what matters) cycles that resulted in us having a minimal install of 800Mb with X11. Obviously gnome-shell doesn't need this package in order to run, so it should not be suggested by gnome-shell. If we want a better GNOME experience, it should be done in task-gnome. If some people objects bloating task-gnome*, disscuss with them instead of hidding those suggests lower in the statck...
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release task-gnome-3.3.2-8.mga2
On Mon, Mar 12, 2012 at 06:16:37PM +0100, Thierry Vignaud wrote: > On 12 March 2012 18:06, ovitters wrote: > > ovitters 1:3.3.2-8.mga2: > > + Revision: 223037 > > - ensure gnome-utils is installed (mga#4903) > > 1) This is not what you've done. > What you've done is suggesting many GNOME packages that don't came > from gnome-utils > but come from their own SRPMS. gnome-utils was split up into various tarballs: http://live.gnome.org/GnomeUtils task-gnome contained only a "Obsoletes: gnome-utils". I replaced it with suggests for the splitted packages to ensure that gnome-screenshot (the bug) as well as the other replacements would be installed. Or do you mean that above webpage is wrong? Could be, didn't really check that thoroughly what packages replaced gnome-utils. > 2) Also as those are suggests, they'll never end on the install DVD, > thus defeating > " ensure gnome-utils is installed" I have asked many times about task-gnome and task-gnome-minimal and everyone has their own definition. I've asked various times if the "GNOME" option in the installer could please reflect "GNOME", and not some weird cut-down version of it called "task-gnome-minimal", but haven't gotten very far with that. I don't want to step on toes and just ignore the "task-gnome-minimal" vs "task-gnome", etc (I still don't get why we have -minimal; I also don't see why we have task-gnome though.. seems that not even Nautilus would be installed), so I added Suggests instead. I don't really see any difference between either having the gnome-screenshot as a Suggests in task-gnome (which the installer doesn't install, it looks at task-gnome-minimal) or as Suggests in task-gnome-minimal (which won't end up on the DVD apparently). If task-gnome-minimal is "not to be touched" and task-gnome is not installed by the installer.. what am I to do to fix bugs? Suggests seems like the only option. Furthermore, I've also added a gnome-screenshot Suggests to gnome-shell. IMO mga#4903 was an avoidable bug. As bugs are discovered on resulting dependency problems, I want to fix every case. To me it seems the wrong way to deal with this, but I rather raise "-minimal" strangeness after Mageia 2 release so I can point at the resulting bugs. -- Regards, Olav
Re: [Mageia-dev] [Freeze] please let in xonotic
11.03.2012 19:28, Colin Guthrie kirjoitti: > However, I do feel we need to be more generally open to freeze pushes. > The justification in this case, IMO, was sufficient and in line with the > previous interpretations of policy we have expected in the past, but I > completely respect misc if he still disagrees. I also believe we should be more open to pushes for packages like xonotic, i.e. "unimportant" leaf packages, since having the new version for software like xonotic is generally more important than having zero regressions (which are in any case limited to xonotic only, and can be fixed later). Line would have to be drawn somewhere, though (otherwise it would become a mess, I guess), and I'm really not sure right now where it should exactly be then This is just my opinion, not based on any previous discussion. -- Anssi Hannula
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release task-gnome-3.3.2-8.mga2
On 12 March 2012 18:06, ovitters wrote: > ovitters 1:3.3.2-8.mga2: > + Revision: 223037 > - ensure gnome-utils is installed (mga#4903) 1) This is not what you've done. What you've done is suggesting many GNOME packages that don't came from gnome-utils but come from their own SRPMS. 2) Also as those are suggests, they'll never end on the install DVD, thus defeating " ensure gnome-utils is installed"
[Mageia-dev] freeze push: rpm-helper
The 0.24.7 release just fixes documentation about add_syslog macro, and drop old sysklogd dead code. -- BOFH excuse #120: we just switched to FDDI.
Re: [Mageia-dev] [soft-commits] [3424] convert to utf8
Le 12/03/2012 17:49, Thierry Vignaud a écrit : On 12 March 2012 17:44, wrote: convert to utf8 Modified Paths rpm/rpm-helper/trunk/AUTHORS Modified: rpm/rpm-helper/trunk/AUTHORS === --- rpm/rpm-helper/trunk/AUTHORS2012-03-12 16:24:14 UTC (rev 3423) +++ rpm/rpm-helper/trunk/AUTHORS2012-03-12 16:44:57 UTC (rev 3424) @@ -1,4 +1,4 @@ -Fr\xE9d\xE9ric Lepied +Frédéric Lepied Herton Ronaldo Krzesinski Thierry Vignaud Guillaume Rousse Time to kill obsolete emails. Fred has gone away from mdv a lng time ago. Ditto for Herton, me, yourself, ... Indeed, I didn't read carefully enough :) Anyway, that will be for next release, I just tagged 0.24.7. -- BOFH excuse #338: old inkjet cartridges emanate barium-based fumes
Re: [Mageia-dev] [soft-commits] [3424] convert to utf8
On 12 March 2012 17:44, wrote: > convert to utf8 > > Modified Paths > > rpm/rpm-helper/trunk/AUTHORS > > Modified: rpm/rpm-helper/trunk/AUTHORS > === > --- rpm/rpm-helper/trunk/AUTHORS 2012-03-12 16:24:14 UTC (rev 3423) > +++ rpm/rpm-helper/trunk/AUTHORS 2012-03-12 16:44:57 UTC (rev 3424) > @@ -1,4 +1,4 @@ > -Fr\xE9d\xE9ric Lepied > +Frédéric Lepied > Herton Ronaldo Krzesinski > Thierry Vignaud > Guillaume Rousse Time to kill obsolete emails. Fred has gone away from mdv a lng time ago. Ditto for Herton, me, yourself, ...
Re: [Mageia-dev] [Freeze] please let in xonotic
On Monday 12 March 2012 08:31, zezinho wrote: > As usually people who does agree says nothing And the few of us who do say we agree, seems to drown in the traffic. :-)= -- Johnny A. Solbu PGP key ID: 0xFA687324 signature.asc Description: This is a digitally signed message part.
[Mageia-dev] Python3 modules
Hello! We will have Python3 in Mageia 2, but we don't build modules in the Py3 version. http://pkgs.org/search/?keyword=python3 is showing a long list of modules for Fedora and very short list for Mageia. Preparing Py3 versions is quite simple - here is an example http://svnweb.mageia.org/packages/cauldron/python-pyparsing/current/SPECS/python-pyparsing.spec?view=markup We have just to prepare two concurrently build roots, one for each python version. Fedora has a list of Py3 compatible modules https://fedoraproject.org/wiki/Python3 Regards!
Re: [Mageia-dev] Freeze Push Question: pulseaudio
12.03.2012 00:32, Colin Guthrie kirjoitti: > Hi, Hi, > We're aiming to get a PA 2.0 release out very soon (within the next 4 > weeks). > [...] > Can this go it? I think it's worth it. I think pulseaudio is an acceptable candidate for exception here, mainly because - it fixes some big audio usability issues (that will only affect more and more systems during MGA2 lifetime) with the new features, and - our package maintainer is the upstream maintainer as well, allowing efficient handling of any bugreports. However, I know I'm probably more lax here than others, so this requires the input of other release managers before a decision. -- Anssi Hannula
Re: [Mageia-dev] Package push request: oxygen-gtk and oxygen-gtk3
On 12 March 2012 16:08, Funda Wang wrote: > As oxygen is our default theme for gtk2 and gtk3, I think we should > mark these two packages as important packages, and push updated > version as soon as possible. Plus, the new versions fixed a nasty bug > that it will crash theme selector when changing from oxygen to another > theme. See: https://projects.kde.org/news/127 Actually it makes other program to crash such as net_applet, mgaapplet, ... So +1
Re: [Mageia-dev] Mageia support for GMA 3600 (Cedar Trail Atom)
On Mon, 12 Mar 2012, zezinho wrote: > Le lundi 12 mars 2012 00:38:00, tux99-...@uridium.org a �crit : > > Sorry ignore the previous pastebins, those were without "vga=795" on the > > kernel line, here are the correct ones: > > > > Please, maybe this could go only into the bug report? There is no bug report because I don't even know if this is a bug or a simple configuration issue, that's what I'm trying to find out.
Re: [Mageia-dev] Fwd: libgdata 0.11.1 (security release)
2012/3/12 Olav Vitters > On Mon, Mar 12, 2012 at 05:39:30PM +0800, Funda Wang wrote: > > I would say yes, we have 0.11.0, and 0.11.1 fixed a security problem. > > We should get it in. > > Funda committed the changes. Please submit. Note that the NEWS file > mentions some configure option, but that isn't needed actually. > > Pushed > -- > Regards, > Olav > -- Anne http://www.mageia.org
Re: [Mageia-dev] Fwd: libgdata 0.11.1 (security release)
On Mon, Mar 12, 2012 at 05:39:30PM +0800, Funda Wang wrote: > I would say yes, we have 0.11.0, and 0.11.1 fixed a security problem. > We should get it in. Funda committed the changes. Please submit. Note that the NEWS file mentions some configure option, but that isn't needed actually. -- Regards, Olav
[Mageia-dev] Package push request: oxygen-gtk and oxygen-gtk3
Hello, As oxygen is our default theme for gtk2 and gtk3, I think we should mark these two packages as important packages, and push updated version as soon as possible. Plus, the new versions fixed a nasty bug that it will crash theme selector when changing from oxygen to another theme. See: https://projects.kde.org/news/127 I've committed the new versions already. Regards.
[Mageia-dev] Fwd: GConf 3.2.5
please submit, I committed all the changes (freeze check on submission works nicely btw :P my script commits + submits in one go, so sysadmins might see some rejected submissions from my userid) -- Regards, Olav --- Begin Message --- About GConf === GConf is a process-transparent configuration database API used to store user preferences. It has pluggable backends and features to support workgroup administration. This component is deprecated - new code should be written to use GSettings. News Fixes: * fix an obvious memory error from the last release thanks to Ionut Biru; apologies to everyone else ChangeLog = http://download.gnome.org/sources/GConf/3.2/GConf-3.2.5.changes (783) Download http://download.gnome.org/sources/GConf/3.2/GConf-3.2.5.tar.xz (1.45M) sha256sum: 4ddea9503a212ee126c5b46a0a958fd5484574c3cb6ef2baf38db02e819e58c6 ___ ftp-release-list mailing list ftp-release-l...@gnome.org http://mail.gnome.org/mailman/listinfo/ftp-release-list --- End Message ---
Re: [Mageia-dev] [soft-commits] [3417] Updating Spanish translation
On 12 March 2012 13:44, wrote: > Revision 3417 Author jacen Date 2012-03-12 13:44:33 +0100 (Mon, 12 Mar 2012) > > Log Message > > Updating Spanish translation that doesn't reflect the actual changes: > Modified Paths > > system-config-printer/trunk/po/es.po > > Modified: system-config-printer/trunk/po/es.po > === > --- system-config-printer/trunk/po/es.po 2012-03-12 09:50:33 UTC (rev > 3416) > +++ system-config-printer/trunk/po/es.po 2012-03-12 12:44:33 UTC (rev > 3417) > @@ -7,9 +7,9 @@ > "Project-Id-Version: system-config-printer\n" > "Report-Msgid-Bugs-To: https://bugzilla.redhat.com/bugzilla\n"; > "POT-Creation-Date: 2008-08-27 16:54-0400\n" > -"PO-Revision-Date: 2012-03-12 02:32+\n" > +"PO-Revision-Date: 2012-03-12 12:42+\n" > "Last-Translator: Luis Llave \n" > -"Language-Team: LANGUAGE \n" > +"Language-Team: LANGUAGE \n" > "MIME-Version: 1.0\n" > "Content-Type: text/plain; charset=UTF-8\n" > "Content-Transfer-Encoding: 8bit\n"
Re: [Mageia-dev] Freeze push: rsyslog
'Twas brillig, and Michael Scherer at 12/03/12 10:45 did gyre and gimble: > Le lundi 12 mars 2012 à 10:41 +, Colin Guthrie a écrit : >> 'Twas brillig, and Colin Guthrie at 11/03/12 17:18 did gyre and gimble: >>> Bugfix release upstream. >>> >>> This includes some runtime systemd autodetection-foo to prevent the need >>> for hardcoding the listen path. This, in theory, means we can drop >>> listen.conf from the systemd package, thus making rsyslog work under >>> non-systemd boots too. >>> >>> We've previously OK'ed updates to mga1 of updated rsyslog versions so >>> this should be a relatively uncontroversial push. >> >> Ping! >> >> I'm waiting for this so I can submit a new systemd which I'd like to >> ensure is part of beta2. > > Pushed. Many thanks, misc. Much appreciated. The corresponding update to systemd also now pushed. KUTGW :) Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] Freeze push: rsyslog
Le lundi 12 mars 2012 à 10:41 +, Colin Guthrie a écrit : > 'Twas brillig, and Colin Guthrie at 11/03/12 17:18 did gyre and gimble: > > Bugfix release upstream. > > > > This includes some runtime systemd autodetection-foo to prevent the need > > for hardcoding the listen path. This, in theory, means we can drop > > listen.conf from the systemd package, thus making rsyslog work under > > non-systemd boots too. > > > > We've previously OK'ed updates to mga1 of updated rsyslog versions so > > this should be a relatively uncontroversial push. > > Ping! > > I'm waiting for this so I can submit a new systemd which I'd like to > ensure is part of beta2. Pushed. -- Michael Scherer
Re: [Mageia-dev] Freeze push: rsyslog
'Twas brillig, and Colin Guthrie at 11/03/12 17:18 did gyre and gimble: > Bugfix release upstream. > > This includes some runtime systemd autodetection-foo to prevent the need > for hardcoding the listen path. This, in theory, means we can drop > listen.conf from the systemd package, thus making rsyslog work under > non-systemd boots too. > > We've previously OK'ed updates to mga1 of updated rsyslog versions so > this should be a relatively uncontroversial push. Ping! I'm waiting for this so I can submit a new systemd which I'd like to ensure is part of beta2. Thanks. Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] [Freeze] please let in xonotic
Le lundi 12 mars 2012 à 08:29 +0100, Maarten Vanraes a écrit : > to get back on topic: perhaps it's not unreasonable to allow a timelimit > exception, like for instance 3 or 4 days where "i forgot it was freeze or > didn't make it in time AND it's not likely to mess everything up" kind of > reason... That was already discussed when we discussed the release cycle. And basically, that would just "let's reduce the freeze by 3/4 days in a more inefficient way". You just move the bickering at the 3/4 days limit ( "but it could have bene if I had submitted yesterday" ) instead of the beggining of the freeze, and you take time to the people who are submitting, since they get message, have to warn packager about "it doesn't work" ( as it happened several time last freeze period ). So next time, maybe we should have a pure good faith based system, instead of enforcing it with youri, since every attempt to enforce lead to discussion. This way : - we do not change anything, so no time to invest in too much communication - no time lost by sysadmin to put the freeze, even if that's minor ( except when stuff break ) - everybody can do as he see fit > (about communication: maybe it's more prudent to have a messagebox above > http://pkgsubmit.mageia.org/ telling us about various freezes and upcoming > soon freezes, even though as a packager it's my task to read meeting logs and > keeping myself up2date) Patch welcome, but frankly, I think there is a point where the duty of being informed must be on the packagers. It is rather depressing to realize that people do not read the announce you send ( and what is more depressing is the number of those that don't once you start to dig out ). If some people missed the announce, maybe we should ask them "where do you read information about the project and where don't you read", so we can identify the communication channel that should be used and those that shouldn't, as i am not sure that hammering more is the solution. -- Michael Scherer
Re: [Mageia-dev] Freeze Push Question: pulseaudio
'Twas brillig, and Colin Guthrie at 11/03/12 22:32 did gyre and gimble: > Can this go in? I think it's worth it. Forgot to add the bug link: https://bugs.mageia.org/show_bug.cgi?id=225#c27 As someone who also has to field support from upstream, I know this issue comes up a lot. I'd very much appreciate it if we could reduce my explanation overhead on this matter :D Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] Fwd: libgdata 0.11.1 (security release)
I would say yes, we have 0.11.0, and 0.11.1 fixed a security problem. We should get it in. 2012/3/12 Olav Vitters : > security thing.. busy atm, cannot handle immediately > -- > Regards, > Olav > > > -- 已转发邮件 -- > From: Philip Withnall > To: FTP Releases > Cc: > Date: Mon, 12 Mar 2012 09:27:46 + (UTC) > Subject: libgdata 0.11.1 > About libgdata > == > > libgdata is a GLib-based library for accessing online service APIs > using the GData protocol — most notably, Google's services. It > provides APIs to access the common Google services, and has full > asynchronous support. > > News > > > Major changes: > * Add a --with-ca-certs configure argument to allow specifying the system CA > cert file — an important security fix to allow libgdata to verify all TLS > certificates before accepting them > > Bugs fixed: > * Bug 667577 — fix introspection for srcdir != builddir builds > * Bug 668365 — libgdata 0.10.x link error because of exported symbols that > don't exist > * Bug 671535 — Security issue in libgdata > > Updated translations: > * be (Kasia Bondarava) > * te (Praveen Illa) > * uk (Korostil Daniel) > > > ChangeLog > = > http://download.gnome.org/sources/libgdata/0.11/libgdata-0.11.1.changes > (3.18K) > > Download > > > http://download.gnome.org/sources/libgdata/0.11/libgdata-0.11.1.tar.xz (1.10M) > sha256sum: ec96788b641f357745646b5645196787bf002182c95298ae80b84b935c69759b > > ___ > ftp-release-list mailing list > ftp-release-l...@gnome.org > http://mail.gnome.org/mailman/listinfo/ftp-release-list
[Mageia-dev] Fwd: libgdata 0.11.1 (security release)
security thing.. busy atm, cannot handle immediately -- Regards, Olav --- Begin Message --- About libgdata == libgdata is a GLib-based library for accessing online service APIs using the GData protocol — most notably, Google's services. It provides APIs to access the common Google services, and has full asynchronous support. News Major changes: * Add a --with-ca-certs configure argument to allow specifying the system CA cert file — an important security fix to allow libgdata to verify all TLS certificates before accepting them Bugs fixed: * Bug 667577 — fix introspection for srcdir != builddir builds * Bug 668365 — libgdata 0.10.x link error because of exported symbols that don't exist * Bug 671535 — Security issue in libgdata Updated translations: * be (Kasia Bondarava) * te (Praveen Illa) * uk (Korostil Daniel) ChangeLog = http://download.gnome.org/sources/libgdata/0.11/libgdata-0.11.1.changes (3.18K) Download http://download.gnome.org/sources/libgdata/0.11/libgdata-0.11.1.tar.xz (1.10M) sha256sum: ec96788b641f357745646b5645196787bf002182c95298ae80b84b935c69759b ___ ftp-release-list mailing list ftp-release-l...@gnome.org http://mail.gnome.org/mailman/listinfo/ftp-release-list--- End Message ---
Re: [Mageia-dev] Freeze Push Question: pulseaudio
12.03.2012 00:32, Colin Guthrie kirjutas: Anyway, this is my justification. I have packages ready to roll. Can this go it? I think it's worth it. Col Working sound is for many users a must have. So if PA 2.0 will get us better support here then i'm all in. No point to wait another year to get this support. Especially if we have upstream with us to fis problems ASAP. -- Sander
Re: [Mageia-dev] ANN: version freeze and what it means for Mageia 1 updates
On 03/12/2012 09:06 AM, Samuel Verschelde wrote: Hi, Just a quick reminder that the version and release of a package in cauldron must ALWAYS be higher (or equal) to that in Mageia 1. Otherwise we cannot I would explicitely add to this to check also updates, backports _and_ testing repos... guarantee upgrade from Mageia 1 to Mageia 2. Since we are in version freeze we must check this with more accuracy. Packagers, let's keep this (obvious) rule in mind (I'm not sure it's enforced in the buildsystem yet, but I may be wrong). QA Team, before validating an update, please check the version in cauldron. BTW : do we have a check.mageia.org page to spot packages for which this is not the case, if there are any? Maybe this reminder is not useful at all, but I think it's always better to send it rather than not. Best regards Samuel "Gives lessons and does nothing" Verschelde -- J.A. Magallon \ Winter is coming...
[Mageia-dev] ANN: version freeze and what it means for Mageia 1 updates
Hi, Just a quick reminder that the version and release of a package in cauldron must ALWAYS be higher (or equal) to that in Mageia 1. Otherwise we cannot guarantee upgrade from Mageia 1 to Mageia 2. Since we are in version freeze we must check this with more accuracy. Packagers, let's keep this (obvious) rule in mind (I'm not sure it's enforced in the buildsystem yet, but I may be wrong). QA Team, before validating an update, please check the version in cauldron. BTW : do we have a check.mageia.org page to spot packages for which this is not the case, if there are any? Maybe this reminder is not useful at all, but I think it's always better to send it rather than not. Best regards Samuel "Gives lessons and does nothing" Verschelde
Re: [Mageia-dev] Mageia support for GMA 3600 (Cedar Trail Atom)
Le lundi 12 mars 2012 00:38:00, tux99-...@uridium.org a écrit : > Sorry ignore the previous pastebins, those were without "vga=795" on the > kernel line, here are the correct ones: > Please, maybe this could go only into the bug report?
Re: [Mageia-dev] [Freeze] please let in xonotic
Le dimanche 11 mars 2012 22:25:32, Michael Scherer a écrit : > > > Le samedi 10 mars 2012 à 10:26 +0100, Thierry Vignaud a écrit : > > > > please let in xonotic-0.6.0 > > > > It's just a game that impacts nothing else. > But so far, I think that we are basically and roughly coherent when > compared to the last freeze period. Therefore, I do not see the need to > communicate a change when there was in fact no changes on the side of > the policy. And sorry, I cannot communicate to say that what people > remember do not correspond to what was done. > As usually people who does agree says nothing, maybe I can say I agree the hardness of this freeze. I mean the way it is being kept. While I am happy to say thank you to TV for all his hard work, his unlucky attempt should drive all of us to forget anything but bugs.mageia.org till the release : a distro with lots of software can be killed by very simple bugs, and we have a lot of them concerning packages without maintainers...
Re: [Mageia-dev] [Freeze] please let in xonotic
Op maandag 12 maart 2012 07:53:38 schreef David W. Hodgins: [...] > My understanding was that Magea 1 supported updating from Mandriva > 2010.2 + Contrib + PLF-Free. > > There were several updates submitted to qa a few days ago, that are > only available in backports in Mdv 2010.2. [...] IMHO backports could be "supported" under Mageia backports, not in regular media. Keeping in mind our limited resources, nonetheless, several of these bugs which seemed to require workaround upon workaround, should get fixed sooner rather than later, because it seems to be getting more complicated or more discussed (and in generally too much resources being spent on it) i'm thinking of: - backports - noarch linking - bug 2317 - livemedia - or in general what we promise ( or rather to be careful what and how we promise): if we say: "there are no livemedia yet, but we're working on it to get it in the next few weeks" ... some people become angry, but you can also say: "There's a major bug preventing us from making livemedia, but we're working on them" and possibly even updating it when it becomes clear it'll be for the next release into "This beta release doesn't have any livemedia, we're hoping to have the next beta release containing livemedia" Similar with backports: it's been promised this time without timelimit, but people seem to be convinced it'll never make it. 3rd party repositories popping up etc... It does not make us look good. and I'm getting to the point where the resources spent on discussing backports seem to be larger than the eventual losses in resources that would have been due to backports being open. But now of all times, backports shouldn't open, rather in the first week after release of mga2 would be a nice timing. to get back on topic: perhaps it's not unreasonable to allow a timelimit exception, like for instance 3 or 4 days where "i forgot it was freeze or didn't make it in time AND it's not likely to mess everything up" kind of reason... But i think the point is now becoming moot if temporary freeze of Beta2 is in effect... (not sure if it is, but i think i saw something regarding it) (about communication: maybe it's more prudent to have a messagebox above http://pkgsubmit.mageia.org/ telling us about various freezes and upcoming soon freezes, even though as a packager it's my task to read meeting logs and keeping myself up2date)
