Re: [Mageia-dev] Python packaging policy
Hi Joseph, On Thu, 13 Dec 2012 14:53:04 +0800 Joseph Wang joequ...@gmail.com wrote: Looking over this page: https://wiki.mageia.org/en/Python_policy * python-pyp2rpm is undergoing review right now. Once it's in cauldron, I'd like to point to that package as something that packagers you should use to get a first draft of a spec file, I've been working with the Fedora people so that it will do both fedora and mageia naming conventions. Sounds good. Does it support building for both Python 2.x and Python 3.x (in case both are supported)? * 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. * Also for grouping. I'd like to add a rule that Development/Python is intended for packages which provide general development libraries for python, and if the library fits into an obvious other category (i.e. python routines for cosmology calculations) those should go into the other category. Sounds good. Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ Rethinking CPAN - http://shlom.in/rethinking-cpan mst I find it’s usually safe to assume that whatever shlomif’s doing, there isn’t a good reason for it. Please reply to list if it's a mailing list post - http://shlom.in/reply .
Re: [Mageia-dev] Python packaging policy
Le 13/12/2012 09:00, Shlomi Fish a écrit : * Also for grouping. I'd like to add a rule that Development/Python is intended for packages which provide general development libraries for python, and if the library fits into an obvious other category (i.e. python routines for cosmology calculations) those should go into the other category. What is the interest ? The only usage of rpm group is in package installation GUI, mostly used by end-users. They don't care of development bricks, they are generally interested by ready-to-user software (applications) only. Don't throw useless effort in sorting python libraries about their purpose, their nature is enough. -- BOFH excuse #253: We've run out of licenses
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release pcre-8.32-5.mga3
On 4 December 2012 08:18, Thierry Vignaud thierry.vign...@gmail.com wrote: fwang fwang 8.32-5.mga3: + Revision: 323949 - add back pcretest pcre requires lib64pcre1 = 8.32-5.mga3. So I should be able to remove old lib64pcre0: rpm -e --test lib64pcre0-8.21-2.mga3.x86_64 error: Failed dependencies: libpcreposix.so.1()(64bit) is needed by (installed) pcre-8.32-5.mga3.x86_64 = lib64pcreposix1-8.32-5.mga3.x86_64.rpm should obsoletes lib64pcre0 as files were moved (std procedure) Ping?
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
On Thursday 13. December 2012 15.24, Claire REVILLET wrote: 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. I agree with Claire. I had the same reaction when reading the suggestion. It's a Bad idea. -- Johnny A. Solbu PGP key ID: 0xFA687324 signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] Python packaging policy
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'. -- BOFH excuse #32: techtonic stress
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] Python packaging policy
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 ? 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 A package name is not a software name... and we have already some packages whose the name is not the same as in other distributions for reasons that belong to our and their organisation : look at JACK (Jack Audio Connection Kit) for instance - opensuse has a rpm simply called jack - Mandriva and Mageia need to name it jackit (because an other software, to rip cd, was already provided in a rpm called jack) - Debian and Ubuntu name their deb jackd or jackd1 (Debian too already used the name jack for the package installing the same cd ripper as Mandrake) - fedora and slackware call the rpm jack-audio-connection-kit (with lowercase...) Those distibutions have their coherency their needs : it's difficult to standardise the packages names for all the distributions because these names have an historical origin ! You can complain ... but that is how it is... For a distribution the need is coherence for its own packagers My two drachmes Philippe
Re: [Mageia-dev] Python packaging policy
On Thu, 13 Dec 2012 14:53:04 +0800 Joseph Wang joequ...@gmail.com wrote: Looking over this page: https://wiki.mageia.org/en/Python_policy * python-pyp2rpm is undergoing review right now. Once it's in cauldron, I'd like to point to that package as something that packagers you should use to get a first draft of a spec file, I've been working with the Fedora people so that it will do both fedora and mageia naming conventions. Will this solve https://bugs.mageia.org/show_bug.cgi?id=3348 ? (which dates back to https://qa.mandriva.com/show_bug.cgi?id=50484 ) Regards Antoine.
[Mageia-dev] service dm restart go on tty3
Hi (Colin) :D I don't know if this is because I still have obsolete files, but if I do a service dm restart just after boot on the console of tty2, then the X server restarts but on tty3, dunno if this is wanted, but I would have expected it to restart on tty1. Cheers, Chris PS :I can explain why I do this, up to an unrestrained desire of testing the improbable! I really do not like the kdm login screen displaying the name of users, and I have a tuned /usr/share/apps/kdm/themes/mageia-kde4/mageia-kde4-nolist.xml that I update by hand each time kdm is updated :-/ PS^2: I suggested during my mandriva time that we have the option to choose this, if someone is also interested, I am happy to provide this file. Cheers, Chris.
Re: [Mageia-dev] service dm restart go on tty3
'Twas brillig, and eatdirt at 13/12/12 19:25 did gyre and gimble: Hi (Colin) :D I don't know if this is because I still have obsolete files, but if I do a service dm restart just after boot on the console of tty2, then the X server restarts but on tty3, dunno if this is wanted, but I would have expected it to restart on tty1. It should, but basically it's up the DMs in question. In gdm I think it tries tty1 first. For mga4 I'll likely try and push through a rejig of how the DM stuff operates which might help this situation a bit. KDM could also likely be patched too. I should likely do more tests in this area tho'. Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] Python packaging policy
On 13/12/12 06:53, Joseph Wang wrote:
Looking over this page:
https://wiki.mageia.org/en/Python_policy
* 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 think it's too strong. There will necessarily be exceptions, like pypes.
For the package names, I can give you my experience as ocaml packager.
Our policy is roughly the same as for python:
- executables keep their upstream names (ex. js_of_ocaml, camlp5, ...)
- libraries take the 'ocaml-' prefix followed by the upstream name as
much as possible (since these upstream names are known). It leads to
packages like ocaml-ocamlgraph or ocaml-ocamlnet since ocamlgraph and
ocamlnet are well-known libs in the community. However when the library
is just a wrapper for a well-known C library, we drop extra ocaml
prefixes or suffixes (ex: upstream sqlite3-ocaml becomes ocaml-sqlite3).
So overall, no policy should be too strict: the need for uniformity
should not make it too hard for users!
* Also for grouping. I'd like to add a rule that Development/Python
is intended for packages
which provide general development libraries for python, and if the
library fits into an obvious
other category (i.e. python routines for cosmology calculations) those
should go into the
other category.
I don't really agree. The current group policy is the following:
- if it's an application/data - in the corresponding group.
- if it's a library for development - in Development/%{the language}.
- if it's a library not meant for anyone to install independently
- in System/Libraries.
I'm not sure users would find a benefit to have python for cosmology in
the Astronomy section and python for Maths in the Maths section and so on.
What I would encourage you to do however is to create a cosmology wiki
page that describes all the cosmology-features of Mageia.
Best,
--
Malo
[Mageia-dev] rootcerts - $arch dependant noarch package?
Hi. In our enviroment we are shipping our own local CA certificate on the machines. In order to learn how to do that properly, I looked at the rootcerts package. In doing that I noticed that the rootcerts package is architecture dependant, as in it builds i586 and x86_64 packages, and not noarch. Yet there is no compiling involved and no binary files shipped, that I can detect, that would warrant an architecture dependant packaging. So why isn't this a noarch package? After all, it's just a set of certificate files. -- Johnny A. Solbu PGP key ID: 0xFA687324 signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release youri-check-0.10.2-2.mga3
Le 13/12/2012 23:27, tmb a écrit : tmb tmb 0.10.2-2.mga3: + Revision: 330532 - fix fedora update git url (P0) There is a configuration file for this kind of issues... No need to patch hardcoded default every time there is a change in fedora mirrors list. -- BOFH excuse #300: Digital Manipulator exceeding velocity parameters
[Mageia-dev] LastFm going subscription
Beginning Tuesday 15 January 2013 radio streaming within the desktop client will only be available to Last.fm subscribers (monthly fee). Due to this should not lastfm-player either be dropped or moved to nonfree now before Mga3 goes final? Charles -- Theory of Selective Supervision: The one time in the day that you lean back and relax is the one time the boss walks through the office. -- Mageia release 3 (Cauldron) for x86_64$ On SuperSizehttp://www.eslrahc.com Registered Linux user #182463 3.7.0-server-0.rc8.1.mga3 x86_64 -- signature.asc Description: PGP signature
Re: [Mageia-dev] LastFm going subscription
On Thu, 2012-12-13 at 18:26 -0500, Charles A Edwards wrote: Beginning Tuesday 15 January 2013 radio streaming within the desktop client will only be available to Last.fm subscribers (monthly fee). Due to this should not lastfm-player either be dropped or moved to nonfree now before Mga3 goes final? The player can be free (libre, open source) even if the service is not. Of course, it may well be less useful... Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org freenode/#xml
[Mageia-dev] systemctl closelog httpd.service not working
While teaching a class in admin of GNU Linux I noted that logrotate was using SysV notation to close the logs in order to rotate them service httpd closelog which works fine, but the equivilent command in systemd systemctl closelog httpd.service does NOT work Richard -- LinuxCabal Asociación Civil Ing. Richard Couture Novell CNE, ECNE, MCNE HP/Compaq ASE Tel.: (+52) (333) 145-2638 Cel.: (+52) (044) 333 377-7505 Cel.: (+52) (044) 333 377-7506 Web: http://www.LinuxCabal.org E-Mail: r...@linuxcabal.org Hosted en la nube Cloud Sigma - www.CloudSigma.com AVISO DE CONFIDENCIALIDAD: Este correo electrónico, incluyendo en su caso, los archivos adjuntos al mismo, pueden contener información de carácter confidencial y/o privilegiada, y se envían a la atención única y exclusivamente de la persona y/o entidad a quien va dirigido. La copia, revisión, uso, revelación y/o distribución de dicha información confidencial sin la autorización por escrito de LinuxCabal está prohibida. Si usted no es el destinatario a quien se dirige el presente correo, favor de contactar al remitente respondiendo al presente correo y eliminar el correo original incluyendo sus archivos, así como cualesquiera copia del mismo. Mediante la recepción del presente correo usted reconoce y acepta que en caso de incumplimiento de su parte y/o de sus representantes a los términos antes mencionados, LinuxCabal tendrá derecho a los daños y perjuicios que esto le cause.
[Mageia-dev] samba reload does not reread /etc/group
While teaching a class in admin of GNU Linux I noted that systemctl reload smbd.service does NOT reread the /etc/group file. When adding a new user to a group which in smb.conf grants them access to a share, it was necessary to restart the service in order to grant the new group members access. It seems odd that samba is caching /etc/group and if so, odder that it can't reread it during a reload... Richard -- LinuxCabal Asociación Civil Ing. Richard Couture Novell CNE, ECNE, MCNE HP/Compaq ASE Tel.: (+52) (333) 145-2638 Cel.: (+52) (044) 333 377-7505 Cel.: (+52) (044) 333 377-7506 Web: http://www.LinuxCabal.org E-Mail: r...@linuxcabal.org Hosted en la nube Cloud Sigma - www.CloudSigma.com AVISO DE CONFIDENCIALIDAD: Este correo electrónico, incluyendo en su caso, los archivos adjuntos al mismo, pueden contener información de carácter confidencial y/o privilegiada, y se envían a la atención única y exclusivamente de la persona y/o entidad a quien va dirigido. La copia, revisión, uso, revelación y/o distribución de dicha información confidencial sin la autorización por escrito de LinuxCabal está prohibida. Si usted no es el destinatario a quien se dirige el presente correo, favor de contactar al remitente respondiendo al presente correo y eliminar el correo original incluyendo sus archivos, así como cualesquiera copia del mismo. Mediante la recepción del presente correo usted reconoce y acepta que en caso de incumplimiento de su parte y/o de sus representantes a los términos antes mencionados, LinuxCabal tendrá derecho a los daños y perjuicios que esto le cause.
[Mageia-dev] Blender don't start
[olivier@localhost ~]$ blender Segmentation fault [olivier@localhost ~]$ rpm -q blender blender-2.65-2.mga3 Regards. -- Olivier Thauvin CNRS - LATMOS ♖ ♘ ♗ ♕ ♔ ♗ ♘ ♖ pgpNNlAjPwlpq.pgp Description: PGP signature
[Mageia-dev] Perl(B::C) installation problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Certains paquets ont été installés mais d'autres ont échoué. Le paquetage demandé ne peut pas être installé : perl-B-C-1.420.0-2.mga2.i586 (car perlapi-5.14.2 est non satisfait) Regards. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJQysoMAAoJEOk/tJ1aQIB9K6QIAKEOcQHVzosFQz8/Wqnhn71u 5mAh0fZaH/hCflXlrZULKKKEDEH1BzLgpSRlUp1ljhCZ7KpBFbhsNV30BcXMazvX KHLsQfVs9WdhRqfsG1R3CFP2vWFvs+ssVr2eObzraLntHzpD4DT3awnTCIZoZQkA VQ3QDACdepDDUL5EQ0cmef99/7i6q18iTdKLils4XSeCibL11HMUIH2KgZ7hbAig TAI73rer32Gou+B11NBdVbJ7ZDyl+vmTRaEaKeup7zsn3R1X9mOSdBBakWyJ6R2A dcsz5cQ4AFH00dHZ9luCjn9SYlrbhZNG3icuabVE967nps76mbjT3KYD2RMbDDg= =P3ps -END PGP SIGNATURE-
Re: [Mageia-dev] LastFm going subscription
On Fri, Dec 14, 2012 at 12:26 AM, Charles A Edwards c...@eslrahc.com wrote: Beginning Tuesday 15 January 2013 radio streaming within the desktop client will only be available to Last.fm subscribers (monthly fee). Due to this should not lastfm-player either be dropped or moved to nonfree now before Mga3 goes final? It could be dropped or stay for those who want to pay the 3€ a month. -- AL I:40: Do what thou wilt shall be the whole of the Law.
