Re: [Mageia-dev] Mageia 2 DVD 64bits install is broken
Hi Juergen, Le 2012-05-25 09:14, Juergen Harms a écrit : Did you file a bug? - I think you should, because - the problem is reproducable on several installations (what do they have in common?) - Mageia should be installable by a newby, without the need to fiddle with the NO ACPI option - it is likely that some time some other user will be caught by the same problem, who might not find this thread. I am assuming you are speaking to me (Marc). No I did not file a bug as the installation of problem mobo's has already been foreseen with the Option settings on the bottom of the installation page. I have also added a thread on the users' mailing list with the subject line: NO ACPI at install time may work for you Now that I think of it, should I guess I should leave a note on the forums. Cheers, Marc
Re: [Mageia-dev] Mageia 2 DVD 64bits install is broken
Le 2012-05-25 20:07, Simple . a écrit : 2012/5/25 Maurice Bateymaur...@bcs.org.uk: On Thu, 24 May 2012 19:01:38 +0100, Simple . wrote: i said that md5 was checked, so the downloaded .iso is ok, But did you do a 'check after write, to confirm that the .iso had been correctly writeen to DVD? I hae not build the .iso into a DVD, but burned it into a USB pen disk, and with a more thorough inspection i was able to see that in the severall tries the same files were saved in the USB with INCOMPLETE names, and that happened in files that had very long names, like: telepathy-kde-common-internals-translations-0.3.0-1.mga2.noarch.rpm vboxadditions-kernel-3.3.6-desktop-2.mga2-4.1.12-5.mga2.x86_64.rpm vboxadditions-kernel-3.3.6-netbook-2.mga2-4.1.12-5.mga2.x86_64.rpm and the 19 failed transactions came from failed dependencies due to not recognized the packages with incomplete names. i used rufus in windows to burn the .iso into the usb, now i dont know if this is specifically caused by rufus or if this is caused by other thing, and here would be better that others could test and reproduce this. Regarding No ACPI i can not confirm what Marc Paré said, and again, the install runned fine, so here was not the case that No ACPI could make any difference, only if the boot didnt run is that i could try No ACPI to see if woud solve it. And when usingNo ACPI the boot freezed. So when in the USB pen disk i renamed the packages to its original filenames, the install went fine and finally made to conclude with sucess Mageia 2 install. Congratulations on getting it to install. Feel free to let us know how you like the version -- but maybe this would be better done on the users mailing list. Cheers, Marc
Re: [Mageia-dev] Mageia 2 DVD 64bits install is broken
Hi Simple Le 2012-05-23 17:03, Simple . a écrit : Hi, I have burned the DVD 64bits iso into a USB pen disk and during the install i get this first problem: Instalation failed, some files are missing: /tmp/image/media/core/telepathy-kde-common-internals-translations-0.3.0-1-mga2.noarch.rpm. You may need to update your urpmi databse. Try to continue anyway? and almost at the install i get another message saying there are 19 transactions failed, severall tehepathy packages, kcm, module and severall x11-driver-video-* packages. Anyway i end the instalation, reboot and then it doesnt even appears KDM, but even if i login in cli and run startx continues not being possible to enter in X Another problem with the dvd iso, is that burning with dd doesnt put it bootable, doesnt appears to be hybrid. At the point where it says Install Mageia and all the other choices, look on the bottom for additional options, hit F6 and pick No ACPI and continue as per normal with the installation.This may solve your problem. Happy install! Cheers, Marc
Re: [Mageia-dev] Mageia 2 DVD 64bits install is broken
Hi Simple Le 2012-05-24 13:47, Simple . a écrit : 2012/5/24 Marc Parém...@marcpare.com: Hi Simple Le 2012-05-23 17:03, Simple . a écrit : Hi, I have burned the DVD 64bits iso into a USB pen disk and during the install i get this first problem: Instalation failed, some files are missing: /tmp/image/media/core/telepathy-kde-common-internals-translations-0.3.0-1-mga2.noarch.rpm. You may need to update your urpmi databse. Try to continue anyway? and almost at the install i get another message saying there are 19 transactions failed, severall tehepathy packages, kcm, module and severall x11-driver-video-* packages. Anyway i end the instalation, reboot and then it doesnt even appears KDM, but even if i login in cli and run startx continues not being possible to enter in X Another problem with the dvd iso, is that burning with dd doesnt put it bootable, doesnt appears to be hybrid. At the point where it says Install Mageia and all the other choices, look on the bottom for additional options, hit F6 and pick No ACPI and continue as per normal with the installation.This may solve your problem. If the problem was from there i wouldnt be able to boot the installer. The installer starts fine, and all goes fine untill the point i get the message: Instalation failed, some files are missing: /tmp/image/media/core/telepathy-kde-common-internals-translations-0.3.0-1-mga2.noarch.rpm. You may need to update your urpmi databse. Try to continue anyway? and that package does exist, so the problem is about listed files in this iso. I just would like some one could try the DVD install and say whats happening. I am writing from a DVD install downloaded from Mageia and burned onto a DVD. I also did a SUM check and all was fine. I tried to install 3-4 times and I got the same messages as you. I then realized that, depending on some boards you may need to install with NO ACPI (btw this happened quite regularly with Mandriva. Then install with NO ACPI on my machine went well and it was all installed 20 minutes later with no hiccups. Give it a try. Cheers, Marc
Re: [Mageia-dev] Mageia 2 DVD 64bits install is broken
Le 2012-05-24 20:16, Simple . a écrit : I am writing from a DVD install downloaded from Mageia and burned onto a DVD. I also did a SUM check and all was fine. I tried to install 3-4 times and I got the same messages as you. I then realized that, depending on some boards you may need to install with NO ACPI (btw this happened quite regularly with Mandriva. Then install with NO ACPI on my machine went well and it was all installed 20 minutes later with no hiccups. Thanks for the tip and clarification, since i was feeling quite alone on this quest, almost like i was inventing something... But i never had any problem in installig mandirva dvd´s but i will now try with No ACPI to see if all goes well. No problem. I did tried with No ACPI and when using after i enter to install the screen stays black and nothing more happens. Hmm, maybe the installer is having problems with your monitor resolution or your video card. How about on the bottom options, make sure the resolution is F3-800x600 and then do F6-No ACPI and try install again. What makes me confusion is that until this release i never problems like this. Yup. These things happen. Could you also send the motherboard and videocard that you are using? Cheers, Marc
Re: [Mageia-dev] Mageia 2 final release is out
Le 2012-05-22 16:39, Anne Nicolas a écrit : Hi all So here it is! Mageia 2 final release is out. - new web site layout: http://mageia.org - blog announcement: http://blog.mageia.org/en/2012/05/22/mageia-2 - download isos: https://www.mageia.org/en/downloads/ - release notes: https://wiki.mageia.org/en/Mageia_2_Release_Notes - errata: https://wiki.mageia.org/en/Mageia_2_Errata Thanks everybody for all the hard work during these last months. I guess we can be proud if this release and we hope you will enjoy this new version. Big thanks for last run to tmb and QA team who did not sleep a lot these last days :) Spread Mageia 2 and enjoy! Congratulations to everyone for the great work and QA. All of your work are greatly appreciated! Merci! Cheers, Marc
Re: [Mageia-dev] Kernel issues with atheros wifi
Le 2012-04-17 16:56, JA Magallón a écrit : On 04/17/2012 10:50 PM, Thomas Backlund wrote: 17.04.2012 23:39, JA Magallón skrev: Hi... I've been bitten by this bug: https://bbs.archlinux.org/viewtopic.php?id=139270p=1 on my netbook. From what I read, ath9k bug is corrected in 3.3.2, and ath5k bug is still present and a couple patches are needed. Are we too late to have a patched 3.3.2 in Cauldron ? ath9k fix is in our kernel-3.3.1-2.mga2 New kernel will land on Cauldron after beta3 is out Thanks, good to know ;) ! Not sure if this is relevant but I had the same problem and looks like the solution for the laptop I was servicing was this (I left this on the thread that I had started on the user mailing list[1]): Just letting people know of the fix for this unit. The laptop's owner returned it so that I could work on a possible fix to the wifi connection. After some testing and trouble shooting, I deleted the NetworkManager through the MCC which allowed a more reliable connection and I also created this file in etc/modprobe.d/ath9k.conf with the line options ath9k nohwcrypt=1 which for some unknown reason made for an even more solid connection -- I found this recommendation on a thread somewhere but lost the location. The laptop now connects to the internet and does not turn itself out, and, it no longer cuts in and out randomly. Cheers, Marc [1] http://comments.gmane.org/gmane.linux.mageia.user/6497
Re: [Mageia-dev] New wiki finally online
Le 2011-11-14 12:34, Oliver Burger a écrit : After quite some work in the last weeks the new wiki is finally available! Check it out at https://wiki.mageia.org Until now only the English wiki is online, other will follow soon. We did import all (or most) of the contents from the old wiki and tried to bring some structure into it. As you can see, there is almost no documentation for the end user till now but the documentation team will start changing that. If you would like to help us on that, just join the doc team in its meeting tommorow at 19.00 UTC in #mageia-doc on the Freenode irc netwoork. And please have a look at https://wiki.mageia.org/en/Wiki_and_Documentation#Page_naming before starting to create pages on the new wiki. We do want to keep some kind of order in it... ee also the blog post about it on http://blog.mageia.org/en/ Cheers, Oliver Congrats on all those who put the wiki together. Very elegant and simple to read. You are awesome! Marc
Re: [Mageia-dev] Anybody having high CPU by kded4 after upgrading to 4.6.90?
Le 2011-06-30 18:34, Radu-Cristian FOTESCU a écrit : This is making me crazy. After upgrading to KDE 4.6.90 (cauldron, of course), the bloody m*f*er kded4 (the worse idea in KDE4) constantly takes 55-75% CPU. Of course, killing it is possible, but this affects the plasmoids. (E.g. it made me inadvertently filling an invalid bug report 1981, which disappeared once I let kded4 live.) Really, isn't anybody experiencing high CPU from kded4? (This is making me crazy. Otherwise, I'll tell you some day about a bug/crash that was *accidentally* fixed by KDE 4.6.90.) Thanks, R-C aka beranger Mine was doing this and I tried to stop it (I don't really know how to do this), so in the end I let it go. It has now stopped. Could it be that it is indexing all of your files? I know that I have 600 gigs of data, and, if KDE4 was trying to index all of these files (photos, music and larger LibreOffice files that it would take quite a while to index them. Maybe this is the problem? My CPU has returned to normal after a couple days of churning. I also never log-out of my system. Cheers Marc
Re: [Mageia-dev] get-skype package for submission
Le 2011-06-09 19:56, Barry Jackson a écrit : I have been working on a package to install Skype current stable release and now feel that it is ready for submission for approval. It has already been improved/corrected/adapted many times following discussions on #mageia-mentoring where I have been given lots of help. The idea evolved here https://bugs.mageia.org/show_bug.cgi?id=154 where the current version is available as an attachment. https://bugs.mageia.org/attachment.cgi?id=551 It has been a challenge and I have learned a lot in working on this. :) Barry Hi Barry Thanks for doing this. I uncompressed the file. What is the difference between the 2 .rpms? You may want to include a readme in the package for people like me. Cheers Marc
Re: [Mageia-dev] get-skype package for submission
Le 2011-06-10 20:13, Barry Jackson a écrit : On 10/06/11 15:08, Marc Paré wrote: Hi Barry Thanks for doing this. I uncompressed the file. What is the difference between the 2 .rpms? You may want to include a readme in the package for people like me. Cheers Marc Marc, It is not really ready for general consumption yet (although it does work). If you want to test it the noarch.rpm is the one to install, not the src.rpm. Barry Thanks, I'll give it a try. Cheers Marc
Re: [Mageia-dev] Providing 32-bit flash-player-plugin in x86_64 nonfree?
Le 2011-06-05 15:45, andre999 a écrit : Marc Paré a écrit : Le 2011-06-05 03:59, Kira a écrit : 在 Sun, 05 Jun 2011 13:25:59 +0800, Marc Paré m...@marcpare.com寫道: I have just installed Mageia on a 64 bit and the 64bit Flash .rpm is quite painless from the Adobe site. Cheers Marc The major problem is that Adobe seems don't like we to distribute the 64-bit version. Sorry, I just rechecked my flash and it is the 32bit version. My fault. But the bottom line is that it works for now. As for the Adobe Square preview, I don't think the 64bit version will suffor for too long in preview release as most of the machines being sold today are 64bit. I don't think that Adobe will sit on the sucess of their 32bit product and ignore the 64bit version. For now the 32bit version works on Firefox 64bit and eventually the 64bit version will be released in .rpm for us to install. We just have be patient. Cheers Marc Salut Marc The plugin is installed in ~/mozilla/firefox/plugins/ (or one of the alternate locations provided by the Firefox rpm), so you can just as easily install the plugin from a tar file. The above location is the first searched by Firefox, so other locations will be ignored for flash, if flash is found there. The only problem with the preliminary version is that it is more likely to have bugs. Personally I install a tar version of flash, as it stays in place across distro updates, even clean installs. (I keep /home intact.) My 2 cents :) Merci for your deux cents! I will do it. Cheers Marc
Re: [Mageia-dev] Mageia 1 is out finally!
Le 2011-06-01 13:29, Anne nicolas a écrit : Hi all Finally release is out and in time! First of all thanks all for the hard work during these 8 months. I guess Mageia community (packagers, admins, translators, testers, artwork) can be proud of this final release. Still some improvments are needed in different part of the project but at leat Mageia distribution is out and ready for final users. Some links for more information http://blog.mageia.org/en/2011/06/01/mageia-1/ http://mageia.org/en/downloads/ http://mageia.org/en/1/notes/ Enjoy this release and see you for Mageia 2 :) Cheers Félicitations to all. I am looking forward to installing it. Cheers Marc
Re: [Mageia-dev] Mageia 1 is out finally!
Le 2011-06-01 13:29, Anne nicolas a écrit : Hi all Finally release is out and in time! First of all thanks all for the hard work during these 8 months. I guess Mageia community (packagers, admins, translators, testers, artwork) can be proud of this final release. Still some improvments are needed in different part of the project but at leat Mageia distribution is out and ready for final users. Some links for more information http://blog.mageia.org/en/2011/06/01/mageia-1/ http://mageia.org/en/downloads/ http://mageia.org/en/1/notes/ Enjoy this release and see you for Mageia 2 :) Cheers Félicitations to all. I am looking forward to installing it. Cheers Marc
[Mageia-dev] Setting NFS shars and making the process more user friendly
I was just recently reminded of this on a Mdv list. Is there a way to make the setting of NFS shares easier for users. Way back in Mandriva 2008 the NFS process was very well done and users would only have to establish NFS shares with other computers and the etc/fstab was properly written. Since Mdv 2009 the process seems to have been broken and I have had to go into the fstab and change manually the pathway to from computername to ip pathway. I had posted the fix on the MDV forums and put in a bug for this. I am not sure if my bug was not well written and maybe that is why it was never really taken up by the dev team. You can find the post here: http://forum.mandriva.com/en/viewtopic.php?f=87t=113793 and you will find the process to establish NFS shares at the very bottom of the post. NOTE that the shortcut to the bugzilla no longer works. I still use this process with MDV2010.2 and set my fstab by hand. I have 4 networked MDV boxes in the house and they all use NFS shares. It would be nice if this were fixed with Mageia as it would be quite an advantage from a user's point of view as this would make the setting of shares fullproof. Setting up of NFS shares could then be advertised as a positive point from a marketing point of view. Note the the setting of NFS shares comes up constantly on helplists and most of these involve the fstab. Marc
Re: [Mageia-dev] Setting NFS shars and making the process more user friendly
Le 2010-12-26 12:17, Daniel Kreuter a écrit : On Sun, Dec 26, 2010 at 6:12 PM, Marc Paré m...@marcpare.com mailto:m...@marcpare.com wrote: Le 2010-12-26 07:16, Daniel Kreuter a écrit : Should I submit this as a bug? Do we have a bugzilla? Marc We should submit it as a bug when we are sure it will exist in Mageia and no at the moment we don't have bugzilla yet, but the guys are working on it. -- Mit freundlichen Grüßen Greetings Daniel Kreuter Thanks. I'll tag it on my reader for a review later. Cheers Marc
Re: [Mageia-dev] Setting NFS shars and making the process more user friendly
Le 2010-12-26 17:29, Maarten Vanraes a écrit : Op zondag 26 december 2010 09:50:34 schreef Marc Paré: I was just recently reminded of this on a Mdv list. Is there a way to make the setting of NFS shares easier for users. Way back in Mandriva 2008 the NFS process was very well done and users would only have to establish NFS shares with other computers and the etc/fstab was properly written. Since Mdv 2009 the process seems to have been broken and I have had to go into the fstab and change manually the pathway to from computername to ip pathway. I had posted the fix on the MDV forums and put in a bug for this. I am not sure if my bug was not well written and maybe that is why it was never really taken up by the dev team. You can find the post here: http://forum.mandriva.com/en/viewtopic.php?f=87t=113793 and you will find the process to establish NFS shares at the very bottom of the post. NOTE that the shortcut to the bugzilla no longer works. I still use this process with MDV2010.2 and set my fstab by hand. I have 4 networked MDV boxes in the house and they all use NFS shares. It would be nice if this were fixed with Mageia as it would be quite an advantage from a user's point of view as this would make the setting of shares fullproof. Setting up of NFS shares could then be advertised as a positive point from a marketing point of view. Note the the setting of NFS shares comes up constantly on helplists and most of these involve the fstab. Marc while we're on the subject, imo, user accessible NFS shares could be used with the notification area; like it was a USB disk, then people can mount/unmount it easier; or perhaps less problems if network is suddenly disabled and we have mounted NFS hosts. This would certainly be quite handy as many households have more than 1 computer and they could then manage share easier. Marc
Re: [Mageia-dev] Release cycle - what is actually POSSIBLE?
Le 2010-11-26 03:14, Wolfgang Bornath a écrit : 2010/11/26 andre999and...@laposte.net: MIhail Papadopoulos a écrit : Why not going down the right path: A rolling release cycle would be simply great. After all, this isn't a commercial distribution, so it shouldn't be a total noob Ubuntu-style mishmash. Why ? What do you mean by rolling ? How would it improve things for the user ? How would it improve things for the developers/packages/translators who provide Mageia ? What are the costs ? What are the benefits ? And how does that compare with the alternatives ? This has already been discussed in length in one of the lists, very early, IIRC ist was early October . There were even polls in communities about. Yes it was. I think it will re-surface again due to Ubuntu's recent advertising of going to a rolling distro scheme. We may have to go through another round of these comments. Do we have an archive list of the user mailist where we can refer people to continue on that particular thread? Are the mailists archived? Marc Marketing Team Member
Re: [Mageia-dev] Release cycle - what is actually POSSIBLE?
Le 2010-11-26 05:35, Oliver Burger a écrit : Marc Parém...@marcpare.com schrieb am 2010-11-26 Do we have an archive list of the user mailist where we can refer people to continue on that particular thread? Are the mailists archived? https://www.mageia.org/pipermail/mageia-dev/20101009/001055.html Merci Olivier Marc
Re: [Mageia-dev] New mirror -- maybe
Le 2010-11-04 03:14, Ahmad Samir a écrit : On 3 November 2010 22:41, Marc Parém...@marcpare.com wrote: If I was to approach our local university about mirroring Mageia, would I have to supply them some specs? What would they need to know and who would they have to get into contact with? They are mirroring the Mandriva KDE updates. University of Waterloo. The I don't understand this bit, they're mirroring just the KDE updates? how so? (or do you mean the unofficial repos at ftp.kde.org?) Sorry, yes. Their PC Club. The KDE4.5.2 update. Marc
[Mageia-dev] New mirror -- maybe
If I was to approach our local university about mirroring Mageia, would I have to supply them some specs? What would they need to know and who would they have to get into contact with? They are mirroring the Mandriva KDE updates. University of Waterloo. The university just announced last week that their fundraising for the year was worth 600 million $$$Cdn. Maybe they could afford a little server space. Marc
[Mageia-dev] LibreOffice
I am a member of the Mageia marketing team and as well as a LibreOffice marketing team member. I have been asked to enquire if LibreOffice will be included in the Mageia distro and if anyone knows who the packager will be for LibreOffice? Ahem ... of course I would encourage Mageia adopt the LibreOffice as its main office suite. Thanks for any informtion. Merci Marc Paré
Re: [Mageia-dev] LibreOffice
Le 2010-11-02 12:30, Hoyt Duff a écrit : On Tue, Nov 2, 2010 at 9:55 AM, Marc Parém...@marcpare.com wrote: I am a member of the Mageia marketing team and as well as a LibreOffice marketing team member. Thanks for any informtion. Merci Marc Paré Could you employ your marketing-fu and come up with a better name than the absolutely horrible LibreOffice?? Sorry, we (LibO community) have already discussed, yelled, screamed, fought, negotiated, voted, tried to pay votes and to buy votes, threatened and finally all agreed (well the majority did) that the name was just fine. Yes, you can still find some dissenters, but, by and large, the overall consensus was that the name was OK and great. So, it is called LibreOffice and some are calling it LO or LibO (I personally call it this). We have gone through the scenarios of how to pronounce it for the English members, but the latin speaking members do no seem to have any problems with its pronunciation. And I think, the general feeling on this is, just pronounce it the way you think is right. I think we went through this stage as well, if I remember correctly. Hope that helps. Marc
Re: [Mageia-dev] LibreOffice
Le 2010-11-02 11:48, Michael Scherer a écrit : Le mardi 02 novembre 2010 à 09:55 -0400, Marc Paré a écrit : I am a member of the Mageia marketing team and as well as a LibreOffice marketing team member. I have been asked to enquire if LibreOffice will be included in the Mageia distro and if anyone knows who the packager will be for LibreOffice? Ahem ... of course I would encourage Mageia adopt the LibreOffice as its main office suite. Hi, We do not have any build system yet, neither do we have official packaging team and so until we have them, I think that discussing every detail on what packages we will have is just a discussion that will happen too soon. ( and it also take some time that I would better spend doing concrete system administration instead of answering and following discussions :/ ) If someone provides a package, then I see no reason to not have it, that's as simple as that. And if people want to start right away, they can start working a package targetting Mandriva cooker, as this would likely be what we will use. Hi Michael: Thanks for the advice. It may be that there is a packager on the LibO team who would like to do the packaging for the Mageia version. maybe this is why they are enquiring. If this is the case, should he/she join the Mageia team? I imagine your answer would be yes. I know that I would encourage any LibO packager to join the Mageia team. Does anyone know if the LibO suite will be adopted as the official Mageia Office Suite? We used to have OOo as our official suite in Mandriva. BTW ... we have been advised to be ready for a LibO final version in 4-8 weeks if all goes well. We are just going through the betas. So, it should be ready for the final version of Mageia when it comes out. Marc
Re: [Mageia-dev] How will be the realese cycle?
Le 2010-10-18 04:18, Wolfgang Bornath a écrit : Here's the result of the German community. After the initial opening of the poll there was a discussion with more than 40 postings, still going on. Involved were people actively using ArchLinux, members of our packaging team and interested users. Voters had the chance to alter their vote during the discussion, which was used by some who learned more about rolling release during the discussion. * Exactly as Mandriva, 6 months release cycle 4% * Exactly as Mandriva, 12 months release cycle 20% * 6 months cycle for core, rolling release model for other software 13% * 12 months cycle for core, rolling release model for other software 41% * Rolling release 22% With 54 % this is a majority for the rolling light model (where the 12 months cycle for core received the most votes). Remarkable is the fact that the Mandriva release cycle (6 months) came in last. Thanks again for the results. I wonder how many more communities are running the poll? The results are becoming more and more obviously clear. Could we start a new thread on this with the results posted on it? Marc
Re: [Mageia-dev] How will be the realese cycle?
Le 2010-10-18 04:26, Wolfgang Bornath a écrit : 2010/10/18 Marc Parém...@marcpare.com: Thanks Michael for the note. This is why I am in favour of streamlining the reporting of bugs from the user side and not the dev. Devs should always count on seeing bugs reported on bugzilla and nothing more. However, on the user side, to keep the reporting of bug flow from breaking down, I suggest a two tier format that I discussed earlier. Maybe have a look at this and comment? I imagine that the Mageia devs are interested in hearing of bugs from as many sources as possible regardless of user experience. Here's the place where I may bring back to attention the proposed system of helpers in the user forums. People who help unexperienced users to write bug reports and will also help them along if the devs ask questions during the lifetime of that bug in bugzilla. A user who has done this once (ideally from the start of a bug until its end) will be eager to do it again when he stumbles across another bug. He will also be eager to teach his new knowledge to other users. This way we will get a larger community of bug reporters than by any documents. There must not be a fixed Bug Friends group, this mentoring can be done by all experienced users. Actually, the process that you describe is exactly what mentoring is all about. I would be in favour of both processes. BTW ... someone mentioned that we should have a different thread for this. Should we do this? Maybe call it Report Bug Process ? Marc
Re: [Mageia-dev] How will be the realese cycle?
Le 2010-10-17 04:34, Tux99 a écrit : On Sun, 17 Oct 2010, David W. Hodgins wrote: I know enough c, perl, python, etc., that I can sometimes figure out where the problem is, (when submitting bug reports), but I don't know enough to put together rpm packages, or where to start, to learn how to do so. Making rpm packages is actually a lot easier than writing C, Perl or Python code, so with your background it would be very easy for you to learn how to make a package. Have a look here, these instructions explain it well, I learnt it from there: http://wiki.mandriva.com/en/Development/Howto/RPM Thanks for the link Tux99, I am interested in this too. Marc
Re: [Mageia-dev] How will be the realese cycle?
Le 2010-10-17 19:44, Michael Scherer a écrit : Le vendredi 15 octobre 2010 à 22:00 -0500, Fernando Parra a écrit : I am just coming back from my weekend, so I may have missed lots of discussion, but there is 2 points in your mail that I really wanted to address. The basic/novice user doesn't read anything, doesn't request anything to some like a bugzilla, And so, because some users are considered too lazy, we should do the work for them ? I am living in a world where days are only 24h long. If people are not able to do their part of the work like filling a proper bug report on bugzilla to get their wish done for free by a already overworked volunteer, the only answer I can give is 'too bad for them'. If packagers were not already busy, yeah, I would think we should have more backports requests. But if there is any packager that think I do not have enough work, give me more, he can send me a mail and I will have no problem to help him solve this issue fo too much free time. While I agree we should lower the bar for all kind of contributions, I am not sure that giving more work to packagers by requesting backports clearly qualify as a contribution, and so as such should not be lowered too easily. So before doing anything, we need to think about scaling from our side. Please take in mind that we are trying to get a considerable number of new users. I do not think I am ok to be counted in the we you use. I do not think I want, nor that I will even try to get a considerable number of new users, I want a sustainable number of users that can be properly taught of free software way and ecosystem, so they can be later part of the community as people who help us in very direct way. And that's what I will try to do. Thanks Michael for the note. This is why I am in favour of streamlining the reporting of bugs from the user side and not the dev. Devs should always count on seeing bugs reported on bugzilla and nothing more. However, on the user side, to keep the reporting of bug flow from breaking down, I suggest a two tier format that I discussed earlier. Maybe have a look at this and comment? I imagine that the Mageia devs are interested in hearing of bugs from as many sources as possible regardless of user experience. Marc Pare
Re: [Mageia-dev] How will be the realese cycle?
Le 2010-10-16 02:56, Luca Berra a écrit : On Fri, Oct 15, 2010 at 10:00:14PM -0500, Fernando Parra wrote: The basic/novice user doesn't read anything, remove basic/novice from the sentence and i will agree ;) doesn't request anything to some like a bugzilla, but give him a forum and he probably will This statement I totally agree with! If a user is told to submit in bugzilla, I find that they will not do it. Reporting to bugzilla for a user, is one more level of serious commitment on their part and most will not want to commit themselves to it. However, if they can report to a forum, this is different. Users view forums as community involvement with community feedback. They may be ask to test out the problem and report back on the result (just like in bugzilla) but they know that other community members will be there to lend a hand and support. If we are going to be really interested in quashing bugs with a lot of community involvement, IMHO, I think that we should offer -- bugzilla for the enthused and commited users. These people are interested on reporting bugs the right way and will replicated and help in debugging. -- but for ordinary users, we could offer them a Report a bug forum where they can report a bug; the community could then replicated the bug; have a Bug-ambassador or bug-reporter or who could then submit it officially on bugzilla. Tracking of that particular bug could then be the responsibility of the Bug-ambassador; once the bug is quashed, the Bug-ambassador could report back to the Report a bug forum of the bug fix and thank the community for their help. This would help validate the user who reported the bug and make him/her feel like a part of the contributing team. IMHO, this would work a lot better for the majority of users who do not want to commit to any more than reporting the bug; the devs would get a more constant stream of bug submissions by Bug-ambassadors who are able to triage submitted bugs on the forum. Doing it this way would still make bugzilla the only place where devs would go to pick up bug information and the Bug-ambassadors would be the people who triage the bugs at the forum level. Marc
Re: [Mageia-dev] How will be the realese cycle?
Le 2010-10-16 12:36, Ahmad Samir a écrit : But generally reporting bugs by proxy is always a bad idea, unless the guy who'll play middle-man can reproduce the exact same bug on his own box. You see, triage team / package maintainer / dev will ask for info about the bug, more than once depending on the bug itself; now Mr. middle-man will have to go to and fro a lot of times, taking info from the user and posting it in bugzilla then taking questions/info from the bugzilla and conveying it to the user; now that's a tedious and tiresome job that's very prone to failure. (it's like a friend being sick and instead of him going to the doctor he sends you on his behalf because you know the symptoms :)). It's much better to help the user formulate a useful bug report, that's easier / more productive for all involved parties. There would be no middle man. Once the middle-man could replicate the bug and verify the bug with other users, then the middle-man would submit to bugzilla. That's it. From there on, the middle-man will take care of testing requests from devs. As far as reporting back to the original user who reported the bug, as an extra gesture of kindness, the middle-man would just post on the Report a bug forum that the bug has been quashed or is still under review ... but not to the user but to the Report a bug forum. The idea is to keep the flow of possible bug reports coming in an organised way. The middle-man would have to be someone with a little more experience than that of a new user and also someone who has an interest in working this way. We will get more bug reports from users by keeping it simple and easy. Marc
Re: [Mageia-dev] How will be the realese cycle?
Le 2010-10-16 15:52, Renaud MICHEL a écrit : On samedi 16 octobre 2010 at 21:29, Marc Paré wrote : There would be no middle man. Once the middle-man could replicate the bug and verify the bug with other users, then the middle-man would submit to bugzilla. That's it. From there on, the middle-man will take care of testing requests from devs. That would only work for pure software bugs. If the bug is hardware related, it is unlikely that the middle man will be able to reproduce it. For those we really need the input from the real bug reporter. And for software bugs, the middle man would have to reproduce the software environment of the reporter, which may be complicated if he installed software from third party (or worse, proprietary software). Sometimes the problem is obvious and only related to a single package, and for such case a forum with some contributors reproducing the bug and then submitting a bug report may work. But if the problem is related to a particular combination of packages then the middle man could spend a considerable amount of time replicating the reporter particular configuration before he can actually reproduce the bug. I think it may work if those bug friends (don't remember who proposed that name) only take for themselves the simple, one package, software only bugs, and suggest to the reporter to create himself a bugreport (eventually providing assistance if the reporter has never done it before) describing his problem, because the devs will really need his feedback first hand. That forum would be an easier entry point than bugzilla for users not familiar with bugreports. Yes you are perfectly right. This is where the the bug report would be ramped up to the bugzilla stage, and at the point, the reporter would have obviously shown an interest in the resolution/fix of the bug. This would in effect would create a mentorhsip/reporter relationship and a great training opportunity for the reporter. We would then have, by default, a mentorship programme in the Report a bug forum that may eventually form other bug friends This would be a great opportunity for Mageia to teach reporters how to use bugzilla. IMHO, this would still be a simple way of dealing with normal users who do not want to involve themselves any more than reporting a bug. And for those who develop a taste for furthering their knowledge of the process of bug reporting, the bug friend could then mentor this person ... who could eventually become a bug friend himself/herself. Marc
Re: [Mageia-dev] How will be the realese cycle?
Le 2010-10-16 16:08, Frederic Janssens a écrit : On Sat, Oct 16, 2010 at 21:52, Renaud MICHEL r.h.michel+mag...@gmail.com mailto:r.h.michel%2bmag...@gmail.com wrote: I think it may work if those bug friends (don't remember who proposed that name) only take for themselves the simple, one package, software only bugs, and suggest to the reporter to create himself a bugreport (eventually providing assistance if the reporter has never done it before) yes, it is mainly there that 'help with followup' is needed. If that help is well done, a certain number of the helped could become helpers later on. describing his problem, because the devs will really need his feedback first hand. That forum would be an easier entry point than bugzilla for users not familiar with bugreports. -- Renaud Michel Frederic Thanks Frederic, my feeling also. Marc
Re: [Mageia-dev] How will be the realese cycle?
Le 2010-10-16 18:35, Romain d'Alverny a écrit : On Sat, Oct 16, 2010 at 21:29, Marc Parém...@marcpare.com wrote: Le 2010-10-16 12:36, Ahmad Samir a écrit : It's much better to help the user formulate a useful bug report, that's easier / more productive for all involved parties. There would be no middle man. Once the middle-man could replicate the bug and verify the bug with other users, then the middle-man would submit to bugzilla. That's it. From there on, the middle-man will take care of testing requests from devs. As far as reporting back to the original user who reported the bug, as an extra gesture of kindness, the middle-man would just post on the Report a bug forum that the bug has been quashed or is still under review ... but not to the user but to the Report a bug forum. The idea is to keep the flow of possible bug reports coming in an organised way. The middle-man would have to be someone with a little more experience than that of a new user and also someone who has an interest in working this way. We will get more bug reports from users by keeping it simple and easy. Yes, and for everyone. I tend to agree with Ahmad, as well as with you. You may as well imagine we improve the Bugzilla process with a front-process, guiding the reporter about her bug report. That may be a forum with people active there, educating the user about the bug and the reporting process; And/or that may be a better designed bug reporting process with a better flow (providing and getting info to/from the user), querying a knowledge-base, filtering known/resolved queries out of yet-another-duplicate-bug-report and ultimately opening a bug in Bugzilla with a specific interaction to the user (so she knows what happens next).* That removes the middle-man issue and that filters out as well people that are not concerned enough to report/follow-up on a bug (provided the process is, indeed, better designed and better welcomes the end user). * moreover, I believe this type of improvement would benefit many, many, if not all, projects using a bug report tool. Cheers, Romain Thanks for the note Romain. I think what this all boils down to is, does the Mageia project want to actively seek out bugs and encourage its users to report bugs? If Mageia is interested in seriously quashing bugs, then the reporting process has to be streamlined in such a way as to encourage the reporting of bug as painlessly as possible for users. Human nature being what it is, people will gladly report a bug if there is a way to do so quickly and easily. However, it gets more complicated if you ask users to follow up on their bug report, as in bugzilla. IMHO, it would be easier if Mageia offered users: -- The reporting of bugs through bugzilla as is usually done, and the devs can work out these problems with the normal messaging that normally goes along with the bugzilla process. -- For users who have no intention of being part of bugzilla and who would still like to report a bug, a forum discussion where a middle man or bug facilitator would help triage the bugs in this forum, verify the bug and then submit it in their name. The user would not be obligated from this point on to involve herself with the testing of possible bug repairs. The bug facilitator would be obligated to the usual bugzilla process. Of course if the user wished to learn more and participate in the bugzilla process, then the bug-facilitator could help mentor the user to the bugzilla process. This way the user would have 2 methods of reporting, one with a certain amount of commitment and the other with no commitments other than reporting and doing a quick verification with the help of the bug facilitator. The devs would not be part of this process and would work through the bugzilla as usual. And the bug reporting would, IMOH, be more streamlined. Marc
Re: [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc
Le 2010-10-15 07:42, Wolfgang Bornath a écrit : 2010/10/15 Anssi Hannulaanssi.hann...@iki.fi: Seems sensible to ask the mirror owners. It is possible some of them have not been aware of the problem at all, so I think we should make sure they understand that Ubuntu, Debian, Arch, etc. also contain patented technologies (to avoid the situation where they are willing to mirror Ubuntu/Debian/Arch but not allow patented software in Mageia, just because the other distributions didn't notify them of the issue; if they don't want to mirror Mageia if it contained patent-encumbered software, they really shouldn't be mirroring those other distributions either). As mirror maintainer/owner of Mandriva Linux and future Mageia (ftp.mandrivauser.de) I discussed this problem with my friends and we decided not to mirror PLF although a German university does (ftp.gwdg.de). The point is that our mirror is hosted on a private server where just one person is liable (me, unfortunately). But we also decided to mirror the non-free branch of Mandriva Linux. There is non-free and there is patented and/or legally unclear software - we will definitely stay away from the latter when mirroring Mageia. Making a difference between such software on the parent mirror will make it easy for mirrors such as ours. Distributing such software in the same branches as normal software will make it impossible to mirror Mageia. Thanks for the post Wobo. You are the first response to this discussion that has shown a real life / concrete example of the concern that one has to consider when mirroring packages. I really think that this thread is leading nowhere and it obviously needs to be discussed with the main devs and Mageia core group along with individuals knowledgeable in international law, if we want to set things straight right from the start. Marc
Re: [Mageia-dev] How will be the realese cycle?
Le 2010-10-14 09:08, Sinner from the Prairy a écrit : Marc Paré wrote: Thanks for posting the site Tux99. There was talk of more user groups doing the poll/survey. Does anyone know if this is being done? Great data for the devs to consider. Marc This in the Spanish-speaking Mandriva community BlogDrake: http://blogdrake.net/encuesta/que-tipo-de-ciclo-de-releases-deberia-tener- mageia In case the URL gets cut, here it is shortened with Bit.ly: http://bit.ly/am7Ivg Salut, Sinner Gracias Sinner: Is it me or is the poll different? The overall feeling on the Spanish Blogdrake is to like Mandriva a stable system with upgrades and backports at 58%. I imagine this means keeping to Mandriva release cycle with no changes. Wouldn't it make sense to have the same poll? I guess, this way we still get the results of a poll and a sense of the community feeling anyway. Marc
Re: [Mageia-dev] How will be the realese cycle?
Le 2010-10-14 09:57, Tux99 a écrit : Quote: marc wrote on Thu, 14 October 2010 15:49 Is it me or is the poll different? The overall feeling on the Spanish Blogdrake is to like Mandriva a stable system with upgrades and backports at 58%. I imagine this means keeping to Mandriva release cycle with no changes. Wouldn't it make sense to have the same poll? I guess, this way we still get the results of a poll and a sense of the community feeling anyway. I guess the old rule of polls applies: depending on how you formulate the poll question and the description of the options you can hugely influence the results... Personally I think a poll without educating everyone about what exactly each choice would mean is useless. We first need to elaborate detailed alternatives before anyone can make an informed choice. I agree. However, I would view these polls as both a way to inform people and a short measure of what the community members think at this point. It does hold a little value. I am not sure if we all really understand the meaning behind rolling distro, but the polls still do give a little value at this point in time. If we are going to poll communities, the community leaders should really get together and decide on the process and questions so that the information collected is valuable. But Ok, this way we still get a little data to look at. Marc
Re: [Mageia-dev] How will be the realese cycle?
Le 2010-10-14 09:53, Tux99 a écrit : Just to add to my last post: It would be useful if users could disable specifc packages from being updated via the update GUI. What I mean is basically when new updates get presented (which would include new backports) the user could untick specific packages (as is possible now) but also have a second tick-box to store the choice permanently in the skip.list. This would give the user more choice of which packages he wants to always update to the newest version and wich ones he/she prefers to keep frozen at the same version. This is a great idea. Someone should make a note of it. Marc
Re: [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc
Le 2010-10-14 11:02, Anssi Hannula a écrit : On Wednesday 13 October 2010 14:29:14 Marc Paré wrote: Le 2010-10-13 14:23, Michael Scherer a écrit : Le mercredi 13 octobre 2010 à 20:06 +0200, Olivier Méjean a écrit : Le mercredi 13 octobre 2010 19:31:44, Michael Scherer a écrit : Le mardi 12 octobre 2010 à 17:53 +0200, Olivier Méjean a écrit : == And DVDCSS, etc? What's in etc ? However, here in France we have a law Dadvsi on which the Conseil Constitutionnel (something like American Suprem Court) has statuted that the law could not prevent exception of decompilation and the exception of circumvention of DRM if this is for interoperability. In other words the use of libdvdcss is allowed for interoperability. So for me, Mageia can come with libdvdcss and other tools for interoperability And for the people hosting mirrors outside of France ? It's their own responsability, no one force them, and some in the world take the responsability to host mirrors with questionnable software. Let's give them the liberty to choose as we have the opportunity here in France to ship such software. No one forces several company, university, or other groups to mirror ArchLinux, PCLinuxOS, LinuxMint, PLF So I assume that you volunteer to find another Tier 1 mirror to replace ibiblio.org ? I was actually going to approach a university in Canada this week about mirroring but I think I will wait till this is sorted out. I don't believe I could convince them if they read this thread. They would most definitely have second thoughts. Indeed, as even Debian/Ubuntu do not ship libdvdcss (e.g. arch, gentoo do).. As for patents, Ubuntu already has 4 mirrors in Canadian universities. Yes, Ubuntu is riding a wave of popularism at this point. Their product marketing is working quite well. You find/hear of them constantly. It's something we should be doing as soon as we publish our first solid product. The first release is just testing the infrastructure and product so we still have time to organize. Marc
Re: [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc
Le 2010-10-14 12:08, Ahmad Samir a écrit : On 14 October 2010 17:04, Anssi Hannulaanssi.hann...@iki.fi wrote: On Wednesday 13 October 2010 20:54:45 Dimitrios Glentadakis wrote: About codecs Codeina will be available in Mageia ? I find it very comfortable for new and advanced users. Yes. It is available on Mandriva and I don't see any reason to drop it from Mageia. -- Anssi Hannula But codeina only works with gstreamer based apps IIUC... However, it does lend legitimacy to the distro. I would also vote to keep Codeina both as a useful (if somewhat) source for codecs but also for public relations purposes. This is important from a marketing point of view. Marc
Re: [Mageia-dev] How will be the realese cycle?
Le 2010-10-14 10:56, Sinner from the Prairy a écrit : Tux99 wrote: I guess the old rule of polls applies: depending on how you formulate the poll question and the description of the options you can hugely influence the results... This is so true. I follow the politics blog FiveThirtyEight (warning! statistics nerd alert activated!) and again and again, strange-resulting polls are caused by poorly formulated questions, guided answers or lack of proper options. Personally I think a poll without educating everyone about what exactly each choice would mean is useless. We first need to elaborate detailed alternatives before anyone can make an informed choice. This is mostly what Romain has been asking: someone to provide clear definitions of what Rolling Release is. And why Backports does not work. Salut, Sinner Is there a dedicated mailist for the leaders of the different communities? It would probably make sense to have a closed list for them to coordinate projects such as polls, marketing, sharing of resource materials agreemtns etc. Just a place where they could meet and conference to build consensus on different issues. Does this exist? Do we have a list of all the communities that have come on-board to the project? Marc
Re: [Mageia-dev] How will be the realese cycle?
Le 2010-10-14 10:50, nicolas vigier a écrit : On Thu, 14 Oct 2010, Tux99 wrote: I think they should be enabled by default, since it's my impression that the majority of 'normal' users wants new versions of apps, those users who DON'T want them can still always disable them. If backports repository is enabled by default, it should be stable. How do you garantee that backports will never break ? Backports shouldn't be second choice, it should be the default, since that would make Mageia stand out from other distros as being the distro were users get the latest versions of apps before any other major distro provides them. Just providing the latest version of apps is not enough to stand out from other distros. All distros could do it, and they usually already do it in their developement version. But the problem is always the same: adding new versions create instability. Actually, there is a thread on the Mandriva nntp where the latest CUPS in backports break the install. So we are passing the word to people about this. DO NOT INSTALL THE CUPS backports, it may break your Mdv installation. I think the Backport name should just be changed to a more descriptive name and an info button (bubble or Wiki link) describing its intended use to the users. There is a thread on the Mandriva nntp discussing the use of Backport (I started it) as many users had no idea what it meant or the reason behind it. We (users) are ill-informed of its purpose. But ... I like it, and I think it should stay, but in a renamed form and for all users to use ... maybe also add a user help link on that particular page where users could turn to for help. IMHO, what makes or breaks a distro is the communication and the help users get from their knowledgeable counterparts. Use-help and Documentation should be front and centre to the distro. IMHO, if you have enough experience, then you should be helping out on the user help mailists and user help forums to help out those in need of help. Marc
Re: [Mageia-dev] How will be the realese cycle?
Le 2010-10-14 12:42, Romain d'Alverny a écrit : On Thu, Oct 14, 2010 at 18:32, Marc Parém...@marcpare.com wrote: Is there a dedicated mailist for the leaders of the different communities? It would probably make sense to have a closed list for them to coordinate projects such as polls, marketing, sharing of resource materials agreemtns etc. Just a place where they could meet and conference to build consensus on different issues. Does this exist? Do we have a list of all the communities that have come on-board to the project? You mean, the Mageia Community Council? or something else? We're in the process to setup the Council, but we will need each team to coordinate on its own first (so we're blocked by the mailing-list availability, which should come soon - we've been delayed because of hosting issues). Romain Merci Romain I guess this is it. Ok, work in progress. Do we have an on-going list the different communities published that have joined somewhere on the website? Just curious. Marc
Re: [Mageia-dev] How will be the realese cycle?
Le 2010-10-14 13:05, Tux99 a écrit : On Thu, 14 Oct 2010, Maurice Batey wrote: However, I then found that the new version of VLC had problems with DVD menus, and the new CUPS introduced problems (not just in my installation but at least one other Mandriva user). I would put this down to the fact that currently in Mandriva backports are given little attention by the packagers (as has been mentioned by the Mandriva packagers here themselves). Of course if we make them more central to the Mageia strategy then more care and testing is needed before a backport is pushed out. So I wouldn't consider that a fundamental issue with backports, just a procedural issue. Also personally I would consider CUPS a core app so I wouldn't have included that in backports at all. Yup. That was my comment on the Mandriva news group. If a package affects the core or a large amount of other sofware packages, I, myself, would avoid installing it from the Backports. If the updated CUPS was such a great upgrade, then I would imagine that the Mandriva devs would have included it as a normal update and not a Backport upgrade. Backport is great for VLC, Digikam, Amarok updates. But as Maurice mentioned the VLC didn't have the dvdnav plugin with the upgrade ... so there may be some hiccups from time to time with some of the software upgrades. Marc
Re: [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc
Questions about patents is related to which law applies to Mageia. No answers to which law then no clear policy can be applied. For me, since Mageia.org will lead the project (and will own Mageia trademarks) is located in France, since build system of Mageia will be in France then French law is the law we have to consider for Mageia. Debian runs under SPI organization located in the state of New York, USA, thus is ruled by US Laws. As we keep going round in circles, do we have anyone on-board with firm knowledge on international patent/licence laws in this domain (lawyer)? Should we just check with the FSF.org and they could give us an opinion on this? Maybe someone from the Mageia core group could check behind the scenes with the FSF? If anything, the laws of most countries adhere to the notion that being ignorant of the law is no excuse. If we are to put questionable software on different servers, we should maybe get crystal clear facts on the ramifications of doing so. How did the other distros go about making their decisions? I would check with the MAJOR distros, as this is what Mageia is all about. People all over will clamour for our distro. We are going to be a MAJOR and influential distro. So we should behave this way as well when we are setting up our mirror network. So, it sounds to me, that a core group individual, should, as an official representative of the Mageia project, approach these organisations and FSF to check and to get advice/opinons. Just to make sure. Marc
Re: [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc
Le 2010-10-14 21:55, Wolfgang Bornath a écrit : 2010/10/14 Marc Parém...@marcpare.com: So, it sounds to me, that a core group individual, should, as an official representative of the Mageia project, approach these organisations and FSF to check and to get advice/opinons. Just to make sure. Although I may not speak as an official Mageia rep I will present this issue on the next meeting of our FSFE (FSF Europe) group (I'm a FSFE Fellow). Maybe I can report back some helpful facts to this discussion. Sound good to me. If there is a Megeia core group lurking on this thread, could we delegate this task to Wolfgang or if it more of a pressing matter, someone could speak to the FSF directly for an opinion? Marc
Re: [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc
Le 2010-10-13 10:49, andré a écrit : Tux99 a écrit : On Wed, 13 Oct 2010, [UTF-8] Marc Paré wrote: Le 2010-10-12 22:04, Tux99 a écrit : According to your logic that would mean we can't include ssh, openssl, pgp, and even https support in any browser. Does that seems reasonable to you? You need to face it, it would be impossible to make a distro that is legal in every country of the world and at the same time is of any use to the users. Therefore I don't see the need why we should comply with US patent laws when we don't comply with for example Chinese encryption laws. All of your points are exactly what I am trying to point out and even reinforce my concerns. These are all true. This is why, in my opinion, the Mageia distro should not be installing all of these controversial software packages by default. Are you seriously suggesting Mageia should produce a distro without ssh, openssl and even with all browsers stripped of https support? I can imagine how popular that would be with the majority of users... This would then remove that layer of liability from the Mageia project group. In my opinion, Mageia should be wary in wanting to install a fully functioning distro if this means using software packages that may get it into trouble (Mageia itself). But here lies the mistake in your reasoning. Mageia doesn't have to exclude all those packages, since the only liability Mageia has, is towards the French laws. So the sensible choice is to base the choice of packages to include on French law. It is up to the user to make sure he/she only installs and uses packages that are legal in his/her country. Excuse me if I'm wrong -- but you seem to be arguing at cross purposes. Marc says don't install codecs by default, and Tux99 (and many others) say codecs must be included in the distro so the user can choose to install them. Simple solution - include them in the distro, but not installed by default. Where is the problem ? To make things easier, maybe we should put seriously threatened software in the non-free section ? (I mean software which is *known* to have problems, not those just *rumoured* to have.) In any case, I would certainly avoid excluding useful codecs from the distribution ISOs. By the way, it is not only what is permitted in France, but also what is permitted in the countries where the mirrors are hosted. Here in Canada, there is (no longer) a mirror for Mandriva, so the nearest Mandriva mirrors are in the U.S. A few years back, the U.S. restricted severely encryption, unlike in Canada and most of the rest of the world. So to have normal encryption with Mozilla software, we in Canada had to download Mozilla from Europe, since there were at that time no mirrors for Mozilla in Canada. Luckily the U.S. no longer has such restrictions. Having to download an entire distro from Europe would be much more problematic. So it is useful to consider the laws in likely mirror locations. For North America, Canada is always a good choice :) my 2 cents:) - André (andre999) Yes, all of this would be a fine middle ground in my opinion. Re: Canadian repos -- U. of Sherbrook (Québec, Canada) dropped the Mandriva mirrors for unknown reason (I suspect that the person who had a personal interest in maintaining these just moved on). I was however pleasantly surprised to see that U. of Waterloo offering the Mandriva KDE 4.5.0 updates on their servers. We may be able to convince them to mirror the Mageia project on their servers. I may be able to help as I live in Wateloo (no contacts at the U. of Waterloo though), more at the other university Wilfrid Laurier. Marc
Re: [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc
Le 2010-10-13 13:04, Wolfgang Bornath a écrit : 2010/10/13 Marc Parém...@marcpare.com: Yes, I have always seen this as a communication problem from the Mandriva documentation. However, it did fit the at arm's length legal definition of the installation of these pieces of software. That is to mean that Mandriva, in this case, was not complicit in the installation of that particular software. It was clearly a user decision to install them. +1 It's easy to communicate, it's easy to implement fitting even those dumb users some people are talking about. Yesterday I installed the new Ubuntu 10.10, a window opened near the end of the installation process telling me that my hardware may need/use a non-free driver which is available online. The text explains about the non-free status in simple words and then I was asked if I wanted to activate this non-free driver. The same can be done with all that codec stuff. A window opens, telling the user that he will need some special software to listen to MP3s, watch his commercial DVDs, etc. The text explains in simple words the legal implications which may or may not apply to his country. After that he can decide with a simple mouse click on yes or no or ask later (if he has no working internet connection at that time. If he clicks on activate, the needed software will be downloaded and installed. If he clicks on ask later he will be asked as soon as the script detects a working internet connection. If he has selected No and still tries to open a commecrial DVD (or whatever) the window ill appear again reminding him why he can't play the DVD (or whatever). Face it: we do not have any other choice but leave it at the user's decision. All we can do is make it simple if he chooses to bite the bullet. This sounds like a good alternative also. I like this method too! The user is always in control. This thread is actually good in getting different scenarios of implementing legally grey software packages. Maybe someone will take notes of the different methods that could be used to deliver these type of software packages and then the devs or the higher ups will obviously make the final decision after considering all of these delivery methods. Marc
Re: [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc
Le 2010-10-13 14:23, Michael Scherer a écrit : Le mercredi 13 octobre 2010 à 20:06 +0200, Olivier Méjean a écrit : Le mercredi 13 octobre 2010 19:31:44, Michael Scherer a écrit : Le mardi 12 octobre 2010 à 17:53 +0200, Olivier Méjean a écrit : == And DVDCSS, etc? What's in etc ? However, here in France we have a law Dadvsi on which the Conseil Constitutionnel (something like American Suprem Court) has statuted that the law could not prevent exception of decompilation and the exception of circumvention of DRM if this is for interoperability. In other words the use of libdvdcss is allowed for interoperability. So for me, Mageia can come with libdvdcss and other tools for interoperability And for the people hosting mirrors outside of France ? It's their own responsability, no one force them, and some in the world take the responsability to host mirrors with questionnable software. Let's give them the liberty to choose as we have the opportunity here in France to ship such software. No one forces several company, university, or other groups to mirror ArchLinux, PCLinuxOS, LinuxMint, PLF So I assume that you volunteer to find another Tier 1 mirror to replace ibiblio.org ? I was actually going to approach a university in Canada this week about mirroring but I think I will wait till this is sorted out. I don't believe I could convince them if they read this thread. They would most definitely have second thoughts. Marc
Re: [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc
Le 2010-10-13 14:44, Sinner from the Prairy a écrit : Wolfgang Bornath wrote: It's easy to communicate, it's easy to implement fitting even those dumb users some people are talking about. Yesterday I installed the new Ubuntu 10.10, a window opened near the end of the installation process telling me that my hardware may need/use a non-free driver which is available online. The text explains about the non-free status in simple words and then I was asked if I wanted to activate this non-free driver. The same can be done with all that codec stuff. A window opens, telling the user that he will need some special software to listen to MP3s, watch his commercial DVDs, etc. The text explains in simple words the legal implications which may or may not apply to his country. After that he can decide with a simple mouse click on yes or no or ask later (if he has no working internet connection at that time. If he clicks on activate, the needed software will be downloaded and installed. If he clicks on ask later he will be asked as soon as the script detects a working internet connection. If he has selected No and still tries to open a commecrial DVD (or whatever) the window ill appear again reminding him why he can't play the DVD (or whatever). Face it: we do not have any other choice but leave it at the user's decision. All we can do is make it simple if he chooses to bite the bullet. Wolfgang, Well done. Even I understood that. Mageia, as a foundation, will be separated form legal proceedings by passing the burden of the decision to the end user, as a flexible way of acknowledging that laws are not the same everywhere, and the end-user will (should) be better informed than an automated script of what is allowed and not. And if the end user decides to break the law, it is the end user's responsibility. Salut, Sinner At issue here, in the discussion, was the method of delivery. Wolfgang wrote of the Ubuntu method which seems also fine to me. Having repos where contentious software packages were kept (just like PLF) was another method. Others suggested that Mageia repos should just offer up everything regardless of legal implications. Have I missed any other methods? Marc
Re: [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc
I was actually going to approach a university in Canada this week about mirroring but I think I will wait till this is sorted out. I don't believe I could convince them if they read this thread. They would most definitely have second thoughts. Well, then you can simply be clear with them and ask them to see their boss/lawyers/whatever who can decide. After all, I do not see why no one directly asked to mirror admins first. I am not sure that if I were to approach them and ask, as a favour, to mirror Mageia, to then ask them to check with their lawyers etc., that this would make for a good argument for them or give them too much of a feeling of trust. They would just not want to talk. Marc
Re: [Mageia-dev] How will be the realese cycle?
Le 2010-10-14 00:20, Tux99 a écrit : Quote: Fernando Parra wrote on Thu, 14 October 2010 05:59 Sinner from the Prairy wrote: We should publicize more Backports. And I shall reply over and over again, backports isn't a solution, maybe it's a technical solution, but it isn't The Solution. The end users need to do less than now for to get new versions of their favourites applications. Mageia needs to offer more than other distros, much more, in a different way. If we aren't to be able to make a completely new concept, we are in a serious risk to become in other distro at that sea called GNU / Linux. -- Fernando Parragato2...@yahoo.com.mx I agree with what Fernando says, if we could agree on a release cycle that is half way between the fixed release cycle of Mandriva/Ubuntu/Fedora/Suse and the rolling release cycle of PClinuxOS/Gentoo, then Mageia would attract a lot of interest in the Linux world do to it offering something new and compelling rather than the same as everyone else. The results of the poll on mandrivauser.de seem to indicate a strong wish in this direction too, almost half of the voters voted for an annual release cycle with a partial rolling release cycle, i.e. exactly what was suggested in this thread earlier, a stable core updated once a year (apart from security and bug fixes) with new app versions made available during the whole year. http://www.mandrivauser.de/forum/viewtopic.php?f=188t=29694 Thanks for posting the site Tux99. There was talk of more user groups doing the poll/survey. Does anyone know if this is being done? Great data for the devs to consider. Marc
Re: [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc
Le 2010-10-12 12:21, Lucien-Henry Horvath a écrit : Le 12/10/2010 18:19, Tux99 a écrit : I think Mageia should include as much multimedia codecs as possible, it the user's responsibility to know the laws of his/her country and if necessary uninstall anything unlicensed/illegal in his/her country. Not only multimedia but drivers too ... in my humble personal opinion / wishes. Unfortunately, if this is done, I will no longer be able to install legally any Mageia due to our laws. I think it is best if these are not installed but let users know where to get them, mostly through PLF. When I install Mandriva Free for people, I will let them know where the PLF repos are and the files needed and they install these themselves. If Mageia packages include unlicensed software and codecs, the Mageia brand may be held legally responsible for marketing software in countries where the laws do not permit this. I don't really think would be a wise decision. Marc Canada
Re: [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc
Le 2010-10-12 17:45, Tux99 a écrit : Quote: marc wrote on Tue, 12 October 2010 19:31 The safest route is to offer FOSS software (they are well known and many have had their code audited) and leave the fringe softs on a repo that is left to the users' choice as install. Marc, FOSS has nothing to do with whether a particular software infringes on patents in some countries or not, don't confuse the COPYRIGHT license with patents issues. There is plenty of pure FOSS software that is infringing on some patents (primarily in the US with their free-for-all software patent policy), in fact given the amount of software patents granted in the US I wouldn't be surprised if most FOSS software (actually most software, not just FOSS) infringes some patent in the US (heck, even MS Office just got caught infringing on some patent held by some patent-troll). This starts from the Linux kernel all the way to apps like OOo, there is simply no way to make a distro that is patent-safe according to US laws. Why do you think Canonical is incorporated in the UK and not in the US? Why do you think Novell made the patent-protection agreement with Microsoft? The only major commercial Linux distro that is based in US is Redhat and that's probably only because at the time they were founded the patents issue in the US didn't exist yet (at least not like these days). We cannot base our distro on the ridiculous patents laws of the US, first of all there is no legal reason to do so, and second why should users all around the world suffer US patent laws despite they don't apply to them? Having separate plf repos IS A MAJOR OBSTACLE for new users (and for packagers probably too), first of all because most have no idea that these exist and then even if they find out you need to consider all those users on dialup for whom downloading many megabytes of replacement plf packages is a major problem. So again, I suggest we include all the important codecs and drivers/firmware that help the user to have a great out-of-the-box experience with Mageia, but we add a question during installation so the user can decide if he wants to install them or not. This should keep everybody happy, I don't see why this couldn't be agreeable for you. Hi Tux99: http://www.riaa.com/faq.php http://newteevee.com/2010/05/21/mpeg-la-threatens-googles-vp8-with-patent-pool-license/ http://thresq.hollywoodreporter.com/2010/03/new-litigation-campaign-targets-tens-of-thousands-of-bittorrent-users.html http://www.sevensidedcube.net/biggest-movie-law-suite-ever-hurt-locker/ Hmmm ... let's see now, I started collecting this list at 20.11h and it is now 20:13 and all I did was Google 2010 movie lawsuit; 2010 codec lawsuit; 2010 mp3 lawsuit and the list is realistically longer. If you and others are willing to indemnify Mageia users and installers against any lawsuits due to packaging unlicensed software/codecs/etc , this would go a long way to giving people like myself piece of mind. When packaging an OS distro, we (as a community) should assume that the product that our community devs and distro planners will not in the end be cause of concern. If RedHat is able to maintain corporate headquarters in the US, then I would suggest we examine closely their packaging repos. Mageia touts itself as an international distro. You cannot claim international status if you package a distro that is legal in one country and then illegal in another. Some of the software packages have been reverse engineered to circumvent patent laws while others are still in the grey zone and others are not supposed to be installed due to their legal status. This is why, in my opinion, Mageia should try to steer itself away, as much as possible, from grey and illegal areas and leave it to the end user's choice whether or not to install these packages. There is nothing wrong in also adding the Codeina/Fluendo option for those who would rather use this service. We are trying to build a great package. Why would the Mageia team put in peril its existence and the people's income (through potential expensive lawsuits)? If users decide to use this technology then they put themselves in this position and not the distro. We can let users know of the existence of these questionable pieces of software, there is nothing wrong with this, especially when we offer users a perfectly legal way of gaining use of codecs, libs etc. Whether the users decide to use the legitimate way or the other way is completely up to them and not Mageia's responsibility. Marc
Re: [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc
Le 2010-10-12 22:04, Tux99 a écrit : Marc, just as a further point to reflect on: there are countries in the world were encryption is illegal or severely restricted. According to your logic that would mean we can't include ssh, openssl, pgp, and even https support in any browser. Does that seems reasonable to you? You need to face it, it would be impossible to make a distro that is legal in every country of the world and at the same time is of any use to the users. Therefore I don't see the need why we should comply with US patent laws when we don't comply with for example Chinese encryption laws. The only reasonable choice is do what every other distro does: comply with the laws of the country where the distro is legally based in, in this case France. Regardless of all that, it is ALWAYS the user's (not the distro makers) responsibility to comply with local laws of where the distro is being installed/used. All of your points are exactly what I am trying to point out and even reinforce my concerns. These are all true. This is why, in my opinion, the Mageia distro should not be installing all of these controversial software packages by default. These should be added on after the Mageia official distro and the user would thereafter install further software packages that he/she wished to have to make the distro work as he/she wished. This would then remove that layer of liability from the Mageia project group. In my opinion, Mageia should be wary in wanting to install a fully functioning distro if this means using software packages that may get it into trouble (Mageia itself). Let the user then assume that responsibility/liability. This is where, I consider the easy urpmi served its purpose well. It installed repos where the available software that most users would need was made available, but this again was by user choice. Cheers Marc
Re: [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc
Le 2010-10-13 01:14, Tux99 a écrit : On Wed, 13 Oct 2010, [UTF-8] Marc Paré wrote: Le 2010-10-12 22:04, Tux99 a écrit : According to your logic that would mean we can't include ssh, openssl, pgp, and even https support in any browser. Does that seems reasonable to you? You need to face it, it would be impossible to make a distro that is legal in every country of the world and at the same time is of any use to the users. Therefore I don't see the need why we should comply with US patent laws when we don't comply with for example Chinese encryption laws. All of your points are exactly what I am trying to point out and even reinforce my concerns. These are all true. This is why, in my opinion, the Mageia distro should not be installing all of these controversial software packages by default. Are you seriously suggesting Mageia should produce a distro without ssh, openssl and even with all browsers stripped of https support? I can imagine how popular that would be with the majority of users... This would then remove that layer of liability from the Mageia project group. In my opinion, Mageia should be wary in wanting to install a fully functioning distro if this means using software packages that may get it into trouble (Mageia itself). But here lies the mistake in your reasoning. Mageia doesn't have to exclude all those packages, since the only liability Mageia has, is towards the French laws. So the sensible choice is to base the choice of packages to include on French law. It is up to the user to make sure he/she only installs and uses packages that are legal in his/her country. Obviously running in circles here, I guess we both have our opinions and we let it rest at that. Marc
Re: [Mageia-dev] Release cycle - what is actually POSSIBLE?
Le 2010-10-09 03:57, Margot a écrit : There has been a lengthy debate about users' wishes for the Mageia release cycle, but one important voice has been missing from this debate: the collective voice of the devs who will be responsible for producing the releases. Before we start having polls and surveys, it would be useful to hear from our devs. I'm hoping that they have already been communicating with one another in the background (IRC? private emails?) and working out what can actually be done. As this is supposed to be a community-based distro, why do I think that the devs' opinion is so important? (a) They are the ones with the experience, they know how many person-hours it will take to produce a releasable version of Mageia. (b) They are the ones who know how many hours they each have available to personally commit to Mageia - some may be able to work full-time on Mageia, others will have other work or family commitments, and even those who can work full-time on Mageia will occasionally need to sleep and eat! We have two targets: 1) A cauldron version for experienced users to test, and 2) A stable (as much as possible!) version for less experienced end-users. So, devs, please draw on your experience and your knowledge, and tell us what will actually be possible. Hi Margot: Romain suggested this on one of those lenghty threads: - It has been posted before but I guess it's a good read for anyone willing to push an argument in this debate: http://mairin.wordpress.com/2010/09/01/a-story-about-updates-and-people/ It is a nice post explaining the existing different point of views (bonus to clever points about updates frequency and presentation). Now, in the same vein, let's put the discussion at rest a little and have each interested person write down an article with arguments for the why's and how's. So here is a page for that: http://mageia.org/wiki/doku.php?id=rollingdebate Please write down your point of view, detail it as explained on the wiki page, link it and a week from now, everyone involved in the discussion can have a look at it for a summary. That won't trigger a change decision at once (way too soon anyway, we have to roll a first release to assess our new build system and infrastructure and organisation) but it may at least lay down all arguments and allow to have a better view of what everyone understand, agree on definitions and see what is really at stake here. For later reference, discussion and decision. Thanks a lot. Cheers, Romain - Marc
Re: [Mageia-dev] What do you think about create a Mageia Welcome Center?
Le 2010-10-08 09:46, Florian Hubold a écrit : Am 30.09.2010 12:34, schrieb Olivier Méjean: Le jeudi 30 septembre 2010 12:19:43, Robert Xu a écrit : Is a survey necessary ? It's not really necessary. For example, in mandriva my laptop had no internet when booting the first time, as my wireless needs a firmware. So i never completed the survey, and as it only started on the first boot, mandriva never got any real data from me. Maybe when the infrastructure is up and some releases were made, this can be discussed again. For these installations, there could be a case made for preparing an initial form, with the users consent of course, that could be transmitted later, again with user knowledge and consent. It is still to Mageia's advantage, both from a development point of view and marketing point of view, to be aware of the instances of installations. It doesn't have to be an accurate amount, for that matter, it could be an approximation of the amount of installations. This could also be done at the point of download monitoring, as suggested elsewhere, with unique IP's being taken into account. I am more in favour of doing both, but more interested of the at installation and filling a short survey for Mageia stat purposes. This is a more concrete way measuring user participation in the project. Marc
Re: [Mageia-dev] Proposal: Updating released versions (long post)
Le 2010-10-08 16:32, Frank Griffin a écrit : Marc Paré wrote: So, in terms of space used for this, if you had to install all 6, would this tax the system so much and risk filling up the hardrive needlessly. Not really, since the old versions would be removed when the new ones were installed. The behavior I described is not part of the proposal; that's what happens today. It not, if a rollback were done, could all 6 as well as the new F be removed and the old version restored? Yes, that's exactly what happens today.The problem is that today, removing them may cause tons of other packages to have to be removed because they require things that A-F provide. This wasn't a problem on upgrade, because the removal of the old and the addition of the new was a single urpmi transaction (I put this in quotes because urpmi uses transaction to mean something other than what I mean here), and urpmi knew that the new versions supplied all the things that vanished when the old versions were removed. Today, rollbacks have to be done manually - remove new, then install old. Urpmi doesn't know at the time of the removal that you're going to turn around and install the old versions next. It only sees that all the things that both the old and new versions supply are about to disappear from your system, so it tells you that you have to remove any other package which requires those things. If this is possible, would this have an impact on devs preparing Backport versions with rollbacks? RPM dependencies aren't a problem. Urpmi/urpme know all about them. The only packaging changes would be for situations like that where a new version of an application has changed a format of one of its files in your home directory and the new version automatically converts the old version of the file to the new format. In that case, the package would need install scriptlets that copied the old version somewhere so that it could be restored at uninstall time, otherwise the old version of the software won't be able to use the new file format. The biggest chunk of development involved in the proposal is to make urpmi do a rollback as a single operation, just as it does an upgrade. This already exists, in a way; there is a facility called urpmi.recover that does this type of thing. Bit it's not really considered mainstream, and I don't think it's been supported for a while. Thanks. So this thread is to see if there were a possibility to programme a more efficient roll-back option so that it would be more aware of the previous dependencies needs for the previous version. Having double dependencies is not so much of a problem, it is the rollback to a previous version where the dependency confusion may occur, and, ONLY, if an upgraded type of dependency thread had been installed. (Sorry I may have used the wrong terms in the last sentence). Marc
Re: [Mageia-dev] Proposal: Updating released versions (long post)
Le 2010-10-08 23:45, andré a écrit : Frank Griffin a écrit : Marc Paré wrote: Thanks. So this thread is to see if there were a possibility to programme a more efficient roll-back option so that it would be more aware of the previous dependencies needs for the previous version. Having double dependencies is not so much of a problem, it is the rollback to a previous version where the dependency confusion may occur, and, ONLY, if an upgraded type of dependency thread had been installed. (Sorry I may have used the wrong terms in the last sentence). Well, sort of. It's not an issue of efficiency, but of convenience and just making it possible to do without resorting to manual use of the rpm command. The rpm command knows that a new version replacing the old version supplies the same things that the old one did, so it will quietly allow the upgrade. It will also do what we need, i.e. go the other way and replace a newer version with an older one if you use the --oldpackage keyword. We just need urpmi to support its use One thing that could facilitate this process, if the computer has a lot of free disk space, is to rename the files being removed (copying the configuration files), instead of erasing them. Although they will probably have to be erased eventually, since no computer has unlimited disk space. Keeping them long enough that a roll-back is no longer probable could be workable. Then a roll-back could be done very quickly, since the files are already on disk, and presumably reliably. Of course, if new data has been entered, and the format has been changed, this could be problematic. Note that configuration files that have been changed from the installation default are often already saved. (Generally .old is appended to the configuration file name, sometimes .new to the new configuration file.) This of course adds the maintenance task of removing the old files at some point - it could be done automatically according to some criteria, or the user could have to do it manually, perhaps after being prompted about it. (This rollback capability occurs with Microsoft products. The saved files are only removed manually, on user initiative, which partly explains the bloated size of a Microsoft installation over time.) If renaming-instead-of-deleting is implemented, perhaps a do not keep old program files (useful if limited disk space) checkbox option would be useful for computers with less free disk space. Of course how much disk space is usable to save old programs on a computer depends on the disk space usage for other purposes over time. my 2 cents :) - André (andre999) Not sure about this process. Instead of making it easier for a user, this would now make it more difficult to do and add another layer of knowledge for the new user. It would have to be a little more seamless than this. If there were a way at setup to establish the amount of remaining disk space at installation time, and if there were enough space to allow rollbacks without compromising the installation, then I guess the rollback could then be activated. The user could then be advised at this point that this was activated. If there was not enought disk space, a message could warn the user that software rollbacks would not be possible for lack lack of diskspace. I guess then, in the MCC, if a user used the Backports and installed backported software, the rollback amount of diskspace could also be monitored at this level with perhaps an option to delete old programs that are now working well in their updated form. I guess this would take a bit of coding. But at least the use of Backports would make a little more sense with a rollback option in case an updated software installation did not work out. Marc
Re: [Mageia-dev] How will be the realese cycle?
Le 2010-10-07 04:55, Romain d'Alverny a écrit : On Thu, Oct 7, 2010 at 07:34, Gustavo Giampaoli giampaoli.gust...@gmail.com wrote: Could it be possible to use the same schema that Mandriva use + one LTS with three years of support? Regular releases every six months with 18 month support. But we could include this kind of LTS with 36 month. Difference with Ubuntu will be that our LTS will be launched only after the previous LTS ends its cycle. Something like this: http://img819.imageshack.us/i/mageiareleases.jpg/ My doubt is will Magea community be able to handle the support for four releases at the same time in semesters when it happen? If you add the LTS, should regular release support be reduced to 12 months? This way, you'll never have more than 3 releases alive at the same time. Gustavo Giampaoli (aka tavillo1980) It has been posted before but I guess it's a good read for anyone willing to push an argument in this debate: http://mairin.wordpress.com/2010/09/01/a-story-about-updates-and-people/ It is a nice post explaining the existing different point of views (bonus to clever points about updates frequency and presentation). Now, in the same vein, let's put the discussion at rest a little and have each interested person write down an article with arguments for the why's and how's. So here is a page for that: http://mageia.org/wiki/doku.php?id=rollingdebate Please write down your point of view, detail it as explained on the wiki page, link it and a week from now, everyone involved in the discussion can have a look at it for a summary. That won't trigger a change decision at once (way too soon anyway, we have to roll a first release to assess our new build system and infrastructure and organisation) but it may at least lay down all arguments and allow to have a better view of what everyone understand, agree on definitions and see what is really at stake here. For later reference, discussion and decision. Thanks a lot. Cheers, Romain Merci Romain: This should help a lot. So perhaps a return to this discussion later (a a new thread!), with a reference to the wiki page for devs and users alike? Then Mageia will get a better feel for what is the hoped expectation from the devs and users? If people in the new thread were to argue a statement, we could then offer them the http://mageia.org/wiki/doku.php?id=rollingdebate page as reference. Sounds great! Marc
Re: [Mageia-dev] How will be the realese cycle?
Le 2010-10-07 07:23, Olivier Méjean a écrit : Le jeudi 7 octobre 2010 13:00:21, Marc Paré a écrit : I would challenge people to find a regular user who knew what the Backport option was for, you may find some but clearly, they would be in the minority. Otherwise, it would have been used quite extensively by users. This is exactly what a user is usually interested in updating his/her installation. Backport was a media added for Mandriva 2007 in order to provide latest versions of software. However, backport rpms were (and are) not officially supported by Mandriva on the contrary of rpms in main (either /main/release or /main/updates) That make sense for a company based distribution to operate such a discrimination, i am not sure that we have to follow such a way in a community-driven distribution. Olivier I have to say though, that after having browsed through the Mdv2010.1 backports by hand, there is a lot, from a user point of view, that would interest users. All of the sexy upgrades to software are there. I think it would be nice to keep as long as it didn't cause major problems with the installation. Maybe an option to roll-back a software update would be something to consider for users? Marc
Re: [Mageia-dev] How will be the realese cycle?
To make it clearer, if the user wants to install oo-base at a later point with the currend Mdv model he would have to download 20MB if there has been no security updates since release, or 70MB if there has been a security update in the meantime. FYI, there is currently a discussion on the LibO discussion list this very point. You may want to join in and have a say. There is talk of an incremental update or other methods. They are on Gmane too! Marc
Re: [Mageia-dev] How will be the realese cycle?
Personally as a future Mageia packager I will try to concentrate on making backports (apart from maintaining some specific packages) so in a way I will be helping to make Mageia in practice a sort of 'light' rolling distro as suggested by a few people in this thread. But I just want to say that based on my experience spending time since many years on several Linux forums (not specifically Mandriva ones), I can say for sure that the majority of 'normal' (non-geeks) users FEAR AND EVEN HATE distro upgrades, they just want to be able to install new versions of apps, not risky complete distro upgrades. I can vouch for this as well. I help maintain 30-40 Mdv setups that I volunteer to do on my spare time. They are all mostly up to date, only about another 10-15 more to update to Mdv2010.1 -- Mageia soon. For most regular users, a distro upgrade is pretty scary. I usually have to do a lot of hand holding while we go through it and later over the phone. They usually, want someone with installation experience nearby. As for updating packages, in my experience, they will do it quite willingly. They actually look forward to updating to a new version of their favourite software -- the regulars seem to be Firefox, Thunderbird, Digikam (most are using Digikam), Amarok, OpenOffice. So a one year release cycle with lots of app backports (and maybe a kernel backport mid-cycle if there is important new hardware support) is IMHO the best release cycle for 'normal' users. I agree with this too. Most of the people I help will actually tell me to forget about the 2 distro upgrade during the year as it is just too much for them to worry about. I have moved most of them to a yearly upgrade and only do it on the spring editions. They tend to be the bug-fixed versions and lead to fewer phone calls for trouble-shooting. Even then, some would rather stick with their version over the span of 2 years. BTW, a couple of these people have gone on to downloading ISO and upgrading themselves (I've made up an installation form for them to help them out). I have been doing this since Mdv2007. Marc
Re: [Mageia-dev] Identifying Target Markets
Selecting an Education based install (which could be used with other software selections is what I had in mind. This could be called the Education software group (for want of a better name). Like that you don't need a special Education version, it's the same DVD for everyone. Of course, the necessary education software has to be on the DVD. An excellent way to promote Mageia. In fact, using a common DVD, students could take a copy home, and install as well, the young family and/or home office software groups. (Which would necessarily overlap to some extent.) That would work nicely. There is really no need for separate CD's seeing that many of the software packages would be complementary from one type of install to the next. The only problem that I would see in doing such a promotion is that this type of usage would require a server/client solution. This is where the choice of server partnership would become important. RehHat and Suse are well-known servers options in the business world. We could then partner up with them and make sure that Mageia/RedHat or Mageia/Suse solutions are rock solid. Unless we seek a partnership with MandrivaLinux server, but in North American markets, Mandriva is really not a force to contend with and is not really known. Marc Since we're in Canada, Mageia/RedHat and Mageia/Suse make sense due to the greater North American presence, but Mandriva server is a major player in the European and South American markets. The advantage of using Mandriva server in Canada is English/French in the education system in every province. Like I've already said elsewhere, I'd like to see some accommodation with Mandriva for the commercial/server side. In any case, we could always offer a choice of servers. RedHat, Suse, and Mandriva all use compatible RPM packaging. André (andre999) Yes, so I guess if there were different options of installations it would be a good start. Marc
Re: [Mageia-dev] Identifying Target Markets
Le 2010-10-06 17:27, andré a écrit : Hoyt Duff a écrit : On Wed, Oct 6, 2010 at 3:11 PM, andréand...@laposte.net wrote: So far in simplified terms, for the education target, we have focus on school boards in US/Canada and Australia/New Zealand; focus on regional gov'ts in Germany. Here I mean focus in terms of promotion, not in terms of the content of the DVD. Do you have a link to any Mandriva docs that detail how the package lists for different targets can be created and implemented? In short, it would be part of creating the installation DVD. Mandriva does not implement this function in a manner useful to our purposes. Let me explain. There would be a number of install groups, (for want of a better expression), all on the same DVD. Each group will have a list of packages to be installed, which could be individually selected/deselected as desired. This is similar to what is already available on a Mandriva install DVD, with an important difference : install groups would not be mutually exclusive. In other words, the education group (targeting school needs), the young family group (targeting families with young children), and the home office group, would probably all contain, for example, a version of OpenOffice (be it Go-oo, LibreOffice, or the officiel OpenOffice from Oracle/Sun). Currently, on a Mandriva installation DVD, each application is in only one group.(Server being one of their groups.) Overlapping installation groups allows us to target many uses on the same DVD. We could consider a target as a usage focus. Many users would have more than one focus -- for example, developers would want various development tools, as well as maybe home office if they are an independant consultant. There also could be a multi-level tree. A global group for developers, with a sub-group for packagers (RPM tools), another for C/C++, another for Perl, etc. Or for a potentially more common theme, a global group for education, with sub-groups for pre-school/kindergarten, elementary, secondary, post-secondary. And these various subgroups would almost necessarily have overlaps. The possibilities are only limited by our collective imaginations. The more I think of this, I see an advantage of allowing the DVD installer to access an external group file, (on a usb memory key for example), for more flexibility on installation. Especially useful to install the same software selection on a large number of computers -- without creating a custom installation DVD. Think of the potential :) - André (andre999) Actually, Mandriva did do this, but on a smaller scale, when installing the ISO you got the the choice of desktop KDE, GNOME or personalized (http://wiki.mandriva.com/fr/Installer_Mandriva_Free#Choix_du_bureau). In the personalized section, you could still choose (in my case) the KDE but also any other distro type of pick that you wanted. It would make sense to offer the choices here. For example Gamer; Business; Music; Video; Education etc. The users could, at this point, tailor the installation to one that would suit them best according to their needs. All on one DVD! No need to have multiple type of DVD's. This would be simple enough. Marc
Re: [Mageia-dev] How will be the realese cycle?
Hi all. At this time, there is a survey asking to the blogdrake's community what kind of release cycle they prefer. This survey will be active until the weekend and I think this could be an acceptable look about community preferences. We must keep on mind we're creating a user-oriented distro, so we must be stay in touch about their preferences. Cheers Where is the survey? Marc Sorry, the word is poll :P Blogdrake is the mandriva's oficial spanish-spoken forum. You can find the poll at the frontpage: http://blogdrake.net Thanks. And for those of you who can not speak Spanish, you can use the Google website translate service to read the website. Here is the site translated live from Spa-Eng (you can have it translated into any language with this service) http://translate.google.com/translate?hl=frsl=estl=enu=http%3A%2F%2Fblogdrake.net%2F Salud! Cheers Marc
Re: [Mageia-dev] How will be the realese cycle?
Le 2010-10-06 20:02, vfmBOFH a écrit : 2010/10/7 Marc Paré m...@marcpare.com mailto:m...@marcpare.com Le 2010-10-06 17:10, vfmBOFH a écrit : 2010/10/1 atilla ontas tarakbu...@gmail.com mailto:tarakbu...@gmail.com mailto:tarakbu...@gmail.com mailto:tarakbu...@gmail.com I'm just wondering if we follow Mandriva's release cycle model. Every 6th months a release or one year and one release. I think we should make one release in one year. By doing so devs and translators won't be in rush in every 6 months. Also there are major changes like systemd/upstart; those system related things will be more mature in a year to use. It makes the distro more stable and decraese mirrors space waste. One more thing. Do we follow Mandriva's release naming scheme? I.e. do we call our first release 2011.x ? I don't like this naming scheme and suggesting using number of release as naming like Mageia 1.0 or using code names. What's your opinion? Hi all. At this time, there is a survey asking to the blogdrake's community what kind of release cycle they prefer. This survey will be active until the weekend and I think this could be an acceptable look about community preferences. We must keep on mind we're creating a user-oriented distro, so we must be stay in touch about their preferences. Cheers Where is the survey? Marc Sorry, the word is poll :P Blogdrake is the mandriva's oficial spanish-spoken forum. You can find the poll at the frontpage: http://blogdrake.net IMHO, I think such a poll could be mis-leading as it supposes that users will have experienced rolling releases, light rolling release, LTS and the Mandriva update/upgrade. If enough people vote, the vote will show the Mandriva way as being preferred as, again, most users do not have that much experience in different upgrade/update methods. It will be a closer result if fewer people take part in it. I think the distro dev's would be in a better position to explain the pro's and con's of these different types and explain to we users the amount of work/development time needed to maintain these. Marc
Re: [Mageia-dev] How will be the realese cycle?
school/university labs... etc. And even for personal use, not many would appreciate having to do an unanticipated reinstall or restore from backup. Particularly those who want to avoid upgrading their distro every 6 months. ;) Rolling distro, anyone ? - André (andre999) Romain suggest an article describing the pro's and con's of all methods as we seem to be going around in circles. Then there would be a clearer picture as to our options. Marc
Re: [Mageia-dev] Identifying Target Markets
Targeting the school boards makes a lot of sense. Note that Openoffice targeted various gov't organisations in France, some of which ended up migrating to Mandriva as well. Maybe that could work with school boards as well. I'm tempted to try something like that with mine, in banlieue of Montréal. Just out of curiosity, what is your school board ? For the server, if Mandriva management were a little more reasonable, it would be good to partner with them. (I'd like to see something like RedHat/Fedora.) In any case, you can't go wrong with RedHat. André (andre999) Bonjour André: As an example, the official word from the Ontario Ministry of Education is that if users cannot afford the use of MSOffice, that we are allowed to promote the use of StarOffice. Here is the official link: http://www.osapac.org/db/view_software.php?id=310 Sun had made arrangements to provide support through their 1-800 ... telephone service (unofficially, they had also said that they would have supported OpenOffice user queries as well, although this policy may have changed after this policy had been posted on the net). There are over 2 million students being taught in Ontario where I teach. Quite a good market to target. You can find the statistics on registered school student numbers here: http://www42.statcan.ca/smr08/2007/smr08_088_2007-eng.htm If we were to commit to an Education based install (this could be done at the point of installation where you could tag the type of distro that you would want installed) with SOLID alternatives for the most common software packages used in educational institutions, then we could make a convincing case for the installation of Mageia desktops in schools. Most governmental agencies today are sensitive to ways of cutting down on expenses. The only problem that I would see in doing such a promotion is that this type of usage would require a server/client solution. This is where the choice of server partnership would become important. RehHat and Suse are well-known servers options in the business world. We could then partner up with them and make sure that Mageia/RedHat or Mageia/Suse solutions are rock solid. Unless we seek a partnership with MandrivaLinux server, but in North American markets, Mandriva is really not a force to contend with and is not really known. Marc
Re: [Mageia-dev] Identifying Target Markets
Le 2010-10-03 02:34, Wolfgang Bornath a écrit : 2010/10/3 andréand...@laposte.net: Targeting the school boards makes a lot of sense. Again this is something you can not generalize, different countries have different structures. In Germany it is not a school board who decides what software will be bought for a certain region or school. This is decided on state level for the various states of the federal republic. You have to go to some state office and compete with the reps of Microsoft. You do not talk to parents or teachers, it's some bureaucrats who decide this over here (with very few exceptions). Same with many other countries. This school board system as in the US is not a world wide system. I can't speak for André (he sounds like he is Canadian), but I am not a US citizen, I am Canadian. Our school system and software purchase models are the same as you describe. However, we do consult with school boards and interested partners before acquiring software licences. I am sure, the German states would consult with their partners before doing such as well. We have provinces in Canada and, as you say, in Germany you have states -- same hierarchy but with different names. As far as I know, the American model is more of a federalist model and consultation/coordination is done mostly from a national point of view. I am sure someone on the list will straighten us out on this account. We shouldn't assume that, if people describe a different system on this ML, that they are therefore American citizen who are trying to impose it on everyone. I just assume that we are all Canadians on the list (chuckles). Marc
Re: [Mageia-dev] Identifying Target Markets
Le 2010-10-03 04:34, Wolfgang Bornath a écrit : 2010/10/3 Marc Parém...@marcpare.com: I can't speak for André (he sounds like he is Canadian), but I am not a US citizen, I am Canadian. Our school system and software purchase models are the same as you describe. However, we do consult with school boards and interested partners before acquiring software licences. I am sure, the German states would consult with their partners before doing such as well Unfortunately they do not. There have been lots of discussions but especially the hierarchy concerning education is very tight over here. All decisions are political decisions, not primarily based on technics or facts but on the political programs. SIngle schools or parents or students are not involved in such decisions. wobo It is strange that parents, teachers and even students would not have a say. How can there be an acquisition and amortization period for your software programmes if you do not consult with your partners? I do not know of any system where it would survive without input from groups using the software/hardware. Otherwise, people would simply not use the software that was dictated to them and the politicians would then have to try to rationalize the reasons why they spent the $ for software that nobody uses. There must be a consultative process otherwise your educational system would have complained for sure. In Canada, and in my province of Ontario, we are even mandated to get input from our students. We all have a say. That is not to say that there is no political involvement, but even so, voices of all ages are heard and reported back to the people in charge of planning and purchases. Marc
Re: [Mageia-dev] Talk of Browsers
Majority of users do not want choice. Those of us who want choice are knowledgeable enough to find out how to install $AlternativeSoftware. Salut, Sinner I agree with this statement. Human nature, being what it is, will always look for the shortest and easiest route. Marc
Re: [Mageia-dev] About Mandriva tools future : Host Mandriva tools on github
Le 2010-10-01 06:38, Fabrice Facorat a écrit : I've been following closely all the Mandriva vs Mageia story. I found it unfortunate that we have to come to this way, but I guess there's a serious fracture between Mandriva and part of its community. We have no choice except to cope with this and try to do our best to allow this unfortunate situation to found a sensible solution in the future. As we know, one of the Mandriva strenght are the Mandriva tools, however Mandriva tools have some issues : - they are written in perl. Sorry for perl dev, but I do still think that perl is harder to understand than C-like based syntax langages. However we must admit that we are not going to rewrite all the Mandriva tools ;-) However better documentation ( PerlDoc tags ) could help a little. - Mandriva tools are not used by others distributions ( except PCLinuxOS, United Linux, and ... Mageia ) and so have few external contributions : They notably lack visibility. I do think also that Mandriva will have to use its ressources in an efficient way. Here aree my proposals, feel free to discuss : 1. host Mandriva tools on github or code.google.com. This will ease fork maintenance and tracking, to contribute back ( without having to have a Mandriva account ) 2. Make some decisions about the tools we should keep, and the ones we should ... trash. For example we did replace printerdrake with system-config-printer ( python ), and msec have been rewritten ( python ). Whereas I do think that system-config-printer is way buggier than printerdrake, I guess that at some points, we will have to do this more and more : replace some Mandriva tools with for example some Fedora ones. Please note however that this bring its own issues : python vs perl, and the integration with the rest of Mandriva infrastructure 3. A decision will have to be made concerning net_applet and NetworkManager 4. Whereas I do love rpmdrake, I do think also that something will have to be done about it as its UI is clearly outdated and not on par with the competition : - Ubuntu software center : http://seilo.geekyogre.com/2010/09/software-center-with-a-dose-of-zeitgeist-and-maybe-teamgeist/ , http://en.wikipedia.org/wiki/Ubuntu_Software_Center , https://wiki.ubuntu.com/SoftwareCenter - iTunes App Store : http://www.askdavetaylor.com/how_to_download_iphone_apps_from_apple_itunes_store.html , http://cybernetnews.com/download-iphone-firmware-20-itunes-77-app-store-and-more/ - Interesting discussion about PackageKit direction : http://mairin.wordpress.com/2010/09/01/a-story-about-updates-and-people/ So we may have to completely rewrite rpmdrake UI or switch to packagekit with and urpmi backend. 5. Junior tasks contributions. I noticed while visiting the LibreOffice website. They have junior task for people willing to contribute to the codebase, and most of theses junior tasks consist to improve code clarity, fix comments. I guess that the same thing could be done with Mandriva tools, notably adding perldoc tags/comments. Last but not least, I know that on Mageia ML, there was a discussion about the people we should target. Here are some interesting reflexions : Sweet Caroline : http://mairin.wordpress.com/2010/09/02/sweet-caroline/ fedoraproject.org redesign update : http://mairin.wordpress.com/2010/09/03/fedoraproject-org-redesign-update/ You must be this tall to ride: __ : http://mairin.wordpress.com/2010/10/01/you-must-be-this-tall-to-ride-__/ Thanks for your observations Fabrice. Just speaking from the user point of view. Let us not lose sight that one of the strong points of Mandriva/Mageia is the use of the MCC. Having all the controls under one title and well integrated is what really distinguishes Mandriva from the other distros. Practically in all of the news items that I have read of Mandriva, they mention the powerful tools at the users' disposal to help in configure/maintain the Mandriva distro, and this type of comment has been going on for years. I hope that Mageia would not stray from this tool. Whichever way the devs decide to programme the tools from the back-en does not matter to the user. How easily it is to configure/maintain the distro is what counts to the user and it is quite a strong selling point. When I help out people with their Mandriva setup and I tell them to go to their MCC (if they are not familiar with it, I usually say You know, the blue sceen and red wrench thingy at the bottom of your monitor., they are confortable in using it. The only thing that I find lacking for the MCC is the lack of immediate help. If a user has never used a section of MCC, they will normally abandon the use of that section. But if there were a help button that would explain, in a graphic way (either video or by slide show) the use of that section, then that would go a long way in helping out. I sincerely hope that the MCC (Mageia Contol Centre) will not be abandoned. Marc
Re: [Mageia-dev] About Mandriva tools future : Host Mandriva tools on github
Le 2010-10-01 07:23, Tux99 a écrit : On Fri, 1 Oct 2010, Fabrice Facorat wrote: This is about making some decisions about some tools. Some of the Mandriva tools have outdate UI, cluttered UI and even are sometimes buggy. The situation persists since many years already, so at some point we should ask ourself : are we going to rewrite them, notably the UI, to make them be more 2010, or should we use another tool with another GUI. Personally I don't see anything wrong with the GUI of the draktools. If imrpoving them means to rewrite them from scratch or replace them with inferior tools from other distros, then that would be a big effort and/or step backwards just for the estetics. Substance counts a lot more than appearance to me. P.S: cc'ing in both cooker and mageia lists is not a good idea as many people are not on both lists so the discussion will just split in two Ooops, Tux99, it also looks like your post has broken the thread on the dev side. The thread probably best belongs on the dev mailist. Marc
Re: [Mageia-dev] Can Firefox be included in Mageia?
Le 2010-09-30 15:55, Anne nicolas a écrit : As a note, I spoke with Pascal Chevrel today from Mozilla Europe. He told me that Debian was going back to use Firefox. Legal issues are solved --- Anne I believe even at the time that Debian had issues with the Firefox brand, that Mozilla didn't really consider it an issue. Mozilla had a harder issues with the Debian re-branding of Firefox. The message they tried to send to the debian community is that there was really not such a big issue over this. Nice to see its fixed as it takes a little work from the dev's to remove the brand out of software and, normally, if you have made it a big deal, then it all has to come out totally. Just imagine the work the Mageia dev's have to go through to remove the Mandriva mention from the distro before working on it. I am sure the debian devs are breathing a sigh of relief and shaking their heads over this one. Marc ___ Mageia-dev mailing list Mageia-dev@mageia.org https://www.mageia.org/mailman/listinfo/mageia-dev
Re: [Mageia-dev] State of the kitchen
Le 2010-09-22 17:49, Anne nicolas a écrit : Hi all News on our messy kitchen available below :) http://blog.mageia.org/?p=18 (other languages coming soon) As you can see work is going on and we are doing everything so that we can start very soon. As a reminder, you can register on http://mageia.org/wiki if you wish to contribute or have a look on http://donation.mageia.org to help Mageia project. Thanks again for your support Cheers! --- Anne Thanks to all at Mageia, looks all great! Marc ___ Mageia-dev mailing list Mageia-dev@mageia.org https://www.mageia.org/mailman/listinfo/mageia-dev
