Re: [Mageia-dev] Freeze Push Question: pulseaudio
) complained there is _too_ much to download after a first installation, and why we shouldn't reduce the number of bugfixes for that, we can at least try to not plan to have more of them. And that's my 5th reason. So yes, I understand that you would like to push feature so it benefit to people. All upstream developers want that, all packagers want that. I would have loved to have the latest apache on our server for next upgrade, I would have loved to have systemd sooner for the buildsystem, or indeed, having the latest PA for the various bluez/A2DP fix Heck I would be sure that we have latest apache on our servers, as this would allow to have a cleaner , contrary to what people may think, no one actively work to break computers of others. I see that you think you would be able to properly handle everything. Because everybody think this. Yet, you would be alone on this on our side, and that's also a risk. If you were too busy to push PA sooner, and see that kernel 3.3 was planned to be the final, then there is a high chance that you would be too busy again. So for thoses 5 reasons, I would say no, even if I would rather see this just for free software advancement. -- 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 fundaw...@gmail.com 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] 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] [Freeze] please let in xonotic
Le samedi 10 mars 2012 à 10:26 +0100, Thierry Vignaud a écrit : Hi please let in xonotic-0.6.0 It's just a game that impacts nothing else. Niet. That's bugfix or security fixes. -- Michael Scherer
Re: [Mageia-dev] [Freeze] please let in xonotic
Le dimanche 11 mars 2012 à 14:47 +0200, Sander Lepik a écrit : 11.03.2012 14:42, Manuel Hiebel kirjutas: Le dimanche 11 mars 2012 à 14:29 +0200, Sander Lepik a écrit : 11.03.2012 14:21, Michael Scherer kirjutas: Le samedi 10 mars 2012 à 10:26 +0100, Thierry Vignaud a écrit : Hi please let in xonotic-0.6.0 It's just a game that impacts nothing else. Niet. That's bugfix or security fixes. Honestly, WTF?! It's a new package. According to sophie it's not a new package: http://sophie.zarb.org/rpms/810fca5bd939c8e4a6858a5711c5200f Yeah, i take some of my words back. But there is another problem - 0.6.0 seems to be in mdv2010.2. So upgrade path from Mandriva is broken. We do not garantee upgrade path from mdv 2010.2 to mga 2 -- Michael Scherer
Re: [Mageia-dev] [Freeze] please let in xonotic
Le dimanche 11 mars 2012 à 14:29 +0200, Sander Lepik a écrit : 11.03.2012 14:21, Michael Scherer kirjutas: Le samedi 10 mars 2012 à 10:26 +0100, Thierry Vignaud a écrit : Hi please let in xonotic-0.6.0 It's just a game that impacts nothing else. Niet. That's bugfix or security fixes. Honestly, WTF?! It's a new package. How much harm can it do? The same as any packages. What did people didn't understand about focus on bugfixes ? I would understand this rejection if we would have backports enabled. But we don't. Some point release can cause more trouble than this package. If by point release, you mean version upgrade in a minor version, that's also blocked. If by point release, you mean rebuild with spec change, that's much easier to revert and detect, since there is less changes to look at. And that's a part where packagers can realistially check. That's not the case for most tarballs where there is several changes for a new version. Frankly, there is a time where we should say this is the version we choose for the release. We are not doing a rolling release. So either you agree that there is a time to say stop to upgrade, be it on the day of release or before, and think that the time we choosed is not the right time, and in which case, they should clearly tell. Or you want a rolling release, and again, you have to clearly say I want to have a rolling release and I will answer there was some threads in the past -- Michael Scherer -- Michael Scherer
Re: [Mageia-dev] Version freeze: reminder
Le dimanche 11 mars 2012 à 01:59 +0100, Thierry Vignaud a écrit : On 8 March 2012 11:31, Anne nicolas enn...@mageia.org wrote: Version freeze is now active. As a reminder please have a look here https://www.mageia.org/pipermail/mageia-dev/2012-March/012533.html for more details. For years, the freeze never impacted our own tools since unless packages we are not upstream, we prefer to release than patch (which also helps get latest translations). Now, drakx* stuff got blocked. For years, the whole stack have been developped in the last minute. So I would request we relax the freeze for our own stuff. else It'll made pushing fixes quite slow painfull. In worst case, instead of pushing the stack in ~30mns, it may takes days. eg if I fix sg in urpmi, I've to wait for someone to actually push urpmi before asking to push drakx-installer-stage2 with new urpmi. Yes. Or you can backport the fix as patch. Or say that's just a bugfix release. eg if I fix sg in rpm, I've to wait for someone to actually push rpm before asking to push perl-URPM to drakx-installer-stage2. Perl-URPM would not require a version upgrade, so would not need anyone to push, as well as drakxinstall-stage2. Since a fix to rpm would be a patch, that's also no a version upgrade. So for version freeze, there is no need of anything special. And for release freeze, I would hope that we do not need fix that requires to rebuild 4 differents rpms. At least not more than once... It can become way more painful for eg: dietlibc fixkmod|ldetectdrakx-installer-binariesdrakx-installer-images eg: if would fix sg in dietlibc for kmod. Thus I would have 4 requests with delays between each. Or enable me to push new perl-URPM/urpmi/drakx* like I was able to do in the old days No, for the aformentioned reasons. --
Re: [Mageia-dev] [Freeze] please let in xonotic
Le dimanche 11 mars 2012 à 14:24 +0100, Thierry Vignaud a écrit : On 11 March 2012 13:54, Michael Scherer m...@zarb.org wrote: please let in xonotic-0.6.0 It's just a game that impacts nothing else. Niet. That's bugfix or security fixes. Honestly, WTF?! It's a new package. How much harm can it do? The same as any packages. What did people didn't understand about focus on bugfixes ? Sorry but I'm the one pushing that package and I am ALSO FEELING ALONE FIXING BUGS... Yes, I have seen that you are the one pushing the package. Did I missed something about you ? And I have seen that you are pushing fixes ( and also non fixes after version freeze since it was not properly enforced ) But I fail to see the relation between this and the push of a game past the version freeze. -- Michael Scherer
Re: [Mageia-dev] Notify i18n on string changes
Le dimanche 11 mars 2012 à 10:37 +0100, Oliver Burger a écrit : Hi there, I noticed, Thierry was adding new strings to drakx. We are after i18n freeze, so please tell i18n team explicitely, when you do something like that. I think we did wanted to send automated mail on commit for that, i did add support for that on our svn setup, but I guess i didn't have time to finish the job. -- Michael Scherer
Re: [Mageia-dev] [Freeze] please let in xonotic
Le dimanche 11 mars 2012 à 15:36 +0100, Thierry Vignaud a écrit : On 11 March 2012 14:45, Michael Scherer m...@zarb.org wrote: It's a new package. How much harm can it do? The same as any packages. What did people didn't understand about focus on bugfixes ? Sorry but I'm the one pushing that package and I am ALSO FEELING ALONE FIXING BUGS... Yes, I have seen that you are the one pushing the package. Did I missed something about you ? And I have seen that you are pushing fixes ( and also non fixes after version freeze since it was not properly enforced ) But I fail to see the relation between this and the push of a game past the version freeze. This means it's quite rude that people that don't do any fix at all shouts focus on bugfixes to those who are actually doing bug fixes and also, AS WAS ALWAYS DONE WHEN EXPLAINED, request some exceptions to the freeze policy. Doing bug fixes is not some kind pf money to get exceptions. We said that exception should be justified, and this break nothing at all is not a justification. And regarding the personal attack on my involvement, I will try to pretend it didn't happen. -- Michael Scherer
Re: [Mageia-dev] [Freeze] please let in xonotic
Le dimanche 11 mars 2012 à 17:58 +0100, Samuel Verschelde a écrit : Le dimanche 11 mars 2012 13:21:57, Michael Scherer a écrit : Le samedi 10 mars 2012 à 10:26 +0100, Thierry Vignaud a écrit : Hi please let in xonotic-0.6.0 It's just a game that impacts nothing else. Niet. That's bugfix or security fixes. Communication tip for the future : when such a policy change happens (this is a policy change, there were more exceptions in the past before package freeze, for leaf packages without weird deps and post/pre scripts and little impact), let's try to highlight it *before*. We asked if people understood what version freeze mean, and people all said yes. http://meetbot.mageia.org/mageia-dev/2012/mageia-dev.2012-02-15-20.13.log.html#l-75 So I assumed that people were aware of what was posted last time : http://permalink.gmane.org/gmane.linux.mageia.devel/4015 and that very good reasons where basically the same for everybody. It seems there is some misunderstanding, likely coming from another discussion that the one I found. Can people just tell me where they have seen their interpretation of freeze, cause I have read the one I posted twice, I still think it correspond that what i just said. There was a communication effort to announce the freeze: I read freeze announce, was present at the last packager meeting. However it didn't struck me, it all looked like the usual end of release cycle, with their common-sense exceptions. A message such as contrarily as what happened in the past (this is the important part, highlight a *change*), there will be no exception even for leaf non-critical packages, so that you all focus on bugfixes, as we know that otherwise you will not fix bugs and continue updating your packages. I took a look at the archives for the last round ( ie mageia 1 ), thanks to evolution. Since people were upset because this exception should have been granted, I assumed that the same type of exception would have been granted in the past numerous times ( I mean, if people didn't remember the mail saying this would not be granted, that's likely because we granted it several time, enough time to have people totally forget what was posted in the first place ). I found exactly 1 package that not at least saying that's a bug fix release, this fix a CVE, it fix upgrade., ie all reasons that were announced we would likely let this pass. It was alienarena on 06/05/2011, and it was pushed by boklm around 2h after the mail was sent. That's the only one I can find that was not corresponding at the criteria we laid out for being a regular exception ( cf url given sooner ), but it was still granted. We trusted boklm as well as others to choose, so he did. But still, if we look at the list given before ( and since no one answered at all and no one complained later, I assumed that everybody agreed, especially since this was based on common sense ), it was said it would likely not pass. So if there wasn't others ( and I will assume that's the case unless someone show others examples that I could have missed ), we can see that the whole but it was granted last time assumption is either based on : - 1 single rpm being a exception that would have been refused and that wasn't ( ie, a weak example ) or : - based on a different last time than last year ( and then why did no one complained last year is left as a exercise ) or : - based on different perception of what type of exception were granted last time, perception that doesn't align with the reality of the archives I checked. 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. And we can see that as tmb said, the problem is not that granting would disturb the distribution, but that granting once for a minor package would lead to the same type of lengthy and heated discussion as we are having now, but for each packages. The more complex the rules are, the more discussion and the more problem we will have to solve. -- Michael Scherer
Re: [Mageia-dev] lvm2 initscript is marked as a config file...?
Le mardi 06 mars 2012 à 22:12 +0200, Anssi Hannula a écrit : 06.03.2012 21:48, Colin Guthrie kirjoitti: Hiya I noticed while doing the updates round that the file /etc/init.d/lvm2-monitor had a .rpmnew... Thus is seems to be marked as a config file. Is this correct? Most initscripts are not meant to be configured... is this the exception that proves the rule? Doesn't look like configurable. I have many times seen random non-config files marked as %config(noreplace) in very old .specs just because they are in /etc. This instance also predates mdv SVN migration (unfortunately their CVS has been brought down). (maybe rpmlint wrongly warned about them many many years ago, causing people to add unwanted %config flags...) That's it. And that's something that always bothered me on a fundamental level, if that's not config, it should not be in /etc/, as this gave likely wrong expectation to people ( ie, that they could safely hack around initscripts and have no problem on upgrade ). The systemd approach with inheritance is much cleaner on this regard.
Re: [Mageia-dev] Release_blocker bugs
Le mercredi 07 mars 2012 à 21:43 +0100, Manuel Hiebel a écrit : Hello, How can we (the bugsquad or other people) determinate what can be a release_blocker bug ? in the triage guide we can see: The release_blocker priority is only relevant to bugs filed on Cauldron or beta releases, and should only be used for issues which are sufficiently critical that it would severely impair the overall quality of a release if it were made available without the issue being resolved. That is not clear for me. And the only mail relating to that, was from Anne in May and not useful for me. I would say stuff that cannot be fixed after release would be release blocker. Not to say that the rest cannot be too, but at least, that's the first criteria. So a software on livecd that crash on startup would also be a blocker. -- Michael Scherer
Re: [Mageia-dev] agetty vs. mingetty
Le jeudi 08 mars 2012 à 10:38 -0500, Liam R E Quin a écrit : On Thu, 2012-03-08 at 14:17 +, Colin Guthrie wrote: So if we switch to mingetty in getty@.service we'll be sacrificing serial console support. Web hosting companies sometimes provide access to a serial console. Then I guess they can also take the step of installing agetty or mgetty and configure it, since they have to configure it anyway. So we are just adding 1 rpm to install, documented to in the man pages ( and the rest of the web ). -- Michael Scherer
Re: [Mageia-dev] Versions freeze
Le samedi 03 mars 2012 à 23:35 +0100, Maarten Vanraes a écrit : Op zaterdag 03 maart 2012 22:34:41 schreef Sander Lepik: Well, actually I'm sure it could. But why? All meeting logs are publicly available at https://meetbot.mageia.org/ Why? Because now i know this link for some time and then i forget it again :) Sorry but Mageia isn't the only project where i'm contributing. I just can't remember everything. But thanks for the link. -- Sander maybe we could have the meetbot send it to another mailing list and the people who don't frequently are able to follow the meetings can subscribe to that. Send patchs upstream, and we will use it sooner or later. -- Michael Scherer
Re: [Mageia-dev] oce (opencascade) license issues
Le vendredi 02 mars 2012 à 23:46 +, Barry Jackson a écrit : I have been working on oce, but need help deciding on where to put it and with what license. Oce is the OPENCascade Community Edition. Earlier versions are/were packaged by Mdv and Fedora, and recently Deb has included it. It seems from OPENCascade's own license literature to be LGPL-like with differences. (but rpmlint is not happy with that). Fedora consider it non-free, but since all the source is available and redistributable I don't know why, so ignore my comment on line 1 of the spec. There are links in the spec to license references. See https://bugzilla.redhat.com/show_bug.cgi?id=458974 ( notably the comment from #10 ). I would push this to non-free, because that would be a problem for a company. -- Michael Scherer
Re: [Mageia-dev] Versions freeze
Le vendredi 02 mars 2012 à 20:53 +0100, Maarten Vanraes a écrit : Op vrijdag 02 maart 2012 20:16:11 schreef Thomas Backlund: 02.03.2012 21:08, Dimitri Jakov skrev: Besides... GNOME 3.4 is going to be released on March 28 - does that Yes we know... mean that we won't be able to ship it with Mageia 2? Nope, we have that as an exception to the freeze... (that's why we already run 3.3.x) we will have Gnome 3.4.x and KDE 4.8.x in Mageia 2 also, I hope mariadb-5.5.x final (right now we have 5.5.20 which is the alpha version; beta will come quite soon, then the rc and finals follow pretty fast and these only contain bugfixes) Next time, maybe waiting for the beta would be better, cauldron is not mean to be a playground for testing upstream softwares when we do not have a strong assurance that the stable will end i the stable release. If everybody start to do that, we spend more time on upgrading to version that should have been stable than fixing others bugs. And if upstream could also try to be a little bit less original and follow some easy to grasp convetion about version number. -- Michael Scherer
Re: [Mageia-dev] Versions freeze
Le vendredi 02 mars 2012 à 16:06 +0100, Johnny A. Solbu a écrit : On Friday 02 March 2012 15:31, Wolfgang Bornath wrote: Back in my school days when we had to do a home work project of 1 month our teacher used to remind us the day before scheduled deadline - for people like me it meant to start working on the project! Some people may be like me... Maybe we should have a policy on when to remind developers on version freezes. Say, one or two weeks before the freeze, so they get a chance to submit final changes. We reminded there is version freeze coming during meetings ( like http://meetbot.mageia.org/mageia-dev/2012/mageia-dev.2012-02-15-20.13.log.html#l-75 ), or what is the plan until the release ( http://meetbot.mageia.org/mageia-dev/2012/mageia-dev.2012-01-26-20.03.html ). We gave the list of date in advance ( https://wiki.mageia.org/en/Mageia_2_development ) and a link to the planning in every mail of announce, as well in blog posts and forums post. We have a calendar ( http://www.mageia.org/en/calendar/ ), where the freeze was given. And I expect people to either be experienced packager ( ie who have already done 1 release and so know the rules ), or to be new packagers with a experienced packager ( ie mentor ) who should have explained the release cycle. So if people have missed the whole plan, there is a problem that we need to fix, and the first step would be to collect reasons why they did missed it, not nag more everybody on every possible channels. For people who didn't miss and who read the mails etc, the reminder are annoying and the more reminder we put, the more they will start to ignore them. And I see no reason to annoy those that do the job and follow thing to help those that don't. So if someone want to start collecting feedback, digesting it and present it, just say that you are volunteer on the list, and start the collect. -- Michael Scherer
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release xdm-1.1.11-3.mga2
Le mercredi 29 février 2012 à 18:44 +0100, Oliver Burger a écrit : Am 29.02.2012 17:34, schrieb Thierry Vignaud: On 29 February 2012 17:08, damsbuildsystem-dae...@mageia.org wrote: damsdams 1.1.11-3.mga2: + Revision: 216185 - Add 'Provides: dm' (bug #4532) This is wrong IMHO as the only packages that requires or suggest dm are: - xguest - task-xfce-minimal xguest didn't work with xdm and task-xfce-minimal had better require the dm it wants like task-gnome task-kde do So I think this should be reverted. Let's fix task-xfce-minimal instead. Which brings back the question, which of our dms should provide dm? None ? After all, if dm is used for xguest, the provides used should reflect that. For drakdm, I think there is a hardcoded list, and as you say, every task-* pull a prefered dm. So what is it used for, except asking question to users ( and most that would not care or not know what it mean ) ? -- Michael Scherer
Re: [Mageia-dev] please drop python-xpcom
Le lundi 27 février 2012 à 11:02 +0100, Zézinho a écrit : can a sysadmin please drop python-xpcom from cauldron? It was needed by sugar-browse-activity, but it now uses webkit... No chance of people using it by itself ? -- Michael Scherer
Re: [Mageia-dev] Removing Core 32bit from x86_64
Le samedi 25 février 2012 à 14:04 +0200, Sander Lepik a écrit : 25.02.2012 13:47, zezinho kirjutas: Le samedi 25 février 2012 11:44:58, Sander Lepik a écrit : They would have to add 32-bit core + 32-bit nonfree (as Skype is in nonfree) which is not even listed media for 64-bit system. So for now Skype is not avalaible in x86_64 without activating 32-bit nonfree? No, as it's noarch it's available in 64-bit nonfree too, but it needs 32-bit core for libs that it uses. Then, it should no be noarch. -- Michael Scherer
Re: [Mageia-dev] Removing Core 32bit from x86_64
Le samedi 25 février 2012 à 14:59 +0200, Sander Lepik a écrit : 25.02.2012 14:39, Michael Scherer kirjutas: Le samedi 25 février 2012 à 14:04 +0200, Sander Lepik a écrit : 25.02.2012 13:47, zezinho kirjutas: Le samedi 25 février 2012 11:44:58, Sander Lepik a écrit : They would have to add 32-bit core + 32-bit nonfree (as Skype is in nonfree) which is not even listed media for 64-bit system. So for now Skype is not avalaible in x86_64 without activating 32-bit nonfree? No, as it's noarch it's available in 64-bit nonfree too, but it needs 32-bit core for libs that it uses. Then, it should no be noarch. From the policy POV yeah, it shouldn't. From the usability POV.. well, it's our only option to make Skype available for 64-bit users. Usability issues should not be fixed by bypassing policy. We do not move software to wrong repository because this is easier. If people want a 32 bits binary from non-free, they need to activate it, especially for a dubious one such as skype, that is forbidden ( and by forbidden, I mean that it would disciplinary sanction ) in my last 2 jobs. And if that's too complex, people can also ask to the developers to push a 64 bits build. ( of course, since that's Microsoft, they will likely do nothing, but that's the price to pay for being dependent of a proprietary software ) So the package should be fixed, because currently, the deps are broken ( ie, the self containement rule is broken ), and that's IMHO enough for warranting a removal of the package if no one step to correct that. -- Michael Scherer
Re: [Mageia-dev] Removing Core 32bit from x86_64
Le vendredi 24 février 2012 à 12:12 +0100, Kamil Rytarowski a écrit : I think wine is using 32bit packages too. I think people who are able to use wine ( who is far from being fool proof enough ) are also able to read a doc explaining how to enable 32 bits repositories, and wine by itself is IMHO not a good reason to bloat installation and interface for the rest of us. -- Michael Scherer
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release cogl-1.9.6-1.mga2
Le jeudi 23 février 2012 à 09:32 +0100, Olav Vitters a écrit : On Wed, Feb 22, 2012 at 11:35:13PM +0100, Thierry Vignaud wrote: On 22 February 2012 23:33, Olav Vitters o...@vitters.nl wrote: Hard versionated requires are bogus and just defeat the purpose of libification: [..] Will be OK next time: See http://svnweb.mageia.org/packages/cauldron/cogl/current/SPECS/cogl.spec?r1=212291r2=212418 Is it possible to write an rpmlint check for this? If so, could you? :) there's at least requires-on-release is here for years... Ah, but it won't prevent packages from being submitted? If we are sure that every package is clean ( or most of them are ), and that someone volunteer to handle the complaint, we can turn it. But I think this would be better to do the change after mageia 2. -- Michael Scherer
Re: [Mageia-dev] Qt-based software unusable under XFCE since almost 2 days
Le dimanche 19 février 2012 à 12:19 +, Païou a écrit : Oliver Burger oliver.bgr@... writes: I don't see the reason for this answer. Michael is just trying to make sure, we don't have a unmaintained major DE. Now, some maybe a bit harsh words on the developer mailing list - this is no user support list or forum or whatever - are far better, then having something like xfce unmaintained. After all, what makes users run away: some not all that courteous mails on the -dev ml, whose existence they may or may not be aware of or a perhaps buggy, not updated, unmaintained desktop? And if we keep a whole DE unmaintained in the repos, what does that say about overall package quality? Oliver OK, you are right. Sorry. I wish ardently that Xfce remains maintained. I guess lots of people do. But history shown this is not enough. Let's suppose we keep xfce, despites being unmaintained. When people report bugs, they will have no or few answers. They will not like and complain. Maybe more than with a maintainer, maybe they will not care. When there will be bugs, no one will step to fix them. So people who try this will either say this DE is buggy, or this distribution is buggy. Then, likely sooner or later, someone will say the DE work fine on AnotherDistribution, so people will think the distribution is buggy and switch to AnotherDistribution. While the outcome look the same ( ie, people leaving because there is no package, or leaving because it is not working ), in one case, they will switch by thinking the distribution is not having what I want, but the rest was working and will not badmouth us. In the other case, they will think the distribution is buggy, and complain. So how ending like this would help us in the long run ? Maybe that's just me, but each time I mentioned I am doing package for Mandriva in the past 5 years, people kept explaining me that they faced some bug dating back to mandrake 7.0 time, and that they switched distributions and how they now live in a world filled with pink pony giving them candy, yadayadayada. Besides being demotivating for me ( cause my time travel machine is still not working ), this was hurting the promotion of Mandriva. Did someone ever heard fedora is bad because they didn't ship Xfce at the start. I never did, and I think everybody forgot it. I could surely give several example on all distribution of missing packages and people forgetting once the issue is fixed. So people are likely quicker to forget lack of packages than lack of quality. And if we do not have the ressources to achieve quality packages, then it is much more saner for us to choose the least damaging solution in the long term, ie removing packages. There was enough complains about Mandriva shipping buggy softwares, and if as a community, we cannot increase work done to fix this ( we tried, we even put 2 developers together to see if they mate and produce a 3rd one to help us ), we do not have much others choice. For my part I participate in it as tester, where from my a little bit virulent reaction. This place is also, I think, the only place where it is possible to have a dialogue with developers. (except bugzilla, but bugzilla is more specific) There is lots of place to have a dialogue, be it on irc, in real life and so on. And if some of us ( and me the first ) do not go on forums on a frequent basis, there is various reasons that were already explained in the past ( http://permalink.gmane.org/gmane.linux.mandrake.cooker.devel/305365 ), so I can only direct you to my previous answers as it is likely still valid ( at least for me ). -- Michael Scherer
Re: [Mageia-dev] Qt-based software unusable under XFCE since almost 2 days
Le samedi 18 février 2012 à 10:33 +0100, Olivier Thauvin a écrit : * Michael Scherer (m...@zarb.org) wrote: Le vendredi 17 février 2012 à 19:18 +0100, Claire Revillet a écrit : Hi, As a second point : there is still no xfce-* maintainer and as many people are using it on cauldron and as we have bug on Could we have xfce directly from dvd/dual/live installation please : it will be great that someone grab those packages. The candidat will have all our gratitude :) (and bug report :p ) If there is so much users, why is there no volunteer for taking just one package ? Being user does not mean having knowledge to maintain it. I know at least 2 people in the packagers group who use xfce. So if they have no knowledge for maintaining rpms ( and a dm doesn't require more knowledge than anything else ), that would be shocking. Anyway, if a major DE is unmaintained, maybe we should start to think removing it until there is enough volunteer, since we do not want to have a popular application to be crappy due to lack of maintainer. This would be lying to user, and giving them false expectations. -- Michael Scherer
Re: [Mageia-dev] Incorrect submission check: Unity desktop
Le mercredi 15 février 2012 à 16:38 +0100, Olav Vitters a écrit : I got the following submission error: Submission errors, aborting: - yelp-3.3.3-2.mga2.x86_64: - invalid-desktopfile /usr/share/applications/yelp.desktop value GNOME;Unity; for key OnlyShowIn in group Desktop - yelp-3.3.3-2.mga2.i586: - invalid-desktopfile /usr/share/applications/yelp.desktop value GNOME;Unity; for key OnlyShowIn in group Desktop Unity is a valid and registered desktop. Desktop-file-utils validates it as of version 0.19. Above submission check is outdated and wrong. Please fix the check so I can submit it again. We have updated desktop-file-utils on valstar. -- Michael Scherer
Re: [Mageia-dev] About dm
Le vendredi 17 février 2012 à 14:32 +0100, Oliver Burger a écrit : Am 17.02.2012 14:26, schrieb Païou: It could be due to the fact that xdm, who is also automatically installed, does not possess the property dm Well I don't think because kdm gets installed also, when gdm is installed, which does provide dm. See bug 4532. The question, why xdm does not provide dm I can't answer. Was there a technical reason or was it only forgotten? Because no one never documented exactly what is needed to be providing dm, or what it exactly mean. Does it mean to be one of the choice of the prefdm service ? Does it mean to be able to understand /etc/X11/wmsession.d/ ? Ant others need to be seen as dm ? Where would it have impact, in drakdm, somewhere ? Without enough formalism in the interaction of rpms, this is just gonna be a hack. People will add provides, will change stuff, without any consistency, and curiously, that later cause issues. -- Michael Scherer
Re: [Mageia-dev] Qt-based software unusable under XFCE since almost 2 days
Le vendredi 17 février 2012 à 19:18 +0100, Claire Revillet a écrit : Hi, As a second point : there is still no xfce-* maintainer and as many people are using it on cauldron and as we have bug on Could we have xfce directly from dvd/dual/live installation please : it will be great that someone grab those packages. The candidat will have all our gratitude :) (and bug report :p ) If there is so much users, why is there no volunteer for taking just one package ? -- Michael Scherer
Re: [Mageia-dev] Incorrect submission check: Unity desktop
Le mercredi 15 février 2012 à 16:06 +, Pascal Terjan a écrit : On Wed, Feb 15, 2012 at 15:38, Olav Vitters o...@vitters.nl wrote: I got the following submission error: Submission errors, aborting: - yelp-3.3.3-2.mga2.x86_64: - invalid-desktopfile /usr/share/applications/yelp.desktop value GNOME;Unity; for key OnlyShowIn in group Desktop - yelp-3.3.3-2.mga2.i586: - invalid-desktopfile /usr/share/applications/yelp.desktop value GNOME;Unity; for key OnlyShowIn in group Desktop Unity is a valid and registered desktop. Desktop-file-utils validates it as of version 0.19. Above submission check is outdated and wrong. Please fix the check so I can submit it again. I think the test is run on the server, meaning Mageia 1, which has 0.18 Yep. I guess that's time to test the new shiny sysadmin repo \o/ -- Michael Scherer
Re: [Mageia-dev] Incorrect submission check: Unity desktop
Le jeudi 16 février 2012 à 07:34 +0100, Michael Scherer a écrit : Le mercredi 15 février 2012 à 16:06 +, Pascal Terjan a écrit : On Wed, Feb 15, 2012 at 15:38, Olav Vitters o...@vitters.nl wrote: I got the following submission error: Submission errors, aborting: - yelp-3.3.3-2.mga2.x86_64: - invalid-desktopfile /usr/share/applications/yelp.desktop value GNOME;Unity; for key OnlyShowIn in group Desktop - yelp-3.3.3-2.mga2.i586: - invalid-desktopfile /usr/share/applications/yelp.desktop value GNOME;Unity; for key OnlyShowIn in group Desktop Unity is a valid and registered desktop. Desktop-file-utils validates it as of version 0.19. Above submission check is outdated and wrong. Please fix the check so I can submit it again. I think the test is run on the server, meaning Mageia 1, which has 0.18 Yep. I guess that's time to test the new shiny sysadmin repo \o/ And to report that it doesn't work ( seems it cannot find glib-devel, so I assume 'wrong source configuration' ). -- Michael Scherer
Re: [Mageia-dev] Error message while trying checkout a package?with mgarepo
Le samedi 11 février 2012 à 15:22 +0100, Dimitrios Glentadakis a écrit : Στις Σάββατο 11 Φεβρουάριος 2012 15:00:42 nicolas vigier γράψατε: On Sat, 11 Feb 2012, Dimitrios Glentadakis wrote: Στις Σάββατο 11 Φεβρουάριος 2012 14:41:59 nicolas vigier γράψατε: On Sat, 11 Feb 2012, Dimitrios Glentadakis wrote: What could be wrong ? Did you try to do a checkout on packages svn repository without mgarepo to see if that works ? svn co svn+ssh://svn.mageia.org/svn/packages/cauldron/null/current it works, it gave me this: [dglent@localhost mgarepo]$ svn co svn+ssh://svn.mageia.org/svn/packages/cauldron/null/current Password: Password: It shouldn't ask you for password if you uploaded your ssh key on https://identity.mageia.org/ in https://identity.mageia.org/ i choose sshPublicKey i add my key , i clic ok but there is no field added - (also i did it a second time and i did nt see that was the field Mobile, and i added in the mobile field. Now impossible to delete it. I have the message page not fount) - From ldap.log : Feb 11 15:03:50 valstar slapd[2240]: conn=1159066 op=3 MOD dn=uid=dglent,ou=People,dc=mageia,dc=org Feb 11 15:03:50 valstar slapd[2240]: conn=1159066 op=3 MOD attr=sshPublicKey Feb 11 15:03:50 valstar slapd[2240]: conn=1159066 op=3 RESULT tag=103 err=19 text=modify breaks constraint on sshPublicKey Are you sure that you used the complete It seems that the key that was uploaded was not in the good format. Can you make sure that you used the complete ssh key, ie the whole line, not just the binary encoded blurb in the middle. Without the beginning, ( ie ssh-rsa/ssh-dsa ), there is no way it would work, since openssh cannot guess the format and the algo to use. So try again by using the complete line : ssh-rsa XXXx f...@example.org And if this solve the problem, could mentors please ensure that newer packagers actually really understand how ssh is supposed to work before directing them to sysadmin for diagnosing the same problem over and over? ( alternative version : code proper error reporting in identity ) ( 2nd alternative version : add a foolproof mgarepo command to create and upload keys into our ldap ) -- Michael Scherer
Re: [Mageia-dev] Myspell/Hunspell Gascon dictionaries - licensing problem
Le dimanche 12 février 2012 à 08:59 +0100, Kamil Rytarowski a écrit : Hello! I've found that we use in myspell-gsc_FR (and now hunspell-gsc) files that are licensed under BY-NC-ND http://creativecommons.org/licenses/by-nc-nd/3.0/ Fedora qualifies it as a bad license http://fedoraproject.org/wiki/Licensing Yes, the NC would prevent someone from selling the cd without explicit permission from upstream. This include selling the cd for a symbolic price ( like 1 euro ) for a free software fair. ( see http://freedomdefined.org/Licenses/NC ) Therefore I would put it into nonfree. What to do with this package? Can we obsolete with a package from Nonfree section (hunspell-gsc in Mga2) a package from Core (myspell-gsc_FR in Mga1)? I guess, yes. If we really want to be clean, we should put obsoletes in mageia-release or somewhere like that. -- Michael Scherer
Re: [Mageia-dev] Error message while trying checkout a package?with mgarepo
Le dimanche 12 février 2012 à 11:30 +0100, Oliver Burger a écrit : Am 12.02.2012 11:16, schrieb Michael Scherer: Are you sure that you used the complete It seems that the key that was uploaded was not in the good format. Can you make sure that you used the complete ssh key, ie the whole line, not just the binary encoded blurb in the middle. Without the beginning, ( ie ssh-rsa/ssh-dsa ), there is no way it would work, since openssh cannot guess the format and the algo to use. So try again by using the complete line : ssh-rsa XXXx f...@example.org And if this solve the problem, could mentors please ensure that newer packagers actually really understand how ssh is supposed to work before directing them to sysadmin for diagnosing the same problem over and over? Guilty as charged, but actually Dimitrios was a bit faster then me and I didn't have that much time yesterday to try and work this out. ( alternative version : code proper error reporting in identity ) ( 2nd alternative version : add a foolproof mgarepo command to create and upload keys into our ldap ) If any of those two should be done, including it in identity would be the better way, I think. We have people aside from packagers with svn commit rights, e.g. the i18n team commiters. Indeed. But we can do both, and I think that adding a command to mgarepo would help to enforce a better security practice ( ie, few people know that using ssh-agent can cause issue if someone is root on the server that you connect too, since this person can reuse your key by hijacking the agent ). As an idea: instead of that input field or as an alternative provide a possibility to upload the pubkey file? This well make sure, no half keys are uploaded. In fact, we already make sure that no half key are uploaded ( hence the lack of key after upload ), we just do not signal it. And having a specific input would be slightly more complex ( but doable ), and less generic ( and I think Buchan wanted to avoid that, but maybe I am wrong ). -- Michael Scherer
Re: [Mageia-dev] Error message while trying checkout a package?with mgarepo
Le dimanche 12 février 2012 à 11:38 +0100, Dimitrios Glentadakis a écrit : Στις Κυριακή 12 Φεβρουάριος 2012 11:16:26 Michael Scherer γράψατε: Le samedi 11 février 2012 à 15:22 +0100, Dimitrios Glentadakis a écrit : Στις Σάββατο 11 Φεβρουάριος 2012 15:00:42 nicolas vigier γράψατε: On Sat, 11 Feb 2012, Dimitrios Glentadakis wrote: Στις Σάββατο 11 Φεβρουάριος 2012 14:41:59 nicolas vigier γράψατε: On Sat, 11 Feb 2012, Dimitrios Glentadakis wrote: What could be wrong ? Did you try to do a checkout on packages svn repository without mgarepo to see if that works ? svn co svn+ssh://svn.mageia.org/svn/packages/cauldron/null/current it works, it gave me this: [dglent@localhost mgarepo]$ svn co svn+ssh://svn.mageia.org/svn/packages/cauldron/null/current Password: Password: It shouldn't ask you for password if you uploaded your ssh key on https://identity.mageia.org/ in https://identity.mageia.org/ i choose sshPublicKey i add my key , i clic ok but there is no field added - (also i did it a second time and i did nt see that was the field Mobile, and i added in the mobile field. Now impossible to delete it. I have the message page not fount) - From ldap.log : Feb 11 15:03:50 valstar slapd[2240]: conn=1159066 op=3 MOD dn=uid=dglent,ou=People,dc=mageia,dc=org Feb 11 15:03:50 valstar slapd[2240]: conn=1159066 op=3 MOD attr=sshPublicKey Feb 11 15:03:50 valstar slapd[2240]: conn=1159066 op=3 RESULT tag=103 err=19 text=modify breaks constraint on sshPublicKey Are you sure that you used the complete It seems that the key that was uploaded was not in the good format. Can you make sure that you used the complete ssh key, ie the whole line, not just the binary encoded blurb in the middle. Without the beginning, ( ie ssh-rsa/ssh-dsa ), there is no way it would work, since openssh cannot guess the format and the algo to use. So try again by using the complete line : ssh-rsa XXXx f...@example.org And if this solve the problem, could mentors please ensure that newer packagers actually really understand how ssh is supposed to work before directing them to sysadmin for diagnosing the same problem over and over? ( alternative version : code proper error reporting in identity ) ( 2nd alternative version : add a foolproof mgarepo command to create and upload keys into our ldap ) i tried it again without success. What did you tried exactly ? ( cause I see that something looking like a ssh key ended in the mobile ldap field, but I also see the same constraint violation on sshKey that I save earlier, but i am rather sure to have tested the change and seen people able to upload keys before ) -- Michael Scherer
Re: [Mageia-dev] Error message while trying checkout a package?with mgarepo
Le dimanche 12 février 2012 à 12:55 +0100, Dimitrios Glentadakis a écrit : Στις Κυριακή 12 Φεβρουάριος 2012 12:47:00 Michael Scherer γράψατε: Le dimanche 12 février 2012 à 11:38 +0100, Dimitrios Glentadakis a écrit : i tried it again without success. What did you tried exactly ? ( cause I see that something looking like a ssh key ended in the mobile ldap field, but I also see the same constraint violation on sshKey that I save earlier, but i am rather sure to have tested the change and seen people able to upload keys before ) i added the complete line of the file ~/.ssh/id_dsa.pub it starts with : ssh-dss B3NzaC1kc3MAAACBALDU4.ygi2efzDPmBw== dglent@localhost Ok, so openssh use ssh-dss for dsa key, and ssh-rsa for rsa keys ( how intuitive ). The regexp I used to validate key was wrong, can you try again a few minute, just the time that I fix this ? Something that i did before too but as it did nt work i tried multiple times (also once i tried to added from AAAxx and this is what you saw in the logs probably ) and once i forgot to change the filed label and i added to the mobile filed. Actually i cannot delete this field (mobile) either, i have the error message page not found I will remove it from ldap. -- Michael Scherer
Re: [Mageia-dev] Automatically determining all GNOME packages
Le jeudi 09 février 2012 à 09:32 +0100, Olav Vitters a écrit : For GNOME QA purposes, I'd like to list all Mageia packages which come from *.gnome.org (download.gnome.org or ftp.gnome.org). In the spec file, the Source: usually has an URL. IMO the most reliable option is checking the Source: URL. I thought of matching http://git.gnome.org/repositories.txt or http://download.gnome.org/sources to the Mageia package name; but I already know that there are differences. I also looked into urpmq, but I don't see any way to determine the Source URL. So: anyone know of a good way to query the Source: URL from all the spec files? I would use sophie ( sophie.zarb.org ). Requirement: I don't want to overload the Mageia infrastructure! (e.g. I could checkout the entire http://svnweb.mageia.org/packages/cauldron/, but that is a bit madness) I doubt this will overload our infrastructure. -- Michael Scherer
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release libwacom-0.3-1.mga2
Le mercredi 08 février 2012 à 21:16 +0100, Olav Vitters a écrit : On Wed, Feb 08, 2012 at 04:42:05PM -0300, John Balcaen wrote: 2012/2/8 Olav Vitters o...@vitters.nl: On Wed, Feb 08, 2012 at 08:01:02PM +0100, Thierry Vignaud wrote: For next major release of libwacom, I've prevented this to happen again. Now, we've to fix building of gnome-control-center gnome-settings-daemon with new libwacom: There are new versions for those. I've submitted them. However, some work needs to be done for splitting systemd daemons and making gcc/gsd (forgot which) depend on those daemons. If i'm not wrong coling said that it was a no-go for this. Splitting up? Last email I saw, misc said he wanted it split up. This is not much what I want than what we agreed to be able to do for mageia 2, ie still be able to use sysvinit to boot, and if we can ( and I think we can ), be able to remove systemd rpm cause people will complain otherwise. I personnally would have switched to systemd since I prefer this, but I guess not everybody agreed with this plan. -- Michael Scherer
Re: [Mageia-dev] [RFE] Bundled copies of system libraries - call for participation
Le mardi 07 février 2012 à 14:42 +0100, Florian Hubold a écrit : I've just whipped up https://wiki.mageia.org/en/Packages_carrying_bundled_copies_of_system_libraries It's purpose is listing and maybe documenting the reasons why some packages carry bundled copies of system libraries. I've begun with ffmpeg, as it has a rather bad record for security updates on Mageia 1 IMHO, as some security updates would almost have been missed, some were delayed for a long time, and some wouldn't have been noticed unless by accident. Please, every packager participate, and list the packages you know about. Another good example would be xulrunner. PS: Maybe it should also be used to documented the packages which require some static linking, and the reasons, if there are any of these. While on it, would it be worth noting the attempt we had to solve the issue ( like punching dev in the face until they understand ) ? Also, I guess we can add links to similar pages, if any, on other distribution would help. I found https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries and i know there is a page for debian to help use find potential bundled libraries, but i cannot find it. -- Michael Scherer
Re: [Mageia-dev] Servers downtime scheduled from Feb. 1 to 2 for maintenance
Le lundi 30 janvier 2012 à 23:19 +0100, Romain d'Alverny a écrit : Hello everyone, some Mageia servers will be down from Wednesday Feb. 1st to Thursday Feb. 2nd for maintenance. Particularly, the following services will be unavailable: - our LDAP/user identity db, - build system, - Bugzilla, - all mailing-lists hosted on ml.mageia.org, - Wiki, - forums. - transifex - epoll - svn, git - youri web interface - maint db in short, almost all web applications ( ie, hosted on alamut ), and the build system. See http://svnweb.mageia.org/adm/puppet/manifests/nodes/ And to complete : - ldap will still work ( we do have a redundant setup, even if I have not finished making sure everything use the 2nd ldap in case of failure ), but readonly - mails will still be queued, so nothing should be lost We will announce on irc the exact moment when we plan to shutdown servers. -- Michael Scherer
Re: [Mageia-dev] stardict 3.0.3
Le lundi 30 janvier 2012 à 20:53 +0100, Claire Revillet a écrit : Le 30/01/2012 17:55, Kamil Rytarowski a écrit : Hello! W dniu 30.01.2012 14:33, Funda Wang pisze: Personally, i'm in favour of dropping it, due to what is said in its homepage: StarDict hasn't seen any active development for many years Well it's worth to consider importing goldentict too, but I'm against dropping stardict - it's actually alive and people keep porting it to GTK3. https://code.google.com/p/stardict-3/updates/list Hi What about asking his (her) opinion to the maintainer *before* upgrading it to the new version ? + kamilkamil - new versdion 3.0.3 - disable all patches, they seem merged - update URL - update SOURCE ** As the maintainer, it was to me to take the decision to upgrade or propose something else for mageia. So as the maintainer, can you explain to us why you did not warn us of the copyright problem that we can see since 07/2011 on http://stardict.sourceforge.net/ -- Michael Scherer
Re: [Mageia-dev] stardict 3.0.3
Le lundi 30 janvier 2012 à 22:56 +0100, Claire Revillet a écrit : Le 30/01/2012 22:50, Funda Wang a écrit : 2012/1/31 Claire Revilletgren...@zarb.org: For me StarDict is a dead project and I was looking for a successor. There is no information on the copyright infringement and the tarball that can be downloaded on the new site are exactly the same as the old ones ! So the first possibility is: there was truly a copyright problem and there is still (this may be proved in the future if the copyright owner ask to close again the project) ; second possibility: there was no copyright problem (but a more obscure one), but, still, the project is not very active. I think there is no copyright problem with the stardict the program itself, only the data files (dictionaries). But the author has been missing for half a year: http://goldendict.org/forum/viewtopic.php?f=4t=1109 It's also what I think : no really copyright pb with the code (and yes, I had seen link :\ ). Unfortunately, that's not really the opinion of the sourceforge lawyers. I assume that since you didn't warn us of a problem during the 6 months that you at least took the initiative as a maintainer to contact sourceforge.net, and that you received a answer letting you safely to dismiss their analysis. So can you share the answer, and/or the analysis ? Because I think that if we have a special treatement for patents and DMCA despites having legal protections ( safe harbor laws in the USAs, for example ) for mirrors, we should at least be as vigilant for copyright violation when there is no such provision and much stricter laws ( per various treaty ), as we all know given the current events. -- Michael Scherer
Re: [Mageia-dev] Fwd: GNOME 3.4 will rely on hostnamed, localed, timedated D-Bus API
Le vendredi 27 janvier 2012 à 10:07 +, Colin Guthrie a écrit : 'Twas brillig, and Olav Vitters at 27/01/12 00:00 did gyre and gimble: Daemons will work under sysvinit. Just need to be installed Cool, I'll keep it in mind. They shouldn't need anything special to be honest and I think systemd is required by basesystem anyway I fear some people may not like this, can we avoid adding a hard requires, and in this case, split the package ? ( or at least, if we cannot do otherwise, we need to document it, and how to disable systemd in the release notes, with clear instruction. People will complain, but we will answer this is documented ). -- Michael scherer
Re: [Mageia-dev] Fwd: gnome-boxes/distro integration
Le vendredi 27 janvier 2012 à 11:50 +0100, Olav Vitters a écrit : gnome-boxes maintainer asking that distributions add automatic installation support for their distro to the relevant components (gnome-boxes + other parts of the stack) first step is just to copy mandriva.xml and clean it ( did already for python-virtinstall but there is still no release ), should be rather simple ( likely done before the end of the day ). On the other hand, the vala part in boxes is more tricky to do. -- Michael Scherer
Re: [Mageia-dev] Fwd: GNOME 3.4 will rely on hostnamed, localed, timedated D-Bus API
Le vendredi 27 janvier 2012 à 16:14 +, Colin Guthrie a écrit : 'Twas brillig, and Michael Scherer at 27/01/12 15:52 did gyre and gimble: Le vendredi 27 janvier 2012 à 10:07 +, Colin Guthrie a écrit : 'Twas brillig, and Olav Vitters at 27/01/12 00:00 did gyre and gimble: Daemons will work under sysvinit. Just need to be installed Cool, I'll keep it in mind. They shouldn't need anything special to be honest and I think systemd is required by basesystem anyway I fear some people may not like this, can we avoid adding a hard requires, and in this case, split the package ? ( or at least, if we cannot do otherwise, we need to document it, and how to disable systemd in the release notes, with clear instruction. People will complain, but we will answer this is documented ). Systemd is just installed, it doesn't mean it's used. You need to install systemd-sysvinit for it to replace sysvinit. Yes, I know this is just installed and not used, but I am pretty sure that some people will complain. While I'm sure we could split the package up, I'm not really sure how much it gains in practice other than a few kb of disk space. Disk space is not the concern. Making sure I do not start to kill people who complain systemd cannot be removed, this is an outrage !! is the concern :) But if this cannot be done or too hard, no problem. -- Michael Scherer
Re: [Mageia-dev] Official VM images for Mageia 2?
Le jeudi 26 janvier 2012 à 12:16 +0200, Buchan Milne a écrit : On Wednesday, 25 January 2012 17:30:23 Romain d'Alverny wrote: Uses can be: evaluation, development/staging environments, you name it too. hurdman has some experience and is a first volunteer to work on this; others? (input, recipes, hands). I don't know if there is that much value in providing specific VM images, when instead we may want to look at providing good tools for sharing VM configs and tools for easily generating images from those configs. Some interesting tools which we don't seem to have yet: http://libguestfs.org/ http://libguestfs.org/virt-v2v/ You can add oz, boxgrinder. And there is the script based on virt-install that i sent a few months ago ( still no release of virt-install, so no mageia integration, maybe I should start to poke maintainer for a release ). It should be fairly easy to generate vm as well as iso. -- Michael Scherer
Re: [Mageia-dev] Build tip welcome
Le mardi 24 janvier 2012 à 21:35 +0100, Zézinho a écrit : I am trying to update IceWM to 1.3.7 as Fedora did. It does not build on Cauldron : http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20120124202332.zezinho.valstar.28538 Even the current version 1.3.3 does not build in Cauldron. I welcome any hint about this : In file included from /usr/include/glib-2.0/glib/gthread.h:34:0, from /usr/include/glib-2.0/glib/gasyncqueue.h:34, from /usr/include/glib-2.0/glib.h:34, from /usr/include/gdk-pixbuf-2.0/gdk-pixbuf/gdk-pixbuf.h:31, from /usr/include/gdk-pixbuf-2.0/gdk-pixbuf-xlib/gdk-pixbuf- xlib.h:24, from yimage.cc:17: /usr/include/glib-2.0/glib/gatomic.h:65:1: error: ‘deprecated’ was not declared in this scope /usr/include/glib-2.0/glib/gatomic.h:65:1: error: expected ‘)’ before ‘(’ token /usr/include/glib-2.0/glib/gatomic.h:65:1: error: expected ‘)’ before ‘(’ token /usr/include/glib-2.0/glib/gatomic.h:65:1: error: expected unqualified-id before string constant /usr/include/glib-2.0/glib/gatomic.h:65:1: error: expected ‘)’ before string constant You should take a look at yimage.cc, around line 17 in icewm source code. Likely a macro that was incorrectly used. -- Michael Scherer
Re: [Mageia-dev] ConsoleKit vs systemd session tracking for Mageia 2
Le lundi 23 janvier 2012 à 15:51 +0100, Olav Vitters a écrit : FYI, These seem to be compile time checks. Meaning: if --enable-systemd is added to ./configure, the functionality won't work on sysvinit. I am not sure exactly what will break under sysvinit. The bugreports to contain some discussion though. Could a systemd expert look into this and suggest what is best for Mageia 2? Since we decided to keep non systemd boot as fully supported for mageia 2 : https://www.mageia.org/pipermail/mageia-dev/2011-July/006532.html and to have both usable side by side : https://bugs.mageia.org/show_bug.cgi?id=2120 I guess it is best to keep the old system for the time being. So do not use --enable-systemd until mageia 3. -- Michael Scherer
Re: [Mageia-dev] qemu new upstream release (1.0-rc1) and should we move from qemu-kvm to qemu?
Le samedi 14 janvier 2012 à 21:10 +0100, Kamil Rytarowski a écrit : Hi! We have succeed to push the patch upstream http://git.qemu.org/?p=qemu.git;a=commitdiff;h=0e0e7facc775e9bb020314f48751b3d09f316c8b It took 2 months.. It will be shipped with the next version of Qemu so no need to take care of the patch for next releases. Can I now patch the old Qemu in Mga1 to ship UDP support and therefore be usable within GNS3? I will then fix GNS3 and its requirements too. That's a non bugfix update, so that doesn't fullfill the policy. I am not opposed on having the patch in cauldron however. -- Michael Scherer
Re: [Mageia-dev] FireFox ESR = we should totally go for this wrt stable releases
Le vendredi 13 janvier 2012 à 11:21 +, Claire Robinson a écrit : On 13/01/12 09:36, nicolas vigier wrote: On Fri, 13 Jan 2012, Sander Lepik wrote: 13.01.2012 03:20, Maarten Vanraes kirjutas: see https://blog.mozilla.com/blog/2012/01/10/delivering-a-mozilla-firefox- extended-support-release/ see https://wiki.mozilla.org/images/9/9d/Esr-release-overview.png ESR is a 1y extended supported release... looking at the image we'd be having supported versions for our 9month release schedule every time... we should totally use this release and not go towards FF11 for our release. We've been complaining about the too quick release schedule... this is our chance! ( i think if the FF maintainer wishes, he could also do backports of the regular releases... ) i'm hoping everyone agrees? including FF maintainer? I don't agree. But i'm not the maintainer. Why not? * Since fx10 all non-binary extensions are compatible by default (so our main problem goes away). * fx10 in 6 months is dead old for users POV. Many unhappy users. Lower popularity for Mageia. (Ubuntu AFAIK is going with fast schedule). * We will miss too many new and cool features. * When we release We could say the same about any other software. Firefox was an exception on updates policy because there was no other choice. But there's no reason to keep it as an exception when they provide a supported version. With 12 months support more often than not it would need updating in the lifespan of the Mageia 9 month release anyway. Firefox is one of those programs that people like to be bang up to date with. All softwares are one of those programs. The only one that some non technical users do not want to be updated are those that they do not know, like glibc, python, perl. But still, there is people that want it up to date, so firefox is nothing special. It is 'bragging rights' to ship with the latest and something reviewers always give version numbers of along with libreoffice, kde, gnome. Sure, and we neither update libreoffice, kde, gnome or the linux kernel. Some people do ( kde is upated by Fedora, as well as the linux kernel ). So that's a consistency issue, about what we promise to users. Stability is just that, stuff that do not have interface changes every 6 weeks, stuff that do not have slight mistranslation everytime string change, stuff that do not risk breaking software after every updates. I understand the arguments to go with the 12 months support but I think for the reasons above we should stick with the normal release cycle or maybe even offer both? Offering both would mean to double our workload of supporting firefox, and have no advantages by using the long supported release. And that's rather useless from my point of view, if the goal is to reduce the workload. There is already enough work to support the distribution. -- Michael Scherer
Re: [Mageia-dev] FireFox ESR = we should totally go for this wrt stable releases
Le vendredi 13 janvier 2012 à 05:13 -0800, Chris Evans a écrit : This really doesn't make sense. The browser is our interface to the internet. I (as a user) feel a need to have the latest version of my browser complete with all security patches. What do you think that a long supported firefox be, if not a firefox with proper security patches ? And frankly, if Firefox is so important to people because, doesn't t warrant to be extra careful with it, and to not change it every day ? that's important to me, so please risk breaking it every 6 week is just non sense. And yet, that's basically what people seems to assume. I really couldn't care less if I have the latest gnome or kde. Surfing the net using a browser with known security issues bothers me. Again, what do you think that Firefox ESR is ? let's distribute a tarball with know security holes ? I think this is why so many people consider firefox to be an exception to the rule. Where most software that is older is considered to be more stable, when talking about a browser it is generally the opposite. It would be nice to at least give the users a choice, There is already the choice. People can do the work themself, they can get the binary bundle from Mozilla, they can run cauldron. So please, stop using the choice argument when it doesn't correspond to reality. maybe have the LTR version as well as the latest release available. I have seen other distros provide chrome stable, testing, and unstable. Allowing the user to choose which version they are most comfortable with. That's also a pain to have it updated every X weeks. -- Michael Scherer
Re: [Mageia-dev] Over-zealous rpmlint policy (rejecting rt)
Le jeudi 12 janvier 2012 à 11:12 +0200, Buchan Milne a écrit : I am trying to get rt (3.8.11) into the distro (a package that I am using on a different distro in a production environment), to be followed up with the rt (4.0.4) I have queued (which I am testing in preparation for upgrading our production environment). I would really like to get this package into the distro, but it is being rejected (http://pkgsubmit.mageia.org/uploads/rejected//cauldron/core/release/20120110140334.buchan.valstar.18287.youri) due to: Submission errors, aborting: - rt-3.8.11-1.mga2.noarch: - dir-or-file-in-usr-local /usr/local/lib/rt/plugins - dir-or-file-in-usr-local /usr/local/lib/rt - dir-or-file-in-usr-local /usr/local/lib/rt/po - dir-or-file-in-usr-local /usr/local/lib/rt/lib - dir-or-file-in-usr-local /usr/local/etc/rt - dir-or-file-in-usr-local /usr/local/lib/rt/html The documented way for extending RT is by installing files in this location. We can either: 1)Make it more difficult for users to extend RT with local plugins etc. 2)Fix rpmlint 3)Not have RT misc, you have experience of both rt and rpmlint, can you provide an opinion? Would it be possible to separate 'dir-or-file-usr-local' into separate rules (one for files, one for dirs)? While I agree we shouldn't ship files in /usr/local, I don't see why we shouldn't ship dirs in /usr/local ... We shouldn't ship directories for the same reason that we shouldn't ship file, ie FHS. See : http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#USRLOCALLOCALHIERARCHY More specifically : It needs to be safe from being overwritten when the system software is updated. So the question is whether someone who change directory permissions will see them overwritten or not when the software is updated, and wether that a FHS violation. Afaik, rpm would reset the permission ( the same goes for removal of the directory ). See also : No other directories, except those listed below, may be in /usr/local after first installing a FHS-compliant system. Again, that's not clear if we can modify it later or not ( ie, is instaling rt on installation part of first installing or not ). I guess we should get a opinion from FHS/LSB people on this. In the mean time, I guess the point 1 is the easiest way, it can be changed later once we clarified FHS (or if we decide that we do not care about following standards, but that's really something I would like to avoid ). -- Michael Scherer
Re: [Mageia-dev] please stop doing bugs for updating magia 1
Le mercredi 11 janvier 2012 à 11:24 -0500, Juan Luis Baptiste a écrit : On Wed, Jan 11, 2012 at 3:43 AM, Florian Hubold doktor5...@arcor.de wrote: Well, 2) and 3) are not valid reasons here, because backports should get a similar amount of QA testing as normal update candidates, and for the updates policy require a bugreport for validation through QA. I think this is unrealistic in practice. For updates, QA will be testing one bug fix, with a backport you will have dozens or more new features to test, you can't expect for QA to test all of them to be able to give the OK, more if they even don't use the backported app in a daily basis. Testing of a backport has to be more relaxed and compromise to test some basic stuff like that it installs and starts correctly, maybe the package maintainer can give some hints on what else to test, but the rest we will have to trust in the maintainer's judgement. So trusting and having bugs are totally unrelated. And if you doubt that bugs appear, just see our bugzilla. We trust upstream ( most of them ), and yet there is bugs. If you think that all version backports should be tested in the same way as updates by QA, then all versions upgrades in cauldron should be tested by QA before pushing them to the BS right ? No, they should be tested before being put in the stable release. And that's exactly what we do by freezing and testing before release. why risk for a bug on a program when updating to a new mga version and not when doing a backport ?, it's exactly the same situation. That was already extensively discussed in the past, but if we do the same stuff than in Mandriva, we will end with the same result than in Mandriva. - people don't test backports, because that's not mandatory = some bugs slips. then users start to say do not use backport if you do not know what you do or if you are not expert, because I had $problem once. With time, such advice start to impermeate the community, and people start to simply not use backports. Worst, some people just do cherry picking of backports, and take one or two or them, and this result in wierd bugs with 2 effects : - we lose time - user think we are doing a bad quality distribution, because he has a mix that he is the only one in the world to have. Non technical users tell him he should not mix ( and they are right ), and so he start to feel bad because we gave him something that do not ork. Some users also end with system unsupported, so no security update, nor bugfixes. In the end, users complain that distribution is broken, and that impact our image. We cannot tell do not mix, because we cannot tell them to update backports without fear, as that would be lying. And in the end, saying this is not supported, but we offer to you is just sending a confusing message. If we start to give low quality stuff as Mageia, people will just think Mageia is low quality. -- Michael Scherer
Re: [Mageia-dev] please stop doing bugs for updating magia 1
Le mercredi 11 janvier 2012 à 17:48 +0100, Christian Lohmaier a écrit : On Wed, Jan 11, 2012 at 4:51 PM, Guillaume Rousse guillomovi...@gmail.com wrote: Le 11/01/2012 16:09, Antoine Pitrou a écrit : As a Mageia user I would expect Mageia to package significant *bugfix releases* and ship them in the updates for the stable distro. You'd rather read the current update policy, rather than expect blind assertions: https://wiki.mageia.org/en/Updates_policy Whoa - this is a rather stupid policy. (my opinion, yours obviously differs). For the most part, an update should consist of a boldpatched build of the same version/bold of the package released with the distribution, I am pretty sure that you can express yourself without starting by insulting people. That would surely help to be listened ( cause right now, I must tell that I am not very keen on that ) Welcome to distro-isolation, putting burden on maintainers, giving them all the reason to deny a reasonable request for a bugfix release because it just is too much work to hunt for a specific commit that fixed bug x. If that's too much work for a maintainer and if that's important for you, you can : - do your own package, supported by yourself for yourself or : - provide the patch If that's too much work for you too, then that's likely too much work for others too. For example, it would be nice if an up-to-date Mageia 1 system had Python 2.7.2 rather than Python 2.7.1 (not a deal-breaker, of course, but nice). There's more than a hundred bug fixes between the two versions and I don't expect Mageia to have independently fixed many of these bugs. A bug may vary from a typo in a man page to a critical security update, And a typo-fix is not worthwhile to have? When we take in account the fact it would still need proper QA, there is likely stuff that are more important than a typo. And a typo is just a extreme case, and a simplificaition. If we start to have a complex update policy, we are just losing time for almost nothing. which make the number of claimed bugfix a poor decision metric. A non-regression ensurance would be a better one, but it's quite difficult to assert. Don't assume all upstream projects are a bunch of clueless idiots. We didn't say that. We just assume that errors happen to everybody. For upstream releases that have a clear version/release scheme, with micro releases being compatible bugfixes only, the above mentioned policy is completely nonsense, same for your fear of regressions, etc. Regressions do happens. Sure, you cannot be save of regressions, but what makes you think you are smarter than upstream? What makes you so sure that not the one commit you add as a patch to your package is the one that causes the regressions? For 1, we usually do not do distro patch. I personnaly think this should be avoided as much as possible, and that we should push as much patch upstream. We have a rather huge backlog to clean. For 2, we also usually take patch from upstream. Some of us are also good enough to understand patchs, and to see what they mean, if they fix something, etc. Of course, there is some software that are rather specialized or obscure, but that's far from being the majority. Regressions have the nice habit of being triggered by changes in apparently unrelated code... And that's why we should reduce the number of changes. My 0.02€ only, but I strongly suggest for that update policy to be clarified. When there is no dedicated bugfix release procedure in the upstream package, an update is a rebuild of the same version with a corresponding patch. That's reasonable (as opposed to using a newer minor or even major release, those are backports). But once again: if upstream has a major.minor.micro scheme with micro versions being bugfix releases, I really don't see any sane reason for not allowing those updates. Maybe if you started to be less insulting, and instead started to look at the discussion on the ml in the past on the list, when the policy was discussed ( and access to the old wiki too ), you would likely find the reasons saner. -- Michael Scherer
Re: [Mageia-dev] please stop doing bugs for updating magia 1
Le mercredi 11 janvier 2012 à 16:09 +0100, Antoine Pitrou a écrit : On Tue, 10 Jan 2012 20:28:15 -0600 Luis Daniel Lucio Quiroz dlu...@okay.com.mx wrote: You dont get me, I mean, stop asking updates for mageia 1 just because there is another newversion. Uh. As a Mageia user I would expect Mageia to package significant *bugfix releases* and ship them in the updates for the stable distro. For example, it would be nice if an up-to-date Mageia 1 system had Python 2.7.2 rather than Python 2.7.1 (not a deal-breaker, of course, but nice). There's more than a hundred bug fixes between the two versions and I don't expect Mageia to have independently fixed many of these bugs. If you think shipping bugfixes isn't part of the QA for a stable version then I'm not sure what said QA should be (apart from updating Firefox to new major versions that is :-)). The policy ( as I remember when we discussed on this ml ) would allow to ship it, the specific case that I had in mind was postgresql, because it has a strict policy on backporting fixes, and regression testing, but python would fit too. However, my current workload and priority list do not place doing a python update on the top of the list. As you say, that's not a deal breaker, so I prefer to focus on what would be more important or urgent ( like for example, fixing servers and broken raid array ). -- Michael Scherer
Re: [Mageia-dev] [RFC] Moving various packages/codecs to tainted
Le lundi 09 janvier 2012 à 21:08 -0500, David Walser a écrit : Sure, I but I think Mandriva achieved a good balance between respecting patents and not being overly paranoid. I suppose you can't blame a US company like RedHat for being overly paranoid, but as you said, Mandriva hasn't had any problems. Are there any there examples out of there of distros trying to achieve this balance? Obviously we don't want to follow Ubuntu or ROSA in pretending patents don't exist. You forgot that Mandriva didn't have any lawyers to begin with. And Red Hat had problem with patents, like the 2 issues mentionned there http://arstechnica.com/open-source/news/2009/03/red-hat-faces-another-patent-infringement-lawsuit-over-jboss.ars If you dig in SEC filling, you would see such problems in the past too. Now, users should not fear patents, they would likely not be sued. And to tell the truth, neither would the association or mirrors, that's not the issue. This would be a issue however for some type of commercial users ie a OEM shipping Mageia. And if people really want to take users in mind ( and I said enough time that I personally don't ), people should then keep in mind that most potential users are not able to install a distribution and that the OEM road is the only one for them. And this OEM road requires us to be clear on patents to ease their work as much as possible, hence the split ( and the split is also valid for non-free, because some non-free package have restrictive licenses, like not for commercial use or stuff like that ). And if we want to have people working on the distribution, we need to make sure they are able to create a commercial offer around it without too much risk or problem. OEM is such a way, as would various others. While I would advocate a removal of tainted ( since I do not care of users, nor commercial developers ), there is reasons to keep it to ease the work of others. Also, keep in mind that some people would not be aware of the patents issues if there was no split in the first place, or would not know how widespread it is. And I think we all agree that we should avoid a second SCO-like case, this time based on patents, and one of the various step to prevent that would be to make sure people are aware. -- Michael Scherer
Re: [Mageia-dev] references to outside web sites/wiki
Le vendredi 06 janvier 2012 à 20:31 +1300, Glen Ogilvie a écrit : On Wednesday, 4 January 2012 23:56:01 Romain d'Alverny wrote: On Wed, Jan 4, 2012 at 22:36, Johnny A. Solbu coo...@solbu.net wrote: On Wednesday 04 January 2012 21:06, Romain d'Alverny wrote: wiki.mandriva.com may be shut down for good in just a few days What? Are Mandriva serisouly considering closing down the Wiki? Mandriva is on the path to filing for bankruptcy on January 16th. Does anyone have a complete mirror / copy of the Mandriva svn repository, or a complete set of SRPMs from cooker? I would be concerned this becomes unavailable, as it's a valuable resource for packages not yet imported into Mageia and contains a history of the package that Mageia does not have. D-C should still hold the srpm. For the svn you would have to start now syncing, IMHO. ( even if I doubt mdv will die ) -- Michael Scherer
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release dsniff-2.4-0.b1.1.mga2
Le mercredi 04 janvier 2012 à 11:03 +0200, Thomas Backlund a écrit : Anssi Hannula skrev 3.1.2012 23:05: On 02.01.2012 12:21, guillomovitch wrote: Name: dsniff Relocations: (not relocatable) Version : 2.4 Vendor: Mageia.Org Release : 0.b1.1.mga2 Build Date: Mon Jan 2 11:18:17 2012 Install Date: (not installed) Build Host: ecosse Group : MonitoringSource RPM: (none) Size: 210074 License: BSD Signature : (none) Packager: guillomovitchguillomovitch URL : http://www.monkey.org/~dugsong/dsniff/ Summary : Network audit tools Description : Tools to audit network and to demonstrate the insecurity of cleartext network protocols. Please do not abuse this software. guillomovitchguillomovitch 2.4-0.b1.1.mga2: + Revision: 189630 - drop epoch, we don't care about updating from mdv anymore We don't? Oh yes we do. Atleast from 2010.1 We did for 1, not for 2 or cauldron or anything else. So as long the package is not pushed on 1, I think we agreed that people could not care about upgrade path from Mandriva. -- Michael Scherer
[Mageia-dev] (likely Quick) meeting tonight
Hi, quick summary for tonight : - announce for alpha 3 ( ennael will not be here, and I may be late but do not plan to, but you never know with Paris public transportation ) -- Michael Scherer
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release dsniff-2.4-0.b1.1.mga2
Le mercredi 04 janvier 2012 à 16:16 +0200, Anssi Hannula a écrit : On 04.01.2012 11:54, Michael Scherer wrote: Le mercredi 04 janvier 2012 à 11:03 +0200, Thomas Backlund a écrit : Anssi Hannula skrev 3.1.2012 23:05: On 02.01.2012 12:21, guillomovitch wrote: Name: dsniff Relocations: (not relocatable) Version : 2.4 Vendor: Mageia.Org Release : 0.b1.1.mga2 Build Date: Mon Jan 2 11:18:17 2012 Install Date: (not installed) Build Host: ecosse Group : MonitoringSource RPM: (none) Size: 210074 License: BSD Signature : (none) Packager: guillomovitchguillomovitch URL : http://www.monkey.org/~dugsong/dsniff/ Summary : Network audit tools Description : Tools to audit network and to demonstrate the insecurity of cleartext network protocols. Please do not abuse this software. guillomovitchguillomovitch 2.4-0.b1.1.mga2: + Revision: 189630 - drop epoch, we don't care about updating from mdv anymore We don't? Oh yes we do. Atleast from 2010.1 We did for 1, not for 2 or cauldron or anything else. So as long the package is not pushed on 1, I think we agreed that people could not care about upgrade path from Mandriva. Well, I don't like that, IMO we should not remove upgradeability so soon, even if we won't officially support it. Well, if we do not officially support it, then we do not support it, that's all. There is no that's unofficially supported or stuff like that. Supported mean we will do test and fix bug if they happen, and not supported mean we reserve our right to not do anything. And that's exactly what happen right now. But anyway, this affects people doing 2010.1-mga1-mga2 as well... Or are you saying that isn't supported either, and people should do new installs?? We do not support upgrading mdv2010.1 rpms with rpm from mga2, so if a maintainer want to remove this, he can. Someone doing mdv2010.1-mga1 will end with a mix of mdv2010.1 and mga1 if the system is not cleaned, and that's not something we should support, not more than mga X + any random repository upgrade to mga X+1 IE, that's not mga1 - mga2, that's mga1 + 3rd party repo that happened to work by chance to mga2. -- Michael Scherer
Re: [Mageia-dev] Proposal: Cinnamon for Mageia
Le mercredi 04 janvier 2012 à 20:21 +0100, bernd a écrit : As you know, Cinnamon is a fork of Gnome-Shell with the look feel workflow of Gnome2, developed and maintained by Clement Lefebvre Clem from Linux-Mint. At the moment, already rpms and debs for other distributions like Ubuntu, Fedora, Arch and OpenSuse are built: http://cinnamon.linuxmint.com/?page_id=61 In my opinion, Cinnamon will be a sustainable alternative for ex-Gnome2-users, who don't like the smartphone-look of Gnome3 It will be sustainable when it will have been sustained a bit, don't you think ? ( because mint already announced first to add js extension to gnome shell, then to fork gnome 2, then to develop a new DE , so maybe they will do another thing next week ). ( and personally, I do have both a smartphone and gnome 3, and I wonder if people who say there is a smartphone look to gnome 3 have a smartphone, cause mine do not really look like gnome 3 ) I do not have much trust in linuxmint code ( there is several unfixed serious flaw in their python tools, like https://github.com/linuxmint/mintupdate/blob/master/usr/lib/linuxmint/mintUpdate/mintUpdate.py#L1444 or https://github.com/linuxmint/mintnanny/blob/master/usr/lib/linuxmint/mintNanny/mintNanny.py#L71 ), but if someone do proper packages ( and if they do not open hole like these one ), why not. -- Michael Scherer
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release dsniff-2.4-0.b1.1.mga2
Le mercredi 04 janvier 2012 à 20:09 +0200, Anssi Hannula a écrit : On 04.01.2012 19:29, Michael Scherer wrote: Le mercredi 04 janvier 2012 à 16:16 +0200, Anssi Hannula a écrit : On 04.01.2012 11:54, Michael Scherer wrote: Le mercredi 04 janvier 2012 à 11:03 +0200, Thomas Backlund a écrit : Anssi Hannula skrev 3.1.2012 23:05: On 02.01.2012 12:21, guillomovitch wrote: Name: dsniff Relocations: (not relocatable) Version : 2.4 Vendor: Mageia.Org Release : 0.b1.1.mga2 Build Date: Mon Jan 2 11:18:17 2012 Install Date: (not installed) Build Host: ecosse Group : MonitoringSource RPM: (none) Size: 210074 License: BSD Signature : (none) Packager: guillomovitchguillomovitch URL : http://www.monkey.org/~dugsong/dsniff/ Summary : Network audit tools Description : Tools to audit network and to demonstrate the insecurity of cleartext network protocols. Please do not abuse this software. guillomovitchguillomovitch 2.4-0.b1.1.mga2: + Revision: 189630 - drop epoch, we don't care about updating from mdv anymore We don't? Oh yes we do. Atleast from 2010.1 We did for 1, not for 2 or cauldron or anything else. So as long the package is not pushed on 1, I think we agreed that people could not care about upgrade path from Mandriva. Well, I don't like that, IMO we should not remove upgradeability so soon, even if we won't officially support it. Well, if we do not officially support it, then we do not support it, that's all. There is no that's unofficially supported or stuff like that. Supported mean we will do test and fix bug if they happen, and not supported mean we reserve our right to not do anything. And that's exactly what happen right now. IMO there is a level between officially supported and we intentionally break it, which means that we advise against it but do not hinder people from doing it. Yes, there is different levels of support, obviously, since people have different but that doesn't mean we should rely on them, or try to officially use them. Again, saying we support that, so we do that, and we don't support this, so people are free to do what they want is simpler. The whole scheme of having stuff we do, stuff we do not promise but try to, stuff we do not promise and we do not try to ( or more ) make things less clear for everybody. Having a non uniform policy will make things harder for newer packagers ( and for olders too ). We have users ( in the past ) that complained about the lack of reliability of packages on Mandriva. And this was IMHO because we had a policy of 'we keep everything and we say they are in a section of maybe supported'. The whole message contribs is not supported but main is was simple and yet, too complex to grasp ( because people didn't check contrib/main before installing anything, ). It was also far from the truth because some stuff in contribs were more supported than stuff in main, and thus we were sending mixed messages. So we should really stick on what we support, and send a simple, clear and correct message. And I think we need to keep things simple to solve such issues in the long run. But anyway, this affects people doing 2010.1-mga1-mga2 as well... Or are you saying that isn't supported either, and people should do new installs?? We do not support upgrading mdv2010.1 rpms with rpm from mga2, so if a maintainer want to remove this, he can. Someone doing mdv2010.1-mga1 will end with a mix of mdv2010.1 and mga1 if the system is not cleaned, and that's not something we should support, not more than mga X + any random repository upgrade to mga X+1 IE, that's not mga1 - mga2, that's mga1 + 3rd party repo that happened to work by chance to mga2. I have to strongly disagree with this. If upgrading from 2010.1 to mga1 is officially supported (and it is), we can't say you can't upgrade your mga1 system to mga2 anymore because you have some old pkgs installed which we never asked you to remove (assuming no non-mdv 3rd party repos here). First, it doesn't break the whole upgrade. In fact, if we look carefully, people who were running non supported software ( ie a package from Mandriva ) will still run the same unsupported software and the same binary. And upgrade will likely work without error messages. Because nothing requires dsniff, except its own subpackage. Secondly, it didn't matter much before Guillaume uploaded dsniff. 1 week ago, anyone who would have upgraded to mga2 with dsniff installed from mdv would have been in the exact same situation than now, except nobody cared at all. And the proof that nobody cared is that nobody pushed the rpm sooner. Would it have been pushed to 1, yes, that would have breached what we agreed to do. But it was not pushed to 1
Re: [Mageia-dev] [packages-commits] [188982] fixed desktop file patch
Le dimanche 01 janvier 2012 à 18:14 +0100, Angelo Naselli a écrit : Install rpmlint-mageia-policy. It should probably be suggested by rpmlint, we want Mageia policy applied by default. Michael, any objection? I guess it should be removed upstream, since no one use this check anymore ( ie, fedora policy is against, mandriva policy is against, our is against ). I will check with suse, but I think they also don't compress patchs. So it make sense to silence it directly there, instead of filtering everywhere. I think you're right about patch compression, but i think you should also answer to the subject concerning rpmlint-mageia-policy installation (required, sugested etc...) I answered several time by the past, but I guess I can repeat myself once again : - no suggest , they are unspecified, and causing problem ( like not working for people that disable them, and bloating installation for everybody else , and just giving no useful information for people to decide to install or not ) - no requires from rpmlint on policy, since people have been asking to be able to use different policy ( and since rpmlint is already required by policy, that would make a loop and I would like to avoid that ). -- Michael Scherer
Re: [Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help
Le lundi 02 janvier 2012 à 19:41 +0100, Marja van Waes a écrit : Hi everyone, Can someone please help to fix bug 1956? You don't need to be a regular forum visitor. We need someone to find and implement a probably existing MOD, needed to keep forum posts history when unlimited edit time is enabled From wobo's comment #32: Capabilities needed: Well, one could say that anybody who - knows how to run phpBB as admin and - has seen a line of php - knows how to edit code (respecting tags and such) - knows how to cutpaste should be able to install an existing MOD (if I'm not mistaken there is one or more). I know next to nothing about php coding. But I've been running a phpBB forum for a couple of years and successfully implemented some MODs in phpBB2 and phpBB3. With no help (except the phpBB-forum in case of problems). In practice you have a detailed installation README for each MOD. Like - open file /foo/bar/doo.php - Find the line which starts with '..' - After that add - . And more such step-by-step guidance My eyes start to bleed dues to such guidances. -- Michael Scherer
Re: [Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help
Le lundi 02 janvier 2012 à 22:17 +0100, Maarten Vanraes a écrit : Op maandag 02 januari 2012 21:40:31 schreef Michael Scherer: Le lundi 02 janvier 2012 à 19:41 +0100, Marja van Waes a écrit : Hi everyone, Can someone please help to fix bug 1956? You don't need to be a regular forum visitor. We need someone to find and implement a probably existing MOD, needed to keep forum posts history when unlimited edit time is enabled From wobo's comment #32: Capabilities needed: Well, one could say that anybody who - knows how to run phpBB as admin and - has seen a line of php - knows how to edit code (respecting tags and such) - knows how to cutpaste should be able to install an existing MOD (if I'm not mistaken there is one or more). I know next to nothing about php coding. But I've been running a phpBB forum for a couple of years and successfully implemented some MODs in phpBB2 and phpBB3. With no help (except the phpBB-forum in case of problems). In practice you have a detailed installation README for each MOD. Like - open file /foo/bar/doo.php - Find the line which starts with '..' - After that add - . And more such step-by-step guidance My eyes start to bleed dues to such guidances. i'm sure misc means to say that we should have all our changes in packages/puppet config so that we can update without issues. and with file edits, that's a whole different thing. I was more thinking of proper patchs or better, proper modules, with files to deploy in a well know directory . Something that do not remind me of Alien 4 movie. -- Michael Scherer
Re: [Mageia-dev] [packages-commits] [188982] fixed desktop file patch
Le samedi 31 décembre 2011 à 14:21 +0100, Olivier Blin a écrit : Jani Välimaa jani.vali...@gmail.com writes: 2011/12/31 Matteo pasotti.mat...@gmail.com: please unzip patches Ok, I was following the warnings coming from rpmlint. Install rpmlint-mageia-policy. It should probably be suggested by rpmlint, we want Mageia policy applied by default. Michael, any objection? I guess it should be removed upstream, since no one use this check anymore ( ie, fedora policy is against, mandriva policy is against, our is against ). I will check with suse, but I think they also don't compress patchs. So it make sense to silence it directly there, instead of filtering everywhere. -- Michael Scherer
Re: [Mageia-dev] How broken are RPM dependencies allowed to be?
Le mercredi 14 décembre 2011 à 01:20 -0800, Dan Fandrich a écrit : On Tue, Dec 13, 2011 at 09:04:39PM -0500, Liam R E Quin wrote: It's really hard to test for dependencies like this, as the person building the package will have working versions of everything. It would be tricky, but entirely possible to be tested automatically. Then show us. The infrastructure is handled with puppet, you can send patchs, or just send the script to run to test everything and produce report, we can take care of integrating it. -- Michael Scherer
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release perl-Libconf-0.42.10-3.mga2
Le dimanche 11 décembre 2011 à 14:51 +0100, Olivier Blin a écrit : Thierry Vignaud thierry.vign...@gmail.com writes: On 11 December 2011 03:58, Mageia Team buildsystem-dae...@mageia.org wrote: URL : http://www.libconf.net/ Summary : Configuration file abstraction layer Description : Libconf is a wrapper to the main configuration files of the system. It's mainly a generic parser plus many templates. URL seems wrong Looks like dams did not renew the domain :) The project is dead since several years. If people want something similar there is augeas and perl-Augeas-Config. ( http://search.cpan.org/dist/Config-Augeas/lib/Config/Augeas.pm ) -- Michael Scherer
Re: [Mageia-dev] Package adoption campaign, 3 months later
Le samedi 10 décembre 2011 à 12:14 +0100, Samuel Verschelde a écrit : You're explaining why having orphan packages is bad and it's hard to disagree, but I fail to see why such a mailing list for people who are ready to devote some time to orphan packages would make things worse. It's not because it's not the ideal solution that it's bad, is it? Because such a mailling list would just incite people to add package and never remove them, because that's not really unmaintained, that's collectively maintained. Which is just a non sense. That's how it was in Mandriva, so the proposition is just not helping. Each time a cleaning was attempted, someone said but come on, we are taking care of it collectively, so you cannot remove, it could still help. And so almost nothing was removed. I see no reason to think it will be different. Same situation, same spirit, same users, same outcome. Either people agree that we should have no orphans, and then the list is useless, or they think we should keep orphans, and then this is causing issues. Middle ground ( like let's keep orphan for X months ) are just a variation of the first one, and so we would just be discussing the duration. So let's try to make a proposal, if there is a list, after how many months should a package be removed from the repository if not maintained ( and by maintained, I do not say not changes or anything, I really mean no one listed as maintainer ) ? -- Michael Scherer
Re: [Mageia-dev] Package adoption campaign, 3 months later
Le jeudi 08 décembre 2011 à 18:51 +0800, Funda Wang a écrit : 2011/12/8 Samuel Verschelde sto...@laposte.net: His/her work would be the following: - identifiy (with bugsquad's help) the orphan packages that have lots of unresolved bugs or are severely outdated, - do the same for packages that have a maintainer but are in a similar situation, - try to find packagers or apprentices to take care of them. Not necessarily make them become maintainer, but at least solve users bugs. - try to find maintainers for orphan packages. I would suggest that registering nobody as a mailing list, so that every interested packagers could join to help. No. For the reasons already highlighted several time, this would not work. That's the situation at mandriva, and we know well the problem it cause ( aka, obscure communication, no one really in charge of a rpm, so not one feeling responsible for bugs or anything ). Either a package is maintained and should be marked as such, or it is not, and should be marked as such, with a unfortunate fate for him sooner or later. The goal is not to align lots of unmaintained packages, but to have a maintained distribution. People have been complaining for quality since a lot of time, and that's the only way to have it. If not, this end like Mandriva, people see and fill bugs, they are not fixed, and no one care. This greatly undermine the confidence in the distribution in the long run, and so while having maintainer is not a magic solution, this is a important step in the right direction. A free-for-all pool is just a mess. -- Michael Scherer
Re: [Mageia-dev] RFC: Opening Backports (once again...)
Le mardi 06 décembre 2011 à 01:29 +0200, Anssi Hannula a écrit : The biggest problem for me is that it is really difficult to test any changes, one'd need a mockup of the whole buildsystem... and I don't want to propose any patches blind :) 2 vm + setup of puppet should be able to fully replicate the configuration. Despites being seen as a hot skill ( http://siliconangle.com/blog/2011/10/31/puppet-and-hadoop-among-the-hottest-it-skills/ ), I am rather surprised that no one take the opportunity to learn it and to help. -- Michael Scherer
Re: [Mageia-dev] RFC: Opening Backports (once again...)
Le mardi 06 décembre 2011 à 00:56 +0200, Thomas Backlund a écrit :
Now,
here comes the question about backports once again.
We are now 6+ months into Mageia 1, and we are nowhere closer to opening
backports that we were at Mageia 1 release time.
Because of that there are 3rdparty repos popping up everywhere...,
something we hoped to avoid atleast partly when starting this project.
Well, the backport issue ( ie :
- no garantee of keep the distribution upgradable
- no security )
have also not been fixed, so that's rather unfair to
And at current rate we will probably release Mageia infinity
before backports is opened.
It has been delayed because of needed infrastructure changes,
something no-one have had time to do so far...
I know there is only some coding missing and someone should
do it, buth truthfully there are only a few that knows the
code used in the buildsystem enough to actually make it happend,
and they are already othervise busy or overloaded...
(this is no rant against them, as all here are using their
personal free time to help out)
And to be honest I dont see that changing anytime soon...
Then we have a bigger problem to solve.
So here is a suggestion to get some value to our endusers:
we add a backports branch on svn
So packages for backports would use:
svn.mageia.org/packages/backports/1/package/{current,pristine,releases}
and allow that to be used for backports.
Using a separate branch is also a cleaner way of providing
backports, and makes it easy to separate changes needed only
for Cauldron (or backports).
Then in practice, that mean having a 2nd/3rd distribution ( because
there is a separate 2nd svn branch, and a 3rd one for later ) and so
that's a big no for me. Having 2+ branchs is just asking for trouble
when they are not in sync ( and since keeping everything in sync
properly with svn is a pain if there is a divergence, this will not be
done ).
Worst, if we do like in mdv and propose 2 way of backporting ( submit
from cauldron, submit from a branch ), this will create a mess of having
some packages from cauldron, some from the branch, and people having no
way from knowing where does a package come from. This also make the
system harder to maintain and to follow, and rather impossible to script
properly.
So that's also to be avoided.
Having a separate branch where people can write also remove the only
incentive I have seen for backports, ie, wider testing of our packages,
because they may not really the same as in cauldron.
So here is what I propose :
- have X branchs, but do not let anyone commit on it, besides a system
user. When a package is submitted to cauldron, it is also copied to this
branch, ie, we make sure current is in sync. The same goes for version
N-1 being copied from N once a backported rpm have been submitted to be
used by people. Once a distribution is no longer supported, we close the
branch, and disable the sync.
- backports are only submitted from the branch, with separate
markrelease, tags, whatever. This let us have proper audit of backports,
and who did what.
- packagers still need to commit and submit on cauldron before any
backports. So we miss no fixes or anything by mistake. We also make sure
that cauldron is always the highest version possible, thus permitting at
least some form of upgrade. ( either stable to stable, provided
backports are used, or stable to cauldron ). And we also ensure that
backports are done first on the most recent stable version, for the same
reason ( ensure some form of upgrade path, as asked several time by
users ).
And we can still use %ifdef if a need arise for a different spec between
distribution versions. While that make spec less readable, that's more
readable than having forked specs 2 or 3 times.
This requires :
- 1 youri action to copy the package to current backport branch ( can be
done based on the markrelease action and the others )
- 1 svn configuration to prevent people from writing directly there ( or
just say to not do it, and burn people who do it )
- youri config to let people submit from backports to backports_testing.
--
Michael Scherer
[Mageia-dev] No meeting tonight
Hi, sorry for the short notice, but I have some personal urgency tonight, and Anne is not avaliable, so no meeting this evening. -- Michael Scherer
Re: [Mageia-dev] Teamviewer and X86_64 build . . .
Le lundi 28 novembre 2011 à 12:31 +0100, Oliver Burger a écrit : Each and every one of those proprietary tools has to be looked at on its own. E.g. some years ago there was quite a discussion about TrueCrypt and its license which led to the exclusion of truecrypt from almost all major distros. If that license issue isn't solved, I wouldn't change a jota of that decision. Guess that could help : https://bugzilla.redhat.com/show_bug.cgi?id=743497 -- Michael Scherer
Re: [Mageia-dev] Teamviewer and X86_64 build . . .
this way. People can just compare Ubuntu reputation to Debian one, and see which one was able to survive without spending million of dollars each year. And also which one serve as a base for the other. -- Michael Scherer
Re: [Mageia-dev] Teamviewer and X86_64 build . . .
Le lundi 28 novembre 2011 à 15:10 +0100, Florian Hubold a écrit : Am 28.11.2011 14:55, schrieb Guillaume Rousse: Le 28/11/2011 11:45, Robert Fox a écrit : There a few key proprietary softwares which make the Linux work a bit easier to integrate and play nice with the others . . . Like Skype, Picasa Teamviewer (to name a few). Other distros get this (like Linux Mint!): http://www.liberiangeek.net/2010/04/how-to-install-teamviewer-on-linux-mint-and-connect-to-windows/ Why not switch to linux mint then, if you feel it better suited for your need ? I'm more and more concerned about this whole attitude: you guys should make my own life easier, because other already do it. That's just plain consumerism. Uhmm, converse argument would that you want to make your life (and also that of other distribution users) harder because you don't want to be that consumer-like? Doesn't sound that reasonable to me, and please remember, it's not always plain black vs. white decisions. I can live without a get-teamviewer package, but just because of the facts that i'm able to install/troubleshoot it without help, because i know the tools to do this (rpm/urpmi) and doing that for a long time. In the end the question should be: Do we want to make the distribution just for ourselves, just for the sake of having our own linux distro, or do we want also some other people to use it, who aren't IT specialists, programmers or rocket scientists? That's a false dichotomy. Have you seen the price of teamviewer ? If you didn't, just check : http://www.teamviewer.com/en/licensing/index.aspx So if a company can give this amount of money to use teamviewer, I think they can also spend a little to have a sysadmin able to install it. For the others people ( ie those covered by private use ), that's a tool for advanced users. Since teamviewer is likely used for remote assistance, at least one of the participant is knowledgeable in IT. And so the so-called advanced users should surely be able to download a tarball and run the only executable in the tarball to start it. That's not harder than doing the same on windows, and people are perfectly able to do it. -- Michael Scherer
Re: [Mageia-dev] Proposition to drop the package pastebin from Mageia
Le jeudi 24 novembre 2011 à 10:49 +0100, Sandro CAZZANIGA a écrit : Now we need pastebin.mageia.org :) Well, if you are ready to maintain it, just submit a patch to the puppet configuration. -- Michael Scherer
Re: [Mageia-dev] Changing default media names
Le lundi 21 novembre 2011 à 10:32 +0100, nicolas vigier a écrit : On Mon, 21 Nov 2011, Samuel Verschelde wrote: Le lundi 21 novembre 2011 09:57:20, Guillaume Rousse a écrit : Le 21/11/2011 01:51, Maarten Vanraes a écrit : in short: let rpmdrake show this short description (which looks more or less like the current name, but clearer) where the current name is now and i'm ok with this proposal. Better formulation: let's use different strings for different purposes, instead of a single generic media 'name' with unclear semantic: - an identifier for computer, without any metacharacter, to be used in command line - a description for humans, to be displayed in GUIs, without any kind of character restriction That's it :) Ok, so everybody agree with changing the names with the proposal I made, and adding an optional description line in media.cfg on the mirrors and /etc/urpmi/urpmi.cfg for each media, to be displayed by rpmdrake in a description column in drakrpm-edit-media near the name ? Yeah, let's stop abusing identifier as a user friendly description. -- Michael Scherer
Re: [Mageia-dev] qemu new upstream release (1.0-rc1) and should we move from qemu-kvm to qemu?
Le dimanche 13 novembre 2011 à 22:32 +0100, Kamil Rytarowski a écrit : On 13.11.2011 10:58, Michael Scherer wrote: Le samedi 12 novembre 2011 à 21:11 +0100, Kamil Rytarowski a écrit : On 12.11.2011 20:20, Michael Scherer wrote: Le samedi 12 novembre 2011 à 16:44 +0100, Kamil Rytarowski a écrit : There is also one important patch missed in Mageia - http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg00787.html it's dependency for the GNS3 simulator. OpenSUSE already includes it https://build.opensuse.org/package/files?package=qemuproject=openSUSE%3ATools If nobody is against I will do it and contact the maintainer (misc). I prefer to wait on the stable release ( ie, no rc1 ). We will wait on stable version of qemu. OK And no patch unless it comes from upstream ( and even, I am not keen on backporting feature, better wait for stable release ). GNS3 is already in stable! This package is broken - no dynamips (=no router emulation at all...), no patched qemu (no virtualization support at all...) According to the developers and their online documentation for package maintainers http://forum.gns3.net/post11571.html UDP patched Qemu is dependency/very important. The fact that someone pushed a broken package is not a good reason to add patches to qemu. OK, but I don't understand this. Why to keep defunct packages (this could be at least major+ issue on our bugzilla) in stable and don't even want to fix, ignore this academic software (with maybe overall 1 000 000* downloads and 100 000 regular users), and to support... the inadvisable opinion of Mageia around.. at least the GNS3 users. Let me rephrase again. Everybody sooner or later think that soft is great, but why do not add just a small patch there. That's just one patch, where is the problem ? The problem appear just after a few months, when the patch is still not upstream, and that someone who do not know C, python whatever has to take the software and maintain it. Or when someone who know how to program lose time rediffing the patch instead of doing something more useful. We face bugs that cannot be reproduced upstream, security problem that could be added in non reviewed patch by devs. Fragmentation in linux distributions are also caused by differents features, due to patchs. All of this need to be avoided, and I think we have enough problems with stuff that people do not want to take care of it to not add more burden, be it under the form of a small patch. All big collections start by one little stuff. * 799 968 Windows Downloads (just from the sourceforge mirrors) of the latest Windows binary of GNS3 (source http://sourceforge.net/projects/gns-3/files/GNS3/0.7.4/) We have too many patches on a general scale, and I do not want to end with a 2nd package like gdb. Patches make harder to upgrade, harder to make sure security is done correctly, and harder to ensure stuff are working ( since we are on our own when we patch something ). So for the patches, make sure it is upstream It's not qemu upstream, it's GNS3 and its community upstream. If you want to have a feature in qemu, the road is push it upstream. Once accepted upstream, it will sooner or later be in our packages. ( and given the discussion on ml, it should be soon ) When I ask the developers, they don't know if qemu will include the patch at all and when (now or after one year) and they suggested to do the openSUSE way (today the most recommended and full featured Linux distro for GNS3). Maybe we are not talking of the same patch, but I am talking of this one : http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg00629.html AFAIK, the patch have been accepted, just not committed yet. The last mail were from 1 week ago. The only issue is that they are in freeze for now, and the git web interface is down, and I do see the commit in my checkout about it so far. and then in a tarball ( again, given that's a rc 1, that should be ok soon ). We must fix the package and provide at least not so heavy broken ones... I've prepared new version of GNS3, included into svn dynamips and xdotool (this one suggested) - these I can maintain with my mentor, so I ask for patch qemu in stable versus UDP support. Updates are not supposed to get new features, Well this is a special case - the bugfix provides the feature, or the feature provides the bugfix. People will always tell it is a special case. We can always say that any feature is a bugfix, provided we say that the bug is I cannot do that. -- Michael Scherer
Re: [Mageia-dev] (second attempt) suggesting sectool be dropped
Le lundi 14 novembre 2011 à 22:09 -0800, Robert M. Riches Jr. a écrit : (New list subscriber...needed to fix registered email address to post...) I was asked to submit this suggestion to the mailing list: As a Mageia user, I believe msec was much better off with_OUT_ sectool. In its present state, sectool is BADLY broken. It whines for pages about file permissions that are exactly as they should be. Can you be more specific ? It leaves two orphaned gpg-agent processes. Fill bug report about this, that can surely be corrected by upstream. It leaves at least three files or directories cluttering up /tmp. Same for that. -- Michael Scherer
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release kdenlive-0.8.2-1.mga2
Le lundi 14 novembre 2011 à 19:29 -0300, Balcaen John a écrit : Le lundi 14 novembre 2011 23:17:32 zezinho a écrit : Le lundi 14 novembre 2011 20:23:40, Juan Luis Baptiste a écrit : So what is the final decision about this ? is there going to be an update or not ? I vote no, let's wait for backports, like all other new versions. i not agree at all because - we did it for KDE SC 4.6 (upgrading from 4.6.3 to 4.6.5). - the list of bug fixes (especially the number of crash corruption fix) - it's a *minor* version not a major one The policy is not about minor version, it is bugfixes only. Not everybody make the distinction between minor and major, especially for software developpers. And again, the question of QA is here. Since we didn't detect the regression ( and since there is so much crashes to fix, and sine everybody think that's important enough to bypass our policy, according to people in the thread ), how do people plan to make sure the most obvious one are corrected ? Do we have open bug reports about them, with clear reproducer ? And do at least someone plan to use kdenlive enough to say this fixed the bug I have been seeing before ? Or do we plan to do it started, so it is good enough, let's ship it ? -- Michael Scherer
Re: [Mageia-dev] qemu new upstream release (1.0-rc1) and should we move from qemu-kvm to qemu?
Le samedi 12 novembre 2011 à 21:11 +0100, Kamil Rytarowski a écrit : On 12.11.2011 20:20, Michael Scherer wrote: Le samedi 12 novembre 2011 à 16:44 +0100, Kamil Rytarowski a écrit : There is also one important patch missed in Mageia - http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg00787.html it's dependency for the GNS3 simulator. OpenSUSE already includes it https://build.opensuse.org/package/files?package=qemuproject=openSUSE%3ATools If nobody is against I will do it and contact the maintainer (misc). I prefer to wait on the stable release ( ie, no rc1 ). We will wait on stable version of qemu. OK And no patch unless it comes from upstream ( and even, I am not keen on backporting feature, better wait for stable release ). GNS3 is already in stable! This package is broken - no dynamips (=no router emulation at all...), no patched qemu (no virtualization support at all...) According to the developers and their online documentation for package maintainers http://forum.gns3.net/post11571.html UDP patched Qemu is dependency/very important. The fact that someone pushed a broken package is not a good reason to add patches to qemu. We have too many patches on a general scale, and I do not want to end with a 2nd package like gdb. Patches make harder to upgrade, harder to make sure security is done correctly, and harder to ensure stuff are working ( since we are on our own when we patch something ). So for the patches, make sure it is upstream ( and given the discussion on ml, it should be soon ) and then in a tarball ( again, given that's a rc 1, that should be ok soon ). We must fix the package and provide at least not so heavy broken ones... I've prepared new version of GNS3, included into svn dynamips and xdotool (this one suggested) - these I can maintain with my mentor, so I ask for patch qemu in stable versus UDP support. Updates are not supposed to get new features, so that's no. And again, maybe people could do more tests before pushing broken rpm to stable ( like gsn3 ). -- Michael Scherer
Re: [Mageia-dev] [RFC] move cairo-dock to tainted because of trademark/patent issues
Le mercredi 09 novembre 2011 à 23:48 +0100, Florian Hubold a écrit : Am 09.11.2011 23:37, schrieb Michael Scherer: Le mercredi 09 novembre 2011 à 21:40 +0100, Florian Hubold a écrit : Am 09.11.2011 21:15, schrieb Michael Scherer: For the icons, what is the problem exactly, ie what icons are copyrighted ? Only linked the ml thread for the icons for reference. It is not said which are trademarked (and more important by whom) i guess it could be seen as a derivated work to the original lemmings game from DMA design. But as the game pingus is existing, and has not been sued, i don't think they have a valid point there. Maybe the problem is somewhere else, like a icon of windows, stuff like that. Hence the question. No, only animated penguins in there, I've attached the compressed directory if you want to take a look. I guess the superman could have been a issue ( dc-comics want to make sure the trademark is well defended ). But that seems far fetched since pingus is in fedora. The tarball cairo-dock-plugins has however some trademarked icons in Scooby-Do/data ( ebay, amazon, firefox, yahoo ). -- Michael Scherer -- Michael Scherer
Re: [Mageia-dev] qemu new upstream release (1.0-rc1) and should we move from qemu-kvm to qemu?
Le samedi 12 novembre 2011 à 16:44 +0100, Kamil Rytarowski a écrit : There is also one important patch missed in Mageia - http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg00787.html it's dependency for the GNS3 simulator. OpenSUSE already includes it https://build.opensuse.org/package/files?package=qemuproject=openSUSE%3ATools If nobody is against I will do it and contact the maintainer (misc). I prefer to wait on the stable release ( ie, no rc1 ). We will wait on stable version of qemu. And no patch unless it comes from upstream ( and even, I am not keen on backporting feature, better wait for stable release ). -- Michael Scherer
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release llvm-2.9-2.mga2
Le mercredi 09 novembre 2011 à 21:36 -0500, Charles A Edwards a écrit : On Wed, 9 Nov 2011 20:59:55 +0100 (CET) Mageia Team buildsystem-dae...@mageia.org wrote: Name: llvm Relocations: (not relocatable) Version : 2.9 Vendor: Mageia.Org Release : 2.mga2Build Date: Wed Nov 9 20:51:13 2011 Install Date: (not installed) Build Host: = Group : Development/Other Source RPM: (none) Size: 9586055 License: NCSA Signature : (none) Packager: Mageia Team http://www.mageia.org URL : http://llvm.org/ Summary : Low Level Virtual Machine (LLVM) I'm puzzled.or maybe just thick. Why is it that mesa tainted (lib64dri-drivers-7.11-4.mga2.tainted) now requires this In order to satisfy the 'libLLVM-2.9.so()(64bit)' dependency, one of the following packages is needed: 1- llvm-2.9-1.mga2.x86_64: Low Level Virtual Machine (LLVM) (to install) 2- lib64llvm2.9-2.9-2.mga2.x86_64: LLVM shared libraries (to install) Was mesa built intentionally with that dependency. Mesa use llvm to compile shader on the fly to be used on 3d hardware. IE, 3d games give some instruction in some specific language, and that's compiled to be run on your GPU, with some optimisation. ( hope this answer the question, if not, I guess either john or anssi have understood the real question ) -- Michael Scherer
Re: [Mageia-dev] [RFC] prefer dma rather than postfix in prefer.vendor.list for msec mga1 - mga2 upgrade
Le mercredi 09 novembre 2011 à 19:38 +0100, Florian Hubold a écrit : Hi there, as Anssi made me aware msec currently has a Requires on sendmail-command for cauldron, this was the outcome of the last discussion about msec / MTA. However, currently in /etc/urpmi/prefer.vendor.list postfix is preferred as sendmail-command and mail-server. Anssi's vote and mine is to replace preference on postfix with dma to ensure users get dma installed with the upgrade from Mageia 1 - 2 and not postfix which needs configuration. What configuration ? AFAIK, Postfix work out of the box for the use case of msec/cron, mail sent to root are delivered to root mailbox, unless someone added a aliase. From a quick look at dma, it behave the same ( ie, it take aliase from the same file, thus requiring the same configuration, or needing the same declaration of a smart host ). Wouldn't it be better to send everything to /var/log if no mta are found ? ( ie, do something like that : http://fedoraproject.org/wiki/Features/NoMTA ). We have the proper version of cronie ( I hope ), so what prevent us ? -- Michael Scherer
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release kdenlive-0.8.2-1.mga2
Le lundi 07 novembre 2011 à 19:39 +0100, Angelo Naselli a écrit : In data lunedì 7 novembre 2011 11:49:06, Michael Scherer ha scritto: Then the question is why did we ship a buggy software in our release. Did no one test the package to let important bug slip ? Because shit happens :) If shit happen, then 151 bugs is IMHO a rather serious diarrhea. The point is not why we released, but why not to update it. My point is why do we do the work twice. In case people didn't notice, there was a thread about there is too much update. Some stuff are unavoidable, like security updates. Some others could be avoided. And shipping a update is more costly ( it involve more people and a more complex process ) than shiping a proper package in the first place. So the best way to ensure less updates is to find why we do need to update in the first place. IE, how could have we prevented it. And if we were not able to detect regression in the first place, how can we make sure that the update will fix something ? -- Michael Scherer
Re: [Mageia-dev] [RFC] move cairo-dock to tainted because of trademark/patent issues
Le mercredi 09 novembre 2011 à 14:14 +0100, Florian Hubold a écrit : Hi there, after updating cairo-dock and -plugins to the latest version, it has come to my attention that cairo-dock has been removed from Fedora due to patent issues, as can be seen here: http://pkgs.fedoraproject.org/gitweb/?p=cairo-dock.git;a=blob;f=dead.package;h=2f21e743a00cfe3accc33b8d5c974f2572bcdfc5;hb=9e2eb0b9936f326a454f6104a81c6061a5528625 I've found no further explanation about this so far. The corresponding patent (from Apple) should be this one: http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1Sect2=HITOFFd=PALLp=1u=%2Fnetahtml%2FPTO%2Fsrchnum.htmr=1f=Gl=50s1=7,434,177.PN.OS=PN/7,434,177RS=PN/7,434,177 IMHO this Apple patent should not have been issued because of prior art: http://en.swpat.org/wiki/Apple_Dock but currently it's effective and we need to respect it. The base claim is indeed weak. A related discussions about cairo-dock and trademarks of some of the included icons in cairo-dock-plugins can be seen here: http://lists.fedoraproject.org/pipermail/legal/2009-January/000505.html To be honest, i don't think this was appropriate as those icons clearly seem to come from the game pingus, which is FL/OSS. So i request cairo-dock and cairo-dock-plugins and cairo-dock-themes be moved to tainted. Any objections? Yes, I do have one, I think we agreed that tainted was for enforced patents, or those that would likely be enforced. While the definition is fuzzy, I doubt that the patent will be enforced, mainly because it is weak, Red Hat lawyers are right for a US company, but we are not in the same position as Red Hat ( ie, we are not in the US, we are not a company with several millions on the bank account and no one will ever attack us because we are competing with them ). For the icons, what is the problem exactly, ie what icons are copyrighted ? -- Michael Scherer
Re: [Mageia-dev] [RFC] prefer dma rather than postfix in prefer.vendor.list for msec mga1 - mga2 upgrade
Le mercredi 09 novembre 2011 à 22:41 +0200, Anssi Hannula a écrit : On 09.11.2011 22:34, Florian Hubold wrote: Am 09.11.2011 20:48, schrieb Michael Scherer: Le mercredi 09 novembre 2011 à 19:38 +0100, Florian Hubold a écrit : Hi there, as Anssi made me aware msec currently has a Requires on sendmail-command for cauldron, this was the outcome of the last discussion about msec / MTA. However, currently in /etc/urpmi/prefer.vendor.list postfix is preferred as sendmail-command and mail-server. Anssi's vote and mine is to replace preference on postfix with dma to ensure users get dma installed with the upgrade from Mageia 1 - 2 and not postfix which needs configuration. What configuration ? AFAIK, Postfix work out of the box for the use case of msec/cron, mail sent to root are delivered to root mailbox, unless someone added a aliase. From a quick look at dma, it behave the same ( ie, it take aliase from the same file, thus requiring the same configuration, or needing the same declaration of a smart host ). Wouldn't it be better to send everything to /var/log if no mta are found ? ( ie, do something like that : http://fedoraproject.org/wiki/Features/NoMTA ). We have the proper version of cronie ( I hope ), so what prevent us ? msec already sends everything also to /var/log, which was disregarded in last discussion because normal users don't look there and it slowly adds up on diskspace. Normal users also do not read local mailboxes and the mailboxes slowly add up on diskspace. And log files can be rotated, unlike mailboxes. Maybe the log are not rotated on the other hand, so that's a bug that could/should be fixed, if that's the case. What we could do is either : - install nothing by default - install postfix/dma/whatever by a drakwizard if/when user give a email for msec alert. Maybe another solution would be to make msec smarter and not spew 100 lines per hours. I am all for msec but as I say often, this look like a Homer Simpson invention. WDYT ? -- Michael Scherer
Re: [Mageia-dev] dir-or-file-in-tmp
Le vendredi 04 novembre 2011 à 22:18 +, Barry Jackson a écrit : The BS recently (correctly) rejected a package which attempted to create a dir in /tmp. This was not however found beforehand by rpmlint in the spec. What test is done by the BS to catch this? Why is this not included in rpmlint? Running rpmlint on the binary package. And rpmlint doesn't replace manual inspection. -- Michael Scherer
Re: [Mageia-dev] Please test: initscripts+systemd in updates_testing
Le mardi 01 novembre 2011 à 12:54 +0100, Johnny A. Solbu a écrit : On Monday 31 October 2011 18:17, Michael Scherer wrote: So why merge / and /usr and kill a usable feature? What is the usable feature ? I can ask you the same thing: What is the usable feature of merging the two? What benefit do I get as a result? I suggest to re-read the other mails of the thread, especially the one where I give this url : http://www.spinics.net/lists/fedora-devel/msg158642.html ( PS: please try to not insult others with saying thing like most stupid thing ever performed ). -- Michael Scherer
Re: [Mageia-dev] Please test: initscripts+systemd in updates_testing
Le mardi 01 novembre 2011 à 01:56 -0400, David W. Hodgins a écrit : On Mon, 31 Oct 2011 13:17:15 -0400, Michael Scherer m...@zarb.org wrote: What is the usable feature ? To be able to put some kind of quota on /usr ? To be able to use a different fs for / and /usr ? I once ran into the situation where installing a package succeeded, but caused the / filesystem usage to hit 100%. The next reboot failed, due to this. The problem was likely due to not having anywhere to place pid file and others state related information. The /run mounted on tmpfs is a solution for that, AFAIK, and so most system should no longer face this problem. Maybe there is others reason to not start, but based on my experience, there is no obvious one. Even if I think that storing pid may no longer be needed for house keeping, thanks to systemd usage of cgroups. -- Michael Scherer
Re: [Mageia-dev] Re : E17 packaging
Le samedi 29 octobre 2011 à 18:38 +0100, Philippe Reynes a écrit : Hi all, Another solution is to package e17 twice (like chromium): - an E17 -stable based stable tarball, as it was almost/already done - an E17-unstable based on svn, as it's done now I am a little bit stupid, but can you explain how it solve the issue of not bypassing our update policy ? -- Michael Scherer
Re: [Mageia-dev] Updating ruby to 1.9.3?
Le lundi 31 octobre 2011 à 14:12 +0800, Funda Wang a écrit : Hello, After reading this: http://www.ruby-lang.org/en/news/2011/10/06/plans-for-1-8-7 We will support mageia 2 for 18 months (May 2012 to Nov 2013). But upstream will end ruby 1.8.7 at the time of June 2013. That means, we won't have any support from upstream even for security issues from June 2013 to Nov 2013. Of course, if mageia 2 be delayed Should we update ruby into 1.9 so that we still have support from upstream? Afaik, ruby 1.9 use a slightly different syntax than ruby 1.8 ( and of course, that's slightly incompatible, which translate usually to slightly lots of issues ). I know that puppet just fixed some issue regarding ruby 1.9. I am not sure the rest of the crowd is following. -- Michael Scherer
Re: [Mageia-dev] Please test: initscripts+systemd in updates_testing
Le dimanche 30 octobre 2011 à 14:19 +0200, Thomas Backlund a écrit : Colin Guthrie skrev 30.10.2011 13:26: 'Twas brillig, and Thomas Backlund at 29/10/11 21:13 did gyre and gimble: So? it's less impact on / than stuffing all of /usr on / I don't understand what point you're trying to make here. You'd be moving a whole bunch of stuff to /... And it becomes very tricky to administer exactly what to move to / as the dependencies are non-trivial to work out, the QA burden is very high to test all the various combinations of setups to ensure all the required bits have been moved to / After doing all that QA and ensuring all is well, then the whole separate of /usr and / is totally blurred anyway. As someone campaigning to keep /usr on a separate partition, I'd have thought this was what you were trying to protect against in the first place... it seems totally contradictory to suggest this as a solution. Keep in mind that one of the key aims in highlighting this issue via systemd is to actually ALLOW /usr to be a useful and self contained filesystem. If /usr is properly configured without leaking half of it to / it could be shared across multiple machines far more easily or even mounted as ro by default which could prove handy for security. Again, this is about highlighting the issues with an aim to making /usr much more useful. This is a laudable aim but you seem to be shooting it down due to gut reactions and prejudice. I've not yet seen any technical arguments from you about the topic. I'm saying moving the stuff that is _really_ needed, not based on udev might run... well, thinking some more on it I guess the real design flaw (not systemd specific) is using all of udev in init. Init should not care about more than getting disc access (and probably network for pxe boots) That's the point that Lennart make, ie : we used to have / to mount all partition and /usr to be mounted, now, we have initramfs to mount /, and then / to mount /usr, so it would be simpler to merge / and /usr So that's simple. For stuff needed for initial boot, we have initrd, for the rest, that's /usr/ http://www.spinics.net/lists/fedora-devel/msg158642.html Then we wouldn't have to worry about what udev might run and could keep a very clean / Well, it _is_ idiotic if it breaks working setups / possibilities to finetune systems. It depends on your definition of working. Sure if you specifically work around the know limitations of the design then you may get a bootable system, which you could classify as working, but I wouldn't say this is a robust base. Just a house of cards waiting for the next failure. I'd rather try and address the problems properly and be frank about it in the discussions. Well, it has worked 24/7 for servers for atleast last 15 years for servers I maintain, so I'd say that is pretty robust. That's also what people say about manually compiling software in solaris, and I think they are wrong, so that's not really a compeling argument to my eyes. In fact using packages prevent me from finetuning my software is also a common and recuring theme from the same people ( well, slightly less recuring nowadays as I didn't meet people telling me so since gentoo and slackware usage slightly dropped ). We have unix server since 1970, that doesn't mean the assumption that lead to some design decision are not open to be revisited. -- Michael Scherer
Re: [Mageia-dev] Re : Re : E17 packaging
Le lundi 31 octobre 2011 à 12:40 +, Philippe Reynes a écrit : Hi all, If you talk about this page : http://www.mageia.org/wiki/doku.php?id=updates_policys[]=updates[]=policy I think that I'm the stupid guy. I don't really understand where is the issue with this page and e17. Ok so there is a bug to fix in e17, what do you do ? Or a security issue like the one I found ( and that should be fixed I hope soon, after reporting it 3 times upstream ). if the answer is we ship a newer snapshot who requires to rebuild everything regarding e17 because there is no guarantee of binary stability ( ie, ABI wise ) and that will introduce unwanted changes, then the problem is here. Unless the snapshot are bugfixes only ( and they are not ), that's a problem. That's already annoying to have to do it for chrome, firefox and thunderbird to not happily increase our burden with a whole desktop environnement. So far, I have asked the question 3 times. No one answered at all. Also, please do not top post. -- Michael Scherer
Re: [Mageia-dev] Please test: initscripts+systemd in updates_testing
Le lundi 31 octobre 2011 à 19:06 +0200, Thomas Backlund a écrit : Michael Scherer skrev 31.10.2011 18:07: Le dimanche 30 octobre 2011 à 14:19 +0200, Thomas Backlund a écrit : I'm saying moving the stuff that is _really_ needed, not based on udev might run... well, thinking some more on it I guess the real design flaw (not systemd specific) is using all of udev in init. Init should not care about more than getting disc access (and probably network for pxe boots) That's the point that Lennart make, ie : we used to have / to mount all partition and /usr to be mounted, now, we have initramfs to mount /, and then / to mount /usr, so it would be simpler to merge / and /usr -ENOTCONVINCED So why merge / and /usr and kill a usable feature? Just have initramfs mount / and /usr, no need to merge. What is the usable feature ? To be able to put some kind of quota on /usr ? To be able to use a different fs for / and /usr ? Then we wouldn't have to worry about what udev might run and could keep a very clean / Well, it _is_ idiotic if it breaks working setups / possibilities to finetune systems. It depends on your definition of working. Sure if you specifically work around the know limitations of the design then you may get a bootable system, which you could classify as working, but I wouldn't say this is a robust base. Just a house of cards waiting for the next failure. I'd rather try and address the problems properly and be frank about it in the discussions. Well, it has worked 24/7 for servers for atleast last 15 years for servers I maintain, so I'd say that is pretty robust. That's also what people say about manually compiling software in solaris, and I think they are wrong, so that's not really a compeling argument to my eyes. Yeah, well that's your opinion. That's also yours, or you would be using solaris or slackware instead of doing packages. In fact using packages prevent me from finetuning my software is also a common and recuring theme from the same people ( well, slightly less recuring nowadays as I didn't meet people telling me so since gentoo and slackware usage slightly dropped ). We have unix server since 1970, that doesn't mean the assumption that lead to some design decision are not open to be revisited. I dont mind people revisiting design decisions, but breaking working setups sucks bigtime. So basically, you want fix that just change nothing ? But I guess that's the development trend nowdays: I cant be bothered to fix things properly so I just call it depreceated... and go ahead and break things just as I like Well, what do you propose to fix this properly ? -- Michael Scherer
Re: [Mageia-dev] Re : Re : Re : E17 packaging
Le lundi 31 octobre 2011 à 16:56 +, Philippe Reynes a écrit : So, yes, there isn't any way to manage bug/security issue in a very easy way when upstream team don't provide stable tarball. So, what is the mageia policy in this case ? no packaging at all ? private packaging ? So far, there is no policy specific for this issue. Hence the importance of discussing. Personnaly, I think we should really try hard to avoid a 4th firefox-like problem. I also think the current way is not something that will satisfy upstream coders if we ship old versions of their software when they think it is not ready. So as Florian told, maybe packaging a proper script to update e17 could help. I think we can ship the stable bit of e17, for people wanting to use them. Or see https://www.mageia.org/pipermail/mageia-dev/2011-October/009155.html for other type of solution. -- Michael Scherer
Re: [Mageia-dev] Review Of Bugs
Le lundi 31 octobre 2011 à 21:06 +, Colin Guthrie a écrit : 'Twas brillig, and Maarten Vanraes at 31/10/11 20:55 did gyre and gimble: Op maandag 31 oktober 2011 21:34:04 schreef D.Morgan: [...] But seriously, if we can't maintain/fix something like chromium-browser, we should just drop it completely, maybe have a get-chromium package instead why ? i package it regularly and tvignaud too. what about dropping all packages that have bugs ? this is just stupid and you should first ask ppl packaging it before giving such ideas ok, i get it, (allthough i did say IF) I guess it's a misguided attempt of myself to get more maintainership... I think the attempts to get more official partnerships by Samuel and yourself are very valuable, but by the same token, I think we need to accept that having a single maintainer for some packages just doens't make sense. For example things like initscripts, udev, systemd etc. should be maintained by a core team, and IMO, not a single person (tho' if someone steps up and is proven to be reliable then this is obviously not a bad thing per-se!). I'm certainly happy to help out here. Well, so far, the system do not support this. So either this supposed team is able to organise itself to have one of the member to act as a gate to take maitainership and dispatch task, or someone patch the maintdb script to have more than one person. As long as being managed by several people will be seen the same way as maintained by nobody, we will have the same problem as mandriva. Being maintained officially by someone do not prevent others to help. So I do not see any good reason to have them marked as nobody. -- Michael Scherer
Re: [Mageia-dev] Review Of Bugs
Le lundi 31 octobre 2011 à 22:16 +, Colin Guthrie a écrit : 'Twas brillig, and Michael Scherer at 31/10/11 21:44 did gyre and gimble: Le lundi 31 octobre 2011 à 21:06 +, Colin Guthrie a écrit : 'Twas brillig, and Maarten Vanraes at 31/10/11 20:55 did gyre and gimble: Op maandag 31 oktober 2011 21:34:04 schreef D.Morgan: [...] But seriously, if we can't maintain/fix something like chromium-browser, we should just drop it completely, maybe have a get-chromium package instead why ? i package it regularly and tvignaud too. what about dropping all packages that have bugs ? this is just stupid and you should first ask ppl packaging it before giving such ideas ok, i get it, (allthough i did say IF) I guess it's a misguided attempt of myself to get more maintainership... I think the attempts to get more official partnerships by Samuel and yourself are very valuable, but by the same token, I think we need to accept that having a single maintainer for some packages just doens't make sense. For example things like initscripts, udev, systemd etc. should be maintained by a core team, and IMO, not a single person (tho' if someone steps up and is proven to be reliable then this is obviously not a bad thing per-se!). I'm certainly happy to help out here. Well, so far, the system do not support this. Indeed. So either this supposed team is able to organise itself to have one of the member to act as a gate to take maitainership and dispatch task I think both socially and expectation wise, being a the gatekeeper in such context still carries a lot of responsibility that people would not feel too comfortable with, nor would there necessarily be the social hierarchy where said gatekeeper would feel sufficiently authorised to dish out tasks to others. or someone patch the maintdb script to have more than one person. This would be better, or perhaps team accounts can be created which forward mail to the members rather than having multiple maintainers.. There would be several problem with that : - that would would break the assumption we used in our ldap of 1 account = 1 person, assumption that we used every where in the auth system. For example, on the bugzilla settings, or seeing the bug that are assigned - that would also have the side effect of having some package not managed while appearing as such. For example, unless all maintainer are equally skilled, we will not - that doesn't solve the issues of who decide who get in the group. That's a basic gouvernance issue that I ask each time the question arise, and that is never answered AFAIK. The more important problem is not really technical, as I said in the past, but really organisational. The proposal of a core team will just mean we have a 2 tier hierarchy of maintainer, like we did in the past with main/contribs. Except that it doesn't solve the issue of having thing not really maintained. ( and that's not really very egalitarian IMHO ) If people in the core team cannot solve all problems, ie, if we have specialization ( which seems unavoidable IMHO ), we still need to know who can do something, hence some way to find who maintain something. What if the team take care of gcc, glibc, systemd, but there is only 1 person knowing enough gcc out of X ? How do we see there is a problem when this person say I cannot do my work for now/I leave. Who ultimately decide if needed ? As long as being managed by several people will be seen the same way as maintained by nobody, we will have the same problem as mandriva. Personally I don't buy that explanation. Of course it can be true in some cases (everyone just waits for someone else to fix it) but I suspect the odds of things getting fixed is still much higher than when a package is officially maintained by nobody... Yet, there is several studies on the social proof ( one of the most affordable is the book from Robert Cialdiani, see the chapter about it ). On a side note, the issue is not to put more packagers to solve more bugs, but to put the right person in charge. The maintainer db is the way we use for the first step for maintainer. Now if a packager want help, he can simply ask. But in the end, if no step to do anything, the bug will still be there. Being maintained officially by someone do not prevent others to help. So I do not see any good reason to have them marked as nobody. I certainly don't expect a package maintained by a team to be marked as nobody (well, certainly not longer term). Yet, that's exactly what happen at Mandriva since years, and that's the problem. Ie, if we do not start to solve the issue now, it will just stay as longer term as usual. Ie, there is lots of rpm marked as unmaintained that are not, and lots that are marked as maintained. And for now, the choice are either nobody, or someone. Anything else is not coded, and therefor do not exist. But again, I think even
