Re: [Mageia-dev] Importing RPM Spec File Syntax
Luca Berra schrieb am 2011-01-19 > "Name: foo" > appers to be working > in rpm 4.6 "Version: foo" is totally borked, dunno with rpm 5 > this is why i will continue on using macros for version and > release. %define myver 1.0 > %define myrel %mkrel 1 > > Name: foo > Version: %myver > Release: %myrel Can't follow you there: what is or is not working with "Version: foo" or "Release: %mkrel foo"? Oliver
Re: [Mageia-dev] Importing RPM Spec File Syntax
'Twas brillig, and Oliver Burger at 19/01/11 08:07 did gyre and gimble: > Luca Berra schrieb am 2011-01-19 >> "Name: foo" >> appers to be working >> in rpm 4.6 "Version: foo" is totally borked, dunno with rpm 5 >> this is why i will continue on using macros for version and >> release. %define myver 1.0 >> %define myrel %mkrel 1 >> >> Name: foo >> Version: %myver >> Release: %myrel > > Can't follow you there: what is or is not working with > "Version: foo" or "Release: %mkrel foo"? I think he's saying that if you do this: Name: foo then you can subsequently use %name elsewhere in the spec and all will be well. But if you use: Version: 1.0 then you cannot use %version elsewhere in the spec. So defining it manually is the best way to do it so it can be used elsewhere. However, I could not replicate that here on my pre-RPM5 cooker box. Using the version with the tag and using %version worked just fine. So I think I have misinterpreted too :s Col -- Colin Guthrie mageia(at)colin.guthr.ie 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] Importing RPM Spec File Syntax
On 19 January 2011 10:24, Colin Guthrie wrote: > I think he's saying that if you do this: > Name: foo > then you can subsequently use %name elsewhere in the spec and all will > be well. > > But if you use: > Version: 1.0 > then you cannot use %version elsewhere in the spec. > > So defining it manually is the best way to do it so it can be used > elsewhere. > > However, I could not replicate that here on my pre-RPM5 cooker box. > Using the version with the tag and using %version worked just fine. So I > think I have misinterpreted too :s Indeed since I've used "Version: 1.0" for 12 years...
[Mageia-dev] 19/01/2011 meeting
Hi there Next meeting will happen tonigh on #mageia-dev at 20h UTC. Here are our topics: - Review of build system and distro bootstrap - Proposal for mentoring process (wiki page will be updated today): review and comments - Review on current mentoring process and people concerned - Review on policies import As usual feel free to propose any other topic provided our meeting stay in human timetable :). It would be great to have a short one this time and keep something longer for next one as it will be last wednesday of january. Cheers -- Anne http://www.mageia.org
Re: [Mageia-dev] Python Packaging Policy
2011/1/19 Michael scherer : > Because that would 1) requires a patch to rpm that we do not have or > 2) patch all python packages to had %ghost on all *.pyc, and do a > compilation of > *pyc ( the 2nd part is easy, the first one is slightly harder to automate ) > 3) do not care about file tracking, but that's unclean. > > Do not get me wrong, I think that's the way forward, but that's not applicable > in a few days. of course Can we forget for a little Mandriva and talk about Mageia ? I mean, we are before the alpha stage, so it's time to think about what the future can be did you read the OpenSuse policy ? http://en.opensuse.org/openSUSE:Packaging_Python of course the best solution would be be to put into the rpm only *.py, bitcompilling them at install and trac *.pyc and *.pyo as %ghost but it seems that neither Fedora, neither OpenSuse have problem to package bitcompiled files (the %fdupes OpenSuse solution seems not bad) or can we patch distutils/command/install.py even more than OpenSuse (https://build.opensuse.org/package/view_file?file=python-distutils-rpm-8.patch&package=python&project=home%3Acoolo%3Abranches%3AopenSUSE%3AFactory&srcmd5=25a3587ace933a14ae62edfc4cd927b7) did, to generate a rpm-compatible format that would manage %ghost ?
Re: [Mageia-dev] Python Packaging Policy
On Wed, 19 Jan 2011 08:25:23 +0100 Michael scherer wrote: > > > I'm not sure about "twice the work": you don't need to track twice the > > software releases (except for the interpreter itself), or twice the > > upstream patches, etc. > > Well, if we handle this like 2 separates languages, that mean 2 separates > rpms for > each modules. Or we should be clever when generating 1 rpm to have the modules > for both python 3 and python 2 generated ( Except when the developper did > choose > to have separate tarball or code base ) > Having one rpm that produces 2 modules also mean that we will rebuild all > modules > for python3 and all for python2, and I know that for example Buchan will not > like > the extranous trafic it would generate. Well AFAIK some other distros (not Debian and Ubuntu which have a more complicated system) have separate packages per interpreter version (python2.4-twisted, python2.6-twisted, etc.). But you can put all versions in a single package too. I see no hard reason against that. Regards Antoine.
[Mageia-dev] background and theme path
Hi, I'd like to move away from the hardcoded backgrounds location for themes, and put them in a distro-neutral path (was /usr/share/mdk/backgrounds/ in Mandriva) Most Gnome backgrounds appear to be located in /usr/share/pixmaps/backgrounds/ (some are in /usr/share/backgrounds/) Is everyone ok to have our backgrounds in /usr/share/pixmaps/backgrounds// and the distro default as /usr/share/pixmaps/backgrounds/default.jpg ? Thanks -- Olivier Blin - blino
Re: [Mageia-dev] background and theme path
Donald Stewart On 19 January 2011 12:06, Olivier Blin wrote: > Hi, > > I'd like to move away from the hardcoded backgrounds location for > themes, and put them in a distro-neutral path > (was /usr/share/mdk/backgrounds/ in Mandriva) > > Most Gnome backgrounds appear to be located in > /usr/share/pixmaps/backgrounds/ (some are in /usr/share/backgrounds/) > > Is everyone ok to have our backgrounds in > /usr/share/pixmaps/backgrounds// and the distro default as > /usr/share/pixmaps/backgrounds/default.jpg ? > > Thanks > > -- > Olivier Blin - blino > KDE uses a different path, I think that it is /usr/share/wallpapers or similar, maybe a symlink would be useful.
Re: [Mageia-dev] Importing RPM Spec File Syntax
On 15 January 2011 12:08, Remy CLOUARD wrote: > 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, I don't agree, if you rediff the patch against version 2.0 the the version in the patch name should change; one reason is, it can't be applied to version 1.0 any more without restoring the old patch from an older SVN rev. or rediffing it again. [...] > -- > Rémy CLOUARD > () ascii ribbon campaign - against html e-mail > /\ www.asciiribbon.org - against proprietary attachments > > -- Ahmad Samir
Re: [Mageia-dev] Importing RPM Spec File Syntax
On 17 January 2011 23:53, Florian Hubold wrote: > Am 15.01.2011 11:08, schrieb Remy CLOUARD: >> >> 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). > > I have one comment, or more of a question: Why is it that some time ago > there used to be this syntax as de-facto standard: > > %define name > Name: %name > > Never understood this, so i went with what seems the new standard, > which saves you at least 3 lines per spec and improving readability. > > So anyone can enlighten me why name, release and version had %defines? > Just more visibility, ideally it comes down to that package maintainer's preference. (One point to note, if you see it in an unmaintained package go ahead and change it if you want; however if you see it in the spec of maintained package, ask the maintainer first, a nicety but still.. :)). -- Ahmad Samir
Re: [Mageia-dev] background and theme path
On Wed, Jan 19, 2011 at 01:06:49PM +0100, Olivier Blin wrote: > Hi, > > I'd like to move away from the hardcoded backgrounds location for > themes, and put them in a distro-neutral path > (was /usr/share/mdk/backgrounds/ in Mandriva) > > Most Gnome backgrounds appear to be located in > /usr/share/pixmaps/backgrounds/ (some are in /usr/share/backgrounds/) > > Is everyone ok to have our backgrounds in > /usr/share/pixmaps/backgrounds// and the distro default as > /usr/share/pixmaps/backgrounds/default.jpg ? > > Thanks Well, I’d say it would be better if it were also desktop-neutral. AFAIK, there is one freedesktop specification for icons [1], but not for wallpapers, it would be nice to raise this subject on fd.o ml. I don’t know which package owns /usr/share/pixmaps/backgrounds/, but apparently it’s not desktop-common-data. I would rather not having to install gnome packages/kde packages for that. Regards, [1] http://www.freedesktop.org/wiki/Specifications/icon-theme-spec -- Rémy CLOUARD () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments pgpIdK61PzyjD.pgp Description: PGP signature
Re: [Mageia-dev] background and theme path
Remy CLOUARD writes: > On Wed, Jan 19, 2011 at 01:06:49PM +0100, Olivier Blin wrote: >> I'd like to move away from the hardcoded backgrounds location for >> themes, and put them in a distro-neutral path >> (was /usr/share/mdk/backgrounds/ in Mandriva) >> >> Most Gnome backgrounds appear to be located in >> /usr/share/pixmaps/backgrounds/ (some are in /usr/share/backgrounds/) >> >> Is everyone ok to have our backgrounds in >> /usr/share/pixmaps/backgrounds// and the distro default as >> /usr/share/pixmaps/backgrounds/default.jpg ? >> > Well, I’d say it would be better if it were also desktop-neutral. > > AFAIK, there is one freedesktop specification for icons [1], but not for > wallpapers, it would be nice to raise this subject on fd.o ml. We can raise the subject there, but we should have a fast short-term decision for Mageia as well, this is blocking for packages import. So that would be either /usr/share/pixmaps/backgrounds, /usr/share/wallpapers, or /usr/share/backgrounds Any idea about how other distros are handling this? > I don’t know which package owns /usr/share/pixmaps/backgrounds/, but > apparently it’s not desktop-common-data. I would rather not having to > install gnome packages/kde packages for that. No packages owns it yet. $ LC_ALL=C rpm -qf /usr/share/pixmaps/backgrounds/ file /usr/share/pixmaps/backgrounds is not owned by any package -- Olivier Blin - blino
Re: [Mageia-dev] background and theme path
On 19 January 2011 15:02, Olivier Blin wrote: > Remy CLOUARD writes: > >> On Wed, Jan 19, 2011 at 01:06:49PM +0100, Olivier Blin wrote: >>> I'd like to move away from the hardcoded backgrounds location for >>> themes, and put them in a distro-neutral path >>> (was /usr/share/mdk/backgrounds/ in Mandriva) >>> >>> Most Gnome backgrounds appear to be located in >>> /usr/share/pixmaps/backgrounds/ (some are in /usr/share/backgrounds/) >>> >>> Is everyone ok to have our backgrounds in >>> /usr/share/pixmaps/backgrounds// and the distro default as >>> /usr/share/pixmaps/backgrounds/default.jpg ? >>> >> Well, I’d say it would be better if it were also desktop-neutral. >> >> AFAIK, there is one freedesktop specification for icons [1], but not for >> wallpapers, it would be nice to raise this subject on fd.o ml. > > We can raise the subject there, but we should have a fast short-term > decision for Mageia as well, this is blocking for packages import. > > So that would be either /usr/share/pixmaps/backgrounds, /usr/share/wallpapers, > or /usr/share/backgrounds > > Any idea about how other distros are handling this? > >> I don’t know which package owns /usr/share/pixmaps/backgrounds/, but >> apparently it’s not desktop-common-data. I would rather not having to >> install gnome packages/kde packages for that. > > No packages owns it yet. > $ LC_ALL=C rpm -qf /usr/share/pixmaps/backgrounds/ > file /usr/share/pixmaps/backgrounds is not owned by any package > > -- > Olivier Blin - blino > gnome-screensaver uses /usr/share/backgrounds. I think /usr/share/wallpapers is the best one. -- Ahmad Samir
Re: [Mageia-dev] Not present at tonight meeting ( again )
2011/1/19 Michael scherer : > Hi, > I will not be present at the packagers's meeting tonight, as > I will likely be finishing the app installer meeting in > Nuremberg ( transalte : discuss in a pub ). > The wifi is expensive, and so I had to use ninja > powers to get ssh access ( translate : use mad h4x0r > skill ). > So sorry, especially for ennael that I let do the work. > -- > Michael Scherer > I just wanted to say : I'll never be present on Wednesday evenings for a year, due to personal agenda. So, if you (the people who meet) could find a way to not meet on the same day every week, I'll be most than thankful. And no, I can't change my agenda. It was like that even before mageia was created. Who am I ? Well, I'm just trying to be a mageia packager :P -- Ludovic Bellière
Re: [Mageia-dev] Importing RPM Spec File Syntax
On Wed, Jan 19, 2011 at 02:44:35PM +0200, Ahmad Samir wrote: > On 15 January 2011 12:08, Remy CLOUARD wrote: > > 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, > > I don't agree, if you rediff the patch against version 2.0 the the > version in the patch name should change; one reason is, it can't be > applied to version 1.0 any more without restoring the old patch from > an older SVN rev. or rediffing it again. But that mean we lose history of svn ? -- Michael Scherer
Re: [Mageia-dev] Importing RPM Spec File Syntax
Michael scherer skrev 19.1.2011 15:30: On Wed, Jan 19, 2011 at 02:44:35PM +0200, Ahmad Samir wrote: On 15 January 2011 12:08, Remy CLOUARD wrote: 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, I don't agree, if you rediff the patch against version 2.0 the the version in the patch name should change; one reason is, it can't be applied to version 1.0 any more without restoring the old patch from an older SVN rev. or rediffing it again. But that mean we lose history of svn ? svn mv old_patch_name new_patch_name and then update new_patch_name to apply correctly. -- Thomas
Re: [Mageia-dev] background and theme path
1. Leave them where they are for now (breaks less things) and 2. pursue standardization with freedesktop.org, then 3. adopt that standard. Done in three. -- Hoyt
Re: [Mageia-dev] background and theme path
Hoyt Duff writes: > 1. Leave them where they are for now (breaks less things) and > > 2. pursue standardization with freedesktop.org, then > > 3. adopt that standard. > > Done in three. I wouldn't want to keep a path with "mdk" inside, even temporarily -- Olivier Blin - blino
Re: [Mageia-dev] background and theme path
I understand your sentiment. Given unlimited resources, it is an acceptable choice. I'm not advocating ignoring it. Nor am I saying it should continue unabated. I'm advocating a way to 'solve' the problem on a long-term basis with a minimum of hassle. As a matter of expediency, it does no harm to maintain the status quo (especially since this item is not obvious to the typical newbie user) and frees time and resources for more pressing, if less ideological , needs. On 1/19/11, Olivier Blin wrote: > Hoyt Duff writes: > >> 1. Leave them where they are for now (breaks less things) and >> >> 2. pursue standardization with freedesktop.org, then >> >> 3. adopt that standard. >> >> Done in three. > > I wouldn't want to keep a path with "mdk" inside, even temporarily > > -- > Olivier Blin - blino > -- Hoyt
Re: [Mageia-dev] Not present at tonight meeting ( again )
On 19.01.2011 02:12, Michael scherer wrote: > Hi, > I will not be present at the packagers's meeting tonight, as > I will likely be finishing the app installer meeting in > Nuremberg ( transalte : discuss in a pub ). > The wifi is expensive, and so I had to use ninja > powers to get ssh access ( translate : use mad h4x0r > skill ). > So sorry, especially for ennael that I let do the work. Unfortunately I'll miss the meeting as well. -- Anssi Hannula
Re: [Mageia-dev] background and theme path
Ahmad Samir writes: I'd like to move away from the hardcoded backgrounds location for themes, and put them in a distro-neutral path (was /usr/share/mdk/backgrounds/ in Mandriva) Most Gnome backgrounds appear to be located in /usr/share/pixmaps/backgrounds/ (some are in /usr/share/backgrounds/) Is everyone ok to have our backgrounds in /usr/share/pixmaps/backgrounds// and the distro default as /usr/share/pixmaps/backgrounds/default.jpg ? >>> Well, I’d say it would be better if it were also desktop-neutral. >>> >>> AFAIK, there is one freedesktop specification for icons [1], but not for >>> wallpapers, it would be nice to raise this subject on fd.o ml. >> >> We can raise the subject there, but we should have a fast short-term >> decision for Mageia as well, this is blocking for packages import. >> >> So that would be either /usr/share/pixmaps/backgrounds, >> /usr/share/wallpapers, >> or /usr/share/backgrounds >> >> Any idea about how other distros are handling this? >> >>> I don’t know which package owns /usr/share/pixmaps/backgrounds/, but >>> apparently it’s not desktop-common-data. I would rather not having to >>> install gnome packages/kde packages for that. >> >> No packages owns it yet. >> $ LC_ALL=C rpm -qf /usr/share/pixmaps/backgrounds/ >> file /usr/share/pixmaps/backgrounds is not owned by any package > > gnome-screensaver uses /usr/share/backgrounds. > > I think /usr/share/wallpapers is the best one. Actually, /usr/share/backgrounds seems pretty good, since gnome-control-center uses this directory by default I'll use this one temporarily. -- Olivier Blin - blino
Re: [Mageia-dev] background and theme path
> Actually, /usr/share/backgrounds seems pretty good, since > gnome-control-center uses this directory by default > I'll use this one temporarily. > > -- > Olivier Blin - blino > Then can KDE be patched to look there, packaging complimentary backgrounds will be far simpler then, 4 packages can be merged into 3 or so
[Mageia-dev] importing spec-helper [build-system progress]
I was looking to help and found spec-helper to be (hopefully) one of the easier ones left: - there's still some java stuff, which i assume dmorgan (and hopefully some help) is going to take care of. - there's rpm stuff - and seemingly alot of duplicates in mdv and mga list. so, this one was one of the few left. except, is spec-helper one of the patches ones too? Buildrequires will have to be changed to perl(IPC::Run3) instead of perl(IPC::Run), so my question is: Do i patch this to run with IPC::Run3 ? or is this to be forked? lemme know what you think.
Re: [Mageia-dev] [RFC] Ruby packaging policy
On Mon, Jan 10, 2011 at 01:49:30AM +0100, Michael Scherer wrote: > Le vendredi 07 janvier 2011 à 23:45 +0100, Remy CLOUARD a écrit : > > You can find the page here: > > http://wiki.mandriva.com/en/Policies/Ruby [...] > 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-*. > Ok, so I assume ruby rpm should be packaged as a gem or as a regular package, but not both (sounds sensible anyway) [...] Now, I’ve made an erb template to match what we discussed up till now. You can see the result here http://wiki.mandriva.com/en/Ruby_packaging_policy#Samples A few comments about this spec: - devel package is generated to pull the development dependencies, maybe it could be created also whenever there are additional files that are not in the require_paths node of the YAML specification. There are several things that need to be fixed: - in gem2rpm, version requirements should translate the ~> operator (it means >= X.Y and < Z) - in rubygems.rb, files that are not in require_paths are deleted. So we have to support test_files so that they can be included in the devel packages Regarding the specification, I would like to generalize tests, but that will not be an easy task, because of circular dependencies, don’t know how to circumvent the issue, because even if I first do the import without the check for the bootstrap, It’s likely that the problem will arise when upgrading the package, requiring to disable the test first and then activate it again… Regards, -- Rémy CLOUARD () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments pgpys5NQlChAb.pgp Description: PGP signature
[Mageia-dev] On importing /soft
http://svn.mageia.org/soft-cleaning/status.html#monitor-edid says "- README: Some reference to the Mandriva mailing list and bugzilla will need to be changed to Mageia ones" Do we really want to? What is the point? I think we can package this tool as-is, as a tool provided by Mandriva like if we were packaging a non distro specific tool developed by RedHat or Debian or anyone and let people report their bugs upstream if the README says so. If someday it becomes unmaintained or for any other reason, we can fork it, but currently I think of it as an external tool and see no reason in importing it into our svn I did not read the full list but I guess there are other standalone tools that we don't need to fork into our svn. Opinions?
Re: [Mageia-dev] On importing /soft
On Wed, 19 Jan 2011, Pascal Terjan wrote: > http://svn.mageia.org/soft-cleaning/status.html#monitor-edid > says "- README: Some reference to the Mandriva mailing list and > bugzilla will need to be changed to Mageia ones" > > Do we really want to? > What is the point? > I think we can package this tool as-is, as a tool provided by Mandriva > like if we were packaging a non distro specific tool developed by > RedHat or Debian or anyone and let people report their bugs upstream > if the README says so. > > If someday it becomes unmaintained or for any other reason, we can > fork it, but currently I think of it as an external tool and see no > reason in importing it into our svn > > I did not read the full list but I guess there are other standalone > tools that we don't need to fork into our svn. > > Opinions? Yes, I agree. If it is not necessary to fork something (no proprietary images, no important and incompatible changes required) then we should not fork it until it becomes necessary.
Re: [Mageia-dev] On importing /soft
> If someday it becomes unmaintained or for any other reason, we can > fork it, but currently I think of it as an external tool and see no > reason in importing it into our svn Do you mean to avoid importing the source code to modify it? If so, i agree, we can just import it as source package like other tarball... -- Angelo signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] On importing /soft
2011/1/19 Angelo Naselli : >> If someday it becomes unmaintained or for any other reason, we can >> fork it, but currently I think of it as an external tool and see no >> reason in importing it into our svn > Do you mean to avoid importing the source code to modify it? > If so, i agree, we can just import it as source package like other > tarball... > Sure as long as there is no license issue > -- > Angelo > -- Anne http://www.mageia.org
Re: [Mageia-dev] On importing /soft
Op woensdag 19 januari 2011 21:32:13 schreef Pascal Terjan: > http://svn.mageia.org/soft-cleaning/status.html#monitor-edid > says "- README: Some reference to the Mandriva mailing list and > bugzilla will need to be changed to Mageia ones" > > Do we really want to? > What is the point? > I think we can package this tool as-is, as a tool provided by Mandriva > like if we were packaging a non distro specific tool developed by > RedHat or Debian or anyone and let people report their bugs upstream > if the README says so. > > If someday it becomes unmaintained or for any other reason, we can > fork it, but currently I think of it as an external tool and see no > reason in importing it into our svn > > I did not read the full list but I guess there are other standalone > tools that we don't need to fork into our svn. > > Opinions? i agree, about spec-helper ... similar thing? or not?
Re: [Mageia-dev] On importing /soft
On Wed, Jan 19, 2011 at 21:13, Angelo Naselli wrote: >> If someday it becomes unmaintained or for any other reason, we can >> fork it, but currently I think of it as an external tool and see no >> reason in importing it into our svn > Do you mean to avoid importing the source code to modify it? > If so, i agree, we can just import it as source package like other > tarball... Yes I mean not importing into /soft and handling it as external tarball
Re: [Mageia-dev] On importing /soft
On Wed, Jan 19, 2011 at 21:33, Maarten Vanraes wrote: > Op woensdag 19 januari 2011 21:32:13 schreef Pascal Terjan: >> http://svn.mageia.org/soft-cleaning/status.html#monitor-edid >> says "- README: Some reference to the Mandriva mailing list and >> bugzilla will need to be changed to Mageia ones" >> >> Do we really want to? >> What is the point? >> I think we can package this tool as-is, as a tool provided by Mandriva >> like if we were packaging a non distro specific tool developed by >> RedHat or Debian or anyone and let people report their bugs upstream >> if the README says so. >> >> If someday it becomes unmaintained or for any other reason, we can >> fork it, but currently I think of it as an external tool and see no >> reason in importing it into our svn >> >> I did not read the full list but I guess there are other standalone >> tools that we don't need to fork into our svn. >> >> Opinions? > > i agree, > > about spec-helper ... similar thing? or not? Not sure, I think it's independent from the distro (as the scripts don't handle the policy themselves, it's done by rpm config) but some rpm guru would know more :)
Re: [Mageia-dev] importing spec-helper [build-system progress]
Maarten Vanraes writes: > except, is spec-helper one of the patches ones too? > > Buildrequires will have to be changed to perl(IPC::Run3) instead of > perl(IPC::Run), so my question is: > > Do i patch this to run with IPC::Run3 ? or is this to be forked? Why can't you keep IPC::Run ? -- Olivier Blin - blino
Re: [Mageia-dev] importing spec-helper [build-system progress]
Op woensdag 19 januari 2011 23:33:10 schreef Olivier Blin: > Maarten Vanraes writes: > > except, is spec-helper one of the patches ones too? > > > > Buildrequires will have to be changed to perl(IPC::Run3) instead of > > perl(IPC::Run), so my question is: > > > > Do i patch this to run with IPC::Run3 ? or is this to be forked? > > Why can't you keep IPC::Run ? it looks to me that perl-IPC-Run3 is built for mga and perl-IPC-Run isn't? or am i mistaken?
Re: [Mageia-dev] importing spec-helper [build-system progress]
Maarten Vanraes writes: > Op woensdag 19 januari 2011 23:33:10 schreef Olivier Blin: >> Maarten Vanraes writes: >> > except, is spec-helper one of the patches ones too? >> > >> > Buildrequires will have to be changed to perl(IPC::Run3) instead of >> > perl(IPC::Run), so my question is: >> > >> > Do i patch this to run with IPC::Run3 ? or is this to be forked? >> >> Why can't you keep IPC::Run ? > > it looks to me that perl-IPC-Run3 is built for mga and perl-IPC-Run isn't? or > am i mistaken? Then you can just build perl-IPC-Run for Mageia -- Olivier Blin - blino
Re: [Mageia-dev] background and theme path
On Wed, 19 Jan 2011 13:53:08 +0100, Remy CLOUARD wrote:
> On Wed, Jan 19, 2011 at 01:06:49PM +0100, Olivier Blin wrote:
> > Hi,
> >
> > I'd like to move away from the hardcoded backgrounds location for
> > themes, and put them in a distro-neutral path
> > (was /usr/share/mdk/backgrounds/ in Mandriva)
> >
> > Most Gnome backgrounds appear to be located in
> > /usr/share/pixmaps/backgrounds/ (some are in /usr/share/backgrounds/)
> >
> > Is everyone ok to have our backgrounds in
> > /usr/share/pixmaps/backgrounds// and the distro default as
> > /usr/share/pixmaps/backgrounds/default.jpg ?
> >
> > Thanks
> Well, I’d say it would be better if it were also desktop-neutral.
>
> AFAIK, there is one freedesktop specification for icons [1], but not for
> wallpapers, it would be nice to raise this subject on fd.o ml.
>
> I don’t know which package owns /usr/share/pixmaps/backgrounds/, but
> apparently it’s not desktop-common-data. I would rather not having to
> install gnome packages/kde packages for that.
>
> Regards,
>
> [1] http://www.freedesktop.org/wiki/Specifications/icon-theme-spec
Some ideas:
- pixmap != background/wallpaper, so better /usr/share/{backgrounds,wallpapers}
- as probably in a future will also exist shared sounds, videos or other
things, and as there is no XDG standard, why not group everything in something
like /usr/share/media/{wallpaper,image,audio,video} ?
--
J.A. Magallon \ Software is like sex:
\ It's better when it's free
