Re: [Mageia-dev] Consolidation of the spell checkers - current status before Beta 1 and general version freeze
On 22.02.2012 09:34, D.Morgan wrote: On Thu, Feb 16, 2012 at 4:00 AM, Kamil Rytarowskin...@gmx.com wrote: On 14.02.2012 15:40, Kamil Rytarowski wrote: To-do before the version freeze (I think, I can finish it tonight): - review additional ~50 hunspell dicts and use better obsoletion of myspell - stop providing enchant-dictionary in 2/3 aspell dicts Done. All Hunspell dictionaries are ready, Aspell one are cleaned and Myspell is moved into obsoletes. Have fun and feel free to submit bugs. aspell is still available on mirors. Do we need to remove them manually from the repo ? No, Aspell can't be obsoleted definitely (and so removed from mirrors) in this moment. Current goal is to stop installing, requiring it. It's still a requirement of Scribus (there is an upstream bug) and PHP (Thomas is having look) + Perl (there are bugs against Jerome's packages) modules.
[Mageia-dev] Return of the jedi
I could get a new computer, I'm back and ready for processing the bugs assigned to me :)
Re: [Mageia-dev] Consolidation of the spell checkers - current status before Beta 1 and general version freeze
On 12/02/22 09:40 +0100, Kamil Rytarowski wrote: It's still a requirement of Scribus (there is an upstream bug) and PHP (Thomas is having look) + Perl (there are bugs against Jerome's packages) modules. perl-Test-Spelling has been taken care of. perl-Padre-Plugin-SpellCheck is currently being worked upon upstream, i'll update it as soon as it's done. perl-Lingua-Ispell needs to be obsoleted, but i cannot find a task-obsolete package as we talked about - any news about this? jérôme
Re: [Mageia-dev] Consolidation of the spell checkers - current status before Beta 1 and general version freeze
On 22 February 2012 10:28, Jerome Quelin jque...@gmail.com wrote: perl-Lingua-Ispell needs to be obsoleted, but i cannot find a task-obsolete package as we talked about - any news about this? For perl modules, it can be done in perl-base IMHO...
Re: [Mageia-dev] Consolidation of the spell checkers - current status before Beta 1 and general version freeze
On 12/02/22 11:04 +0100, Thierry Vignaud wrote: On 22 February 2012 10:28, Jerome Quelin jque...@gmail.com wrote: perl-Lingua-Ispell needs to be obsoleted, but i cannot find a task-obsolete package as we talked about - any news about this? For perl modules, it can be done in perl-base IMHO... but then, should it also provides it? otherwise, package would remain on mirrors, wouldn't it? jérôme
Re: [Mageia-dev] Consolidation of the spell checkers - current status before Beta 1 and general version freeze
On 22.02.2012 10:28, Jerome Quelin wrote: On 12/02/22 09:40 +0100, Kamil Rytarowski wrote: It's still a requirement of Scribus (there is an upstream bug) and PHP (Thomas is having look) + Perl (there are bugs against Jerome's packages) modules. perl-Test-Spelling has been taken care of. perl-Padre-Plugin-SpellCheck is currently being worked upon upstream, i'll update it as soon as it's done. perl-Lingua-Ispell needs to be obsoleted, but i cannot find a task-obsolete package as we talked about - any news about this? jérôme Thank you Jerome! Could you also have a look at perl-Text-Aspell?
[Mageia-dev] Cinnamon
Hi, Just want to find out if there is any plan to make Cinnamon desktop available for Mageia 2. TIA, -- finid
Re: [Mageia-dev] Cinnamon
Le mercredi 22 février 2012 à 05:37 -0700, LinuxBSDos.com a écrit : Hi, Just want to find out if there is any plan to make Cinnamon desktop available for Mageia 2. See the thread: http://comments.gmane.org/gmane.linux.mageia.devel/10858
Re: [Mageia-dev] Packaging help for GDM+GNOME Mageia background (long)
On Sun, Feb 19, 2012 at 01:13:44PM +0100, Olav Vitters wrote: To recap, I need to put the following files in some package: - /usr/share/gnome-background-properties/mageia.xml = mageia-theme-Default ? who owns the directory then? Planning to ignore the directory ownership. - http://www.mageia.org/g/media/logo/mageia-2011.svg = mageia-theme-Default or desktop-common-data ? Planning to put that in mageia-theme-Default. - /usr/share/glib-2.0/schemas/mageia-theme-Default.override = mageia-theme-Default and depend on glib2.0-common? Planning to make mageia-theme-Default depend on glib2.0-common. - (and patch gnome-control-center) = not sure if I can :P My C is limited to copy/paste skills, so this might take a while. As I received no response, I assume proceeding is fine? -- Regards, Olav
Re: [Mageia-dev] Mageia 2 beta 1
Hi Anne, *, On Tue, Feb 21, 2012 at 9:00 PM, Anne nicolas enn...@mageia.org wrote: Hi there As announced on blog, isos are now available on public mirrors. http://blog.mageia.org/en/2012/02/21/mageia-2-is-approaching-test-mageia-2-beta-1/ Still no live cds available :-/ but we hope to have it ready in coming days, stay tuned. Hope they will come soon as... Beta stage is just essential for final release. So please take some time for tests and use Bugzilla :) without a live-iso, I won't be able to have a look - and probably quite a few other won't have a look either... ciao Christian
Re: [Mageia-dev] Mageia 2 beta 1
Le 22/02/2012 14:41, Christian Lohmaier a écrit : Hi Anne, *, On Tue, Feb 21, 2012 at 9:00 PM, Anne nicolas enn...@mageia.org wrote: Hi there As announced on blog, isos are now available on public mirrors. http://blog.mageia.org/en/2012/02/21/mageia-2-is-approaching-test-mageia-2-beta-1/ Still no live cds available :-/ but we hope to have it ready in coming days, stay tuned. Hope they will come soon as... Beta stage is just essential for final release. So please take some time for tests and use Bugzilla :) without a live-iso, I won't be able to have a look - and probably quite a few other won't have a look either... We are looking for people to make it possible in time. Join the team ! ciao Christian -- Anne http://mageia.org
Re: [Mageia-dev] printer-filter-utils
Am 20.02.2012 15:00, schrieb David Walser: Florian Hubold wrote: Am 19.02.2012 15:59, schrieb David Walser: Pascal Terjan wrote: I was looking at that package, which is a collection of drivers for some printers, not updated for years It is one of the two packages requiring automake1.4, because of the included drv_z42 Looking on http://www.openprinting.org/driver/drv_z42/ original website no longer exist, and even if openprinting now hosts it they say This driver is obsolete. Recommended replacement driver: gutenprint Should we drop it? Does anyone has enough time to see if other drivers in this package may still be needed? And actually, if we install this package. Also from openprinting, there are security issues fixed in the newest foomatic-filters (needs updated in Mageia 1 and Cauldron, see Bug 3979). They also have a new CUPS filters set that probably needs to be packaged. Upstream notes on it: Apple decided to not continue to develop and maintain the CUPS filters and backends which are not used by Mac OS X and moved them to OpenPrinting. They also did not accept the new filters for the PDF-based printing workflow as they are also not used by Mac OS X. All these filters we continue to maintain now in one package, the OpenPrinting CUPS Filters and announce here the first stable release of this package, versionn 1.0.1. As you mentioned it, there are far bigger changes coming than just adding a new cups filter package (which is still in beta state AFAIK) as that is just smaller fallout from changes explained in below links. http://thread.gmane.org/gmane.linux.printing.fsg/2020 http://cyberelk.net/tim/2012/02/06/cups-1-6-changes-ahead/ Yikes, thanks for the links Florian. The future removal of browsing and requirement of avahi is really unfortunate. So this work will be needed for when we move to CUPS 1.6, which will be after Mageia 2. Here's a good page that details the work we as a distro will need to do: http://www.linuxfoundation.org/collaborate/workgroups/openprinting/pdf_as_standard_print_job_format That's just part of the work, and i've already tried to mention that a few times. Also in the future for print server discovery avahi would need to run on the client and on the server, BTW.
[Mageia-dev] Faster GNOME package submission
I've enhanced my mga-gnome script to be able to increase the version number + reset %mkrel in an existing spec file. The script is meant for GNOME related packages/versions! To e.g. increase boabab to version 3.3.2: # just once: mkdir ~/src ~/bin ~/pkgs cd ~/src svn co svn+ssh://svn.mageia.org/svn/soft/mga-gnome/trunk mga-gnome cd ~/bin ln -s ~/src/mga-gnome mga-gnome # command itself: mga-gnome increase baobab 3.3.2 This will: cd ~/pkgs mgarepo co baobab - checks current version is newer than existing version - do some regexp magic to increase version + reset %mkrel - some verifications for the regexp magic mgarepo sync -d(downloads the new version) bm -p --nodeps (check that patches apply) I want it to also check the version more closely, e.g.: 3.3.x - 3.3.y : OK (unstable-unstable) 3.3.x - 3.4.0 : OK (unstable-stable) 3.2.x - 3.2.y : OK (stable-stable) 3.2.x - 3.3.y : NOT OK (stable-unstable) You might get a few bad looking tracebacks when mgarepo or bm fails. I have to make the output a bit nicer. Anyway, I've just tried this with a few packages. In future, I might automatically even do: mgarepo ci -m new version mgarepo submit But I want to first do more testing, plus add SHA256 verification (what GNOME uses and advises). -- Regards, Olav
Re: [Mageia-dev] [soft-commits] [3012] Add ability to increase the version number of a given package
On 22 February 2012 17:06, r...@mageia.org wrote:
Revision 3012 Author ovitters Date 2012-02-22 17:06:51 +0100 (Wed, 22 Feb
2012)
Log Message
Add ability to increase the version number of a given package
Command tries to be careful and does various checks (patches still apply,
etc)
Too sad it doesn't support this:
%define rel 3
%define release %mkrel %rel
(which is hard anyway and should be rare though it does exist among
mga packages)
+def version_cmp(a, b):
+Compares two versions
+
+Returns
+ -1 if a b
+ 0 if a == b
+ 1 if a b
+
+Logic from Bugzilla::Install::Util::vers_cmp
+A = re_version.findall(a.lstrip('0'))
+B = re_version.findall(b.lstrip('0'))
+
+while A and B:
+a = A.pop(0)
+b = B.pop(0)
+
+if a == b:
+continue
+elif a == '-':
+return -1
+elif b == '-':
+return 1
+elif a == '.':
+return -1
+elif b == '.':
+return 1
+elif a.isdigit() and b.isdigit():
+c = cmp(a, b) if (a.startswith('0') or b.startswith('0')) else
cmp(int(a, 10), int(b, 10))
+if c:
+return c
+else:
+c = cmp(a.upper(), b.upper())
+if c:
+return c
+
+return cmp(len(A), len(B))
Please do not reinvent the whell and do sg like this instead:
import rpm
def compare(t1, t2):
# t1 and t2 are tuples of (version, release)
v1, r1 = t1
v2, r2 = t2
return rpm.labelCompare(('1', v1, r1), ('1', v2, r2))
Re: [Mageia-dev] [soft-commits] [3012] Add ability to increase the version number of a given package
On Wed, Feb 22, 2012 at 06:13:12PM +0100, Thierry Vignaud wrote:
On 22 February 2012 17:06, r...@mageia.org wrote:
Revision 3012 Author ovitters Date 2012-02-22 17:06:51 +0100 (Wed, 22 Feb
2012)
Log Message
Add ability to increase the version number of a given package
Command tries to be careful and does various checks (patches still apply,
etc)
Too sad it doesn't support this:
%define rel 3
%define release %mkrel %rel
(which is hard anyway and should be rare though it does exist among
mga packages)
I could support that or you can commit something to support this.
However, I want this mga-gnome to be very reliable. No hope for the
best. IMO, paranoia is best... best to error out if anything might
appear strange.
+def version_cmp(a, b):
[..]
Please do not reinvent the whell and do sg like this instead:
import rpm
def compare(t1, t2):
# t1 and t2 are tuples of (version, release)
v1, r1 = t1
v2, r2 = t2
return rpm.labelCompare(('1', v1, r1), ('1', v2, r2))
Cool! I knew there had to be something like this, but couldn't be
bothered to investigate. The version_cmp I just copy/pasted from some
Python code I wrote for GNOME.
--
Regards,
Olav
Re: [Mageia-dev] Problem with rpm -q --whatrequires
'Twas brillig, and David W. Hodgins at 22/02/12 04:36 did gyre and gimble: On Tue, 21 Feb 2012 04:27:17 -0500, Colin Guthrie mag...@colin.guthr.ie wrote: Is this because the kernel requires it as Requires(pre) and thus it doesn't show up? Should it show up? I don't know if it should show up for rpm or not, but it works with urpmq ... [root@hodgins /]# rpm -q --whatrequires dracut no package requires dracut [root@hodgins /]# urpmq --whatrequires dracut dracut kernel-desktop-3.2.6-3.mga2 kernel-desktop586-3.2.6-3.mga2 kernel-linus-3.2.6-1.mga2 kernel-linus-3.2.7-1.mga2 kernel-netbook-3.2.6-3.mga2 kernel-rt-3.2.6-0.rt13.1.mga2 kernel-server-3.2.6-3.mga2 kernel-tmb-desktop-3.2.6-1.mga2 kernel-tmb-desktop586-3.2.6-1.mga2 kernel-tmb-laptop-3.2.6-1.mga2 kernel-tmb-server-3.2.6-1.mga2 kernel-vserver-3.2.6-1.mga2 kernel-vserver-3.2.7-1.mga2 Yeah this is what Dexter said too, but it's really quite bad that the two tools offer the same argument, but they actually work differently. See my earlier reply about this 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] [changelog] [RPM] cauldron core/release cogl-1.9.6-1.mga2
On 22 February 2012 21:14, wally buildsystem-dae...@mageia.org wrote: wally wally 1.9.6-1.mga2: + Revision: 212291 - new version 1.9.6 - new major 8 - drop unneeded P1 Hard versionated requires are bogus and just defeat the purpose of libification: installed lib64cogl7-1.9.4-2.mga2.x86_64 is conflicting because of unsatisfied cogl-i18n[== 1.9.4-2.mga2] (...) Some requested packages cannot be installed: libcogl7-1.9.4-2.mga2.i586 (due to unsatisfied cogl-i18n[== 1.9.4-2.mga2], trying to promote typelib(Meta)) libmutter-gir3.0-3.3.5-1.mga2.i586 (due to conflicts with libmutter-private0-3.3.5-1.mga2.i586, trying to promote typelib(Meta)) libmutter-private0-3.3.5-1.mga2.i586 (due to unsatisfied libcogl.so.7) libtotem0-3.3.90-1.mga2.i586 (due to unsatisfied libcogl.so.7) Continue installation anyway? (Y/n) Will be OK next time: See http://svnweb.mageia.org/packages/cauldron/cogl/current/SPECS/cogl.spec?r1=212291r2=212418
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release cogl-1.9.6-1.mga2
On 22 February 2012 23:33, Olav Vitters o...@vitters.nl wrote: Hard versionated requires are bogus and just defeat the purpose of libification: [..] Will be OK next time: See http://svnweb.mageia.org/packages/cauldron/cogl/current/SPECS/cogl.spec?r1=212291r2=212418 Is it possible to write an rpmlint check for this? If so, could you? :) there's at least requires-on-release is here for years...
