Re: [Mageia-dev] Importing Perl policy
On 11/01/08 23:14 +0100, Remy CLOUARD wrote:
I just imported the perl packaging policy in the wiki, could someone
review it please ? It’s located there:
http://mageia.org/wiki/doku.php?id=perl_policy
seems to be correct. i added information about shipping META.{json|yml}
to use upstream prereqs.
2) About the tools, will we have a CPANPLUS-Dist-Mga backend, or will we
reuse the CPANPLUS-Dist-Mdv ?
i'll release cpanplus-dist-mageia when i find some tuits.
regards,
jérôme
--
jque...@gmail.com
[Mageia-dev] Importing RPM Groups
Hi, I just imported the RPM Groups page into the wiki. I verified the list was complete with what rpmlint returns as valid RPM groups. Maybe some groups are obsolete, others could be created Proposal for removal: Graphical desktop/FVWM based (only one entry) Graphical desktop/Sawfish (only one entry) Proposal for creation: Development/Haskell Development/OCaml Graphical desktop/LXDE Networking/Chat (merge with Instant Messaging) Sound/Players (because listening to music and creating it is a very different thing IMHO) Sound/Editors Sound/Other WDYT ? Regards, -- Rémy CLOUARD () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments pgp4CIGLaZCbh.pgp Description: PGP signature
Re: [Mageia-dev] Importing RPM Groups
Le dimanche 9 janvier 2011 10:49:19, Remy CLOUARD a écrit : Hi, I just imported the RPM Groups page into the wiki. I verified the list was complete with what rpmlint returns as valid RPM groups. Maybe some groups are obsolete, others could be created Proposal for removal: Graphical desktop/FVWM based (only one entry) Graphical desktop/Sawfish (only one entry) Proposal for creation: Development/Haskell Development/OCaml Graphical desktop/LXDE Networking/Chat (merge with Instant Messaging) Sound/Players (because listening to music and creating it is a very different thing IMHO) Sound/Editors Sound/Other WDYT ? Regards, I think groups may need a bigger rework than just those changes. To me, package groups should be as close as possible as menu entries (for graphical packages), but maybe that would be too few groups ? In fact, debian has some advance upon us on this, by the use of debtags. We could maybe simplify grouping if we could put some information in tags rather than in groups. I don't know if there are cross-distributions efforts to harmonize package groups, but that would be an interesting subject to tackle in the upcoming meeting in Nürnberg. More questions than answers :) Regards Samuel Verschelde
Re: [Mageia-dev] packages importing: some questions
Le 09/01/2011 14:13, Florian Hubold a écrit : Is this http://repository.mageia.org/mageiatools/cooker/i586/core/release/ only a temporary adress or the final repo structure? Shouldn't it be called .../mageiatools/cauldron/... then or is there something i missed? nope, because this package is for cooker :) -- Sandro Cazzaniga IRC: Kharec (irc.freenode.net) Twitter: @Kharec
Re: [Mageia-dev] packages importing: some questions
Florian Hubold skrev 9.1.2011 15:13: Hello, after reading http://www.mageia.org/wiki/doku.php?id=packaging#starting_package_import i have some questions: Is this http://repository.mageia.org/mageiatools/cooker/i586/core/release/ only a temporary adress or the final repo structure? Shouldn't it be called .../mageiatools/cauldron/... then or is there something i missed? Its named /cooker/ so you know it works on cooker install (python-2.7) There is also a /2010.1/ so you know it works on 2010.1 install (python-2.6) Then point 4. IV.: Why should we check if it does NOT have an clear, explicit license? Shouldn't we rather check if it DOES have a clear and explicit license? So is this just a typo? That's a typo, yes... -- Thomas
Re: [Mageia-dev] Adding Java-Policy
Le 08/01/2011 12:30, Renaud MICHEL a écrit : On samedi 08 janvier 2011 at 10:39, Farfouille wrote : I will be very interested at least to try. I propose to work on it until sunday evening and come back here with my attempt. Thank you, I will review it (from a beginner POV) once you have something. On sunday evening the status is that I've started to collect information but unfortunately my wash machine made a nervous breakdown. Anyway I hope to publish something tomorrow cheers -- Farfouille
Re: [Mageia-dev] Mageia policies
On Fri, Jan 07, 2011 at 11:10:29PM +0100, Remy CLOUARD wrote: Hi guys, First of all, thanks for the reviews ! Huge kudos to Daniel who reviewed most of them. Hi, Thanks again for all the imports/reviews/threads. I’ve missed an important point in the process. The license used on mandriva wiki is the Creative Commons Attribution-ShareAlike 2.5, and we use the license we use is Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported. Thus, when you import the policy, be sure to mention this at the end of the page. It could also be nice to add the authors (look at the revision history of Mandriva’s wiki. I didn’t include Category Changes, because that’s not relevant, but if you are lazy, you can list them all. I added that point on the policies-review page Regards, -- Rémy CLOUARD () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments pgpR62BPMcxAJ.pgp Description: PGP signature
Re: [Mageia-dev] packages importing: what replaces rpm-mandriva-setup-build
On Sat, Jan 8, 2011 at 15:08, Jerome Quelin jque...@gmail.com wrote: hi, perl does: BuildRequires: rpm-mandriva-setup-build = 1.8 what should it be translated to? rpm-mageia-setup-build? or nothing at all, since we'll have the latest greatest version? :-) I would say nothing since older version will never exist on mageia and that package will always be installed during build
Re: [Mageia-dev] Mageia policies
Le dimanche 9 janvier 2011 20:58:24, Remy CLOUARD a écrit : On Fri, Jan 07, 2011 at 11:10:29PM +0100, Remy CLOUARD wrote: Hi guys, First of all, thanks for the reviews ! Huge kudos to Daniel who reviewed most of them. Hi, Thanks again for all the imports/reviews/threads. I’ve missed an important point in the process. The license used on mandriva wiki is the Creative Commons Attribution-ShareAlike 2.5, and we use the license we use is Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported. Is there a reason why we need a NC clause ? It seems very restrictive to me. Regards Samuel Verschelde
Re: [Mageia-dev] Mageia policies
On Sun, Jan 9, 2011 at 22:30, Samuel Verschelde sto...@laposte.net wrote: Le dimanche 9 janvier 2011 20:58:24, Remy CLOUARD a écrit : I’ve missed an important point in the process. The license used on mandriva wiki is the Creative Commons Attribution-ShareAlike 2.5, and we use the license we use is Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported. Is there a reason why we need a NC clause ? It seems very restrictive to me. It may be that, the default license in default setup footer of dokuwiki is a CC By-NC-SA. But that was _not_ on purpose, we just did not checked this. Until now (thanks baud for the notification about this on webteam list). I fixed [1] this on the wiki footer, using now the By-SA CC license. I expect it is understandable that, using material being under By-SA (MDV wiki) requires to keep it under the same license. And that the NC provision is, at best, counter-productive in a open source/free software context. [1] provided it was a clear dokuwiki setup and that we did not change the footer license, I think we can assume that no specific license was used until now. Choosing for By-SA was made with the perspective of the above. Open for debate of course; we should have been more careful about this bit on day 1. :-/ Cheers, Romain
Re: [Mageia-dev] New bugzilla proposal
Le vendredi 07 janvier 2011 à 19:04 +0100, Romain d'Alverny a écrit : Ok, the point of this discussion is to know what we put as: - Products - Components This can be updated later (as in: adding/renaming products/components). So we should just aim at the smallest acceptable set, so that we can open our Bugzilla instance, see what it shows, update and open it for actual usage. So trying to summarize above discussion, I suggest as products: * Mageia with components: - installation - software - new software request - release (media, process) - (for versions, cauldron first, we'll see later for the rest) * Websites with components: - www - forum - blog - wiki - maint-db - (for versions, live/dev does not make much sense here; so maybe just numbering, maybe just no version for a start; depends on the release process) If we intend ( and Buchan do, and I am sure that Stormi also ) to reuse and let people reuse some of the web software we wrote outside of Mageia ( ie, Buchan spoke of having identity to be proposed to the openldap community ), I would keep website for the installation we have, and also treat them as software for people who deployed it on their own server. But that doesn't apply to everything, obviously. So in website, we treat our instances, and then I think that depend on the number of instance we have. Even if I doubt we will have more than stable no stable ( or trunk / stable, whatever the name ). * Infrastructure - ? (misc?) I do think that people should fill bug report against me elsehwere than on mageia bugzilla. For infrastructure, I guess we can simply put 1 product, and later decide once we see what is buggy ( because we did not plan to have bugs yet, so we cannot tell where they should be filled ). Maybe say that we review the component every year with bug triage team ? -- Michael Scherer
Re: [Mageia-dev] Importing Licensing Policy
Le dimanche 09 janvier 2011 à 00:15 +0100, Remy CLOUARD a écrit : Hello, I just started to import the Licensing policy from the Mandriva wiki. Here are notable changes: - replacing Mandriva with Mageia - adapting the page to the Mageia mirror structure - in the mandriva page (which is outdated on that point) there was a mention about a contact, which is Adam Williamson on the mandriva wiki. Who would be in charge of the points mentionned in the first paragraph of the licensing guidelines ? Shall we just keep the mageia-dev mailing list as a contact ? Adam basically asked to Tom Spot, a Red hat manager that is in charge of licensing, among others ( he is the bridge between engineering and legal departement ). Maybe adam can help us again :) - no mention of restricted repositories at the moment - subsequently, no package eligible for the “Proprietary” license *khof* nvidia *khof* - adding a complete list of license names (produced by rpmlint) I think we should try to sync with fedora, as that basically what is done for rpmlint. -- Michael Scherer
[Mageia-dev] A nice tools over Sophie
Hi, You probably know sophie (http://sophie.zarb.org). I am currently working on QA tools working with the new XML-RPC features provide by new website. I do think this can help us to reimport rpm in mageia. This tools upload rpm information from rpm given as argument then perform a dependencies check. The tools still need some work, but it works. Here an example over current Mandriva cooker: [oliv...@volantis trunk]$ perl bin/sophie-rpm -c sophie.conf ~/RPM/RPMS/noarch/mmm-cgi-0.44-0.1mdv2010.1.noarch.rpm Loarding /home/olivier/RPM/RPMS/noarch/mmm-cgi-0.44-0.1mdv2010.1.noarch.rpm Analysing /home/olivier/RPM/RPMS/noarch/mmm-cgi-0.44-0.1mdv2010.1.noarch.rpm perl(Getopt::Long): perl-base-5.12.2-5mdv2011.0.x86_64.rpm perl-Getopt-Long-2.380.0-1mdv2010.0.noarch.rpm rpm-helper = 0.16: rpm-helper-0.23.1-2mdv2011.0.noarch.rpm /bin/sh: bash-4.1-8mdv2011.0.x86_64.rpm perl-base: perl-base-5.12.2-5mdv2011.0.x86_64.rpm perl(Pod::Usage): perl-5.12.2-5mdv2011.0.x86_64.rpm mmm = 0.44-0.1mdv2010.1: Are unresolved: mmm = 0.44-0.1mdv2010.1 Error, unresolved: mmm = 0.44-0.1mdv2010.1 Of course to do the same over Magiea the mirror have to be finalize and Cauldron add to Sophie's DB. Regards. -- Olivier Thauvin CNRS - LATMOS ♖ ♘ ♗ ♕ ♔ ♗ ♘ ♖ pgpGxBDkpsbfO.pgp Description: PGP signature
Re: [Mageia-dev] Importing RPM Groups
Le dimanche 09 janvier 2011 à 11:54 +0100, Samuel Verschelde a écrit : Le dimanche 9 janvier 2011 10:49:19, Remy CLOUARD a écrit : Hi, I just imported the RPM Groups page into the wiki. I verified the list was complete with what rpmlint returns as valid RPM groups. Maybe some groups are obsolete, others could be created Proposal for removal: Graphical desktop/FVWM based (only one entry) Graphical desktop/Sawfish (only one entry) That look like a good criteria for removal, yes Proposal for creation: Development/Haskell Development/OCaml Graphical desktop/LXDE Networking/Chat (merge with Instant Messaging) Sound/Players (because listening to music and creating it is a very different thing IMHO) Sound/Editors Sound/Other WDYT ? Regards, I think groups may need a bigger rework than just those changes. To me, package groups should be as close as possible as menu entries (for graphical packages), but maybe that would be too few groups ? Well, we would still have to do something for non graphical rpm, and I would think that the vast majority would fall in this category. And the context and order of magnitude is different. In the menu, you don't want to have too many category, because that would provide clutter. On a database of more than 1000 rpms, you will have lots of packagers whatever you do, so while we should aim for less clutter, we cannot do much due to the number of rpm. In fact, debian has some advance upon us on this, by the use of debtags. We could maybe simplify grouping if we could put some information in tags rather than in groups. I don't know if there are cross-distributions efforts to harmonize package groups, but that would be an interesting subject to tackle in the upcoming meeting in Nürnberg. Yup. But we should first decide what do we use group for. Ie, they appear in : - packages managers ( to the extended sense, that mean rpmdrake, and installer ) - elsewhere ? They are then used by : - users ? - developers ( don't think so ) And used for what purpose ? - finding packages that fulfill some usage criteria ? ( like I need a software for doing sound related stuff ) - removing some package from the list And I would also see what others lists do exist. IE, the group of debian, of fedora, of opensuse, etc, etc. So see if we can inspire from them, etc. -- Michael Scherer
Re: [Mageia-dev] Importing RPM Groups
Samuel Verschelde a écrit : Le dimanche 9 janvier 2011 10:49:19, Remy CLOUARD a écrit : Hi, I just imported the RPM Groups page into the wiki. I verified the list was complete with what rpmlint returns as valid RPM groups. Maybe some groups are obsolete, others could be created Proposal for removal: Graphical desktop/FVWM based (only one entry) Graphical desktop/Sawfish (only one entry) Proposal for creation: Development/Haskell Development/OCaml Graphical desktop/LXDE Networking/Chat (merge with Instant Messaging) Sound/Players (because listening to music and creating it is a very different thing IMHO) Sound/Editors Sound/Other WDYT ? Regards, I think groups may need a bigger rework than just those changes. Agreed. Although it might not be a bad idea to start with these minor changes. To me, package groups should be as close as possible as menu entries (for graphical packages), but maybe that would be too few groups ? I have long thought this as well. And the menu system should accommodate console apps as well. (Strictly speaking it does, but generally you have to add the entries yourself.) Don't forget that the XDG menu system doesn't require a major GUI like Gnome or KDE, or even LXDE. It could be presented by a console app. It is basically just a tool to readily access (console or GUI) applications. All the more reason to try to harmonize (in both directions) the presentation of packages for installation with the menu system. In fact, debian has some advance upon us on this, by the use of debtags. We could maybe simplify grouping if we could put some information in tags rather than in groups. Right. With multiple tags, we can more finely classify packages. Particularly useful for such groups as network (internet in the menus), where a package -- such as Mozilla Seamonkey -- can be email / irc / file-transfer / www (as well as html editor) all at the same time. Those distinctions remain useful when looking for a package with a particular function. However the user package tools (such as mageia-app-db and rpmdrake) should still present the packages by rpm group / tag, and not just rpm group, in order to present a more manageable number of packages. Of course with this approach, a package with multiple tags will be presented in more than one location. (That used to happen with RedHat installation cds.) There could also be a mechanism to not separately present a group/tag catagory with less than a certain number of members (say 3), to avoid a too balkanized presentation. So if only 1 or 2 members, it is merged with the parent category. In the case of FVWM and Sawfish mentioned above, they would be presented directly in the desktop GUI group. It occurs to me that there is essentially no difference between package groups and tags, except that a package can have multiple tags. It might be useful to keep them separate on that basis - the package being required (or allowed ?) to specify exactly one group, and permitted to specify any number of tags. Just a random thought. I don't know if there are cross-distributions efforts to harmonize package groups, but that would be an interesting subject to tackle in the upcoming meeting in Nürnberg. Very good idea. The more we can harmonize, the better for third-party packages, the end-user, and Linux in general. (I'd like to see .rpm and .deb harmonized.) More questions than answers :) Good questions lead to better answers :) Regards Samuel Verschelde my 2 cents :) -- André
Re: [Mageia-dev] [RFC] Ruby packaging policy
Le vendredi 07 janvier 2011 à 23:45 +0100, Remy CLOUARD a écrit :
Hello there,
It’s been quite some time since I started working on ruby modules, and
I’ve been working on the policy too.
You can find the page here:
http://wiki.mandriva.com/en/Policies/Ruby
Now, there are some things that still need to be clarified.
The most controversial part is the naming convention.
Many ruby modules are packaged via gem, and fedora introduced a strange
naming convention, calling their package rubygem-%{gemname}. This
convention was soon followed by other rpm-based distro such as opensuse
and momonga, and we also have some of them.
This cause problem since we do have rpm present twice ( without people
noticing, as I dicovered when trying to use gitorious ). More ever, this
is confusing for packagers. There is also potential breakage if someone
start to do tarball, then gems, etc etc.
I have already expressed my opinion on the subject, and still maintain
it :
ruby rpm should be ruby-*.
Several people ( Pascal Terjan
http://lists.mandriva.com/cooker/2010-11/msg00063.php , Guillaume
Rousse ) also raised concern about this when this discovered after being
pushed 1 year ago without discussion
( http://lists.mandriva.com/cooker/2010-03/msg00401.php ) .
Python does also have egg, and they play nice with rpm ( ie, we ship
file that make egg think our python module are installed as egg ).
Cpan also provides archives ( but that unused )
I’m not against changing that convention, but this raises also other
questions.
1) Do we also need to change the provides/requires ? ie
Requires: ruby(%{gemname})
instead of
Requires: rubygem(%{gemname})
2) is there a way to make youri watch for rubygem-%{gemname} in case we
opt for that change ? Or better, can youri watch for %{gemname} on
rubygems.org ?
yes. Just need a patch :)
About files:
shall we keep the gem in the cache directory ? I’m not sure this is
really useful, up till now I added it, but it makes the package a bit
bigger
Well, what is the goal of keeping the source in two location ?
Shall we do a -doc subpackage for big packages ? I think it may be
interesting for package that have a lot of documentation and that are
part of an ecosystem (ie, gems required for other packages like
gitorious)
That's not specific to ruby. Again, we should follow existing
conventions.
--
Michael Scherer
Re: [Mageia-dev] Choosing packagers representatives
Le vendredi 07 janvier 2011 à 07:00 +0100, Daniel Kreuter a écrit : Am Freitag, 7. Januar 2011, um 01:38:39 schrieb Pascal Terjan: On Thu, Jan 6, 2011 at 23:55, Maarten Vanraes maarten.vanr...@gmail.com wrote: Op vrijdag 07 januari 2011 00:02:56 schreef Anne nicolas: Here are finally the results and detail of this vote https://epoll.mageia.org/vote/ISJTLYRT Thanks for participating! the voting is clear, but however: something odd is going on with epoll, and should be looked it, imho: there's invalid votes, but there's also a valid vote with a non-participant on it. (anssi) ? and sandro is there twice? perhaps there is still bugs in it? (not that it would change the results) Maybe invalid ballots are when people chose someone from the list of voters and not the list of candidates The question is, for what reason are these fields? When i voted i was questening myself what i should do with them so i left them blank as they were. But not everyone does so (as we can see now). I think that's because we do not really master epoll. The administration interface is not so hard to use, but could indeed be improved ( was on the TODO list before someone tricked me to do sysadmin for the project ). The bigger question i, why is the vote for anssi valid, but for stormi not (line 7)? Indeed. Maybe bugs, unfortunately, we only did smaller tests ( ie, check that 3/4 people who know how to vote could do it ). -- Michael Scherer
