Re: Tree-Maintenance: current/devel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Enrico Weigelt wrote: * Slava Zanko slavaza...@gmail.com schrieb: Hi, Enrico, please don't hurry. Wait please a few days (may be, after New Year). All existing patches need to be collected in one place. This place will git (browse: http://www.midnight-commander.org/browser). It contains the How can I checkout/clone it ? ssh-keygen -f mc-devel mkdir -p ~/.ssh/keys chmod 0700 ~/.ssh/keys mv -f mc-devel ~/.ssh/keys/mc-devel.key mv -f mc-devel.pub ~/.ssh/keys/mc-devel.pub chmod 0600 ~/.ssh/keys/mc-devel.key [ ! -f ~/.ssh/config ] touch ~/.ssh/config cat ~/.ssh/config EOF host www.midnight-commander.org IdentityFile ~/.ssh/keys/mc-devel.key host midnight-commander.org IdentityFile ~/.ssh/keys/mc-devel.key EOF mail ~/.ssh/keys/mc-devel.pub to Patrick Winnertz Then: git clone ssh://www.midnight-commander.org:/git/mc.git Or may be anonymous r/o access: git clone git://midnight-commander.org/git/mc.git Then simply to work: # to view all local branches git branch # to view all branches ( included from parent(s) git ) git branch -a # make remote branch as local git branch --track stable origin/stable # switch to branch 'stable' git checkout stable # get changes from parent git git pull # push changes to parent git git push P.S. I'm not a professional in git... Thanks to Patrick Winnertz - he my teacher in git :) WBR, Slavaz. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFJWysVb3oGR6aVLpoRApyUAJ4jbRjeP4bGyxJbYW/BnIYWYPruBwCffA4q 3htj5y6ANIYSHG4ofeDyIoI= =e7G0 -END PGP SIGNATURE- ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: bundled intl stuff necessary
Enrico Weigelt schrieb: Hi folks, is it necessary to have the intl lib bundled into mc or could it be taken directly from the system ? (I admit, I don't know much about how it really works ;-o) I don't think it is necessary. There are many other projects who have dropped the internal intl/ directory. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Further Midnight Commander development
* Slava Zanko slavaza...@gmail.com schrieb: Hi, Is it a good idea to make git-branch Stable based on 4.6.1 and git-branch Current based of the current cvs-code (4.6.2-pre1)? I'd really suggest forking the stable tree on 4.6.1 release and let it be the rc for 4.6.2, then step by step merge in all the patches/branches floating around the net. And, of course, will apply all accepted the patches to the branch of Current. Then a lot of people will be able to test patches (even those who do not know how to apply the patches). We'd rather should call that tree testing, IMHO ;-o cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: bundled intl stuff necessary
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Roland Illig wrote:
Enrico Weigelt schrieb:
Hi folks,
is it necessary to have the intl lib bundled into mc or could it
be taken directly from the system ?
(I admit, I don't know much about how it really works ;-o)
I don't think it is necessary. There are many other projects who have
dropped the internal intl/ directory.
If we started to talk about the source tree...
What now:
config
doc
edit
lib
m4
maint
po
slang
src
syntax
vfs
I think, this not good.
lib - in my mind must be sources of library(es) of project.
What we see in directory lib?
doc - Documentation of project, included:
- - man pages
- - Users manual
- - Developers manual (doxygen?)
- - Maintainers manual (how make packages on all known OSes, for example)
Now in directory 'doc' only manpages... and README-files at all
subdirectoryes.
My purpose (in far-near future):
doc
man (current ${src_root}/doc)
contributor (contributor manuals)
developer (developers manual)
user (all README-files, readme about hotkeys, all other
user-related)
contrib
contrib/extfs (current ${src_root}/vfs/extfs)
contrib/hints
contrib/lib (current ${src_root}/lib, except mc.hint.* and
README.xterm)
contrib/maint (current ${src_root}/maint)
contrib/syntax (current ${src_root}/syntax)
lib
lib/edit (current ${src_root}/edit)
lib/mcglib (may be, needed as mcslang for embedded systems... Little
internal library... but it's only thinks)
lib/slang
lib/vfs
lib/vfs/samba
m4
po
src
WBR, Slavaz.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFJWzU2b3oGR6aVLpoRAhsuAJ914GDP2/6kAPx53GQgzQ86QBFLOQCfXupQ
2WJiflZRaGvsv7CY80Rt/TM=
=a/Gh
-END PGP SIGNATURE-
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Tree-Maintenance: current/devel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Enrico Weigelt wrote: Or may be anonymous r/o access: git clone git://midnight-commander.org/git/mc.git Initialized empty Git repository in /home/crosstool/XXX/mc/.git/ remote: fatal: Out of memory, realloc failed remote: aborting due to possible repository corruption on the remote side. fatal: early EOF fatal: index-pack failed The machine still/again seems to run out of memory :(( Hm... try again. :( To Patrick Winnertz: Is time now for migrate to much powerfull server? WBR, Slavaz. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFJWzkUb3oGR6aVLpoRAjUKAJ9mKgw4Y5czAyrDfGMDVvOCdMV4CQCcCvi3 U0HMKFLjc4ICOtk1EA2EYeM= =rm2B -END PGP SIGNATURE- ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Happy New Year
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, folks. Happy New Year, have enough money and happiness to you and your family. And many thanks for the wish to further develop of Midhight Commander. Big... no, huge thanks, guys. WBR, Slavaz. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFJW0JDb3oGR6aVLpoRAtiKAJ9L/e1XQzi5h/4msGCdQe1fhFgHHgCdF99r PYpq+2bINpC3UwamRFjsxwg= =0tze -END PGP SIGNATURE- ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Tree-Maintenance: current/devel
On Wed, 31 Dec 2008 10:19:33 +0200 Slava Zanko wrote: Or may be anonymous r/o access: git clone git://midnight-commander.org/git/mc.git Is it possible to make an anonymous r/o http access to git for those people who lives behind the corporative proxy? git clone http://midnight-commander.org/git/mc.git Regards, Andrew. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Tree-Maintenance: current/devel
* Slava Zanko slavaza...@gmail.com schrieb: Hm... try again. :( Okay, got it now. I'm already in process of preparing patches from rhclub to git tree. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: HAVE_MMAP still necessary ?
On Sat 2008-12-27 21:43:53, Enrico Weigelt wrote: * Enrico Weigelt weig...@metux.de schrieb: Hi folks, I really wonder whether the mmap() stuff is still needed at all. It doesnt seem to be really used anywhere. Ups, didn't look hard enough (just scanned the vfs subdir) ;-O Okay, there're mainly two mmap()-using places: a) cmd.c: compare_files() - it uses the mmap() call directly (w/o going over mcvfs), and it seems to work on local files only. wouldn't it make sense to let it run via mcvfs ? b) view.c: it tries to mmap() in the file, obviously to let the kernel do all the loading. BUT: do we *really* want mmap() here, or just some get me that file into memory()-call (same in cmd.c) ? I believe the idea is to be able to view parts of huge file without loading them to RAM first. (for really big files, they may not even fit in RAM.) -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: RFC: Suggestion for workflow on patches
Hey - Every patch which should be applied to the git should be attached to a bugreport in our ticketsystem. There should be for each patch a own ticket so that we have a good overview. hmm, has the drawback, that it's bit unconvenient (as long as we don't have an automatic cmdline tool for that ;-P) moves the talks away from the list. No not really.. You only post indrect to the list via the ticket system... all things will hit then the mailinglist and can be discussed there if the need is there :) Of course, an ideal situation would be an gateway between maillist and trac, so new tickets are sent to the list and replies are automatically bounced to the ticket's comments. There will be such a gateway. All things which are added to tickets in trac get already bounced to the list. Vice versa is not working atm, I work on this currently. Afterwards you only needs to cc tic...@midnight-commander.org (or something else) and the answer will show up in the corresponding ticket. - Every patch that is in the ticket system must be approved by two devs in order to get applied again the working branch (master). Ok, seems reasonable. BTW: does trac have some voting mechanism ? No, sadly not.. at least I found nothing up to now. Bug I'll search further. :) Until there is a solution for this we need to do this by writing something into the ticket ( a defined text for ACK /NACK). Maybe something like this: - XYZ-asdf.patch revision 2 : ACK or: - ABC-fdsa.patch revision 1 : NACK There exists a VotePlugin but as I understand it you can only vote for tickets and not for patches with different revisions... and this doesn't help us in my eyes :S Great ! Maybe you could also install the xmlrpc plugin, so I can code my own upload tool. I'll have a look on the plugin.. but there seems to be some issues with newest trac (0.11) which is running on www.m-c.org. What do you think? Is this workflow for patches okay? If yes I would write this down somewhere in the wiki in order to make it official. ACK. BTW: may I request write access to the wiki ? Should be there now (together with your ssh access). Do you want to write this down in the wiki and link it on the first page? :) Greetings Winnie -- . '' ` . Patrick Winnertz win...@debian.org : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~winnie - http://www.der-winnie.de `- Debian - when you have better things to do than fixing systems signature.asc Description: This is a digitally signed message part. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
