Re: [pgadmin-hackers] AR Update
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ossama Khayat Sent: 02 December 2004 22:00 To: [EMAIL PROTECTED] Subject: [pgadmin-hackers] AR Update Hi, This is an updated file. Hi, Err, is this the same as the one I applied yesterday, or a further update? Regards, Dave ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[pgadmin-hackers] CVS Commit by dpage: Updated Arabic translation [Ossama Khayat]
Log Message: --- Updated Arabic translation [Ossama Khayat] Modified Files: -- pgadmin3/src/ui/ar_SA: pgadmin3.mo (r1.16 - r1.17) pgadmin3.po (r1.19 - r1.20) Index: pgadmin3.po === RCS file: /projects/pgadmin3/src/ui/ar_SA/pgadmin3.po,v retrieving revision 1.19 retrieving revision 1.20 diff -Lsrc/ui/ar_SA/pgadmin3.po -Lsrc/ui/ar_SA/pgadmin3.po -u -w -r1.19 -r1.20 --- src/ui/ar_SA/pgadmin3.po +++ src/ui/ar_SA/pgadmin3.po @@ -7,7 +7,7 @@ msgstr Project-Id-Version: pgadmin3\n POT-Creation-Date: 2004-09-05 23:02+0200\n -PO-Revision-Date: 2004-12-01 16:50+0300\n +PO-Revision-Date: 2004-12-03 00:45+0300\n Last-Translator: Ossama M. Khayat [EMAIL PROTECTED]\n Language-Team: Arabic [EMAIL PROTECTED]\n MIME-Version: 1.0\n @@ -2212,7 +2212,7 @@ #: src/ui/frmQuery.cpp:134 msgid Explain analyse query -msgstr Explain analyse query +msgstr شرح استعلام التحليل #: src/ui/frmQuery.cpp:130 #: src/ui/frmQuery.cpp:196 @@ -2221,7 +2221,7 @@ #: src/ui/frmQuery.cpp:133 msgid Explain verbose query -msgstr Explain verbose query +msgstr شرح الاستعلام المطوّل # standard # standard @@ -2992,7 +2992,7 @@ #: src/ui/frmOptions.cpp:273 #: src/ui/frmQuery.cpp:498 msgid Log files (*.log)|*.log|All files (*.*)|*.* -msgstr Log files (*.log)|*.log|All files (*.*)|*.* +msgstr ملفات السجلات (*.log)|*.log|كل الملفات (*.*)|*.* # standard #: input:647 @@ -3798,7 +3798,7 @@ # standard #: input:158 msgid Parameter -msgstr Parameter +msgstr متغير #: src/schema/pgType.cpp:137 msgid Passed by Value? @@ -4200,14 +4200,14 @@ #: src/ui/frmQuery.cpp:791 msgid Query files (*.sql)|*.sql|All files (*.*)|*.* -msgstr Query files (*.sql)|*.sql|All files (*.*)|*.* +msgstr ملفات الاستعلام (*.sql)|*.sql|كل الملفات (*.*)|*.* #: src/ui/frmQuery.cpp:821 msgid Query files (*.sql)|*.sql|UTF-8 query files (*.sql)|*.sql|All files (*.*)|*.* msgstr ملفات الاستعلام (*.sql)|*.sql|ملفات استعلام UTF-8 (*.sql)|*.sql|كل الملفات (*.*)|*.* msgid Query files (*.sql)|*.sql|UTF-8 query files (*.usql)|*.usql|All files (*.*)|*.* -msgstr Query files (*.sql)|*.sql|UTF-8 query files (*.usql)|*.usql|All files (*.*)|*.* +msgstr ملفات الاستعلام (*.sql)|*.sql|مفات استعلام بتشفير UTF-8 (*.usql)|*.usql|كل الملفات (*.*)|*.* #: src/db/pgSet.cpp:384 #, c-format @@ -4639,7 +4639,7 @@ #: src/ui/events.cpp:548 msgid SQL Scripts (*.sql)|*.sql|All files (*.*)|*.* -msgstr SQL Scripts (*.sql)|*.sql|All files (*.*)|*.* +msgstr نصوص SQL (*.sql)|*.sql|كل الملفات (*.*)|*.* # standard input:4 # standard ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[pgadmin-hackers] CVS Commit by dpage: Updated Arabic translation [Ossama Khayat]
Log Message: --- Updated Arabic translation [Ossama Khayat] Tags: REL-1_2_0_PATCHES Modified Files: -- pgadmin3/src/ui/ar_SA: pgadmin3.mo (r1.15.2.1 - r1.15.2.2) pgadmin3.po (r1.18.2.1 - r1.18.2.2) Index: pgadmin3.po === RCS file: /projects/pgadmin3/src/ui/ar_SA/pgadmin3.po,v retrieving revision 1.18.2.1 retrieving revision 1.18.2.2 diff -Lsrc/ui/ar_SA/pgadmin3.po -Lsrc/ui/ar_SA/pgadmin3.po -u -w -r1.18.2.1 -r1.18.2.2 --- src/ui/ar_SA/pgadmin3.po +++ src/ui/ar_SA/pgadmin3.po @@ -7,7 +7,7 @@ msgstr Project-Id-Version: pgadmin3\n POT-Creation-Date: 2004-09-05 23:02+0200\n -PO-Revision-Date: 2004-12-01 16:50+0300\n +PO-Revision-Date: 2004-12-03 00:45+0300\n Last-Translator: Ossama M. Khayat [EMAIL PROTECTED]\n Language-Team: Arabic [EMAIL PROTECTED]\n MIME-Version: 1.0\n @@ -2212,7 +2212,7 @@ #: src/ui/frmQuery.cpp:134 msgid Explain analyse query -msgstr Explain analyse query +msgstr شرح استعلام التحليل #: src/ui/frmQuery.cpp:130 #: src/ui/frmQuery.cpp:196 @@ -2221,7 +2221,7 @@ #: src/ui/frmQuery.cpp:133 msgid Explain verbose query -msgstr Explain verbose query +msgstr شرح الاستعلام المطوّل # standard # standard @@ -2992,7 +2992,7 @@ #: src/ui/frmOptions.cpp:273 #: src/ui/frmQuery.cpp:498 msgid Log files (*.log)|*.log|All files (*.*)|*.* -msgstr Log files (*.log)|*.log|All files (*.*)|*.* +msgstr ملفات السجلات (*.log)|*.log|كل الملفات (*.*)|*.* # standard #: input:647 @@ -3798,7 +3798,7 @@ # standard #: input:158 msgid Parameter -msgstr Parameter +msgstr متغير #: src/schema/pgType.cpp:137 msgid Passed by Value? @@ -4200,14 +4200,14 @@ #: src/ui/frmQuery.cpp:791 msgid Query files (*.sql)|*.sql|All files (*.*)|*.* -msgstr Query files (*.sql)|*.sql|All files (*.*)|*.* +msgstr ملفات الاستعلام (*.sql)|*.sql|كل الملفات (*.*)|*.* #: src/ui/frmQuery.cpp:821 msgid Query files (*.sql)|*.sql|UTF-8 query files (*.sql)|*.sql|All files (*.*)|*.* msgstr ملفات الاستعلام (*.sql)|*.sql|ملفات استعلام UTF-8 (*.sql)|*.sql|كل الملفات (*.*)|*.* msgid Query files (*.sql)|*.sql|UTF-8 query files (*.usql)|*.usql|All files (*.*)|*.* -msgstr Query files (*.sql)|*.sql|UTF-8 query files (*.usql)|*.usql|All files (*.*)|*.* +msgstr ملفات الاستعلام (*.sql)|*.sql|مفات استعلام بتشفير UTF-8 (*.usql)|*.usql|كل الملفات (*.*)|*.* #: src/db/pgSet.cpp:384 #, c-format @@ -4639,7 +4639,7 @@ #: src/ui/events.cpp:548 msgid SQL Scripts (*.sql)|*.sql|All files (*.*)|*.* -msgstr SQL Scripts (*.sql)|*.sql|All files (*.*)|*.* +msgstr نصوص SQL (*.sql)|*.sql|كل الملفات (*.*)|*.* # standard input:4 # standard ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[pgadmin-hackers] Arabic Translat(or/ion)
Salam, My name is Ossama Khayat, and I'll be the Arabic translator for pgadmin again. If you get any feedback and see any problem I'll be on the list or you can directly mail me for any other issues related to Arabic. regards, Ossama Khayat __ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgadmin-hackers] AR Update
--- Dave Page [EMAIL PROTECTED] wrote: Thanks, update applied to tip and -patches. Cool ;) Would you like me to commit directly to the CVS repository? - Ossama __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [pgadmin-hackers] AR Update
Thanks, update applied to tip and -patches. Regards, Dave. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ossama Khayat Sent: 02 December 2004 22:00 To: [EMAIL PROTECTED] Subject: [pgadmin-hackers] AR Update Hi, This is an updated file. - Ossama Khayat = regards, Ossama Khayat __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgadmin-hackers] AR Update
-Original Message- From: Ossama Khayat [mailto:[EMAIL PROTECTED] Sent: 03 December 2004 09:28 To: Dave Page; [EMAIL PROTECTED] Subject: RE: [pgadmin-hackers] AR Update --- Dave Page [EMAIL PROTECTED] wrote: Thanks, update applied to tip and -patches. Cool ;) Would you like me to commit directly to the CVS repository? No, please send updates when you have them (thought preferrably not daily :-) ). We have quite a strict CVS commit policy so there are very few committers. Now, if anyone knows a way to easily grant commit privs to a single subdirectory only, then perhaps we could arrange something for the translators - after all, it's not like we can test much of what you guys do!! Regards, dave. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgadmin-hackers] AR Update
--- Dave Page [EMAIL PROTECTED] wrote: [...] No, please send updates when you have them (thought preferrably not daily :-) ). We have quite a strict CVS commit policy so there are very few committers. No worries. I'm on the list now. You can directly send to the list and I'll get replies. Thanks, Ossama Khayat __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [pgadmin-hackers] RFC: Update wizard
Miha Radej wrote: hi! Andreas Pflug wrote: Annoying, if you don't want to update. Maybe non-flashing. Or toolbar button, which changes appearance if download is available. The download dlg should be accessible even if no update was automatically detected, to enable manual triggered updates. could you also consider checking for a newer binary snapshot (for windows in my case)? so i wouldn't have to go look every now and then :) i know, i'm being lazy :) The update information checked by pgadmin will be created manually, i.e. it's a kind of release information. We're probably too lazy to update it for every snapshot ;-) Regards, Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[pgadmin-hackers] RFC: Statistics logging of auto update http queries
When pgAdmin is checking for new available updates, I'd like to transfer some statistical data as well, so we can get some kind of information about our users. To have this clean regarding privacy, we should discuss how to do this. Here are my ideas: - Feature should be enabled by default - Before the first update check is performed, the user must be informed about what's going to happen, pointing to the help item describing the post format and the possibility to disable it. - The docs must state clearly what data is transmitted, how it's collected, what we do with it (and what we promise never to do), and point to the sources handling that data for reviewing purposes. Data transmitted: - pgadmin version in use - language in use - update interval (to calculate a weight) - number of registered servers - major version of servers that have been used with pgadmin (collected in the registry) Collected: as above, plus country taken from requesting ip address. Explicitely not to collect: ip address. This data would allow us to estimate the number of pgadmin instances running worldwide, its global distribution and language usage (and resulting from that, which additional languages should be supported). Number of registered servers and versions will give us some hint about the server side. Dave, do you know some OSS authority to review this policy? Regards, Andreas ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [pgadmin-hackers] RFC: Update wizard
-Original Message- From: Andreas Pflug [mailto:[EMAIL PROTECTED] Sent: 03 December 2004 12:18 To: Dave Page Cc: pgadmin-hackers Subject: Re: [pgadmin-hackers] RFC: Update wizard Dave Page wrote: Not directly. The binaries would be corrupted. In the rare case of typo fixes without count change the count could be increased manually. It's a kind of version number anyway. We could use the date too. Why would binaries be corrupted? CVS would change the file to insert the version, which would probably corrupt the binary structure. No, it doesn't, unless it finds a placeholder such as $Id. Even then, I don't think it does so for binary files. In that case then, why distribute the languages seperately? I don't understand the question. We *do* distribute the languages packaged, no? I think I was asking why we shouldn't include the languages in the update zip file, but it was a few days ago now :-) Forget about it! As I also suggested though, there should be an option to turn off auto-checking on the options dialogue. But I could live with non flashing. Disabling autocheck and not updating immediately are different things. The option controls the background checking for updates. If you then double click the alert icon, a dialogue is presented allowing you to select a mirror and download. Speaking of which, we will need to have a list of mirrors on the main webserver that can be downloaded... That is not a problem though. Every 60 days (e.g.) updates are checked, and a feedback is given to the user. After that, the user might decide to upgrade immediately, or do it later. Statusbar icon seems the best solution (but it will need some effort; tooltip and doubleclick on that icon must be supported) Yeah. Regards, Dave. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[pgadmin-hackers] New ftp layout
Hi all, I've created a new ftp layout as discussed earlier. It can be reviewed at http://developer.pgadmin.org/ftp2/ Thoughts/comments are welcome before I make it live. I haven't yet included the debian directories - Raph, can you help out with how they should be handled? Cheers, Dave. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] RFC: Update wizard
Dave Page wrote: No, it doesn't, unless it finds a placeholder such as $Id. Even then, I don't think it does so for binary files. Of course $Id would be necessary. But if CVS doesn't stamp the file, how do you want CVS to handle the revision marking? I think I was asking why we shouldn't include the languages in the update zip file, but it was a few days ago now :-) Forget about it! ?!? You can consider zip as another compression/packaging format, similar to chm. I'm not sure whether wxLocale can handle this too. As I also suggested though, there should be an option to turn off auto-checking on the options dialogue. But I could live with non flashing. Disabling autocheck and not updating immediately are different things. The option controls the background checking for updates. If you then double click the alert icon, a dialogue is presented allowing you to select a mirror and download. Its not as easy as that... for pgadmin base package, I'd only inform about new packages. I wonder if we can do this even system specific, i.e. inform about deb packages on debian, ... For languages, a more complex selection for updating existing and adding new ones is necessary. Regards, Andreas ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgadmin-hackers] New ftp layout
Dave Page wrote: Hi all, I've created a new ftp layout as discussed earlier. It can be reviewed at http://developer.pgadmin.org/ftp2/ Thoughts/comments are welcome before I make it live. Looks good to me. Regards, Andreas ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgadmin-hackers] New ftp layout
Hi all, I've created a new ftp layout as discussed earlier. It can be reviewed at http://developer.pgadmin.org/ftp2/ Thoughts/comments are welcome before I make it live. I haven't yet included the debian directories - Raph, can you help out with how they should be handled? ARGH! :) Debian repositories include each version and you can select a specific version to install if you don't want the latest one. The way the new dirs are organised will generate problems... People will need to change a line in their sources.list (the text file which tell where to find packages) each time a new version is released... I must think about it... Would it be possible to exclude debian dir from X.Y.Z dirs and symlink to ../debian ? Somehing like release/debian directory with packages release/1.0.x/debian - ../debian release/1.2.0/debian - ../debian And so on. don't know... let me think about it. Regards, Raphaël ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] New ftp layout
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On Fri, 3 Dec 2004, Dave Page wrote: I've created a new ftp layout as discussed earlier. It can be reviewed at http://developer.pgadmin.org/ftp2/ Thoughts/comments are welcome before I make it live. What about something like this: * release - Linux - Distro 1 - Distro Version 1 - Distro Version 2 - RPMS - SRPMS - Distro 2 - Windows - ... Os Os OS Same applies for beta, too. Any comments? - -- Devrim GUNDUZ devrim~gunduz.orgdevrim.gunduz~linux.org.tr http://www.tdmsoft.com http://www.gunduz.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBsGlgtl86P3SPfQ4RArXuAJ9FWH4fHBsFjrBV10mZdZlaxSC5ZgCdFm3N /oh26HEha3Lg3xB5DDk9PVU= =/B8h -END PGP SIGNATURE- ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] New ftp layout
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 03 December 2004 14:17 To: Dave Page; [EMAIL PROTECTED] Subject: Re: New ftp layout Hi all, I've created a new ftp layout as discussed earlier. It can be reviewed at http://developer.pgadmin.org/ftp2/ Thoughts/comments are welcome before I make it live. I haven't yet included the debian directories - Raph, can you help out with how they should be handled? ARGH! :) Yup, that's about what I figured you would say!! Debian repositories include each version and you can select a specific version to install if you don't want the latest one. The way the new dirs are organised will generate problems... People will need to change a line in their sources.list (the text file which tell where to find packages) each time a new version is released... I must think about it... Would it be possible to exclude debian dir from X.Y.Z dirs and symlink to ../debian ? Somehing like release/debian directory with packages release/1.0.x/debian - ../debian release/1.2.0/debian - ../debian And so on. Yeah, I can probably do that :-) Give me a few minutes and take a look... Regards, Dave. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgadmin-hackers] New ftp layout
Message d'origine Sujet: [pgadmin-hackers] New ftp layout Date: Fri, 3 Dec 2004 13:04:30 - De: Dave Page [EMAIL PROTECTED] A: pgadmin-hackers [EMAIL PROTECTED] Copie à: [EMAIL PROTECTED] Hi all, I've created a new ftp layout as discussed earlier. It can be reviewed at http://developer.pgadmin.org/ftp2/ Thoughts/comments are welcome before I make it live. less debian specific : why not adding a symlink like current or latest pointing to the latest release. release/current - v1.2.0 Regards, Raphaël ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgadmin-hackers] New ftp layout
Hi, On Fri, 3 Dec 2004, Dave Page wrote: I'm not sure there are enough different Oss are there? The longest directory at the moment only has 12 entries in it, and even if that doubles I don't think it will be hard to find what you need. Mine is nearly the same layout as PostgreSQL.org. Look: http://developer.pgadmin.org/ftp2/release/v1.2.0/ This seems so untidy to me... -- Devrim GUNDUZ devrim~gunduz.orgdevrim.gunduz~linux.org.tr http://www.tdmsoft.com http://www.gunduz.org ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgadmin-hackers] New ftp layout
-Original Message- From: Devrim GUNDUZ [mailto:[EMAIL PROTECTED] Sent: 03 December 2004 13:26 To: Dave Page Cc: pgadmin-hackers; [EMAIL PROTECTED] Subject: Re: [pgadmin-hackers] New ftp layout -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On Fri, 3 Dec 2004, Dave Page wrote: I've created a new ftp layout as discussed earlier. It can be reviewed at http://developer.pgadmin.org/ftp2/ Thoughts/comments are welcome before I make it live. What about something like this: * release - Linux - Distro 1 - Distro Version 1 - Distro Version 2 - RPMS - SRPMS - Distro 2 - Windows - ... Os Os OS Same applies for beta, too. I'm not sure there are enough different Oss are there? The longest directory at the moment only has 12 entries in it, and even if that doubles I don't think it will be hard to find what you need. Regards, Dave. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [pgadmin-hackers] RFC: Update wizard
-Original Message- From: Andreas Pflug [mailto:[EMAIL PROTECTED] Sent: 03 December 2004 13:19 To: Dave Page Cc: pgadmin-hackers Subject: Re: [pgadmin-hackers] RFC: Update wizard No, it doesn't, unless it finds a placeholder such as $Id. Even then, I don't think it does so for binary files. Of course $Id would be necessary. But if CVS doesn't stamp the file, how do you want CVS to handle the revision marking? CVS doesn't have to mark the file internally. Consider what happens if you try to check out a specific revision of a file - we can do that via the web, eg: http://cvs.pgadmin.org/cgi-bin/viewcvs.cgi/pgadmin3/src/ui/ar_SA/pgadmin 3.po?rev=1.20 Gets us rev 1.20. In a similar was it shouldn't be difficult to query cvs for the latest version number of a given file. Its not as easy as that... for pgadmin base package, I'd only inform about new packages. I wonder if we can do this even system specific, i.e. inform about deb packages on debian, ... Even if it just opened a browser at the selected mirror it would be helpful. Other than that, how do we determine the exact OS (ie. the difference between redahat9 and suse8 for example)? For languages, a more complex selection for updating existing and adding new ones is necessary. Yeah, though that shouldn't be a major problem as they're platform independent. Regards, Dave. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] New ftp layout
-Original Message- From: Devrim GUNDUZ [mailto:[EMAIL PROTECTED] Sent: 03 December 2004 13:38 To: Dave Page Cc: pgadmin-hackers; [EMAIL PROTECTED] Subject: RE: [pgadmin-hackers] New ftp layout Hi, On Fri, 3 Dec 2004, Dave Page wrote: I'm not sure there are enough different Oss are there? The longest directory at the moment only has 12 entries in it, and even if that doubles I don't think it will be hard to find what you need. Mine is nearly the same layout as PostgreSQL.org. Look: Didn't we just have a discussion about how virtually every release of pg is structured differently under the binaries directory? :-) http://developer.pgadmin.org/ftp2/release/v1.2.0/ This seems so untidy to me... Seems OK to me. I think having an OS/Version structure could prove less friendly - for example, for the last release, I used slackware 9, for this one, slackware 9.1 and probably for the next slackware 10, or even higher. This would have left a structure like: v1.0.0 slackware 9.0 v1.0.1 slackware 9.0 v1.0.2 slackware 9.0 v1.2.0 slackware 9.1 v1.X.0 slackware 10.0 Similar situations exist for other OS's. That just seems over the top to me. Does anyone else share Devrim's concern? Regards, Dave ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] RFC: Update wizard
Dave Page wrote: -Original Message- From: Andreas Pflug [mailto:[EMAIL PROTECTED] Sent: 03 December 2004 13:19 To: Dave Page Cc: pgadmin-hackers Subject: Re: [pgadmin-hackers] RFC: Update wizard No, it doesn't, unless it finds a placeholder such as $Id. Even then, I don't think it does so for binary files. Of course $Id would be necessary. But if CVS doesn't stamp the file, how do you want CVS to handle the revision marking? CVS doesn't have to mark the file internally. Consider what happens if you try to check out a specific revision of a file - we can do that via the web, eg: http://cvs.pgadmin.org/cgi-bin/viewcvs.cgi/pgadmin3/src/ui/ar_SA/pgadmin 3.po?rev=1.20 Gets us rev 1.20. In a similar was it shouldn't be difficult to query cvs for the latest version number of a given file. First, do we really want to hammer CVS for each update check? I'd think having this in an available versions file is sufficient. Second, the issue is not to retrieve a version, but to identify the version of the language file currently in use. We need an identifyable string inside the file for that. Regards, Andreas ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgadmin-hackers] New ftp layout
On Fri, 03 Dec 2004 13:04:30 +, Dave Page wrote: I've created a new ftp layout as discussed earlier. It can be reviewed at http://developer.pgadmin.org/ftp2/ Nice. About the FC1-RPM: 1. I suggest that you duplicate it in a directory called fc2, since it runs on fc2, as well. That way, all existing Fedora Core releases should be covered. 2. I suggest that CURRENT_MAINTAINER files be added in the RPM-directories. The files should - apart from our names, etc. - contain a link to the relevant public key of the packager, i.e. http://troels.arvin.dk/pgp/ or http://www.gunduz.org/devrimgunduz.pgp.pub What about when we release updated binary packages which are not due to updated pgadmin3 releases? I suggest that the RPM directories only contain one RPM file each, i.e. the latest one, and that older RPM releases be moved somewhere, like in release/v1.2.0/fc1/old. Another thought should probably go to how to become yum/apt-friendly with regard to the RPMs. I don't currently have a suggestion, but may return with a suggestion later. -- Greetings from Troels Arvin, Copenhagen, Denmark ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgadmin-hackers] New ftp layout
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Troels Arvin Sent: 03 December 2004 14:10 To: [EMAIL PROTECTED] Subject: Re: [pgadmin-hackers] New ftp layout On Fri, 03 Dec 2004 13:04:30 +, Dave Page wrote: I've created a new ftp layout as discussed earlier. It can be reviewed at http://developer.pgadmin.org/ftp2/ Nice. About the FC1-RPM: 1. I suggest that you duplicate it in a directory called fc2, since it runs on fc2, as well. That way, all existing Fedora Core releases should be covered. I'd rather not do that, as following that logic we may end up with umpteen copies of the same file. There's also the disk/bandwidth overhead of around 80 mirror sites to consider, and the fact that it implies there is a difference between the packages. 2. I suggest that CURRENT_MAINTAINER files be added in the RPM-directories. The files should - apart from our names, etc. - contain a link to the relevant public key of the packager, i.e. http://troels.arvin.dk/pgp/ or http://www.gunduz.org/devrimgunduz.pgp.pub Yup, I just haven't got around to that yet (I only added them to the existing layout a couple of days ago). What about when we release updated binary packages which are not due to updated pgadmin3 releases? I suggest that the RPM directories only contain one RPM file each, i.e. the latest one, and that older RPM releases be moved somewhere, like in release/v1.2.0/fc1/old. No, because that can cause significant rsync traffic as the mirrors delete the moved files, and then download them again. Moving files shouldn't be taken lightly on large mirror networks :-). I dread to think what effect this change is going to have on svr4.postgresql.org as it is!! Another thought should probably go to how to become yum/apt-friendly with regard to the RPMs. I don't currently have a suggestion, but may return with a suggestion later. OK, look forward to it. The closest we have so far is the debian stuff of course - Raphael might be able to provide some pointers on that. Regards, Dave. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgadmin-hackers] RFC: Update wizard
Dave Page wrote: More preciesly, the issue is to detect whether a file has been updated. I suggested CVS as it should be simple to initial look for a file newer than the releases CVS tag, and following that, newer than the one previously downloaded. But we don't want to create a kind-of cvs client in pgadmin, no? How to identify the currently installed versions, if not with a version string compiled in? Mind you, maybe I'm underestimating the number of users we may get. Perhaps this should work from the ftp mirror network? I've been asking about this a while ago. We don't know until we try, I'm afraid... Regards, Andreas ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [pgadmin-hackers] RFC: Update wizard
-Original Message- From: Andreas Pflug [mailto:[EMAIL PROTECTED] Sent: 03 December 2004 14:46 To: Dave Page Cc: pgadmin-hackers Subject: Re: [pgadmin-hackers] RFC: Update wizard Dave Page wrote: More preciesly, the issue is to detect whether a file has been updated. I suggested CVS as it should be simple to initial look for a file newer than the releases CVS tag, and following that, newer than the one previously downloaded. But we don't want to create a kind-of cvs client in pgadmin, no? How to identify the currently installed versions, if not with a version string compiled in? For a new install, get the file if it is newer than the build date. Once a file is downloaded, it's modification date is logged in the registry and used for future checks. I wasn't proposing a CVS client in pgAdmin BTW - viewcvs with appropriate templates should be easily parse-able, and it can certainly serve files of any version, from any branch. Mind you, maybe I'm underestimating the number of users we may get. Perhaps this should work from the ftp mirror network? I've been asking about this a while ago. We don't know until we try, I'm afraid... No, but it might be better to assume the worst... Doing it this way, it shouldn't be too difficult to automate an extraction from CVS onto the master server, and generate an index file of what's there. The more I think about it, the more that seems the best option... Regards, Dave. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [pgadmin-hackers] New ftp layout
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Troels Arvin Sent: 03 December 2004 14:10 To: [EMAIL PROTECTED] Subject: Re: [pgadmin-hackers] New ftp layout 2. I suggest that CURRENT_MAINTAINER files be added in the RPM-directories. The files should - apart from our names, etc. - contain a link to the relevant public key of the packager, i.e. http://troels.arvin.dk/pgp/ or http://www.gunduz.org/devrimgunduz.pgp.pub Yup, I just haven't got around to that yet (I only added them to the existing layout a couple of days ago). Can you explain something to me? Why don't you /simply/ upload your key to a keyserver? To me, gpg signing is efficient if (at least): - your key is available from a third party - your key is signed by someone you trust - you have all the required files to inform people the key has been compromised. IMHO, uploading your key to a public keyserver makes it mandatory for you to generate revocation certificates... Something you may not do if your key is not much distributed. - your private key is protected (I mean not on a host on the net) I bet we won't be able to sign each other but why not (Hey Dave, still ok for next summer holidays ? ;p) The only pub key I distribute in the deb repo is the key used to sign debian unofficial repository release files. This key is not on keyserver because it does not meet the above requirements. Having the key on a keyserver helps getting the pub keys rapidly as people first think the key is available on a keyserver(?). Thanks for teaching me, Raphaël ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [pgadmin-hackers] RFC: Update wizard
-Original Message- From: Andreas Pflug [mailto:[EMAIL PROTECTED] Sent: 03 December 2004 16:08 To: Dave Page Cc: pgadmin-hackers Subject: Re: [pgadmin-hackers] RFC: Update wizard I was afraid you mentioned __TDATE__. This is evaluated at compile time, i.e. precautions must be taken that the file must be compiled even if unchanged. I do a 'make clean;make all' or 'Rebuild All' as a matter of course anyway - I would hope the other packagers do as well. Second, the date is formatted, i.e. we must unformat it locale/lib/compiler/??? dependent before examining. Hmm, shouldn't be - __DATE__ is supposed to always be Mmm dd iirc. __TDATE__ is wx's Unicode version so should be the same. Dunno if the Mmm ever appears in different languages though. /D ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [pgadmin-hackers] RFC: Update wizard
Dave Page wrote: Second, the date is formatted, i.e. we must unformat it locale/lib/compiler/??? dependent before examining. Hmm, shouldn't be - __DATE__ is supposed to always be Mmm dd iirc. __TDATE__ is wx's Unicode version so should be the same. Dunno if the Mmm ever appears in different languages though. That's the part I'm afraid about. Win32 doc says only using asctime() format. asctime doc doesn't say anything about language dependency. Regards, Andreas ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgadmin-hackers] [pgadmin-support] corrections v1.2 rc2: rpm 4 madrake 10.1
Dave,
snip...
Spec file line changed:
%configure --with-wx-config=%{withwxconfig} --with-wx=/usr
That's no problem - we have a couple of variations of the spec files for
different Oss already so another one can be added.
That said, it would be good to get one all-knowing all-purpose spec
file. Does anyone know if that's do-able? Perhaps it could be
autogenerated as part of the build process?
I not an experienced at generating rpms but I do know it is possible to test
for the various OSs. You can see more on this at www.rpm.org in the docs
section.
configure diff:
--
5201a5202,5205
*wx_gtk2_*)
LIBS=$LIBS -lwx_gtk2_stc-${WX_VERSION}
LIBS=$LIBS $WX_NEW_LDFLAGS
;;
5206c5210
---
No problem there either. Can I get some additional opinions thouogh
before I apply these changes?
Ofcourse. Just wanted to contribute this so others may also use pgadmin.
Thanks for the feedback,
Hugo Ferreira.
On Thursday 02 Dec 2004 09:35, Dave Page wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Hugo Ferreira
Sent: 01 December 2004 10:10
To: [EMAIL PROTECTED]
Subject: [pgadmin-support] corrections v1.2 rc2: rpm 4 madrake 10.1
Hi,
Hello,
I have had to change the src.rpm spec file and the configure
file to be able to generate a rpm for Mandrake 10.1. Changes:
1. Mandrake 10.1 makes available the wxGTK2.5-2.5.3 and
related packages. Only the dynamic versions of the library
are created, so the specs must not use the static configuration flag.
OK.
2. Mandrake 10.1 makes available the wxGTK2.5-2.5.3 and
related packages but these install to the /usr directory
and not the /usr/local so the spec file must also have the
configuration flag altered.
OK.
3. The library names of the wxGTK package are:
- wx_gtk2_xrc-2.5
- wx_gtk2_html-2.5
- wx_gtk2_adv-2.5
- wx_gtk2_core-2.5 -lwx_base_xml-2.5
- wx_base_net-2.5 -lwx_base-2.5
Because of this the configure script must add a new entry in
the case switch to search for and use substring gtk2_ and
not gtk2-.
OK.
I have altered the rc2 src.rpm package and used that to
generate a new src.rpm that can build binary packages for MDK
10.1. I can make this available if anyone wants, just tell me
were to upload it. Please note that this package has a set of
minimum changes and does not comply to Mandrake standards
(doesn't check for package dependencies for example).
Can someone else comment on whether that is likely to cause problems?
I'm not well versed in the ways of the RPM!
Spec file line changed:
%configure --with-wx-config=%{withwxconfig} --with-wx=/usr
That's no problem - we have a couple of variations of the spec files for
different Oss already so another one can be added.
That said, it would be good to get one all-knowing all-purpose spec
file. Does anyone know if that's do-able? Perhaps it could be
autogenerated as part of the build process?
configure diff:
--
5201a5202,5205
*wx_gtk2_*)
LIBS=$LIBS -lwx_gtk2_stc-${WX_VERSION}
LIBS=$LIBS $WX_NEW_LDFLAGS
;;
5206c5210
---
No problem there either. Can I get some additional opinions thouogh
before I apply these changes?
Regards, Dave.
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
