Re: [Mageia-dev] Compatibility: %mdkversion macro?
Le dimanche 16 janvier 2011 00:07:56, Anssi Hannula a écrit : > Hi all! > > Should we have a %mdkversion (and %mdkver/%mdvver) that is hardcoded to > 201100 for the time being, or should we not have one at all? > > Not having it will cause any src.rpms that have any > "%if %mdkversion < x" to fail to build. > > I'm strongly in favor of having it for compatibility reasons, so that > most MDV src.rpms keep building on Mageia for the time being, including > those provided by any 3rd party packagers. > > Not having the macro will cause us to lose that compatibility for very > little benefit, IMO. It could maybe be removed after several releases, > but not before. > > However, it seems blino disagreed with this, and he thinks we should not > have these macros at all. > > What do other people think? If not having those macros means we can't compile mdv SRPMS on mageia, then I'd prefer we keep it. Regards Samuel Verschelde
[Mageia-dev] Compatibility: %mdkversion macro?
Hi all! Should we have a %mdkversion (and %mdkver/%mdvver) that is hardcoded to 201100 for the time being, or should we not have one at all? Not having it will cause any src.rpms that have any "%if %mdkversion < x" to fail to build. I'm strongly in favor of having it for compatibility reasons, so that most MDV src.rpms keep building on Mageia for the time being, including those provided by any 3rd party packagers. Not having the macro will cause us to lose that compatibility for very little benefit, IMO. It could maybe be removed after several releases, but not before. However, it seems blino disagreed with this, and he thinks we should not have these macros at all. What do other people think? -- Anssi Hannula
[Mageia-dev] mgarepo error
I am getting this error, but the package builds $ mgarepo submit svn+ssh://svn.mageia.org/svn/packages/cauldron/php-sasl -r 19483 Implicit target: cauldron No handlers could be found for logger "mgarepo" -- Thomas
Re: [Mageia-dev] Clarification on firmware licenses
On Sat, Jan 15, 2011 at 19:34, Thomas Backlund wrote: > Anssi Hannula skrev 15.1.2011 21:00: >> >> Hi all! >> >> Sorry for bringing this stuff up again, but it seems there is still some >> confusion regarding firmware licenses and to which repository put the >> various firmware packages. >> >> Clear cases: >> - open-source firmware with source code goes to core >> - firmware which doesn't allow modifications or has other similar >> restrictions goes to non-free >> >> However, what to do with firmware that is licensed under a free license >> (e.g. BSD/GPL) that doesn't have source code? >> There are quite a few of those (see e.g. [1]). >> >> A quick look at other distros shows the following: >> >> Debian: >> - All firmware without source code goes to non-free. > > > This is exactly how I have planned to clean up the firmware, > but I have not had the time yet... > I don't agree on that. A firmware under BSD licence is free data in my opinion whether or not it comes with source. On the opposite, anything under GPL without source "can't exist"... Either we consider it is GPL and we should be able to get source if requested and it has no reason to be in non-free, or it is not under GPL and can not be redistributed
Re: [Mageia-dev] Clarification on firmware licenses
Anssi Hannula skrev 15.1.2011 21:00: Hi all! Sorry for bringing this stuff up again, but it seems there is still some confusion regarding firmware licenses and to which repository put the various firmware packages. Clear cases: - open-source firmware with source code goes to core - firmware which doesn't allow modifications or has other similar restrictions goes to non-free However, what to do with firmware that is licensed under a free license (e.g. BSD/GPL) that doesn't have source code? There are quite a few of those (see e.g. [1]). A quick look at other distros shows the following: Debian: - All firmware without source code goes to non-free. This is exactly how I have planned to clean up the firmware, but I have not had the time yet... So kernel-firmware (wich belongs in core) and kernel-firmware-extra (wich belongs in nonfree) will have to be modified... Anything in kernel-firmware without proper license & source will be moved to kernel-firmware-extra. Anything in kernel-firmware-extra with open-source firmware and source will be moved to kernel-firmware. The same goes for every other firmware in the distro. -- Thomas
Re: [Mageia-dev] Importing RPM Spec File Syntax
Hi, > follow the convention of > [package_name]-[version]-[description].patch: > > * [package_name] is the name of the package it applies against, such > as 'shadow-utils' or 'gnupg' Sorry I can't get this... I mean i'm packaging foo, the spec file is for foo the patch is under foo svn directroy, is invoked by foo.spec... so what's the matter in that? > * [version] is the version of the program this patch was developed > against, such as 1.0. hmm in a first view i seconded it, but after a while again i can't see really why. I mean if a patch has been added into version 1.0 you can only know when has been added not if it's still valid. > The name of the patch should not change, even > when it is rediffed, because the version allow to see in a blink since But here if you changed the patch because of rediffing, it's not true that is for version 1.0, but for the new one. Otoh changing the name, means moving or deleting-adding a new patch under svn... So again no reason to add this field -imo of course-. > when this patch has been there. If you happen to see a patch that does > not apply anymore, and rediff it, ask the package maintainer if it has > been sent upstream, and why it hasn’t been merged, and send it > upstream if you think it should be merged. Good point. That should be always asked for since the patch was added by the packagers, but in my experienced i had packages in which passing upstream patches was very hard if not impossible. > * [description] is a short description of the patch's purpose. iirc there is a -b option to be passed to %patch in which you can add a string and again iirc that was used by packagers for a brief description so %patch0 -b string_format is at least clear as your example That also creates, iirc again, files used in patch with their name and string_format suffix (e.g. foo.c -> foo.c.string_format or similar). > Example: foo-1.0-fix-str-fmt.patch for a patch that fixes string format > errors in both cases your and mine (str-fmt and string_format) it's clear for the one who added the patch not the one who handles the package after, because the real point is not the patch itself but the reason of submitting it i believe. Maybe some comments concerning the patch and the patch reason could be clearer than few chars in a string name :) Just my thought of course :) Cheers, -- Angelo signature.asc Description: This is a digitally signed message part.
[Mageia-dev] Clarification on firmware licenses
Hi all! Sorry for bringing this stuff up again, but it seems there is still some confusion regarding firmware licenses and to which repository put the various firmware packages. Clear cases: - open-source firmware with source code goes to core - firmware which doesn't allow modifications or has other similar restrictions goes to non-free However, what to do with firmware that is licensed under a free license (e.g. BSD/GPL) that doesn't have source code? There are quite a few of those (see e.g. [1]). A quick look at other distros shows the following: Debian: - All firmware without source code goes to non-free. - No "GPL" firmware without source code at all, even in non-free (presumably because if Debian would distribute those files, Debian would have to provide the source code to comply with GPL, which it can't do because the source code isn't available at all). - No unknown-license firmware at all. Fedora: - All redistributable firmware is allowed in main repo (there is no non-free repo), even if non-free. - Unknown-license firmware is allowed only if it was previously distributed as part of kernel. Ubuntu: - All redistributable firmware is apparently allowed in main, even if non-free license with restrictions on modification. (this is in contrary to Ubuntu licensing page [2] which says that modification must be allowed for all packages in main). - Unknown-license firmware that was previously in kernel is also in main. - All other firmware files with no license at all is also allowed, in multiverse repository. Mandriva: - No sane policy, half of them is in non-free and the other half in main. - Unknown-license firmware is allowed only if it was previously distributed as part of kernel. [1] http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=blob;f=WHENCE;h=d807e25c5515d05ffe5fe949b480ae661eb079fb;hb=HEAD [2] http://www.ubuntu.com/project/about-ubuntu/licensing -- Anssi Hannula
Re: [Mageia-dev] Java-Policy first draft published
Le 10/01/2011 21:56, Romain d'Alverny a écrit : > > On Mon, Jan 10, 2011 at 21:02, Farfouille wrote: >> Licence discrepency : dokuwiki template says licence is 'CC >> Attribution-Share Alike 3.0 Unported' but web application policy >> (http://mageia.org/wiki/doku.php?id=web_applications_policy) claims >> 'Creative Commons Attribution-ShareAlike 2.5 License' (end of the page) > > I used the quick admin feature of dokuwiki to set it, only the 3.0 > Unported was used. I have still to learn/get the differences between > these versions (notwithstanding that the By-SA provisions mean the > same thing), or whether they are even conflicting (there may be a > natural update path in here). > > Anyway, help/insights (separate thread, please) about this is welcome. > > Romain > > Hi, I browsed through 'CC Attribution-Share Alike 3.0 Unported' on http://creativecommons.org/licenses/by-sa/3.0/legalcode and from the hereafter section, I understand that both licences are compatible "You may Distribute or Publicly Perform an Adaptation only under the terms of: (i) this License; (ii) a later version of this License with the same License Elements as this License; (iii) a Creative Commons jurisdiction license (either this or a later license version) that contains the same License Elements as this License (e.g., Attribution-ShareAlike 3.0 US)); (iv) a Creative Commons Compatible License. If you license the Adaptation under one of the licenses mentioned in (iv), you must comply with the terms of that license. If you license the Adaptation under the terms of any of the licenses mentioned in (i), (ii) or (iii) (the "Applicable License"), you must comply with the terms of the Applicable License generally and the following provisions: (I) You must include a copy of, or the URI for, the Applicable License with every copy of each Adaptation You Distribute or Publicly Perform; (II) You may not offer or impose any terms on the Adaptation that restrict the terms of th e Applicable License or the ability of the recipient of the Adaptation to exercise the rights granted to that recipient under the terms of the Applicable License; (III) You must keep intact all notices that refer to the Applicable License and to the disclaimer of warranties with every copy of the Work as included in the Adaptation You Distribute or Publicly Perform; (IV) when You Distribute or Publicly Perform the Adaptation, You may not impose any effective technological measures on the Adaptation that restrict the ability of a recipient of the Adaptation from You to exercise the rights granted to that recipient under the terms of the Applicable License. This Section 4(b) applies to the Adaptation as incorporated in a Collection, but this does not require the Collection apart from the Adaptation itself to be made subject to the terms of the Applicable License." Cheers -- Farfouille
Re: [Mageia-dev] Importing RPM Spec File Syntax
On Sat, Jan 15, 2011 at 02:01:34PM +0100, Maarten Vanraes wrote: > imo, the source should be applied as well. this would allow us to find the > 'next version of a patch' more easily. Well, as far as I’m concerned, I’m not a fan of overly long names. I think these info could be located at the top of the patch inside, like the suggestion mikala made for describing the purpose of the patch. Regards, -- Rémy CLOUARD pgpHVrHqtZDPT.pgp Description: PGP signature
Re: [Mageia-dev] Importing RPM Spec File Syntax
Op zaterdag 15 januari 2011 14:01:51 schreef John Balcaen: > 2011/1/15 Remy CLOUARD : > > Hi there, > > Hello, > > > I just imported the RPM Spec File Syntax page in the wiki. > > > > It’s located here: http://mageia.org/wiki/doku.php?id=spec_syntax > > > > Please review this page as it’s one of the most important one for the > > beginning of the mentoring process, with the RPM Howto page (yet to be > > imported). > > > > Some comments on this page: > > - Patch naming: > > > > I’m not sure we should go that far for the patch naming policy, and in > > practice it’s not what I’ve seen up till now. > > > > Here’s a proposal: > > Patches must be named in a very explicit manner to make it very clear to > > what version it was originally applied. To that end, a patch needs to > > follow the convention of > > [package_name]-[version]-[description].patch: > > > > * [package_name] is the name of the package it applies against, such > > as 'shadow-utils' or 'gnupg' > > * [version] is the version of the program this patch was developed > > against, such as 1.0. The name of the patch should not change, even > > when it is rediffed, because the version allow to see in a blink since > > when this patch has been there. If you happen to see a patch that does > > not apply anymore, and rediff it, ask the package maintainer if it has > > been sent upstream, and why it hasn’t been merged, and send it > > upstream if you think it should be merged. > > * [description] is a short description of the patch's purpose. > > > > Example: foo-1.0-fix-str-fmt.patch for a patch that fixes string format > > errors > > It would also be nice to add some comment inside like we're trying to do in > our kde's packaging policy ( > http://www.mageia.org/wiki/doku.php?id=kde4_packaging_policy ) > aka > # > # Description: > # Forwarded: > # Bug: > # Author: > # git-svn patches have description automatically, if that format is also ok, i see no reason why not. perhaps some emphasis on git-svn should be made on the wiki, relating to patches. > > - Buildroot changed from the original page > > > > After reviewing it again, I see that some links have to be made to the > > corresponding pages, and an explicit license should be mentionned as > > well. > > [...] > Regarding the spec we've got at least a major difference in our kde's spec > For example not all the %define are localized at the top of the > spec,especially thoses for macro & libname : it's easier for me to have > some of them in the same part.Maybe it's due to our will massive > libification, but having more then 15 > %define for macro & libname without knowing which package is affected. > Also maybe others can find useful to have the %files list for every > package listed > under their description (instead of having all of them after the > %prep,%build etc part ) > > Regards, Personally, i agree regarding the %files part to be under their respective %description and having build stuff on the bottom part. I like that idea. regarding defines, i don't understand completely, but i am in favor of having all defines up top.
Re: [Mageia-dev] Importing RPM Spec File Syntax
Op zaterdag 15 januari 2011 11:08:27 schreef Remy CLOUARD: > Hi there, > > I just imported the RPM Spec File Syntax page in the wiki. > > It’s located here: http://mageia.org/wiki/doku.php?id=spec_syntax > > Please review this page as it’s one of the most important one for the > beginning of the mentoring process, with the RPM Howto page (yet to be > imported). > > Some comments on this page: > - Patch naming: > > I’m not sure we should go that far for the patch naming policy, and in > practice it’s not what I’ve seen up till now. > > Here’s a proposal: > Patches must be named in a very explicit manner to make it very clear to > what version it was originally applied. To that end, a patch needs to > follow the convention of > [package_name]-[version]-[description].patch: > > * [package_name] is the name of the package it applies against, such > as 'shadow-utils' or 'gnupg' > * [version] is the version of the program this patch was developed > against, such as 1.0. The name of the patch should not change, even > when it is rediffed, because the version allow to see in a blink since > when this patch has been there. If you happen to see a patch that does > not apply anymore, and rediff it, ask the package maintainer if it has > been sent upstream, and why it hasn’t been merged, and send it > upstream if you think it should be merged. > * [description] is a short description of the patch's purpose. > > Example: foo-1.0-fix-str-fmt.patch for a patch that fixes string format > errors > > - Buildroot changed from the original page > > After reviewing it again, I see that some links have to be made to the > corresponding pages, and an explicit license should be mentionned as > well. > > Thanks for reviewing this page, > > Regards, i approve for macro %cleanbuildroot to be created (or to do it automagically in %clean and %install
Re: [Mageia-dev] Importing RPM Spec File Syntax
Op zaterdag 15 januari 2011 11:08:27 schreef Remy CLOUARD: > Hi there, > > I just imported the RPM Spec File Syntax page in the wiki. > > It’s located here: http://mageia.org/wiki/doku.php?id=spec_syntax > > Please review this page as it’s one of the most important one for the > beginning of the mentoring process, with the RPM Howto page (yet to be > imported). > > Some comments on this page: > - Patch naming: > > I’m not sure we should go that far for the patch naming policy, and in > practice it’s not what I’ve seen up till now. > > Here’s a proposal: > Patches must be named in a very explicit manner to make it very clear to > what version it was originally applied. To that end, a patch needs to > follow the convention of > [package_name]-[version]-[description].patch: > > * [package_name] is the name of the package it applies against, such > as 'shadow-utils' or 'gnupg' > * [version] is the version of the program this patch was developed > against, such as 1.0. The name of the patch should not change, even > when it is rediffed, because the version allow to see in a blink since > when this patch has been there. If you happen to see a patch that does > not apply anymore, and rediff it, ask the package maintainer if it has > been sent upstream, and why it hasn’t been merged, and send it > upstream if you think it should be merged. > * [description] is a short description of the patch's purpose. > > Example: foo-1.0-fix-str-fmt.patch for a patch that fixes string format > errors > > - Buildroot changed from the original page > > After reviewing it again, I see that some links have to be made to the > corresponding pages, and an explicit license should be mentionned as > well. > > Thanks for reviewing this page, > > Regards, buildroot isn't removed everywhere
Re: [Mageia-dev] Importing RPM Spec File Syntax
2011/1/15 Remy CLOUARD : > Hi there, Hello, > I just imported the RPM Spec File Syntax page in the wiki. > > It’s located here: http://mageia.org/wiki/doku.php?id=spec_syntax > > Please review this page as it’s one of the most important one for the > beginning of the mentoring process, with the RPM Howto page (yet to be > imported). > > Some comments on this page: > - Patch naming: > > I’m not sure we should go that far for the patch naming policy, and in > practice it’s not what I’ve seen up till now. > > Here’s a proposal: > Patches must be named in a very explicit manner to make it very clear to > what version it was originally applied. To that end, a patch needs to > follow the convention of > [package_name]-[version]-[description].patch: > > * [package_name] is the name of the package it applies against, such > as 'shadow-utils' or 'gnupg' > * [version] is the version of the program this patch was developed > against, such as 1.0. The name of the patch should not change, even > when it is rediffed, because the version allow to see in a blink since > when this patch has been there. If you happen to see a patch that does > not apply anymore, and rediff it, ask the package maintainer if it has > been sent upstream, and why it hasn’t been merged, and send it > upstream if you think it should be merged. > * [description] is a short description of the patch's purpose. > > Example: foo-1.0-fix-str-fmt.patch for a patch that fixes string format > errors It would also be nice to add some comment inside like we're trying to do in our kde's packaging policy ( http://www.mageia.org/wiki/doku.php?id=kde4_packaging_policy ) aka # # Description: # Forwarded: # Bug: # Author: # > - Buildroot changed from the original page > After reviewing it again, I see that some links have to be made to the > corresponding pages, and an explicit license should be mentionned as > well. > [...] Regarding the spec we've got at least a major difference in our kde's spec For example not all the %define are localized at the top of the spec,especially thoses for macro & libname : it's easier for me to have some of them in the same part.Maybe it's due to our will massive libification, but having more then 15 %define for macro & libname without knowing which package is affected. Also maybe others can find useful to have the %files list for every package listed under their description (instead of having all of them after the %prep,%build etc part ) Regards, -- Balcaen John Jabber-Id: mik...@jabber.littleboboy.net
Re: [Mageia-dev] Importing RPM Spec File Syntax
Op zaterdag 15 januari 2011 11:08:27 schreef Remy CLOUARD: > Hi there, > > I just imported the RPM Spec File Syntax page in the wiki. > > It’s located here: http://mageia.org/wiki/doku.php?id=spec_syntax > > Please review this page as it’s one of the most important one for the > beginning of the mentoring process, with the RPM Howto page (yet to be > imported). > > Some comments on this page: > - Patch naming: > > I’m not sure we should go that far for the patch naming policy, and in > practice it’s not what I’ve seen up till now. > > Here’s a proposal: > Patches must be named in a very explicit manner to make it very clear to > what version it was originally applied. To that end, a patch needs to > follow the convention of > [package_name]-[version]-[description].patch: > > * [package_name] is the name of the package it applies against, such > as 'shadow-utils' or 'gnupg' > * [version] is the version of the program this patch was developed > against, such as 1.0. The name of the patch should not change, even > when it is rediffed, because the version allow to see in a blink since > when this patch has been there. If you happen to see a patch that does > not apply anymore, and rediff it, ask the package maintainer if it has > been sent upstream, and why it hasn’t been merged, and send it > upstream if you think it should be merged. > * [description] is a short description of the patch's purpose. > > Example: foo-1.0-fix-str-fmt.patch for a patch that fixes string format > errors > > - Buildroot changed from the original page > > After reviewing it again, I see that some links have to be made to the > corresponding pages, and an explicit license should be mentionned as > well. > > Thanks for reviewing this page, > > Regards, imo, the source should be applied as well. this would allow us to find the 'next version of a patch' more easily.
Re: [Mageia-dev] Importing RPM Spec File Syntax
Op zaterdag 15 januari 2011 11:24:52 schreef Cazzaniga Sandro: > Le 15/01/2011 11:08, Remy CLOUARD a écrit : > > Here’s a proposal: > > Patches must be named in a very explicit manner to make it very clear to > > what version it was originally applied. To that end, a patch needs to > > follow the convention of > > > > [package_name]-[version]-[description].patch: > > * [package_name] is the name of the package it applies against, such > > as 'shadow-utils' or 'gnupg' > > * [version] is the version of the program this patch was developed > > against, such as 1.0. The name of the patch should not change, even > > when it is rediffed, because the version allow to see in a blink since > > when this patch has been there. If you happen to see a patch that does > > not apply anymore, and rediff it, ask the package maintainer if it has > > been sent upstream, and why it hasn’t been merged, and send it > > upstream if you think it should be merged. > > * [description] is a short description of the patch's purpose. > > > > Example: foo-1.0-fix-str-fmt.patch for a patch that fixes string format > > errors > > I'm okay for naming patches as you say. It's clean and clear, we > understand well what a mistake they correspond. i disagree with the patch naming: if you rediff a patch, i assume you test it out too, which means it was 'developped' for the current version, and i would like people to start using this version. ie: rediffing is development too.
Re: [Mageia-dev] package import policy
Op zaterdag 15 januari 2011 09:48:42 schreef Remy CLOUARD: > On Sat, Jan 15, 2011 at 01:01:33AM +0100, Maarten Vanraes wrote: > > The wiki page lists method to import a package: > > ( http://www.mageia.org/wiki/doku.php?id=packaging ) > > > > so, i followed every step, then contacted my mentor, only it seems the > > process is not used like that; it seems 2 ways are used; and the one > > used most (by people i know) is not the one that is on the wiki page. > > > > So, i would like to list both on the wiki page, so it is clearer. > > > > this is what i would put for in between step 4 and 5 > > > > - a second possibility is: > > - Read the [[svn-faq|FAQ]] about the new SVN > > - Download the SRPM from a Mandriva Mirror. The rationale behind this > > is > > > > to keep history for past changes in the RPM (there is a pre-rpm5 mdv srpm > > mirror http://tmb.mine.nu/Mageia/Cauldron/mdv-SRPMS-pre-rpm5/ ) > > > > - Check it does not have unlicensed Mandriva stuff: image (icons), > > video, > > > > audio files, other > > > > - Check it does have a clear, explicit license with it. > > - Check software license ( free or not, existence of license file) > > - Rebuild the SRPM (with bm -sl for instance) > > - Import the packages with **mgarepo** import package.src.rpm. Be > > sure to > > > > run this command under your ssh-agent, otherwise import will fail > > > > - Check out the imported version in a repository with mgarepo > > - Check it does not have "mandriva" / "mandrake" occurrences used as > > a > > > > brand/name in the software (history/changelog is ok, emails for > > references are ok) > > > > - Update software on last stable version > > - Send patches upstream if possible > > - Remove useless cruft ( like macro that no longer apply ) > > > > - Buildroot is no longer necessary > > - %mdkversion > > - ldconfig in post (handled by filetriggers) > > > > - commit the update with a good commit message. > > > > any objections? > > So, that means performing the import first, and then commit your changes > inside SVN. Well, I’d say why not, it would help other people review the > changes, and we would also be sure that it’s well formatted too. > > If everyone agree, I’d say we just replace the content on the wiki with > your proposal No this is not a proposal. I'm saying that it seems to me that most people currently importing packages at this moment seem to be using this method, instead of the method proposed on the wiki. That's why i feel that i should add this (along with the other method) to the wiki, to avoid confusion. Pending disapproval of currently active package importers.
Re: [Mageia-dev] Importing RPM Spec File Syntax
Le 15/01/2011 11:08, Remy CLOUARD a écrit : > Here’s a proposal: > Patches must be named in a very explicit manner to make it very clear to > what version it was originally applied. To that end, a patch needs to > follow the convention of > [package_name]-[version]-[description].patch: > > * [package_name] is the name of the package it applies against, such > as 'shadow-utils' or 'gnupg' > * [version] is the version of the program this patch was developed > against, such as 1.0. The name of the patch should not change, even > when it is rediffed, because the version allow to see in a blink since > when this patch has been there. If you happen to see a patch that does > not apply anymore, and rediff it, ask the package maintainer if it has > been sent upstream, and why it hasn’t been merged, and send it > upstream if you think it should be merged. > * [description] is a short description of the patch's purpose. > > Example: foo-1.0-fix-str-fmt.patch for a patch that fixes string format > errors > I'm okay for naming patches as you say. It's clean and clear, we understand well what a mistake they correspond. -- Sandro Cazzaniga IRC: Kharec (irc.freenode.net) Twitter: @Kharec
Re: [Mageia-dev] Importing RPM Spec File Syntax
Le 15/01/2011 11:08, Remy CLOUARD a écrit : > Hi there, > > I just imported the RPM Spec File Syntax page in the wiki. > > It’s located here: http://mageia.org/wiki/doku.php?id=spec_syntax > > Please review this page as it’s one of the most important one for the > beginning of the mentoring process, with the RPM Howto page (yet to be > imported). > > Some comments on this page: > - Patch naming: > > I’m not sure we should go that far for the patch naming policy, and in > practice it’s not what I’ve seen up till now. > > Here’s a proposal: > Patches must be named in a very explicit manner to make it very clear to > what version it was originally applied. To that end, a patch needs to > follow the convention of > [package_name]-[version]-[description].patch: > > * [package_name] is the name of the package it applies against, such > as 'shadow-utils' or 'gnupg' > * [version] is the version of the program this patch was developed > against, such as 1.0. The name of the patch should not change, even > when it is rediffed, because the version allow to see in a blink since > when this patch has been there. If you happen to see a patch that does > not apply anymore, and rediff it, ask the package maintainer if it has > been sent upstream, and why it hasn’t been merged, and send it > upstream if you think it should be merged. > * [description] is a short description of the patch's purpose. > > Example: foo-1.0-fix-str-fmt.patch for a patch that fixes string format > errors > > - Buildroot changed from the original page > > After reviewing it again, I see that some links have to be made to the > corresponding pages, and an explicit license should be mentionned as > well. > > Thanks for reviewing this page, > > Regards, I will review this page. I begin now. -- Sandro Cazzaniga IRC: Kharec (irc.freenode.net) Twitter: @Kharec
[Mageia-dev] Importing RPM Spec File Syntax
Hi there, I just imported the RPM Spec File Syntax page in the wiki. It’s located here: http://mageia.org/wiki/doku.php?id=spec_syntax Please review this page as it’s one of the most important one for the beginning of the mentoring process, with the RPM Howto page (yet to be imported). Some comments on this page: - Patch naming: I’m not sure we should go that far for the patch naming policy, and in practice it’s not what I’ve seen up till now. Here’s a proposal: Patches must be named in a very explicit manner to make it very clear to what version it was originally applied. To that end, a patch needs to follow the convention of [package_name]-[version]-[description].patch: * [package_name] is the name of the package it applies against, such as 'shadow-utils' or 'gnupg' * [version] is the version of the program this patch was developed against, such as 1.0. The name of the patch should not change, even when it is rediffed, because the version allow to see in a blink since when this patch has been there. If you happen to see a patch that does not apply anymore, and rediff it, ask the package maintainer if it has been sent upstream, and why it hasn’t been merged, and send it upstream if you think it should be merged. * [description] is a short description of the patch's purpose. Example: foo-1.0-fix-str-fmt.patch for a patch that fixes string format errors - Buildroot changed from the original page After reviewing it again, I see that some links have to be made to the corresponding pages, and an explicit license should be mentionned as well. Thanks for reviewing this page, Regards, -- Rémy CLOUARD () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments pgp4Guvue2dlG.pgp Description: PGP signature
Re: [Mageia-dev] package import policy
On Sat, Jan 15, 2011 at 01:01:33AM +0100, Maarten Vanraes wrote: > The wiki page lists method to import a package: > ( http://www.mageia.org/wiki/doku.php?id=packaging ) > > so, i followed every step, then contacted my mentor, only it seems the > process > is not used like that; it seems 2 ways are used; and the one used most (by > people i know) is not the one that is on the wiki page. > > So, i would like to list both on the wiki page, so it is clearer. > > this is what i would put for in between step 4 and 5 > > - a second possibility is: > - Read the [[svn-faq|FAQ]] about the new SVN > - Download the SRPM from a Mandriva Mirror. The rationale behind this is > to keep history for past changes in the RPM (there is a pre-rpm5 mdv srpm > mirror http://tmb.mine.nu/Mageia/Cauldron/mdv-SRPMS-pre-rpm5/ ) > - Check it does not have unlicensed Mandriva stuff: image (icons), video, > audio files, other > - Check it does have a clear, explicit license with it. > - Check software license ( free or not, existence of license file) > - Rebuild the SRPM (with bm -sl for instance) > - Import the packages with **mgarepo** import package.src.rpm. Be sure to > run this command under your ssh-agent, otherwise import will fail > - Check out the imported version in a repository with mgarepo > - Check it does not have "mandriva" / "mandrake" occurrences used as a > brand/name in the software (history/changelog is ok, emails for references > are > ok) > - Update software on last stable version > - Send patches upstream if possible > - Remove useless cruft ( like macro that no longer apply ) > - Buildroot is no longer necessary > - %mdkversion > - ldconfig in post (handled by filetriggers) > - commit the update with a good commit message. > > > any objections? So, that means performing the import first, and then commit your changes inside SVN. Well, I’d say why not, it would help other people review the changes, and we would also be sure that it’s well formatted too. If everyone agree, I’d say we just replace the content on the wiki with your proposal Regards, -- Rémy CLOUARD () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments pgpIjTfoWZ1cq.pgp Description: PGP signature
Re: [Mageia-dev] Is libesd needed anymore?
On Sat, Jan 15, 2011 at 12:37 AM, Ahmad Samir wrote: > On 15 January 2011 01:18, Maarten Vanraes wrote: >> Op vrijdag 14 januari 2011 13:22:54 schreef Colin Guthrie: >>> Hi, >>> >>> When importing packages, I'm very tempted to not import esound. It's >>> only used to compile libesd. Do we really need it? >>> >>> I don't think we ship any apps that use only esd, so I don't think >>> that's a problem but perhaps some old legacy apps (i.e. games) still >>> need it. >>> >>> What do people think? It's not really much hassle to support it, but by >>> the same token, dead projects have to be buried at some point! >>> >>> Col >> >> I don't fully agree, dead projects can stay alive (undead). >> >> however, just don't import it, don't have support for it in gnome. and if >> someone really needs it, he can import it and maintain it if he wants to. >> >> in short, drop it and let someone else figure it out at a later date. >> > > Well, no, dead projects are just that, dead... > > And if libesd is dropped all packages that BR it need to be fixed; > maybe postpone this until the importing rush is over, then it can be > phased out after this high pressure stage is over.. (just MHO). > > -- > Ahmad Samir > i think coling is right and this is the best moment to drop packages as we won't have to rebuild anything after dropping it
