[Mageia-dev] Push request : scilab
Hi, Please push scilab 5.4.0. Scilab 5.3.3 doesn't built anymore on cauldron. Claire
Re: [Mageia-dev] Packages with changes on svn
Le 09/01/2013 21:23, David Walser a écrit : scilab i'm working on the new version as the old one refuse to pass on BS. but i'll be late for version freeze /o\ python-scikits-learn done. Claire
Re: [Mageia-dev] Packages with changes on svn
Le 10/01/2013 00:32, Guillaume Rousse a écrit : Le 10/01/2013 00:12, Claire Revillet a écrit : Le 09/01/2013 21:23, David Walser a écrit : scilab i'm working on the new version as the old one refuse to pass on BS. but i'll be late for version freeze /o\ Just push it with an empty file list now, but with the new version number, and fix it later :) Thank you for this wonderfull tip ;)
Re: [Mageia-dev] python guru?
Le 17/12/2012 23:01, zezinho a écrit : If a python guru can give a hint about what is wrong when installing sugar-pippy-activity, thanks. http://check.mageia.org/cauldron/zezinho/dependencies.html Hi zezinho, your package is searching for python 2.5 but we have 2.7 and 3.3. The problem comes from this file : /usr/share/sugar/activities/Pippy.activity/library/pippy/physics/Elements-0.13-py2.5.egg I did not dig too much, but i think you should not include it, but have a require on a python-elements package (which we don't have it yet). my 2 cents Claire
Re: [Mageia-dev] Python packaging policy
Hi, Le 13/12/2012 09:00, Shlomi Fish a écrit : Hi Joseph, On Thu, 13 Dec 2012 14:53:04 +0800 Joseph Wangjoequ...@gmail.com wrote: [...] * I'd like to add a rule (which is followed by current packages) that the prefix py should generally be removed from a package name. For example pyopencl should be called python-opencl. This is the current convention for packages in mageia. I'm OK with it either way. I disagree on that point: software and libraries names are choose by the developers. Who are we to change them ? Adding python- at the beginning of the package name for our own organization is one thing, changing the name is another. And our policy only talk about upstream names containing the complete word python, not just py. Claire
Re: [Mageia-dev] Python packaging policy
Le 13/12/2012 15:43, Guillaume Rousse a écrit : Le 13/12/2012 15:24, Claire REVILLET a écrit : Hi, Le 13/12/2012 09:00, Shlomi Fish a écrit : Hi Joseph, On Thu, 13 Dec 2012 14:53:04 +0800 Joseph Wangjoequ...@gmail.com wrote: [...] * I'd like to add a rule (which is followed by current packages) that the prefix py should generally be removed from a package name. For example pyopencl should be called python-opencl. This is the current convention for packages in mageia. I'm OK with it either way. I disagree on that point: software and libraries names are choose by the developers. Who are we to change them ? A free software distribution, whose part of the added value is overall consistency. Which is out of scope of individual software authors by definition. And the current issue is just about the *package* name, not exactly the software name. Remember when 'thunderbird' was distributed as 'mozilla-thunderbird' ? And just to compare it with other similar practices: - we already normalize perl version numbers, for sorting purpose - we already force lowercase package naming - we already modify software setup, to achieve FHS compliance - we already modify package behaviour, to prevent automatic upgrade, for instance The two latest ones seems far most invasive IMHO than just shipping pycups in a package called 'python-cups' rather than 'python-pycups'. I understand your point, but i fear collisions between package names: (this is not a true example, i can't find one just now) Imagine it exists toto and pytoto in the Python Package Index. It can happen just because some people don't feel the need to add py in the module name as it's already written in python and it's in the Python package index... which seems sensible. Imagine pytoto is imported first with python-toto name for the package. How should i name the package for toto ? We can rename the first one into python-pytoto and import the second with python-toto, but we have to take care of the packages with BR or R on the first one. And it will brake the new policy rule. my 2 cents. Claire
Re: [Mageia-dev] Mageia 3 final set of isos
Le 19/09/12 10:17, Pascal Terjan a écrit : On Wed, Sep 19, 2012 at 9:40 AM, Anne Nicolas enna...@gmail.com wrote: Hi there So here is the discussion about what isos we should keep or have for final release. We had several (many!) proposals on that topics and we need to take some decisions. Here are some prerequisites I can see for what I can read in comments and review about Mageia on the web. - provide a full open source software version - provide CD iso(s) so that it can be quick to download (people having low band-width or paying depending how much they use it) - provide live version(s) - decrease isos number. QA is just a hell on the set we had for Mageia 2 - provide localization as large as possible - provide isos including major drivers including proprietary one to make it easier to install and configure Keep in mind that what you want is not necessarily what another one want. So let start proposals here and discussion. Please add all explanations to your proposal. I would vote for - Live DVDs (1 per arch) - dual arch free CD - dual arch nonfree CD that seems good :) maybe we can replace the dual-arch CDs by enlarged boot.iso, need to send more about it :) it may be as problematic as boot.iso for people with bad connections. I personally prefer a CD that brings correctly the base system than rely on my connection and finish with an installation without rpm (as it did once). Claire
Re: [Mageia-dev] Mageia 3 final set of isos
Le 19/09/2012 15:04, Johnny A. Solbu a écrit : On Wednesday 19 September 2012 14:23, Claire Revillet wrote: boot.iso for people with bad connections. I always use boot.iso when installing, as I install over the network. Then I don't have to remember to remove the CD/DVDs as available repos. The only time I use DVDs for installation, is when I'm installing for other people, either here at my place or at their places. I don't understand the relation between my point and yours. My point is that with a bad connection (like mine and i'm not living in the worse country concerning internet acces) boot.iso is not safe so we should continue providing dual-cd. Dual-cd can make a complete base installation safely and is less to download compare to DVDs.
Re: [Mageia-dev] ANNOUNCE: The /usr move cometh! ---- Instructions
Le 22/07/2012 02:12, Colin Guthrie a écrit : OK, so the packages have now all been uploaded. You should see several packages now that you cannot install on Cauldron. This is intended behaviour. Here is how to update your cauldron systems: 1. Run urpmi --auto-update install everything that can be installed. 2. Ensure that latest dracut is installed. Run urpmi dracut to make sure (it may have been excluded in the --auto-update if it was in a transaction with other packages that could not be installed). 3. Ensure that you do not have zapata or dpkg installed (rpm -e zapata; rpm -e dpkg) 4. Generate a new initrd and include the conversion script: dracut -f -a convertfs 5. If you have /usr on a separate partition - Ensure there is enough free space to hold /bin, /sbin, /lib and /lib64 content. - If your /usr is mounted readonly, change your /etc/fstab to mount it rw. 6. Reboot. 7. At the bootloader prompt, edit the command line and append: rw rd.convertfs (without the quotes) to your command line and then boot. That should be all that is needed :) If you are extra paranoid, or want to see what is going on, then you can remove the splash and quiet options from the kernel too. If you want to see things in more depth, you can also add rd.break=pre-pivot to the kernel. You will be dumped into a shell with your / mounted as /sysroot. This shell is *before* conversion. If you type exit the conversion will be done, and you'll be dumped to another shell afterwards. Typing exit once more here will boot the system as normal. All the best and good luck!!! Col Hi What append if we decide not to make the step on our machine ? Will it still be possible to update ? to package ? Claire
Re: [Mageia-dev] Tonight's meeting
Hi Le 30/05/2012 10:30, Anne Nicolas a écrit : - Development planning for Mageia 3 - Specifications for Mageia 3 Could we talk about the Java dependency problem (don't know if it can be in one of this 2 points) ? Claire
Re: [Mageia-dev] stardict 3.0.3
Le 30/01/2012 17:55, Kamil Rytarowski a écrit : Hello! W dniu 30.01.2012 14:33, Funda Wang pisze: Personally, i'm in favour of dropping it, due to what is said in its homepage: StarDict hasn't seen any active development for many years Well it's worth to consider importing goldentict too, but I'm against dropping stardict - it's actually alive and people keep porting it to GTK3. https://code.google.com/p/stardict-3/updates/list Hi What about asking his (her) opinion to the maintainer *before* upgrading it to the new version ? + kamilkamil - new versdion 3.0.3 - disable all patches, they seem merged - update URL - update SOURCE ** As the maintainer, it was to me to take the decision to upgrade or propose something else for mageia. You have the right to ask me what I want to do with it and to expose your opinion. But next time, ask the maintainer before ! There was no bugreport open for stardict, so no emergency to touch this package. And in case you are no aware of the fact we have a database for maintainership : mgarepo maintdb getpackage_name do the trick. Claire
Re: [Mageia-dev] stardict 3.0.3
I keep updating URLs and SOURCEs - the initial bug-request was there https://bugs.mageia.org/show_bug.cgi?id=3035 (I have reviewed initially 2,500 source-packages). 1) stardict does not appear in the list 2) why maintainers are not been contacted for all those problems ? So what do you think about the future of StarDICT? I was looking at the projects and I'm a little bit affraid of the licenses and patents. For example GoldenDict is said to support Babylon - and this can be problematic with patents. For me StarDict is a dead project and I was looking for a successor. There is no information on the copyright infringement and the tarball that can be downloaded on the new site are exactly the same as the old ones ! So the first possibility is: there was truly a copyright problem and there is still (this may be proved in the future if the copyright owner ask to close again the project) ; second possibility: there was no copyright problem (but a more obscure one), but, still, the project is not very active. So if GoldenDict present, at this time, no license or patent problem and is actively developed : it can be a better choice. Import freeze for mageia 2 will be in march, so I think we have a little time to think about it to choose the best solution for mageia 2 and test it (bugs...) before release. Let's take the week for discussion. you reviewed the dicts if they are legally used? I checked for almost all dict : they are GPL or Creative Commons Attribution-ShareAlike Licence (V3.0). Just 1 as to be modified (quick-deu-eng) or simply removed. I'll do that in the week. I think url information may not be good, but I did not see the point of rebuilding 200 packages just for that (taking into account the fact that dictionaries are not code : they do not evolve). Claire
Re: [Mageia-dev] stardict 3.0.3
Le 30/01/2012 22:31, Claire Revillet a écrit : I keep updating URLs and SOURCEs - the initial bug-request was there https://bugs.mageia.org/show_bug.cgi?id=3035 (I have reviewed initially 2,500 source-packages). 1) stardict does not appear in the list 2) why maintainers are not been contacted for all those problems ? 3) if your point was just to fix bad URLs, why upgrading ? Claire
Re: [Mageia-dev] stardict 3.0.3
Le 30/01/2012 22:50, Funda Wang a écrit : 2012/1/31 Claire Revilletgren...@zarb.org: For me StarDict is a dead project and I was looking for a successor. There is no information on the copyright infringement and the tarball that can be downloaded on the new site are exactly the same as the old ones ! So the first possibility is: there was truly a copyright problem and there is still (this may be proved in the future if the copyright owner ask to close again the project) ; second possibility: there was no copyright problem (but a more obscure one), but, still, the project is not very active. I think there is no copyright problem with the stardict the program itself, only the data files (dictionaries). But the author has been missing for half a year: http://goldendict.org/forum/viewtopic.php?f=4t=1109 It's also what I think : no really copyright pb with the code (and yes, I had seen link :\ ). I don't think the problem is with the dict, because the pages with all the dict are still there : http://abloz.com/huzheng/stardict-dic/ (and easy to find). So, for me, dict are okay. But if the new dev is not really active, it is a good time to change the software for the distribution.
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release gnuplot-4.4.4-2.mga2
Le 12/12/2011 09:28, Dick Gevers a écrit : Dear pterjan, The doc package does not upgrade the old doc package, so none of the gnuplot* packages can be easily installed with urpmi - only if the old -doc package is removed before. Best regards, =Dick Gevers= Your mirrors may not have been uptodate. I had no problems updating my cauldron this morning. Claire (grenoya)
[Mageia-dev] eclipse installation under cauldron
Hi, Now a day, when someone wants to install eclipse he has to answer to less than 17 package selection ! I can anderstand the 2 first (which jvm and javamail vs. classpathx-mail) but the next 15 are ant-* vs. ant17-* choices. I was wondering: Is it temporary ? if not: do we expect that any user that want to use eclipse can understand those questions ? (personnaly, I was not installing eclipse for java use and I don't know the meaning of all those packages) Claire
Re: [Mageia-dev] eclipse installation under cauldron
Le 24/11/2011 21:43, Claire Revillet a écrit : Hi, Now a day, when someone wants to install eclipse he has to answer to less than 17 package selection ! s/to less/not less/ I can anderstand the 2 first (which jvm and javamail vs. classpathx-mail) but the next 15 are ant-* vs. ant17-* choices. I was wondering: Is it temporary ? if not: do we expect that any user that want to use eclipse can understand those questions ? (personnaly, I was not installing eclipse for java use and I don't know the meaning of all those packages) Claire And it seems there is some lines to suppress in different specfiles :) sorry for the french error messages (impossible de créer le répertoire == cannot create folder) : 62/64: eclipse-platform ## cp: impossible de créer le fichier standard « /home/iurt/rpm/tmp//artifacts.xml »: Aucun fichier ou dossier de ce type cp: impossible de créer le lien symbolique « /home/iurt/rpm/tmp//eclipse.ini »: Aucun fichier ou dossier de ce type cp: impossible de créer le répertoire « /home/iurt/rpm/tmp//p2 »: Aucun fichier ou dossier de ce type cp: impossible de créer le répertoire « /home/iurt/rpm/tmp//configuration »: Aucun fichier ou dossier de ce type Eclipse: An error has occurred. See the log file /usr/lib64/eclipse/configuration/1322167734873.log. cp: impossible d'évaluer « /home/iurt/rpm/tmp//artifacts.xml »: Aucun fichier ou dossier de ce type cp: impossible d'évaluer « /home/iurt/rpm/tmp//eclipse.ini »: Aucun fichier ou dossier de ce type cp: impossible d'évaluer « /home/iurt/rpm/tmp//p2 »: Aucun fichier ou dossier de ce type cp: impossible d'évaluer « /home/iurt/rpm/tmp//configuration »: Aucun fichier ou dossier de ce type 63/64: eclipse-jdt ## cp: impossible de créer le fichier standard « /home/iurt/rpm/tmp//artifacts.xml »: Aucun fichier ou dossier de ce type cp: impossible de créer le lien symbolique « /home/iurt/rpm/tmp//eclipse.ini »: Aucun fichier ou dossier de ce type cp: impossible de créer le répertoire « /home/iurt/rpm/tmp//p2 »: Aucun fichier ou dossier de ce type cp: impossible de créer le répertoire « /home/iurt/rpm/tmp//configuration »: Aucun fichier ou dossier de ce type 64/64: eclipse-pde ## cp: impossible de créer le fichier standard « /home/iurt/rpm/tmp//artifacts.xml »: Aucun fichier ou dossier de ce type cp: impossible de créer le lien symbolique « /home/iurt/rpm/tmp//eclipse.ini »: Aucun fichier ou dossier de ce type cp: impossible de créer le répertoire « /home/iurt/rpm/tmp//p2 »: Aucun fichier ou dossier de ce type cp: impossible de créer le répertoire « /home/iurt/rpm/tmp//configuration »: Aucun fichier ou dossier de ce type
