Re: [Mageia-dev] Alpha3 release notes
2012/1/8 Juan Luis Baptiste juan...@mageia.org: On Sat, Jan 7, 2012 at 7:40 AM, Oliver Burger oliver@googlemail.com wrote: Hi all, please do have a look at the alpha3 release notes: https://wiki.mageia.org/en/Mageia_2_alpha3 and fix/complete them. By keeping them up to date during the alpha/beta/rc phases we will finally have some nice release notes for Mageia2. Question, should we add new programs only or updated ones to new versions too ? Both. And don't be afraid to add too many notes. We can always filter it, so it doesn't get too long. Oliver
[Mageia-dev] Missing signatures
Hi there, I noticed, that some packages have missing signatures this morning: /var/cache/urpmi/rpms/acpid-2.0.14-1.mga2.i586.rpm: Missing signature (OK ((none))) /var/cache/urpmi/rpms/ldetect-0.11.5-1.mga2.i586.rpm: Missing signature (OK ((none))) /var/cache/urpmi/rpms/libldetect0.11-0.11.5-1.mga2.i586.rpm: Missing signature (OK ((none))) Could this be related to yesterday's changes in the bs code? Oliver
Re: [Mageia-dev] Missing signatures
2012/1/8 Oliver Burger oliver@googlemail.com: Hi there, I noticed, that some packages have missing signatures this morning: It's also reported to bugzilla: https://bugs.mageia.org/show_bug.cgi?id=4067
Re: [Mageia-dev] Missing signatures
08.01.2012 11:08, Jani Välimaa skrev: 2012/1/8 Oliver Burgeroliver@googlemail.com: Hi there, I noticed, that some packages have missing signatures this morning: It's also reported to bugzilla: https://bugs.mageia.org/show_bug.cgi?id=4067 Yep we had a brief hickup in the signing process, wich I fixed some ~6 hours ago. I just resubmitted some packages with missing signatures, so new packagas should be available shorty. If you find anymore of them, just bump rel and resubmit. -- Thomas
Re: [Mageia-dev] Missing signatures
2012/1/8 Thomas Backlund t...@mageia.org: Yep we had a brief hickup in the signing process, wich I fixed some ~6 hours ago. I just resubmitted some packages with missing signatures, so new packagas should be available shorty. If you find anymore of them, just bump rel and resubmit. Ok.
Re: [Mageia-dev] Orphans - those poor orphans . . .
Le 07/01/2012 11:14, ptyxs a écrit : Le 06/01/2012 17:55, Colin Guthrie a écrit : 'Twas brillig, and Robert Fox at 06/01/12 10:16 did gyre and gimble: After latest Cauldron updates, I got a real long list of suggested orphans - but I believe some of these packages are needed (like hal or basesystem-minimal) - How do I clear out the orphans - like reset the logic behind it so the correct packages will be orphaned? Or is a fresh install in order?? FWIW, as I see some people not liking this feature, personally I don't use --auto-orphans, but instead use urpmq --not-available to find packages I have installed that are no longer provided by the repositories. This will typically include old and unneeded library majors etc. that accumulate after a while. This list is much clearer in what it actually outputs and is basically the same as the yum orphan list command (I forget what the command actually is, but it's what inspired me to write the first version which in turn was vastly improved by a native implementation by (IIRC) Pascal Terjan :)) Col The problem is not 'I like it'/'I don't like it', the problem is that this feature caused sometimes the loss of very important packages making the system unusable and leading to a necessary reinstallation. rpm -e --nodeps also. -- BOFH excuse #42: spaghetti cable cause packet failure
Re: [Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia
Hello,
first, sorry to reply so late, and when you have started to update
hunspell dictionaries packages.
Le 21/12/2011 08:15, Kamil Rytarowski a écrit :
Hello!
[...]
There was a discuss on
1) preparing policies on hunspell-dictionaries
2) deprecate and kill myspell in Mga2
3) changing the default path of dictionaries, from /usr/share/myspell to
/usr/share/hunspell (and to keep backward compatibility links in myspell
directory)
4) to provide enchant-dictionary and hunspell-dictionary by every
hunspell-dictionary
So finally, I've prepared a first version of the policy
https://wiki.mageia.org/en/Hunspell-dictionary_policy
If you like, please tell me your comments of it. Is it right? (Also: is
the .spec correct?) When everything will be accepted then every
hunspell-dictionary will be updated according to the policy.
some comments about the policy:
Version:1.0
Release:%mkrel %{upstream_release}.%{rel}
I don't think it will be possible to use Version 1.0 and upstream
version only in the release; most hunspell dictionaries already use
upstream version as version and have a version 1.0.
--
#Mageia values: 1 - aspell, 2 - hunspell, 3 - language specific
Provides: enchant-dictionary = 2
Provides: hunspell-dictionary
Provides: dictionary-%{languagecode}
about the version value of the provides: is the meaning (1 - aspell, 2 -
hunspell, 3 - language specific) really needed? is it currently used?
Because I think that it could be usefull that the versionned provides
indicates the location of the dictionary:
- current enchant-dictionary = 2 - /usr/share/dict/mozilla
- enchant-dictionary from hunspell - enchant-dictionary = 4 -
/usr/share/hunspell and /usr/share/myspell,
- enchant-dictionary from future hunspell without compatibility link in
/usr/share/myspell - enchant-dictionary = 5 - /usr/share/hunspell only,
- ...
(it seems weird for me to use the same enchant-dictionary = 2
versionned provide, both for deprecated myspell dictionaries, and new
hunspell dictionaries.)
if the versionned provides indicates the location, we can use it if
necessary in Conflicts or Requires in others packages.
e.g. currently Firefox searches dictionnaries in /usr/share/dict/mozilla
(myspell dictionaries). when we change this location, we could add a
Requires enchant-dictionary = 4.
same for hunspell-dictionary and dictionary-%{languagecode}, a
versionned provides could indicate the location of the dictionary.
if we want to be able to remove easily all the compatibility link in the
future, we should really consider this.
PS. The changes of enchant will be proposed or accepted later, Funda has
already prepared the package.
new hunspell dictionaries provides enchant-dictionary and obsoletes
myspell dictionaries, but enchant still can't use the new hunspell
dictionaries. I think that it should be fixed ASAP, or we will release
an alpha 3 with broken spelling for lot of languages.
I propose the attached patches for enchant, so that enchant can use
dictionaries from /usr/share/hunspell, /usr/share/myspell, and
/usr/share/dict/ooo.
Anssi, Kamil, WDYT ?
same problem with firefox and thunderbird, they use dictionaries from
/usr/share/dict/mozilla = myspell dictionaries, that are obsoleted.
(Will we wait for the complete migration, to release alpha 3 ? )
CC: Anssi, enchant and thunderbird maintainer
dmorgan, firefox maintainer
regards,
Luc
--
Luc Menut
diff -Naur enchant-1.6.0.orig/src/myspell/myspell_checker.cpp enchant-1.6.0/src/myspell/myspell_checker.cpp
--- enchant-1.6.0.orig/src/myspell/myspell_checker.cpp 2010-04-01 22:53:37.0 +0200
+++ enchant-1.6.0/src/myspell/myspell_checker.cpp 2011-12-19 23:07:37.0 +0100
@@ -276,6 +276,9 @@
dirs = g_slist_append (dirs, g_strdup (ENCHANT_MYSPELL_DICT_DIR));
#endif
+ dirs = g_slist_append (dirs, g_strdup (/usr/share/myspell));
+ dirs = g_slist_append (dirs, g_strdup (/usr/share/dict/ooo));
+
#if defined(_WIN32)
char* open_office_dicts_dir = myspell_checker_get_open_office_dicts_dir ();
if (open_office_dicts_dir)
Index: enchant.spec
===
--- enchant.spec (révision 184618)
+++ enchant.spec (copie de travail)
@@ -10,6 +10,7 @@
Group: System/Libraries
URL: http://www.abisource.com/projects/enchant/
Source0: http://www.abisource.com/downloads/enchant/%{version}/%{name}-%{version}.tar.gz
+Patch0: enchant-1.6.0-add-more-myspell-dicts-dirs.patch
BuildRequires: pkgconfig(glib-2.0) = 2.6
BuildRequires: pkgconfig(gmodule-2.0)
BuildRequires: pkgconfig(hunspell)
@@ -40,12 +41,13 @@
%prep
%setup -q
+%patch0 -p1
%build
%configure2_5x --disable-static \
--with-system-myspell=yes \
--disable-ispell --disable-aspell --disable-uspell --disable-hspell \
- --with-myspell-dir=%{_datadir}/dict/ooo
+ --with-myspell-dir=%{_datadir}/hunspell
%make
%install
Re: [Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia
08.01.2012 16:19, Luc Menut skrev: same problem with firefox and thunderbird, they use dictionaries from /usr/share/dict/mozilla = myspell dictionaries, that are obsoleted. (Will we wait for the complete migration, to release alpha 3 ? ) Nope. Alpha3 iso building is working from a frozen repo -- Thomas
Re: [Mageia-dev] RFC: Drop mkinitrd completely in favour of dracut.
Anssi Hannula an...@mageia.org writes: Is it possible to detect missing radeon firmware in initrd in early boot, and then switch to loading radeon with modeset=0 ? [...] Does loading of radeon modesetting kernel driver without firmware break the boot completely, or does it just make X.org server fail to start? Here it sorts of breaks the boot. The display is not usable at all, either in the console or in gdm. The screen is flickering with purple color/green colors on top, and white in the bigger part of the screen. Card:ATI Radeon HD 2000 and later (radeon/fglrx): ATI Technologies Inc|RV610 video device [Radeon HD 2400 PRO] [DISPLAY_VGA] -- Olivier Blin - blino
Re: [Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia
Le 08/01/2012 15:29, Thomas Backlund a écrit : 08.01.2012 16:19, Luc Menut skrev: same problem with firefox and thunderbird, they use dictionaries from /usr/share/dict/mozilla = myspell dictionaries, that are obsoleted. (Will we wait for the complete migration, to release alpha 3 ? ) Nope. Alpha3 iso building is working from a frozen repo OK sorry, thanks Thomas for the clarification. I badly understood the mail of Anne about Mageia 2 alpha 3 in progress. Luc -- Luc Menut
Re: [Mageia-dev] Orphans - those poor orphans . . .
Le 07/01/2012 21:13, Maarten Vanraes a écrit : Op zaterdag 07 januari 2012 17:48:36 schreef Thomas Spuhler: [...] It seems to me, auto-orphans gives more headaches than benefits. Why are we clinching to it? because it works for me (and several others) It works SOMETIMES and sometimes it crashes the whole system. -- Ce courriel a été émis à partir du système d'exploitation Mandriva Linux Préférez les logiciels libres et les formats ouverts. LINUX ? IL Y A MOINS BIEN, MAIS... C'EST PLUS CHER !!
Re: [Mageia-dev] Orphans - those poor orphans . . .
2012/1/8 ptyxs pt...@free.fr: Le 07/01/2012 21:13, Maarten Vanraes a écrit : Op zaterdag 07 januari 2012 17:48:36 schreef Thomas Spuhler: [...] It seems to me, auto-orphans gives more headaches than benefits. Why are we clinching to it? because it works for me (and several others) It works SOMETIMES and sometimes it crashes the whole system. I admit that it has been working for me most of the times but I did not use it very often. But what is the priority here? It should only be implemented when it works for everybody (with the usual few exceptions) and not just because it works for some. -- wobo
Re: [Mageia-dev] Orphans - those poor orphans . . .
On Sat, Jan 7, 2012 at 16:48, Thomas Spuhler tho...@btspuhler.com wrote: On Friday, January 06, 2012 12:57:39 PM Sander Lepik wrote: 06.01.2012 21:06, Dale Huckeby kirjutas: Evidently once I've installed package A which requests X, sometimes packages F, L, and T might subsequently get installed which also need X *and presumably would have requested it had it not already been installed*. But when I uninstall A it orphans X because A is the only package that *requested* it. When F, L, and T are installed can't all the packages they *would have requested* be marked whether or not they're already installed? That way a package would be orphaned only when the last package that needs it is uninstalled? Or am I missing something? This is already so. See example: http://pastebin.com/AMj87QiV - after first urpme libplasmaweather4 should be marked as orphan but it's not as it's still required by other package. -- Sander It seems to me, auto-orphans gives more headaches than benefits. Why are we clinching to it? Because I and meany other people finding it useful never faced any problems on their machine with it. The only problems I can remember are: - people wanted to remove some things required by task-kde, which implied removing task-kde, and then all of kde was orphan. I think many things were move to suggests since - some kind of install was installing packages requested by nothing and they were not marked as requested so they were listed as orphans, but this was fixed long ago
Re: [Mageia-dev] Orphans - those poor orphans . . .
On Sat, Jan 7, 2012 at 14:24, Wolfgang Bornath molc...@googlemail.com wrote: 2012/1/7 Sander Lepik sander.le...@eesti.ee: 07.01.2012 13:39, Wolfgang Bornath kirjutas: Of course this is one way to find bugs in packages. But what about the documented (in German) case where - after fresh installation, reboot (ok) and updates right after installation I was presented with a list of more than 100 orphans. - I ran 'urpme --auto-orphans' and rebooted - several system services (which started successfully after installation) refused to start now because of missing files Of course urpmi was not the culprit because it only checks dependencies. But that did matter in that situation. The auto-orphans function obviously listed packages which may have no dependencies but are needed by the system. That's why I do not complain about urpmi but about the whole function. As long as this function is only based on package dependencies it is not safe to use it. Did you choose custom install and unchecked some options? Or did you use LiveCD maybe? Anyway.. function is not to blame. Next time copy those packages that are going to be uninstalled. And they can be rechecked. Which are needed and why they get orphaned. Used the full DVD (32-bit) Mageia 2 Alpha 2 - minimal install with X - after installation and reboot everything was ok - setup the package media (dedicated mirror) and did 'urpmi -auto-update' - I did NOT install or remove one single package manually - after that urpmi showed a list of more than 100 orphans - used 'urpme -auto-orphans - at reboot the start messages showed several errors concerning crond, network-up, postfix, display manager, etc. - system start stopped before x was started. Repeated the boot process with same result. A side question is why I got so many orphans in a minimal system with only around 700 packages in total and only around 2 or 3 dozens of updates (all this happened not long after Alpha 2 release.) Of course urpmi is not the culprit, it is the shortcomings of the function as it is. It should just not be there if its use could lead to such behavior, no matter where the cause comes from. Simply said: a gasoline brand should not be sold if it could do damage to the car's motor, no matter which of the components of the fluid causes the damage.. Anyhow, I will repeat the same operation when Alpha 2 is released in a couple of days and as soon as the system shows orphans I will document that list and (if the same problem arises) dmesg output if available. What else do you need for a reasonable documentation? Thanks, this is obviously an installation bug as those packages should be listed as requested.
Re: [Mageia-dev] Orphans - those poor orphans . . .
Le 08/01/2012 16:59, Pascal Terjan a écrit : On Sat, Jan 7, 2012 at 16:48, Thomas Spuhlertho...@btspuhler.com wrote: On Friday, January 06, 2012 12:57:39 PM Sander Lepik wrote: 06.01.2012 21:06, Dale Huckeby kirjutas: Evidently once I've installed package A which requests X, sometimes packages F, L, and T might subsequently get installed which also need X *and presumably would have requested it had it not already been installed*. But when I uninstall A it orphans X because A is the only package that *requested* it. When F, L, and T are installed can't all the packages they *would have requested* be marked whether or not they're already installed? That way a package would be orphaned only when the last package that needs it is uninstalled? Or am I missing something? This is already so. See example: http://pastebin.com/AMj87QiV - after first urpme libplasmaweather4 should be marked as orphan but it's not as it's still required by other package. -- Sander It seems to me, auto-orphans gives more headaches than benefits. Why are we clinching to it? Because I and meany other people finding it useful never faced any problems on their machine with it. The only problems I can remember are: - people wanted to remove some things required by task-kde, which implied removing task-kde, and then all of kde was orphan. I think many things were move to suggests since - some kind of install was installing packages requested by nothing and they were not marked as requested so they were listed as orphans, but this was fixed long ago I recently installed Okular then i removed xpdf and then used auto-orphans : I immedialtely lost any possibility to use wifi... -- Ce courriel a été émis à partir du système d'exploitation Mandriva Linux Préférez les logiciels libres et les formats ouverts. LINUX ? IL Y A MOINS BIEN, MAIS... C'EST PLUS CHER !!
Re: [Mageia-dev] Missing signatures
On 8 January 2012 12:29, Thomas Backlund t...@mageia.org wrote: Yep we had a brief hickup in the signing process, wich I fixed some ~6 hours ago. I just resubmitted some packages with missing signatures, so new packagas should be available shorty. If you find anymore of them, just bump rel and resubmit. You forgot core/updates_testing/
Re: [Mageia-dev] mentors + apprentices
Hi, I think I will have more free time now so if an apprentice is looking for a mentor, you can contact me
Re: [Mageia-dev] Missing signatures
Le 08/01/2012 12:29, Thomas Backlund a écrit : 08.01.2012 11:08, Jani Välimaa skrev: 2012/1/8 Oliver Burgeroliver@googlemail.com: Hi there, I noticed, that some packages have missing signatures this morning: It's also reported to bugzilla: https://bugs.mageia.org/show_bug.cgi?id=4067 Yep we had a brief hickup in the signing process, wich I fixed some ~6 hours ago. It seems not completely fixed; gedit-3.3.2-1.mga2 built today 08 janv. 2012 at 15:51:09 CET is not signed. rpm -qpi gedit-3.3.2-1.mga2.x86_64.rpm Name: gedit Version : 3.3.2 Release : 1.mga2 Architecture: x86_64 Install Date: (not installed) Group : Editors Size: 12797127 License : GPLv2+ Signature : (none) Source RPM : gedit-3.3.2-1.mga2.src.rpm Build Date : dim. 08 janv. 2012 15:51:09 CET Build Host : jonund Relocations : (not relocatable) Packager: wally wally -- Luc Menut
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release qesteidutil-3.4.0-3.mga2
18.12.2011 10:45, Mageia Team kirjutas: Name: qesteidutil Relocations: (not relocatable) Version : 3.4.0 Vendor: Mageia.Org Release : 3.mga2Build Date: Sun Dec 18 09:36:19 2011 Install Date: (not installed) Build Host: ecosse Group : OfficeSource RPM: (none) Size: 794924 License: LGPLv2 Signature : (none) Packager: Mageia Teamhttp://www.mageia.org URL : http://id.eesti.ee Summary : Estonian ID card utility Description : QEsteidUtil is a user-friendly application for managing Estonian ID Cards. It can be used to to change and unlock PIN codes, examine the personal information stored on the card, extract and view the certificates, set up mobile ID and configure a personal @eesti.ee e-mail address. fwangfwang 3.4.0-3.mga2: + Revision: 183700 - br qtwebkit Why this br? I fail to see reason. :) -- Sander
Re: [Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia
On 08.01.2012 16:19, Luc Menut wrote:
Hello,
first, sorry to reply so late, and when you have started to update
hunspell dictionaries packages.
Le 21/12/2011 08:15, Kamil Rytarowski a écrit :
Hello!
[...]
There was a discuss on
1) preparing policies on hunspell-dictionaries
2) deprecate and kill myspell in Mga2
3) changing the default path of dictionaries, from /usr/share/myspell to
/usr/share/hunspell (and to keep backward compatibility links in myspell
directory)
4) to provide enchant-dictionary and hunspell-dictionary by every
hunspell-dictionary
So finally, I've prepared a first version of the policy
https://wiki.mageia.org/en/Hunspell-dictionary_policy
If you like, please tell me your comments of it. Is it right? (Also: is
the .spec correct?) When everything will be accepted then every
hunspell-dictionary will be updated according to the policy.
some comments about the policy:
Version:1.0
Release:%mkrel %{upstream_release}.%{rel}
I don't think it will be possible to use Version 1.0 and upstream
version only in the release; most hunspell dictionaries already use
upstream version as version and have a version 1.0.
Strong +1 from me for not using hardcoded Version 1.0, please instead
use the %upstream_release in Version.
I don't see any reason to break the versioning policy here.
--
#Mageia values: 1 - aspell, 2 - hunspell, 3 - language specific
Provides: enchant-dictionary = 2
Provides: hunspell-dictionary
Provides: dictionary-%{languagecode}
about the version value of the provides: is the meaning (1 - aspell, 2 -
hunspell, 3 - language specific) really needed? is it currently used?
The intention was that when a package depended on enchant-dictionary,
urpmi would prefer language specific enchant dictionaries over hunspell
dictionaries over aspell dictionaries when presenting a list for the user.
Because I think that it could be usefull that the versionned provides
indicates the location of the dictionary:
- current enchant-dictionary = 2 - /usr/share/dict/mozilla
- enchant-dictionary from hunspell - enchant-dictionary = 4 -
/usr/share/hunspell and /usr/share/myspell,
- enchant-dictionary from future hunspell without compatibility link in
/usr/share/myspell - enchant-dictionary = 5 - /usr/share/hunspell only,
- ...
(it seems weird for me to use the same enchant-dictionary = 2
versionned provide, both for deprecated myspell dictionaries, and new
hunspell dictionaries.)
if the versionned provides indicates the location, we can use it if
necessary in Conflicts or Requires in others packages.
e.g. currently Firefox searches dictionnaries in /usr/share/dict/mozilla
(myspell dictionaries). when we change this location, we could add a
Requires enchant-dictionary = 4.
IMO a better way to handle this would be
Provides: mozilla-dictionary
Provides: hunspell-dictionary
Provides: myspell-dictionary
based on which directories are contained in the package, since other
packages are generally interested in whether the package provides
dictionaries in a specific location. (i.e. a package using dictionaries
in /usr/share/hunspell doesn't care if there are some extra dictionaries
provided in other directories).
same for hunspell-dictionary and dictionary-%{languagecode}, a
versionned provides could indicate the location of the dictionary.
if we want to be able to remove easily all the compatibility link in the
future, we should really consider this.
PS. The changes of enchant will be proposed or accepted later, Funda has
already prepared the package.
new hunspell dictionaries provides enchant-dictionary and obsoletes
myspell dictionaries, but enchant still can't use the new hunspell
dictionaries. I think that it should be fixed ASAP, or we will release
an alpha 3 with broken spelling for lot of languages.
I propose the attached patches for enchant, so that enchant can use
dictionaries from /usr/share/hunspell, /usr/share/myspell, and
/usr/share/dict/ooo.
Anssi, Kamil, WDYT ?
Seems OK.
same problem with firefox and thunderbird, they use dictionaries from
/usr/share/dict/mozilla = myspell dictionaries, that are obsoleted.
(Will we wait for the complete migration, to release alpha 3 ? )
CC: Anssi, enchant and thunderbird maintainer
dmorgan, firefox maintainer
regards,
Luc
--
Anssi Hannula
Re: [Mageia-dev] Orphans - those poor orphans . . .
On Sun, Jan 8, 2012 at 16:04, ptyxs pt...@free.fr wrote: Le 08/01/2012 16:59, Pascal Terjan a écrit : On Sat, Jan 7, 2012 at 16:48, Thomas Spuhlertho...@btspuhler.com wrote: On Friday, January 06, 2012 12:57:39 PM Sander Lepik wrote: 06.01.2012 21:06, Dale Huckeby kirjutas: Evidently once I've installed package A which requests X, sometimes packages F, L, and T might subsequently get installed which also need X *and presumably would have requested it had it not already been installed*. But when I uninstall A it orphans X because A is the only package that *requested* it. When F, L, and T are installed can't all the packages they *would have requested* be marked whether or not they're already installed? That way a package would be orphaned only when the last package that needs it is uninstalled? Or am I missing something? This is already so. See example: http://pastebin.com/AMj87QiV - after first urpme libplasmaweather4 should be marked as orphan but it's not as it's still required by other package. -- Sander It seems to me, auto-orphans gives more headaches than benefits. Why are we clinching to it? Because I and meany other people finding it useful never faced any problems on their machine with it. The only problems I can remember are: - people wanted to remove some things required by task-kde, which implied removing task-kde, and then all of kde was orphan. I think many things were move to suggests since - some kind of install was installing packages requested by nothing and they were not marked as requested so they were listed as orphans, but this was fixed long ago I recently installed Okular then i removed xpdf and then used auto-orphans : I immedialtely lost any possibility to use wifi... What would be useful would be to know what package was removed, and how it had been installed
Re: [Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia
W dniu 08.01.2012 15:19, Luc Menut pisze:
Hello,
Hello Luc, thank you for you mail.
first, sorry to reply so late, and when you have started to update
hunspell dictionaries packages.
Le 21/12/2011 08:15, Kamil Rytarowski a écrit :
Hello!
[...]
There was a discuss on
1) preparing policies on hunspell-dictionaries
2) deprecate and kill myspell in Mga2
3) changing the default path of dictionaries, from /usr/share/myspell to
/usr/share/hunspell (and to keep backward compatibility links in myspell
directory)
4) to provide enchant-dictionary and hunspell-dictionary by every
hunspell-dictionary
So finally, I've prepared a first version of the policy
https://wiki.mageia.org/en/Hunspell-dictionary_policy
If you like, please tell me your comments of it. Is it right? (Also: is
the .spec correct?) When everything will be accepted then every
hunspell-dictionary will be updated according to the policy.
some comments about the policy:
Version:1.0
Release:%mkrel %{upstream_release}.%{rel}
I don't think it will be possible to use Version 1.0 and upstream
version only in the release; most hunspell dictionaries already use
upstream version as version and have a version 1.0.
upstream version != upstream release
We will keep Fedora versioning.
--
#Mageia values: 1 - aspell, 2 - hunspell, 3 - language specific
Provides: enchant-dictionary = 2
Provides: hunspell-dictionary
Provides: dictionary-%{languagecode}
about the version value of the provides: is the meaning (1 - aspell, 2
- hunspell, 3 - language specific) really needed? is it currently used?
Because I think that it could be usefull that the versionned provides
indicates the location of the dictionary:
- current enchant-dictionary = 2 - /usr/share/dict/mozilla
- enchant-dictionary from hunspell - enchant-dictionary = 4 -
/usr/share/hunspell and /usr/share/myspell,
- enchant-dictionary from future hunspell without compatibility link
in /usr/share/myspell - enchant-dictionary = 5 -
/usr/share/hunspell only,
- ...
(it seems weird for me to use the same enchant-dictionary = 2
versionned provide, both for deprecated myspell dictionaries, and
new hunspell dictionaries.)
if the versionned provides indicates the location, we can use it if
necessary in Conflicts or Requires in others packages.
e.g. currently Firefox searches dictionnaries in
/usr/share/dict/mozilla (myspell dictionaries). when we change this
location, we could add a Requires enchant-dictionary = 4.
same for hunspell-dictionary and dictionary-%{languagecode}, a
versionned provides could indicate the location of the dictionary.
if we want to be able to remove easily all the compatibility link in
the future, we should really consider this.
If a package requires enchant-dictionary, then language specific will be
chosen before Aspell. This is the whole idea behind it. (eg. Voikko is
chosen before hunspell-fi and aspell-fi too). And I'm against some
special versioning for directories, we don't really need it.
PS. The changes of enchant will be proposed or accepted later, Funda has
already prepared the package.
new hunspell dictionaries provides enchant-dictionary and obsoletes
myspell dictionaries, but enchant still can't use the new hunspell
dictionaries. I think that it should be fixed ASAP, or we will release
an alpha 3 with broken spelling for lot of languages.
I propose the attached patches for enchant, so that enchant can use
dictionaries from /usr/share/hunspell, /usr/share/myspell, and
/usr/share/dict/ooo.
Anssi, Kamil, WDYT ?
Yes feel free to fix it. As far as I saw Funda was already working with
enchant disabling Aspell and Myspell.
same problem with firefox and thunderbird, they use dictionaries from
/usr/share/dict/mozilla = myspell dictionaries, that are obsoleted.
This must be fixed too - as soon as possible.
(Will we wait for the complete migration, to release alpha 3 ? )
I won't wait now, we are short on time. I want to finish everything
before the general version freeze.
CC: Anssi, enchant and thunderbird maintainer
dmorgan, firefox maintainer
regards,
Luc
So finally - I'm focusing right now just on the Hunspell dictionaries
and this is my painstaking job. And then after it or in the same time
there is need to fix the last remaining packages to use Hunspell/Enchant
correctly.
Re: [Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia
Le 08/01/2012 21:18, Kamil Rytarowski a écrit :
W dniu 08.01.2012 15:19, Luc Menut pisze:
Hello,
[...]
if the versionned provides indicates the location, we can use it if
necessary in Conflicts or Requires in others packages.
e.g. currently Firefox searches dictionnaries in
/usr/share/dict/mozilla (myspell dictionaries). when we change this
location, we could add a Requires enchant-dictionary = 4.
same for hunspell-dictionary and dictionary-%{languagecode}, a
versionned provides could indicate the location of the dictionary.
if we want to be able to remove easily all the compatibility link in
the future, we should really consider this.
If a package requires enchant-dictionary, then language specific will be
chosen before Aspell. This is the whole idea behind it. (eg. Voikko is
chosen before hunspell-fi and aspell-fi too).
OK, I understand the use for enchant-dictionary.
And I'm against some
special versioning for directories, we don't really need it.
sorry but I don't agree with you here.
e.g. in coming days, we will fix firefox (and other mozilla apps) to use
hunspell-dictionaries; we will update the link to
/usr/lib64/firefox-9.0.1/dictionaries - /usr/share/hunspell
and change the requires to hunspell-dictionary.
but hunspell-dictionaries old generation (mga1) provide
hunspell-dictionary, and install dictionaries only in /usr/share/myspell.
how do you plan to handle that the fixed firefox will absolutly need
hunspell-dictionaries new generation, and can't work with
hunspell-dictionaries old generation ?
regards,
Luc
--
Luc Menut
Re: [Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia
W dniu 08.01.2012 21:43, Thomas Backlund pisze: 08.01.2012 22:18, Kamil Rytarowski skrev: W dniu 08.01.2012 15:19, Luc Menut pisze: same problem with firefox and thunderbird, they use dictionaries from /usr/share/dict/mozilla = myspell dictionaries, that are obsoleted. This must be fixed too - as soon as possible. (Will we wait for the complete migration, to release alpha 3 ? ) I won't wait now, we are short on time. I want to finish everything before the general version freeze. Kamil. You must take better note when we send info on -dev ml. Quoting ennael in thread: [Mageia-dev] Mageia 2 alpha 3 in progress quote Hi there First of all, happy new year 2012 and all the best for you and your family. Mageia 2 alpha3 isos are now in progress, public release is planned for 12th of january. Please do not provide for now major updates on packages as we will freeze local repository in coming hours. Thanks for advance /quote Right, excuse me! Thankfully nothing is effected.
Re: [Mageia-dev] gma500 display driver problem with Mageia 2 alpha
Sorry, i don't have a GMA500 aka Poulsbo, but from what i remember investigating for alternatives to this driver (which is prone to breakage due to kernel updates) maybe you want to have a look at https://wiki.ubuntu.com/HardwareSupportComponentsVideoCardsPoulsbo and https://wiki.archlinux.org/index.php/Poulsbo#Kernel.27s_psb-gfx_module Yes, I have read those pages and both of them confirm that the original psb driver that the drakconf try to install as a DKMS module for gma500 will not work with 3.0 kernel coming with Mageia 2.0 alpha1. (compilation of dkms module will fail) So there would now be need for changing the drakconf to use by default some other driver. The easiest candidate would propably be now the psb_gfx module that comes already as a module in mageia 3.0 kernels. I think I am already using this new psb_gfx driver as I selected the fbdev driver in the drakconf. (Instead of selecting the default driver suggested that would have installed the psb dkms module and failed). This psb_gfx driver works for me, but at the moment I only have 800x600 resolution instead of the 1280x720. Mika
[Mageia-dev] urpmi installing src.rpm defaults to --buildrequires
Hi, i donno if it's me, but i noticed the following: [alien@localhost manaplus]$ /usr/sbin/urpmi /tmp/manaplus-1.1.5.1-4.mga1.src.rpm please use --buildrequires or --install-src, defaulting to --buildrequires ... i noticed something was wrong when i clicked on the .src.rpm file on the file browser and chose install the src.rpm file... I do believe it should default to --install-src ?
Re: [Mageia-dev] urpmi installing src.rpm defaults to --buildrequires
On Sun, Jan 8, 2012 at 22:12, Maarten Vanraes al...@rmail.be wrote: Hi, i donno if it's me, but i noticed the following: [alien@localhost manaplus]$ /usr/sbin/urpmi /tmp/manaplus-1.1.5.1-4.mga1.src.rpm please use --buildrequires or --install-src, defaulting to --buildrequires ... i noticed something was wrong when i clicked on the .src.rpm file on the file browser and chose install the src.rpm file... I do believe it should default to --install-src ? Maybe it should depend if you are root
Re: [Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia
Le 08/01/2012 21:18, Kamil Rytarowski a écrit : W dniu 08.01.2012 15:19, Luc Menut pisze: new hunspell dictionaries provides enchant-dictionary and obsoletes myspell dictionaries, but enchant still can't use the new hunspell dictionaries. I think that it should be fixed ASAP, or we will release an alpha 3 with broken spelling for lot of languages. I propose the attached patches for enchant, so that enchant can use dictionaries from /usr/share/hunspell, /usr/share/myspell, and /usr/share/dict/ooo. Anssi, Kamil, WDYT ? Yes feel free to fix it. done - enchant-1.6.0-4.mga2 -- Luc Menut
[Mageia-dev] Security updates needing testing (please help)
There are a number of needed security updates for Mageia 1 that have already been built and just need QA testing so that they can be released. Most of them have testcases already described in the comments. Please help test these if you can so we can get these updates released. Needs testing on i586: https://bugs.mageia.org/show_bug.cgi?id=2950 cifs-utils https://bugs.mageia.org/show_bug.cgi?id=3311 proftpd https://bugs.mageia.org/show_bug.cgi?id=3980 samba Needs testing on x86_64: https://bugs.mageia.org/show_bug.cgi?id=3902 jasper https://bugs.mageia.org/show_bug.cgi?id=3937 dhcp https://bugs.mageia.org/show_bug.cgi?id=3939 nfs-utils https://bugs.mageia.org/show_bug.cgi?id=3940 libxml2 https://bugs.mageia.org/show_bug.cgi?id=3942 icu https://bugs.mageia.org/show_bug.cgi?id=3982 libsndfile https://bugs.mageia.org/show_bug.cgi?id=3985 libtiff https://bugs.mageia.org/show_bug.cgi?id=3993 gif2png https://bugs.mageia.org/show_bug.cgi?id=3994 t1lib https://bugs.mageia.org/show_bug.cgi?id=3998 gimp https://bugs.mageia.org/show_bug.cgi?id=3999 libzip https://bugs.mageia.org/show_bug.cgi?id=2064 krb5-appl Needs testing on both: https://bugs.mageia.org/show_bug.cgi?id=3895 PHP (Thomas also needs to rebuild php-apc and php-eaccelerator) https://bugs.mageia.org/show_bug.cgi?id=3955 cyrus-imapd Already tested, needs pushed by sysadmins: https://bugs.mageia.org/show_bug.cgi?id=3941 libarchive https://bugs.mageia.org/show_bug.cgi?id=3995 libuser
Re: [Mageia-dev] Security updates needing testing (please help)
On 09.01.2012 01:02, David Walser wrote: There are a number of needed security updates for Mageia 1 that have already been built and just need QA testing so that they can be released. Most of them have testcases already described in the comments. Please help test these if you can so we can get these updates released. Needs testing on i586: https://bugs.mageia.org/show_bug.cgi?id=2950 cifs-utils https://bugs.mageia.org/show_bug.cgi?id=3311 proftpd https://bugs.mageia.org/show_bug.cgi?id=3980 samba Needs testing on x86_64: https://bugs.mageia.org/show_bug.cgi?id=3902 jasper https://bugs.mageia.org/show_bug.cgi?id=3937 dhcp https://bugs.mageia.org/show_bug.cgi?id=3939 nfs-utils https://bugs.mageia.org/show_bug.cgi?id=3940 libxml2 https://bugs.mageia.org/show_bug.cgi?id=3942 icu https://bugs.mageia.org/show_bug.cgi?id=3982 libsndfile https://bugs.mageia.org/show_bug.cgi?id=3985 libtiff https://bugs.mageia.org/show_bug.cgi?id=3993 gif2png https://bugs.mageia.org/show_bug.cgi?id=3994 t1lib https://bugs.mageia.org/show_bug.cgi?id=3998 gimp https://bugs.mageia.org/show_bug.cgi?id=3999 libzip https://bugs.mageia.org/show_bug.cgi?id=2064 krb5-appl Needs testing on both: https://bugs.mageia.org/show_bug.cgi?id=3895 PHP (Thomas also needs to rebuild php-apc and php-eaccelerator) https://bugs.mageia.org/show_bug.cgi?id=3955 cyrus-imapd Already tested, needs pushed by sysadmins: https://bugs.mageia.org/show_bug.cgi?id=3941 libarchive https://bugs.mageia.org/show_bug.cgi?id=3995 libuser What about https://bugs.mageia.org/show_bug.cgi?id=3601 krusader -- Anssi Hannula
[Mageia-dev] Security updates needing testing (please help)
On lun., 2012-01-09 at 01:07 +0200, Anssi Hannula wrote: On 09.01.2012 01:02, David Walser wrote: There are a number of needed security updates for Mageia 1 that have already been built and just need QA testing so that they can be released. Most of them have testcases already described in the comments. Please help test these if you can so we can get these updates released. Needs testing on i586: https://bugs.mageia.org/show_bug.cgi?id=2950 cifs-utils https://bugs.mageia.org/show_bug.cgi?id=3311 proftpd https://bugs.mageia.org/show_bug.cgi?id=3980 samba Needs testing on x86_64: https://bugs.mageia.org/show_bug.cgi?id=3902 jasper https://bugs.mageia.org/show_bug.cgi?id=3937 dhcp https://bugs.mageia.org/show_bug.cgi?id=3939 nfs-utils https://bugs.mageia.org/show_bug.cgi?id=3940 libxml2 https://bugs.mageia.org/show_bug.cgi?id=3942 icu https://bugs.mageia.org/show_bug.cgi?id=3982 libsndfile https://bugs.mageia.org/show_bug.cgi?id=3985 libtiff https://bugs.mageia.org/show_bug.cgi?id=3993 gif2png https://bugs.mageia.org/show_bug.cgi?id=3994 t1lib https://bugs.mageia.org/show_bug.cgi?id=3998 gimp https://bugs.mageia.org/show_bug.cgi?id=3999 libzip https://bugs.mageia.org/show_bug.cgi?id=2064 krb5-appl Needs testing on both: https://bugs.mageia.org/show_bug.cgi?id=3895 PHP (Thomas also needs to rebuild php-apc and php-eaccelerator) https://bugs.mageia.org/show_bug.cgi?id=3955 cyrus-imapd Already tested, needs pushed by sysadmins: https://bugs.mageia.org/show_bug.cgi?id=3941 libarchive https://bugs.mageia.org/show_bug.cgi?id=3995 libuser What about https://bugs.mageia.org/show_bug.cgi?id=3601 krusader And all updates candidates: https://bugs.mageia.org/buglist.cgi?cmdtype=doremremaction=runnamedcmd=waiting%20for%20QA%20testsharer_id=22
Re: [Mageia-dev] urpmi installing src.rpm defaults to --buildrequires
Op zondag 08 januari 2012 23:26:38 schreef Pascal Terjan: On Sun, Jan 8, 2012 at 22:12, Maarten Vanraes al...@rmail.be wrote: Hi, i donno if it's me, but i noticed the following: [alien@localhost manaplus]$ /usr/sbin/urpmi /tmp/manaplus-1.1.5.1-4.mga1.src.rpm please use --buildrequires or --install-src, defaulting to --buildrequires ... i noticed something was wrong when i clicked on the .src.rpm file on the file browser and chose install the src.rpm file... I do believe it should default to --install-src ? Maybe it should depend if you are root the thing is that defaulting to --buildrequires is not intuitive, ok, it's what you mostly use, but not what you expect if you're using urpmi. imho if you wanted the buildrequires; you'd exactly do that. i imagine this also changes that in GUI and you're installing .src.rpm, it should NOT ask for superuser credentials... because it's not needed and definately not what you want. is this behavior changed recently, or was it always like this?
Re: [Mageia-dev] urpmi installing src.rpm defaults to --buildrequires
On Sun, Jan 8, 2012 at 23:25, Maarten Vanraes al...@rmail.be wrote: Op zondag 08 januari 2012 23:26:38 schreef Pascal Terjan: On Sun, Jan 8, 2012 at 22:12, Maarten Vanraes al...@rmail.be wrote: Hi, i donno if it's me, but i noticed the following: [alien@localhost manaplus]$ /usr/sbin/urpmi /tmp/manaplus-1.1.5.1-4.mga1.src.rpm please use --buildrequires or --install-src, defaulting to --buildrequires ... i noticed something was wrong when i clicked on the .src.rpm file on the file browser and chose install the src.rpm file... I do believe it should default to --install-src ? Maybe it should depend if you are root the thing is that defaulting to --buildrequires is not intuitive, ok, it's what you mostly use, but not what you expect if you're using urpmi. imho if you wanted the buildrequires; you'd exactly do that. I think urpmi used to always install buildrequires and have no option. The old behaviour remained as default. i imagine this also changes that in GUI and you're installing .src.rpm, it should NOT ask for superuser credentials... because it's not needed and definately not what you want. is this behavior changed recently, or was it always like this? It has always been like that as far as I remember
Re: [Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia
W dniu 08.01.2012 22:04, Luc Menut pisze:
Le 08/01/2012 21:18, Kamil Rytarowski a écrit :
W dniu 08.01.2012 15:19, Luc Menut pisze:
Hello,
[...]
if the versionned provides indicates the location, we can use it if
necessary in Conflicts or Requires in others packages.
e.g. currently Firefox searches dictionnaries in
/usr/share/dict/mozilla (myspell dictionaries). when we change this
location, we could add a Requires enchant-dictionary = 4.
same for hunspell-dictionary and dictionary-%{languagecode}, a
versionned provides could indicate the location of the dictionary.
if we want to be able to remove easily all the compatibility link in
the future, we should really consider this.
If a package requires enchant-dictionary, then language specific will be
chosen before Aspell. This is the whole idea behind it. (eg. Voikko is
chosen before hunspell-fi and aspell-fi too).
OK, I understand the use for enchant-dictionary.
And I'm against some
special versioning for directories, we don't really need it.
sorry but I don't agree with you here.
e.g. in coming days, we will fix firefox (and other mozilla apps) to
use hunspell-dictionaries; we will update the link to
/usr/lib64/firefox-9.0.1/dictionaries - /usr/share/hunspell
and change the requires to hunspell-dictionary.
but hunspell-dictionaries old generation (mga1) provide
hunspell-dictionary, and install dictionaries only in /usr/share/myspell.
Just a technical note:
Old Hunspell dictionaries don't provide anything additional. They are
just dangling without any special integration with the system, please
take a look:
http://svnweb.mageia.org/packages/cauldron/hunspell-fr/current/SPECS/hunspell-fr.spec?revision=134361view=markup
$ urpmq --provides hunspell-nl
hunspell-nl[== 2.00-2.mga1]
New Hunspell dictionaries obsoleteprovide Myspell packages and come
into the Myspell place. They also install dictionaries into the same
place as the predecessor - this is why I put it into the place of the
old enchant-dictionary=2 place.
Gentoo uses common packages for Myspell and Hunspell dictionaries. So
this is additional argument to put Hunspell in the place of Myspell.
how do you plan to handle that the fixed firefox will absolutly need
hunspell-dictionaries new generation,
Fix Mozilla packages (in Mga2) to use new generation dictionaries in
/usr/share/hunspell
and can't work with hunspell-dictionaries old generation ?
Is there need for anything needed in addition of just higher
versionrelease of every new generation hunspell-dictionary in Mga2,
then the one in Mga1? In Mga2 every hunspell-dictionary will be in the
new generation version.
And I think we support Mga1-Mga2 full migration, so everything will be
working.
Am I right?
regards,
Luc
Re: [Mageia-dev] urpmi installing src.rpm defaults to --buildrequires
Op maandag 09 januari 2012 01:01:26 schreef Pascal Terjan: On Sun, Jan 8, 2012 at 23:25, Maarten Vanraes al...@rmail.be wrote: Op zondag 08 januari 2012 23:26:38 schreef Pascal Terjan: On Sun, Jan 8, 2012 at 22:12, Maarten Vanraes al...@rmail.be wrote: Hi, i donno if it's me, but i noticed the following: [alien@localhost manaplus]$ /usr/sbin/urpmi /tmp/manaplus-1.1.5.1-4.mga1.src.rpm please use --buildrequires or --install-src, defaulting to --buildrequires ... i noticed something was wrong when i clicked on the .src.rpm file on the file browser and chose install the src.rpm file... I do believe it should default to --install-src ? Maybe it should depend if you are root the thing is that defaulting to --buildrequires is not intuitive, ok, it's what you mostly use, but not what you expect if you're using urpmi. imho if you wanted the buildrequires; you'd exactly do that. I think urpmi used to always install buildrequires and have no option. The old behaviour remained as default. i imagine this also changes that in GUI and you're installing .src.rpm, it should NOT ask for superuser credentials... because it's not needed and definately not what you want. is this behavior changed recently, or was it always like this? It has always been like that as far as I remember hmm, maybe i've always used rpm -ivh file.src.rpm then...
[Mageia-dev] mentors + apprentices
Hi everyone, We have a newly qualified packager, kamil, who is already maintaining over 160 packages. He is largely responsible for the considerabe decrease in unmaintained packages in the last few days, although many other packagers have contributed. We have another Mandriva packager who has joined our packaging team, nelg (Glen Ogilvie), and is bringing himself up to date for Mageia with jquelin. Also note that philippem (Philippe Makowski) has just posted a message inviting potential apprentices to contact him for mentoring. Any other mentors who feel that they can take on another apprentice are invited to post to this thread. Currently we have 4 apprentice candidates looking for a mentor. am2605 (Andrew Myers), has been waiting now about 5 weeks. He is a longtime Fedora, a web developer, interested in packaging related to Gnome, Java, Eclipse among others, teaching himself Mageia packaging basics. cddesjar (Christopher Desjardins), has been waiting about 3 weeks. He has basic .deb and .rpm packaging experience, including doing texworks and jags on Mageia for himself. Would like to maintain these and R-base. dglent (Dimitrios Glentadakis), had been waiting about a week. He has experience packaging in his personal repos (mageia-gr.org and previously mandrivalinux.gr) with applications he uses, which he would like to package for Mageia repos. He speaks French and English. cyprix (Sam Bailey) He is a long time Mandriva then Mageia user, who runs hosting servers in his work, and is interested in packaging programs for hosting and web-app services. Note that those who have been waiting the longest are at the top of the list. You can find more details at: https://wiki.mageia.org/en/Becoming_a_Mageia_Packager#Packager_apprentice_candidates Mentors, let me know who you take on, and I'll update the tables for you. Thanks :-) Anyone else looking for a mentor, let me know so I can add your name as an apprentice candidate -- or you can do it yourself. https://wiki.mageia.org/en/Becoming_a_Mageia_Packager#Packager_apprentice_candidates See also the previous sections, on becoming a Mageia packager : https://wiki.mageia.org/mw-en/index.php?title=Becoming_a_Mageia_Packageraction=submit#What_is_needed_to_become_a_Mageia_packager To find a mentor, it helps to also post to this list (mageia-dev), or hang out on IRC at freenode #mageia-mentoring. Don't forget that if you contact a mentor directly, they know that you are actively interested. Regards :-) -- André (Packager mentoring program coordinator)
Re: [Mageia-dev] mentors + apprentices
On Mon, Jan 9, 2012 at 7:04 AM, andre999 andre999...@laposte.net wrote: Hi everyone, We have a newly qualified packager, kamil, who is already maintaining over 160 packages. He is largely responsible for the considerabe decrease in unmaintained packages in the last few days, although many other packagers have contributed. We have another Mandriva packager who has joined our packaging team, nelg (Glen Ogilvie), and is bringing himself up to date for Mageia with jquelin. Also note that philippem (Philippe Makowski) has just posted a message inviting potential apprentices to contact him for mentoring. Any other mentors who feel that they can take on another apprentice are invited to post to this thread. Currently we have 4 apprentice candidates looking for a mentor. am2605 (Andrew Myers), has been waiting now about 5 weeks. He is a longtime Fedora, a web developer, interested in packaging related to Gnome, Java, Eclipse among others, teaching himself Mageia packaging basics. when i will have a new slot free i would be interested in this package as he knows java / eclipse. So let see when i will have one ( shouldn't be long ) cddesjar (Christopher Desjardins), has been waiting about 3 weeks. He has basic .deb and .rpm packaging experience, including doing texworks and jags on Mageia for himself. Would like to maintain these and R-base. dglent (Dimitrios Glentadakis), had been waiting about a week. He has experience packaging in his personal repos (mageia-gr.org and previously mandrivalinux.gr) with applications he uses, which he would like to package for Mageia repos. He speaks French and English. cyprix (Sam Bailey) He is a long time Mandriva then Mageia user, who runs hosting servers in his work, and is interested in packaging programs for hosting and web-app services. Note that those who have been waiting the longest are at the top of the list. You can find more details at: https://wiki.mageia.org/en/Becoming_a_Mageia_Packager#Packager_apprentice_candidates Mentors, let me know who you take on, and I'll update the tables for you. Thanks :-) Anyone else looking for a mentor, let me know so I can add your name as an apprentice candidate -- or you can do it yourself. https://wiki.mageia.org/en/Becoming_a_Mageia_Packager#Packager_apprentice_candidates See also the previous sections, on becoming a Mageia packager : https://wiki.mageia.org/mw-en/index.php?title=Becoming_a_Mageia_Packageraction=submit#What_is_needed_to_become_a_Mageia_packager To find a mentor, it helps to also post to this list (mageia-dev), or hang out on IRC at freenode #mageia-mentoring. Don't forget that if you contact a mentor directly, they know that you are actively interested. Regards :-) -- André (Packager mentoring program coordinator)
