Re: [pacman-dev] Translation errors
On Thu, Jul 17, 2008 at 2:41 PM, Xavier [EMAIL PROTECTED] wrote:
Xavier wrote:
Hm, that took more time than I hoped / expected :P
I am still wondering who won the medal of causing the most translation
annoyance between me :
http://projects.archlinux.org/?p=pacman.git;a=commitdiff;h=143135e666f5564240868810f0b8f4bc46ff87b5
(all these [Y/n] to remove)
and Allan :
http://projects.archlinux.org/?p=pacman.git;a=commitdiff;h=3c3cb001a441656c2afba62f0361b83d4987339c
(all these error: to remove)
So you can vote now :)
Also one of my other change became pretty sneaky with the [Y/n] change :
http://projects.archlinux.org/?p=pacman.git;a=commitdiff;h=d5278ebb3ba94efdc9fffb7924ac66b6747d9011
I almost missed that change:
- :: and install the new pacman version now?))) {
+ :: and upgrade these packages now?))) {
Sorry, now done.
Anyway I hope I didn't make too much mistakes in this update :P
I think all translators should pay attention to at least the above
points I mentioned.
I only looked at the last nasty message mentioned above (upgrade these
packages now), and I see that the German translation still includes
[Y/n], and the Chinese and Spanish versions still mention pacman. I
guess Hungarian and Italian versions are fine.
That does not surprise me though, I figured all these things would be
harder to catch by people who don't follow all pacman development, so
that is totally understandable.
One last mistake I just noticed is one untranslated message in libalpm
hungarian translation :
#, c-format
msgid removing '%s' from target list because it conflicts with '%s'\n
msgstr
___
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
zh_CN.po.tar.gz
Description: GNU Zip compressed data
___
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
Re: [pacman-dev] Translation errors
On Thu, Jul 17, 2008 at 11:03 AM, Allan McRae [EMAIL PROTECTED] wrote: By my count of those patches, I made 38 changes and you made 22. So I win! ;) Ahah, but mine was more annoying to delete, at least for me. I could delete the error word quickly with dw in vim, while [Y/n] is seen as many different words. ___ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
[pacman-dev] Updated Hungarian translation (resubmit)
One last mistake I just noticed is one untranslated message in libalpm hungarian translation : #, c-format msgid removing '%s' from target list because it conflicts with '%s'\n msgstr Thx. Fixed. Bye hu.tar.gz Description: GNU Zip compressed data ___ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
[pacman-dev] [PATCH] New PM_TRANS_EVT_LDCONFIG events
From 49899f082d6ccd52dc8164a5856353dd2a12ee20 Mon Sep 17 00:00:00 2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Thu, 17 Jul 2008 12:15:29 +0200
Subject: [PATCH] New PM_TRANS_EVT_LDCONFIG events
User will see running ldconfig... message.
Signed-off-by: Nagy Gabor [EMAIL PROTECTED]
---
lib/libalpm/add.c |2 ++
lib/libalpm/alpm.h|4
lib/libalpm/remove.c |2 ++
src/pacman/callback.c |6 +-
4 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/lib/libalpm/add.c b/lib/libalpm/add.c
index 3b60fb3..12a315d 100644
--- a/lib/libalpm/add.c
+++ b/lib/libalpm/add.c
@@ -873,8 +873,10 @@ int _alpm_add_commit(pmtrans_t *trans, pmdb_t *db)
}
/* run ldconfig if it exists */
+ EVENT(trans, PM_TRANS_EVT_LDCONFIG_START, NULL, NULL);
_alpm_log(PM_LOG_DEBUG, running \ldconfig -r %s\\n, handle-root);
_alpm_ldconfig(handle-root);
+ EVENT(trans, PM_TRANS_EVT_LDCONFIG_DONE, NULL, NULL);
return(0);
}
diff --git a/lib/libalpm/alpm.h b/lib/libalpm/alpm.h
index fbef057..c61533a 100644
--- a/lib/libalpm/alpm.h
+++ b/lib/libalpm/alpm.h
@@ -338,6 +338,10 @@ typedef enum _pmtransevt_t {
* to the callback, respectively.
*/
PM_TRANS_EVT_UPGRADE_DONE,
+/** ldconfig will run */
+ PM_TRANS_EVT_LDCONFIG_START,
+ /** ldconfig ran */
+ PM_TRANS_EVT_LDCONFIG_DONE,
/** Target package's integrity will be checked. */
PM_TRANS_EVT_INTEGRITY_START,
/** Target package's integrity was checked. */
diff --git a/lib/libalpm/remove.c b/lib/libalpm/remove.c
index 864fafa..a5ee3f0 100644
--- a/lib/libalpm/remove.c
+++ b/lib/libalpm/remove.c
@@ -404,8 +404,10 @@ int _alpm_remove_commit(pmtrans_t *trans, pmdb_t *db)
/* run ldconfig if it exists */
if(trans-type != PM_TRANS_TYPE_REMOVEUPGRADE) {
+ EVENT(trans, PM_TRANS_EVT_LDCONFIG_START, NULL, NULL);
_alpm_log(PM_LOG_DEBUG, running \ldconfig -r %s\\n,
handle-root);
_alpm_ldconfig(handle-root);
+ EVENT(trans, PM_TRANS_EVT_LDCONFIG_DONE, NULL, NULL);
}
return(0);
diff --git a/src/pacman/callback.c b/src/pacman/callback.c
index f968873..3bcf55e 100644
--- a/src/pacman/callback.c
+++ b/src/pacman/callback.c
@@ -159,7 +159,7 @@ void cb_trans_evt(pmtransevt_t event, void *data1, void
*data2)
{
switch(event) {
case PM_TRANS_EVT_CHECKDEPS_START:
- printf(_(checking dependencies...\n));
+ printf(_(checking dependencies...\n));
break;
case PM_TRANS_EVT_FILECONFLICTS_START:
if(config-noprogressbar) {
@@ -230,6 +230,9 @@ void cb_trans_evt(pmtransevt_t event, void *data1, void
*data2)
case PM_TRANS_EVT_RETRIEVE_START:
printf(_(:: Retrieving packages from %s...\n),
(char*)data1);
break;
+ case PM_TRANS_EVT_LDCONFIG_START:
+ printf(_(running ldconfig...\n));
+ break;
/* all the simple done events, with fallthrough for each */
case PM_TRANS_EVT_FILECONFLICTS_DONE:
case PM_TRANS_EVT_CHECKDEPS_DONE:
@@ -238,6 +241,7 @@ void cb_trans_evt(pmtransevt_t event, void *data1, void
*data2)
case PM_TRANS_EVT_INTEGRITY_DONE:
case PM_TRANS_EVT_DELTA_INTEGRITY_DONE:
case PM_TRANS_EVT_DELTA_PATCHES_DONE:
+ case PM_TRANS_EVT_LDCONFIG_DONE:
/* nothing */
break;
}
--
1.5.6.3
___
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
Re: [pacman-dev] [PATCH] New PM_TRANS_EVT_LDCONFIG events
From 49899f082d6ccd52dc8164a5856353dd2a12ee20 Mon Sep 17 00:00:00 2001 From: Nagy Gabor [EMAIL PROTECTED] Date: Thu, 17 Jul 2008 12:15:29 +0200 Subject: [PATCH] New PM_TRANS_EVT_LDCONFIG events User will see running ldconfig... message. Signed-off-by: Nagy Gabor [EMAIL PROTECTED] I know that this cannot be accepted to 3.2 because of string freeze. So if you like it, you may push it to 3.2.1. Alternatively, you can keep the alpm part (this is an API extension, which is expected in major releases), and comment out the printf in front-end temporarily (not behaviour change, but extended API). Bye ___ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
[pacman-dev] [translation] updated Turkish translation
Here's the updated Türkçe (Turkish) translation :) -- A day without sunshine is like a day without orange juice. turkish.tar.bz2 Description: application/tbz ___ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
Re: [pacman-dev] vercmp discussion (was: String freeze for 3.2 release)
It indeed looks like we just need to handle the case where it runs out
of segments on one string.
But we have to handle two cases : run out of segments with the
-release number or without it.
So in both cases, I handle it differently if the last remaining
segment starts with a letter or not.
I am not 100% sure that it will work correctly in every single cases,
but the logic seems alright, there is no regression on all existing
vercmp test, and the 4 new tests you posted in an older thread now
pass fine.
I did a quick read on the new vercmp code. This is not an easy-to-read
code (and IMHO it is a bit overkill: strdup, free? - this is not
related to your patch), but it seems OK to me. Overall it is much better
than pre-patch state.
Some little observations:
1. This vercmp the code doesn't follow alpm code style (not related
to your patch, again):
while (*one == '0') one++;
if(!(*one *two)) break;
I like this one-liners better than {} 3 liner version of these.
Is this allowed in our patches, too?
2. A very little notice:
Now 1.5b 1.5, but 1.5.b 1.5
In the block terminology of the code, 1.5b and 1.5.b are identical.
The difference appeared, because your patch uses isalpha() instead of
some next block is alpha? computation. To be honest, this may be
better than 1.5.b 1.5, so you can skip this casuist note.
Bye
___
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
Re: [pacman-dev] vercmp discussion (was: String freeze for 3.2 release)
On Thu, Jul 17, 2008 at 10:23 AM, Nagy Gabor [EMAIL PROTECTED] wrote:
It indeed looks like we just need to handle the case where it runs out
of segments on one string.
But we have to handle two cases : run out of segments with the
-release number or without it.
So in both cases, I handle it differently if the last remaining
segment starts with a letter or not.
I am not 100% sure that it will work correctly in every single cases,
but the logic seems alright, there is no regression on all existing
vercmp test, and the 4 new tests you posted in an older thread now
pass fine.
I did a quick read on the new vercmp code. This is not an easy-to-read
code (and IMHO it is a bit overkill: strdup, free? - this is not
related to your patch), but it seems OK to me. Overall it is much better
than pre-patch state.
Here is the deal- this patch was meant to unify our code with the
upstream RPM code as much as possible. The one thing I shied away from
was using alloca() and using strdup/free instead.
Some little observations:
1. This vercmp the code doesn't follow alpm code style (not related
to your patch, again):
while (*one == '0') one++;
if(!(*one *two)) break;
I like this one-liners better than {} 3 liner version of these.
Is this allowed in our patches, too?
In short, no. The idea here was to stick with the RPM upstream code so
someone can do another diff at a later time to rectify the changes.
2. A very little notice:
Now 1.5b 1.5, but 1.5.b 1.5
In the block terminology of the code, 1.5b and 1.5.b are identical.
The difference appeared, because your patch uses isalpha() instead of
some next block is alpha? computation. To be honest, this may be
better than 1.5.b 1.5, so you can skip this casuist note.
We need to take a step back here and examine things- RPM does a great
amount of work to make version comparison work as good as possible.
If we make a change to the core RPM code, we need to ask why wasn't
this change made upstream or why don't they do it this way. I guess
that is how I see hardcoding things like alpha or beta into the
detection code- they don't do it and seem to be fine with that.
I feel for any changes proposed here, we need to explain why our
version should deviate from the upstream code (as we do in the case of
the pkgrel stuff) before I will really consider a patch to fix
behavior.
-Dan
___
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
Re: [pacman-dev] vercmp discussion (was: String freeze for 3.2 release)
This note inspired me to test '1.0. == 1.0' You may think that this is useless, but image '1.0 ' versus '1.0' (extra spacebar, '\n' etc. character). The old code beats the new one again :-P I mean 3.1 vercmp code beats 3.2 vercmp code. Xav, your patch is excellent. (And I just joked here, of course.) Bye ___ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
Re: [pacman-dev] vercmp discussion (was: String freeze for 3.2 release)
On Thu, Jul 17, 2008 at 5:58 PM, Nagy Gabor [EMAIL PROTECTED] wrote: OK. I believe that RPM guys are cool guys;-) I think they simply don't need this mplayer 1.0rc2 versus 1.0 stuff, because they use different versioning scheme (as I see): http://dag.wieers.com/rpm/packages/mplayer/ I agree with you, that hacking vercmp is not a good idea, that's why I say that we should revert the whole stuff. The old code was tested by Archers for long time, and it seems to worked perfectly. (I know that in case of reverting, our work on new vercmp was just a waste of time, sry.) Personally I still don't see what is fixed by the new imported code. Or it is notably faster? I can be convinced, but not just saying trust on RPM guys. For what it is worth, I totally agree with Nagy. RPM people have to deal with different and odd versioning schemes, so unfortunately, we can't simply reuse their code as is. If our need and usage were closer, it would be a very good idea to follow upstream as close as possible, but since it is not the case, I am not sure it is a good idea. We indeed had perfectly working code, and now we are losing time on a code that didn't really need to be changed. I think that there are many parts of pacman which require a lot of work and attention, but this is not one of them, so I am also in favor or just reverting to the good old working code. ___ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
Re: [pacman-dev] Translation errors
Am Donnerstag 17 Juli 2008 08:41:15 schrieb Xavier: and I see that the German translation still includes [Y/n], ... and what is even worse, it should be [J/n] in German. That particular line was a mess in older versions, anyway. I'll fix it this night. However, is it correct that [Y/n] still appears in the msgid (line 1221): msgid Are you sure you wish to do this? [Y/n] msgstr Sind Sie sicher, dass Sie dies tun möchten? [J/n] ___ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
Re: [pacman-dev] Translation errors
Matthias Gorissen wrote: Am Donnerstag 17 Juli 2008 08:41:15 schrieb Xavier: and I see that the German translation still includes [Y/n], ... and what is even worse, it should be [J/n] in German. That particular line was a mess in older versions, anyway. I'll fix it this night. However, is it correct that [Y/n] still appears in the msgid (line 1221): msgid Are you sure you wish to do this? [Y/n] msgstr Sind Sie sicher, dass Sie dies tun möchten? [J/n] Hm good point. This one is in makepkg, so it is normal indeed, it was not affected by the new Y/n handling inside pacman. However, the above translation is wrong too, you have to keep the [Y/n] intact, because the check itself is not localized. That means that when you have to answer that question, it will only accept yes or y (case insensitive), and not ja or j. Again, all what said above only concerns makepkg. For pacman everything is localized, which is why you need to translate all these strings : [Y/n] , [y/N], YES, NO, etc But it would probably make more sense to just do exactly the same thing in makepkg, and it should be rather easy. Besides, as a benefit of having only one .po file for both makepkg and pacman, we can just reuse all the above strings. ___ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
Re: [pacman-dev] Translation errors
El Thursday 17 July 2008 12:50:13 Matthias Gorissen escribió: Am Donnerstag 17 Juli 2008 08:41:15 schrieb Xavier: and I see that the German translation still includes [Y/n], ... and what is even worse, it should be [J/n] in German. That particular line was a mess in older versions, anyway. I'll fix it this night. However, is it correct that [Y/n] still appears in the msgid (line 1221): msgid Are you sure you wish to do this? [Y/n] msgstr Sind Sie sicher, dass Sie dies tun möchten? [J/n] long time ago i changed the [Y/n] with [S/n] and the users told me that the s key was not recognized by pacman. In that time i ask for a change in the way of process the answer ( n for not and everything else for yes, but the idea was rejected.) I don't know if pacman changed that, i'm a little confused because some translations use both (for example, the fr one). In other words, i think you must let the [Y/n] message untouched. if i am wrong, please tell me for change the questions options. ___ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | Juan Pablo González Tognarelli | http://lacasadeljota.blogspot.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | Si desea verificar el origen de este correo, usted puede buscar mi llave | gpg pública con mi dirección en http://pgp.mit.edu/ y comprobar la firma - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - signature.asc Description: This is a digitally signed message part. ___ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
[pacman-dev] [translation]Spanish translation
Another minor update. I think this is the last one. Thanks to xavier for the explain! - Fixed the localization mesages for the answers pacman.es.po.3.2.fixed-1.tgz Description: application/tgz signature.asc Description: This is a digitally signed message part. ___ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
Re: [pacman-dev] [translation] updated Turkish translation
Samed Beyribey wrote: Here's the updated Türkçe (Turkish) translation :) msgid N msgstr Hayır The translation should be just H here. msgid Are you sure you wish to do this? [Y/n] msgstr Bunu yapmak istediğinize emin misiniz? [E/h] This specific [Y/n] should not be translated. I know it is confusing though. It can be fixed, but not now since we are in a string freeze, so it will have to wait for 3.2.1. I can fix these two errors, so no problem. I can't fix the following one though : #, c-format msgid :: Do you want to cancel the current operation\n :: and upgrade these packages now? msgstr :: Yürütülen işlemi şimdi durdurup\n :: yeni pacman sürümünün yüklenmesini ister misiniz? pacman shouldn't be mentioned anymore, should it? You can just post the correct translation here, no need to send the whole file again. ___ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
Re: [pacman-dev] [translation] updated Turkish translation
Samed Beyribey wrote: Hello, On Friday 18 July 2008 00:26:57 Xavier wrote: Samed Beyribey wrote: Here's the updated Türkçe (Turkish) translation :) msgid N msgstr Hayır The translation should be just H here. msgid Are you sure you wish to do this? [Y/n] msgstr Bunu yapmak istediğinize emin misiniz? [E/h] Oops sorry for the mistake, I've just noticed it. This specific [Y/n] should not be translated. I know it is confusing though. It can be fixed, but not now since we are in a string freeze, so it will have to wait for 3.2.1. I can fix these two errors, so no problem. I can't fix the following one though : #, c-format msgid :: Do you want to cancel the current operation\n :: and upgrade these packages now? msgstr :: Yürütülen işlemi şimdi durdurup\n :: yeni pacman sürümünün yüklenmesini ister misiniz? Then it should be: msgid :: Do you want to cancel the current operation\n :: and upgrade these packages now? msgstr :: Yürütülen işlemi şimdi durdurup\n :: yeni sürümün yüklenmesini ister misiniz? Cool, that was fast. So it is all fixed now. You can see all uptodate translations here : http://shining.toofishes.net/gitweb/gitweb.cgi?p=pacman.git;a=shortlog;h=refs/heads/translations ___ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
Re: [pacman-dev] vercmp discussion (was: String freeze for 3.2 release)
On Thu, Jul 17, 2008 at 11:35 AM, Xavier [EMAIL PROTECTED] wrote: On Thu, Jul 17, 2008 at 5:58 PM, Nagy Gabor [EMAIL PROTECTED] wrote: OK. I believe that RPM guys are cool guys;-) I think they simply don't need this mplayer 1.0rc2 versus 1.0 stuff, because they use different versioning scheme (as I see): http://dag.wieers.com/rpm/packages/mplayer/ I agree with you, that hacking vercmp is not a good idea, that's why I say that we should revert the whole stuff. The old code was tested by Archers for long time, and it seems to worked perfectly. (I know that in case of reverting, our work on new vercmp was just a waste of time, sry.) Personally I still don't see what is fixed by the new imported code. Or it is notably faster? I can be convinced, but not just saying trust on RPM guys. For what it is worth, I totally agree with Nagy. RPM people have to deal with different and odd versioning schemes, so unfortunately, we can't simply reuse their code as is. If our need and usage were closer, it would be a very good idea to follow upstream as close as possible, but since it is not the case, I am not sure it is a good idea. We indeed had perfectly working code, and now we are losing time on a code that didn't really need to be changed. I think that there are many parts of pacman which require a lot of work and attention, but this is not one of them, so I am also in favor or just reverting to the good old working code. I'll admit defeat, I tried. :) Can someone put together a single revert patch to take care of this? I know it took us at least two commits to get the vercmp code updated, so we will probably need to do some manual work to get this reverted. Obviously the vercmptest script should stay, and perhaps we should add the proposed tests from Nagy to the mix. If people do see any improvements that can be backported to the previous code, that would be good to have. -Dan ___ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
Re: [pacman-dev] static libraries not stripped?
On Tue, Jul 15, 2008 at 5:37 PM, Xavier [EMAIL PROTECTED] wrote: I just noticed that the last ffmpeg package is much bigger than the old one (13MB vs 4MB). Looking more in depth in the two packages, it looks like it is all the static libraries which are much bigger now : -rw-r--r-- root/root 4838852 2007-12-05 03:43 usr/lib/libavcodec.a -rw-r--r-- root/root 20604500 2008-06-26 03:12 usr/lib/libavcodec.a Isn't this only because the new one is not stripped? Here is how it is detected by file : $ file -biz /usr/lib/libavcodec.a application/x-archive So could this be an old pacman 3.1 regression ? http://projects.archlinux.org/?p=pacman.git;a=commitdiff;h=721ceee1e2c9b18425d84cf39f6541b2f04072b3 Maybe this code also needs to handle x-archive. $ file -iz /usr/lib/* | grep x-archive | wc -l 366 $ file -iz /usr/lib/*.a | grep x-archive | wc -l 366 $ file -iz /usr/lib/*.a | grep -v x-archive /usr/lib/libcurses.a: application/x-not-regular-file /usr/lib/libdts.a:application/x-not-regular-file /usr/lib/libieee.a: application/x-object /usr/lib/libmcheck.a: application/x-object /usr/lib/libpng.a:application/x-not-regular-file So a few .a files don't appear as x-archive, but apparently the big majority of them do, so maybe this is not a big problem. I think a patch for this is fair game. -Dan ___ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
Re: [pacman-dev] [PATCH] makepkg: speed up svn revision check for large repositories
Dan McGee wrote: On Wed, Jul 16, 2008 at 7:14 AM, Xavier [EMAIL PROTECTED] wrote: On Wed, Jul 16, 2008 at 1:47 PM, Allan McRae [EMAIL PROTECTED] wrote: More google searching on this and requiring to correct my previous assertions... LC_ALL=C is equivalent to LC_ALL=POSIX. Just using LC_ALL= does require LANG= as if LC_ALL is unset it then looks at the LANG variable. So the following all are equivalent (I think...): LC_ALL= LANG= LC_ALL=C - my vote LC_ALL=POSIX Also, LC_ALL= LANG= does not seem to work if LC_MESSAGES is set. So I guess you have to use LC_ALL= LANG= LC_MESSAGES= I would also prefer to just use LC_ALL=C everywhere if that is possible. Patches coming for this? Or what did we decide on? Patch on its way that uses LC_ALL=C everywhere. Allan ___ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
