Re: Reporting Bugs via mail works now (with drawbacks)
Hi, It's possible to add tickets, add comments to existing tickets and the emails will get carbon-copied back to the mc-devel list. opening a ticket seems to work now, but I didn't get any mail back yet. 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: [Midnight Commander] #111: test again
#111: test again
---+
Reporter: Patrick Winnertz win...@debian.org | Owner:
Type: defect| Status: closed
Priority: major | Milestone:
Component: adm | Version: 4.6.1
Resolution: invalid |Keywords:
Blocking:| Blockedby:
---+
Changes (by winnie):
* status: new = closed
* resolution: = invalid
* component: = adm
Old description:
{{{
#!html
a
href=mailto:winnie%40debian.org?Subject=Re%3A%20%23111%3A%20test%20againCc=;Reply
to: Patrick Winnertz
/a
}}}
New description:
{{{
#!html
a
href=mailto:winnie%40debian.org?Subject=Re%3A%20%23111%3A%20test%20againCc=;Reply
to: Patrick Winnertz
/a
}}}
--
--
Ticket URL: http://www.der-winnie.de/trac/ticket/111#comment:2
Midnight Commander www.midnight-commander.org
Midnight Development Center
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #16: savannah: c is _not_ c++
#16: savannah: c is _not_ c++ -+-- Reporter: slavazanko | Owner: winnie Type: defect | Status: accepted Priority: trivial | Milestone: 4.6.2 Component: mcedit | Version: 4.6.1 Resolution: |Keywords: Blocking: | Blockedby: -+-- Changes (by winnie): * owner: = winnie * status: new = accepted * version: = 4.6.1 * milestone: = 4.6.2 Comment: My suggestion would be instead of closing it as invalid, use the attached patch in order to differenciate between c and cpp files. .h files are parsed as c++ files per default. Any comments on this patch? -- Ticket URL: http://www.midnight-commander.org/ticket/16#comment:2 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #16: savannah: c is _not_ c++
#16: savannah: c is _not_ c++ -+-- Reporter: slavazanko | Owner: winnie Type: defect | Status: accepted Priority: trivial | Milestone: 4.6.2 Component: mcedit | Version: 4.6.1 Resolution: |Keywords: Blocking: | Blockedby: -+-- Comment(by winnie): Replying to [comment:3 slavazanko]: Strange line 76 in patch... This is about highlighting e.g comments which are not catched by the keywords above.. therefore I think this should be okay -- Ticket URL: http://www.midnight-commander.org/ticket/16#comment:4 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #65: savannah: Pascal syntax highlighting update
#65: savannah: Pascal syntax highlighting update --+- Reporter: slavazanko | Owner: winnie Type: enhancement | Status: accepted Priority: minor| Milestone: Component: mc-core | Version: Resolution: |Keywords: Blocking: | Blockedby: --+- Changes (by winnie): * owner: = winnie * priority: major = minor * status: new = accepted Comment: Okay, I checked it: write, read, overload and finalization are valid pascal keywords. I'm creating a patch right now. -- Ticket URL: http://www.midnight-commander.org/ticket/65#comment:2 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #65: savannah: Pascal syntax highlighting update
#65: savannah: Pascal syntax highlighting update --+- Reporter: slavazanko | Owner: winnie Type: enhancement | Status: accepted Priority: minor| Milestone: 4.6.2 Component: mc-core | Version: Resolution: |Keywords: Blocking: | Blockedby: --+- Changes (by winnie): * milestone: = 4.6.2 Comment: rev2 seems to be okay for me, therefore: +1 for rev2 Setting Milestone to 4.6.2 as this is very trivial and should be fixed within the next release. -- Ticket URL: http://www.midnight-commander.org/ticket/65#comment:3 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #99: enable git checkout via http
#99: enable git checkout via http -+-- Reporter: winnie | Owner: winnie Type: task| Status: testing Priority: minor | Milestone: Component: adm | Version: Resolution: fixed |Keywords: Blocking: | Blockedby: -+-- Changes (by winnie): * status: accepted = testing * resolution: = fixed Comment: This should be fixed now. Leave it as testing for some days. -- Ticket URL: http://www.midnight-commander.org/ticket/99#comment:3 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #88: savannah: Integration of SMB-Share-Browsing
#88: savannah: Integration of SMB-Share-Browsing -+-- Reporter: slavazanko | Owner: Type: defect | Status: new Priority: major | Milestone: Component: vfs | Version: Resolution: |Keywords: Blocking: | Blockedby: 1 -+-- Changes (by winnie): * blockedby: = 1 -- Ticket URL: http://www.midnight-commander.org/ticket/88#comment:2 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[Midnight Commander] #113: savannah: make tabs and trailing spaces visible
#113: savannah: make tabs and trailing spaces visible
+---
Reporter: slavazanko | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: mc-core | Version: 4.6.1
Keywords: |Blocking:
Blockedby: |
+---
Original: http://savannah.gnu.org/bugs/?13146
||Submitted by:||Oswald Buddenhagen ossi||Submitted on:||Sat 21 May 2005
07:25:17 PM UTC||
||Category:||Editor||Severity:||3 - Normal||
||Status:||In Progress||Privacy:||Public||
||Assigned to:||None||Open/Closed:||Open||
||Release:||current (CVS or snapshot)||Operating System:||All||
Discussion:
{{{
Sun 06 Jul 2008 04:12:04 PM UTC, comment #24:
I noticed I cannot just use the Unicode characters (like p-ch = 0xB7), as
that does not take into account terminals that are not in UTF-8. But the
fix is simple enough (p-ch = SLsmg_Is_Unicode ? 0xB7 : .).
BTW, I also implemented the MS Word-style tabs, i.e. printing a right-
arrow in the middle of a tab. I sort of prefer it over the tabs.
It is a patch that currently replaces the existing tab mechanism, but IMHO
this should all be made configurable once the maintainers decide to wake
up and give me some sort of ok...
(file #16007)
Jan Engelhardt hirogen2
Sun 06 Jul 2008 01:24:09 PM UTC, comment #23:
Patch #4 -- cedit-symbol-prefs.diff
This patch changes the space fill character to some Unicode dot (·) [this
one is also available on the text console], and makes the -- tab
filler into the Unicode ◀──▶ too.
(file #16006)
Jan Engelhardt hirogen2
Sun 06 Jul 2008 01:21:22 PM UTC, comment #22:
Patch #3 -- cedit-fix-whitespace.diff
We definitely need to set MOD_WHITESPACE or the space between tab stops is
drawn with some random color.
(file #16005)
Jan Engelhardt hirogen2
Sun 06 Jul 2008 01:19:54 PM UTC, comment #21:
Patch #2 -- cedit-eol-mark.diff
This patch implements comment #8's suggestion to use ¶ as an EOL marker.
It can be toggled using the OptionsHighlight options dialog, or, of
course, by editing ~/.mc/config directly.
(file #16004)
Jan Engelhardt hirogen2
Sun 06 Jul 2008 01:17:43 PM UTC, comment #20:
Ok since nobody replied here are some patches of my own.
They require that mc(edit) has COMPLETE support for UTF-8!, which is not
the case in the mc source distribution. The openSUSE .src.rpm has the
required utf8 bits. Will try to make them submit theirs.
Patch #1 -- cedit-configurable-highlight.diff
This is for comment #19; it allows to switch highlighting. Firstly, it
adds a dialog (Options Highlight options) where you can precisely select
what to highlight
[ ] Global syntax highlighting
[ ] Tab highlighting (those -- markers, which, btw, can get very
ugly if you have lots of code)
[ ] Whitespace highlighting (dots at the end-of-line, and, if tab
highlighting is disabled, anywhere on the line)
One can already toggle Syntax highlighting with Ctrl-S in mc 4.6.2, for
the latter two, I added Ctrl-V as a hotkey which cycles through the
possibilities. My personal preference is to have Tab highlight OFF and
Whitespace highlight ON.
(file #16003)
Jan Engelhardt hirogen2
Fri 29 Feb 2008 07:16:33 PM UTC, comment #19:
Oh, god... I just updated my Debian box, and I now run MC 4.6.2-pre1 (as
outputted by mcedit --version). It appears that this patch is included in
this version of mcedit. I really dislike it. Besides suffering from the
'cursor disappearing' thingy, I just think its ugly. But that's my humble
opinion :)
How can I disable it? The patches attached to this report don't seem to
make a new configurable parameter available in the configuration dialogs.
Jurrie Overgoor leadpumper
Tue 04 Sep 2007 05:29:40 AM UTC, comment #18:
Pavel, I applied your patch to vte-0.16.8. It works.
Andrew Borodin a_borodin
Mon 03 Sep 2007 01:15:42 PM UTC, comment #17:
Ok. I tracked the bug to vte_terminal_determine_colors() in the vte
package. To request brighter colors one forces the terminal into bold
mode. It seems that in this mode vte allows only the foreground color to
be bright. In vte's terms a bright color is the same color as the normal
one but with a special flag set. So what happens is that when the time
comes for the cursor to blink vte switches the current forground color
with the current background color and vice versa... As I said above
both colors are indentified in the same way but one has a special flag,
however vte uses this flag to brighten the foreground color so at the end
we end up as if nothing happened. It's hard to say whether this is the
desired behaviour .. I'll attach a simple patch which changes vte to do
what seems more logically correct... and I'll open a report in gnome's
[Midnight Commander] #114: savannah: hide dotfiles in home directory
#114: savannah: hide dotfiles in home directory
+---
Reporter: slavazanko | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: mc-core | Version: 4.6.1
Keywords: |Blocking:
Blockedby: |
+---
Original: http://savannah.gnu.org/bugs/?13395
||Submitted by:||Paul Wise pabs||Submitted on:||Tue 14 Jun 2005 09:08:04
AM UTC||
||Category:||Screen output||Severity:||1 - Wish||
||Status:||Confirmed||Privacy:||Public||
||Assigned to:||Roland Illig rillig||Open/Closed:||Open||
||Release:||All versions||Operating System:||All||
Discussion:
{{{
Wed 15 Jun 2005 07:54:19 AM UTC, comment #4:
I would prefer that my idea was not the default - it could be confusing to
some users. The default would remain as it is.
It is a really bad idea and even raises security issues if a
normal user can control the behavior how root sees his/her
files. Whether or not hidden files are displayed to root should
only depend on root's settings and not on any user's settings.
Indeed, and I meant it would be a per-user setting.
I agree that this could set an annoying precedent for the mc developers,
feel free to ignore it.
Paul Wise pabs
Wed 15 Jun 2005 07:16:41 AM UTC, comment #3:
It is a really bad idea and even raises security issues if a normal user
can control the behavior how root sees his/her files.
Whether or not hidden files are displayed to root should only
depend on root's settings and not on any user's settings.
Anyway I guess the same holds for normal users, too. I do want to see
joe's dotfiles if I have permission to, no matter if joe has a directory
entry called (hidden files).
To comment #2: the original reporter (pabs) wanted to make the show
dotfiles the default and have an exception for one directory. Your
proposal is the opposite: make don't show dotfiles the default and allow
to take exceptions. I don't think pabs wants to create such a special file
in every directory except his home. However, someone else might want it
the way you want it. So then we should have the possibility to override
mc's default in both ways: force show, and force not show.
Now this leads to so many possible filenames with special meanings to mc.
If this feature is required at all, I suggest using only one filename or
directory which begins with a dot (such as .mc_specials) and put all the
configuration stuff in this file or under this directory. This would be
quite similar then to the CVS or .svn directories of the version
controlling systems.
Anyway, I basically don't like this whole idea of custom directory
entries, IMHO mc should not pollute the filename namespace and should not
create files that disturb me outside mc (e.g. in ls, nautilus etc...).
I'm perfectly okay with a global configuration options show dotfiles
except in my home if more people would like to see it. If some more
general method is needed, take a look at
http://freshmeat.net/projects/hidefile/ which is an example on how to hide
files outside of mc's scope so that ls, nautilus etc. are also influenced.
My biggest trouble is that once we have this force hidden files and
force no hidden files per-directory options, I'm afraid no-one can stop
people requesting dozens of similar stupid per-directory configuration
options, such as to have different Listing mode, different editor/viewer
etc. to each directory.
Egmont Koblinger egmont
Tue 14 Jun 2005 12:56:40 PM UTC, comment #2:
I would like a custom directory entry, that says:
(hidden files)
or
(hidden directories)
When you press enter over it, it will display all hidden files or
directories. These entries will only be displayed IF there is hidden files
or directories.
Anonymous
Tue 14 Jun 2005 10:27:16 AM UTC, comment #1:
That's a nice idea.
Roland
Roland Illig rillig
Project MemberIn charge of this item.
Tue 14 Jun 2005 09:08:04 AM UTC, original submission:
I'd like to be able to show dotfiles by default, but not when in my
homedir (because there are so many there). A similar option for the root
user - hide dotfiles when in any home dir - might also be useful.
PS: sorry if this is the wrong place to post RFEs
}}}
--
Ticket URL: http://www.der-winnie.de/trac/ticket/114
Midnight Commander www.midnight-commander.org
Midnight Development Center
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
[Midnight Commander] #115: savannah: Select codepage with Ctrl+T don't work
#115: savannah: Select codepage with Ctrl+T don't work
+---
Reporter: slavazanko | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: locale | Version: 4.6.1
Keywords: |Blocking:
Blockedby: |
+---
Original: http://savannah.gnu.org/bugs/?14913
||Submitted by:||SGh sgh||Submitted on:||Fri 04 Nov 2005 08:44:12 AM
UTC||
||Category:||Viewer||Severity:||3 - Normal||
||Status:||None||Privacy:||Public||
||Assigned to:||None||Open/Closed:||Open||
||Release:||4.6.0-pre3||Operating System:||GNU/Linux||
Discussion:
{{{
Sat 05 Nov 2005 08:08:38 AM UTC, comment #1:
Please, refer to the Red Hat bugzilla
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163594
I hope you should find recipe for your problem.
Andy Shevchenko andy_shev
Fri 04 Nov 2005 08:44:12 AM UTC, original submission:
Hi all!
I want to report a bug in mc
GNU Midnight Commander 4.6.1-pre3
Virtual File System: tarfs, extfs, cpiofs, ftpfs, fish, smbfs
With builtin Editor
Using included S-Lang library with terminfo database
With subshell support as default
With support for background operations
With mouse support on xterm and Linux console
With support for X11 events
With internationalization support
With multiple codepages support
I have just installed Debian Linux 3.1r0a and mc distributed with it.
Here is the bug description:
I use ukrainian locale with koi8-u codepage. When I view text files in mc-
viewer I can't select codepage,
selection window appear, I select needed codepage, but nothings happened,
mc does not recoding viewed text.
But in internal editor this feature work fine.
P.S. Sorry for my bad english :)
}}}
--
Ticket URL: http://www.der-winnie.de/trac/ticket/115
Midnight Commander www.midnight-commander.org
Midnight Development Center
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
[Midnight Commander] #116: savannah: infinite loop reading large directories via fish
#116: savannah: infinite loop reading large directories via fish
+---
Reporter: slavazanko | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: vfs | Version: 4.6.1
Keywords: |Blocking:
Blockedby: |
+---
Original: http://savannah.gnu.org/bugs/?15801
||Submitted by:||Mario Lorenz mlo||Submitted on:||Sun 19 Feb 2006
12:15:18 PM UTC||
||Category:||VFS||Severity:||3 - Normal||
||Status:||In Progress||Privacy:||Public||
||Assigned to:||Pavel Tsekov ptsekov||Open/Closed:||Open||
||Release:||4.6.1||Operating System:||GNU/Linux||
Discussion:
{{{
Thu 23 Feb 2006 03:38:12 PM UTC, comment #1:
This problem has been bugging me for a while. I've just commited a patch
which exposes a new user configurable option:
fish_directory_timeout
It contains the lifetime of a directory cache entry measured in seconds.
I've adjusted the default value to 900 seconds (same as in ftpfs).
This option is not configurable through the user interface, yet - one can
change it only by directly editing MC's ini file. I plan to fix this soon.
To test the new code you need to fetch MC from the cvs repository or grab
a snapshot.
Pavel Tsekov ptsekov
Project AdministratorIn charge of this item.
Sun 19 Feb 2006 12:15:18 PM UTC, original submission:
Reading large remote directories via fish (shell link)
over slow network links causes an infinite or at least very long
loop when mc tries to read the directory multiple times.
This is due to the fish directory timeout being hardcoded to 10
seconds, whereas reading a 15000 entry directory via a 64kbit/s link will
take two minutes (way longer if not using compression). This means the
directory objects will be marked obsolete
before the directory is even loaded, causing an immediate reload once
finished, with this pattern sometimes repeating even more often.
That timeout should be tied to the (user settable) ftp directory timeout,
or be given its own user settable value; at the very least it should be
set to a sane value (that is, 10 seconds)
}}}
--
Ticket URL: http://www.midnight-commander.org/ticket/116
Midnight Commander www.midnight-commander.org
Midnight Development Center
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
[Midnight Commander] #117: savannah: consecutive resize events not handled correctly
#117: savannah: consecutive resize events not handled correctly
+---
Reporter: slavazanko | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: mc-core | Version: 4.6.1
Keywords: |Blocking:
Blockedby: |
+---
Original: http://savannah.gnu.org/bugs/?17822
||Submitted by:||Egmont Koblinger egmont||Submitted on:||Fri 22 Sep 2006
01:04:44 PM UTC||
||Category:||Screen output||Severity:||3 - Normal||
||Status:||None||Privacy:||Public||
||Assigned to:||None||Open/Closed:||Open||
||Release:||4.6.1||Operating System:||GNU/Linux||
Discussion:
{{{
Tue 02 Oct 2007 09:18:19 AM UTC, comment #10:
Please, do not steal existing bug reports.
Pavel Tsekov ptsekov
Project Administrator
Mon 01 Oct 2007 09:03:01 PM UTC, comment #9:
when a resize is sent before mc is completely up, it doesn't get the
geometry right, either - and yes, this happens about every time an xterm
-e mc is restored by session management on my system. so the signal
handler should be set up before the initial geometry is queried.
Oswald Buddenhagen ossi
Mon 01 Oct 2007 03:21:44 PM UTC, comment #8:
If you run without mouse support (mc -d), mc doesn't detect resizes.
You need to press a key for mc to resize itself to new window after window
is maximized or resized (press up/down arrow, Ctrl-O, almost anything will
work).
Tested on 4.6.2-pre1.
Denis Vlasenko vda
Wed 08 Nov 2006 01:38:24 PM UTC, comment #7:
Committed. Quite an improvement in behaviour. Thank you.
Leonard den Ottolander leonardjo
Project Member
Mon 06 Nov 2006 10:24:35 PM UTC, comment #6:
As I understand your patch/hack, eliminating the timeouts on a window
resize event significantly reduces the chance mc is still waiting inside
the get_event() loop when a new resize event occurs.
Leonard den Ottolander leonardjo
Project Member
Mon 06 Nov 2006 12:01:58 PM UTC, comment #5:
Please commit it if it seems to be okay for you (I've been using mc 4.6.1
with this patch for a month, and found no side effects, while it makes mc
much better when resizing the terminal). But please don't yet close this
bugreport to remind us that a proper fix is still needed. This patch only
makes it much better, but still there's a small chance for the bug to
appear. Until we have a proper fix, it's good to apply a temporary hack to
heavily decrease the chance for the bug.
Egmont Koblinger egmont
Fri 03 Nov 2006 07:14:55 PM UTC, comment #4:
Shall I commit this patch or should I wait for the piped version?
Leonard den Ottolander leonardjo
Project Member
Tue 10 Oct 2006 04:22:16 PM UTC, comment #3:
Added a resize.patch. This does not suffer from the new bug, though I
don't understand what made a difference.
Still a rewrite to using pipes is needed to fill a minor race condition.
Egmont Koblinger egmont
Tue 10 Oct 2006 03:40:51 PM UTC, comment #2:
Oh, I just found the pselect() call which is supposed to solve this
problem. However, its manpage says the Linux kernel supports this only
since 2.6.16 which is a quite new piece. It says that glibc had an
emulation which is vulnerable to the race condition I just mentioned and
pselect was just introduced for.
The manpage also mentions and recommends the self-pipe trick which is more
portable.
Egmont Koblinger egmont
Tue 10 Oct 2006 03:27:46 PM UTC, comment #1:
Normally mc stays in a select() call in key.c:get_event() which is called
by dialog.c:frontend_run_dlg().
frontend_run_dlg() checks if the window size has changed and calls the
proper functions in this case. Then it does a lot of other things, then
calls get_event() which yet again does a lot of other things and finally
arrives at that select().
A subsequent window resize event (SIGWINCH) causes this select to return
with -1 EINTR which is later handled correctly.
The problem is caused by the lot of code lines executed after checking for
a window size change, but before entering the select call. If another
window size change event occurs while executing these commands, it will
not be handled until select() exits due to a keypress for example.
In key.c:get_event(), I placed the following line above the flag = select
(...) statement:
if (winch_flag) return EV_NONE;
and then my resizing problems were gone. So now I check again for a resize
event right before entering the select function.
Though this modification seems to solve my bug, another bug appeared.
Press F5 on .. so an error dialog box appears. Resize the window now. mc
enters an infinite loop consuming 100% CPU time and not reacting on any
keypress. I don't yet know how to fix this new bug. Swapping the new
statement and the
[Midnight Commander] #118: savannah: cannot specify port number in shell link
#118: savannah: cannot specify port number in shell link
+---
Reporter: slavazanko | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: vfs | Version: 4.6.1
Keywords: |Blocking:
Blockedby: |
+---
Original: http://savannah.gnu.org/bugs/?18042
||Submitted by:||Palo Simo palos||
Submitted on:||Tue 17 Oct 2006 12:51:17 PM UTC||
||Category:||VFS||Severity:||3 - Normal||
||Status:||Ready For Test||Privacy:||Public||
||Assigned to:||Andrew V. Samoilov sav||Open/Closed:||Open||
||Release:||current (CVS or snapshot)||Operating System:||All||
Discussion:
{{{
Mon 30 Oct 2006 08:11:45 PM UTC, comment #4:
Thank you for the patch, it is working okay, great!
I do not use any of the other options, so I don't know if they are
affected - I think you know whether or not ...
Palo Simo palos
Mon 30 Oct 2006 12:04:54 PM UTC, comment #3:
Do I understand correctly that a port number can be combined with C or
r? And does one have to specify a port number if one uses 'r'? Please
explain any syntax changes that you introduced.
No. Look at utilvfs.c:vfs_split_url().
No one syntax change. Only undocumented behaviour changed.
It is possible to use /#sh:u...@host:6789 right now.
And fish uses port1 as 'C' option and port2 as 'r'.
Possible solution is to use 0x11 and 0x12 instead of 1 and 2.
From what I remember from earlier investigations to separate out the
port from the other options we need to add an extra variable to some of
the functions. Am I mistaken?
You are right.
Maybe it's best first to decide on a new option syntax that allows all
combinations and then implement that new syntax?
I am not sure we can allow such redesign because of lack of manpower.
Andrew V. Samoilov sav
Project MemberIn charge of this item.
Sat 28 Oct 2006 12:43:20 PM UTC, comment #2:
Weakness: port number
and r and C option cannot be used together.
Port 1 will be interpretted as 'C' option, port 2 as 'r'.
Do I understand correctly that a port number can be combined with C or r?
And does one have to specify a port number if one uses 'r'? Please explain
any syntax changes that you introduced.
From what I remember from earlier investigations to separate out the port
from the other options we need to add an extra variable to some of the
functions. Am I mistaken?
Maybe it's best first to decide on a new option syntax that allows all
combinations and then implement that new syntax?
Leonard den Ottolander leonardjo
Project Member
Fri 27 Oct 2006 12:15:02 PM UTC, comment #1:
Hello, Palo.
Please test attached patch. This changes have to be documented in manuals
before commit to CVS.
vfs/ChangeLog:
* fish.c: Iterpret SUP.flags as port number if SUP.flags is not in 0,
FISH_FLAG_COMPRESSED and FISH_FLAG_RSH. Weakness: port number
and r and C option cannot be used together.
Port 1 will be interpretted as 'C' option, port 2 as 'r'.
(fish_open_archive_int): Change for above.
(fish_fill_names): Likewise.
Andrew V. Samoilov sav
Project MemberIn charge of this item.
Tue 17 Oct 2006 12:51:17 PM UTC, original submission:
this is a feature request:
include the ability to specify port number to connect to in the shell link
to machine feature
}}}
--
Ticket URL: http://www.midnight-commander.org/ticket/118
Midnight Commander www.midnight-commander.org
Midnight Development Center
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
[Midnight Commander] #119: savannah: Change default copy configuration wanted
#119: savannah: Change default copy configuration wanted
+---
Reporter: slavazanko | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: vfs | Version: 4.6.1
Keywords: |Blocking:
Blockedby: |
+---
Original: http://savannah.gnu.org/bugs/?18877
||Submitted by:||Jian He hejian||Submitted on:||Thu 25 Jan 2007 08:26:27
AM UTC||
||Category:||None||Severity:||3 - Normal||
||Status:||None||Privacy:||Public||
||Assigned to:||None||Open/Closed:||Open||
||Release:||4.6.1||Operating System:||GNU/Linux||
Discussion:
{{{
Thu 25 Jan 2007 08:26:27 AM UTC, original submission:
Is there any way of configure the copy operation to default as to NOT
preserve attributes?
Currently, there is no way to change the defaults. The file mask
dialog options are not persistent.
We really need a way to do that...
}}}
--
Ticket URL: http://www.midnight-commander.org/ticket/119
Midnight Commander www.midnight-commander.org
Midnight Development Center
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
[Midnight Commander] #120: savannah: compare files command would be nice to have in mc
#120: savannah: compare files command would be nice to have in mc
+---
Reporter: slavazanko | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: mcedit | Version: 4.6.1
Keywords: |Blocking:
Blockedby: |
+---
Original: http://savannah.gnu.org/bugs/?20739
||Submitted by:||Zbigniew Luszpinski mr_zbiggy||Submitted on:||Thu 09
Aug 2007 08:45:04 PM UTC||
||Category:||Core||Severity:||3 - Normal||
||Status:||None||Privacy:||Public||
||Assigned to:||None||Open/Closed:||Open||
||Release:||4.6.1||Operating System:||GNU/Linux||
Discussion:
{{{
Thu 23 Aug 2007 01:49:25 PM UTC, comment #1:
You may want to try/test the following patch:
[http://savannah.gnu.org/patch/?5893 patch #5893] - integrated side-by-
side textmode diff viewer
Pavel Tsekov ptsekov
Project Administrator
Thu 09 Aug 2007 08:45:04 PM UTC, original submission:
compare files command would be nice to have in mc. Mc could use
diff util as an engine by providing paths to files as diff
arguments and parsing diff output.
This would be very helpful if someone in the future would like to
add synchronize directories command to mc.
}}}
--
Ticket URL: http://www.midnight-commander.org/ticket/120
Midnight Commander www.midnight-commander.org
Midnight Development Center
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
[Midnight Commander] #121: savannah: Please support IPv6
#121: savannah: Please support IPv6
+---
Reporter: slavazanko | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: mc-core | Version: 4.6.1
Keywords: |Blocking:
Blockedby: |
+---
Original: http://savannah.gnu.org/bugs/?21528
||Submitted by:||Laurent Bigonville bigon||Submitted on:||Tue 06 Nov
2007 10:14:02 PM UTC||
||Category:||VFS||Severity:||3 - Normal||
||Status:||None||Privacy:||Public||
||Assigned to:||None||Open/Closed:||Open||
||Release:||All versions||Operating System:||All||
Discussion:
{{{
Wed 07 Nov 2007 09:31:09 AM UTC, comment #1:
Fedora's MC has a patch which adds IPv6 support to ftpfs. I might
include it in 4.6.2 but I can't promise anything - the patch is
rather large and it'll take some time to review.
Pavel Tsekov ptsekov
Project Administrator
Tue 06 Nov 2007 10:14:02 PM UTC, original submission:
VFS modules should support IPv6
}}}
--
Ticket URL: http://www.midnight-commander.org/ticket/121
Midnight Commander www.midnight-commander.org
Midnight Development Center
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
[Midnight Commander] #122: savannah: UI moves out of range
#122: savannah: UI moves out of range
+---
Reporter: slavazanko | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: mc-core | Version: 4.6.1
Keywords: |Blocking:
Blockedby: |
+---
Original: http://savannah.gnu.org/bugs/?22980
||Submitted by:||M Wedin wed||Submitted on:||Sat 19 Apr 2008 08:52:48 AM
UTC||
||Category:||Viewer||Severity:||3 - Normal||
||Status:||None||Privacy:||Public||
||Assigned to:||None||Open/Closed:||Open||
||Release:||4.6.1||Operating System:||GNU/Linux||
Discussion:
{{{
Sat 19 Apr 2008 08:52:48 AM UTC, original submission:
I eyed through the list of bugs but found nothing similar.
My system is Debian stable (Etch). Now I need to move to a newer computer
and thusly had in mind using mc transfer the files. I have done the same
before and had similar experiences, but this time it was extreme.
The aim was to set up a shell link on the right pane. Generally, the
artefacts only cover the 4 first buttons on the bottom bar (from Help to
Edit). But this time the whole UI moved away.
With F9 I got the top bar to show Right and with the arrow keys, I
pretty much recreated the whole top bar. The contents behind it was of
course gone by then.
I hope this may help in further improving an already great app.
Wed
}}}
--
Ticket URL: http://www.midnight-commander.org/ticket/122
Midnight Commander www.midnight-commander.org
Midnight Development Center
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
[Midnight Commander] #123: savannah: 2GB file size limit in fish
#123: savannah: 2GB file size limit in fish
+---
Reporter: slavazanko | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: mc-core | Version: 4.6.1
Keywords: |Blocking:
Blockedby: |
+---
Original: http://savannah.gnu.org/bugs/?15524
||Submitted by:||Ludovic Drolez ldrolez||Submitted on:||Tue 24 Jan 2006
06:03:58 PM UTC||
||Category:||VFS||Severity:||3 - Normal||
||Status:||None||Privacy:||Public||
||Assigned to:||None||Open/Closed:||Open||
||Release:||All versions||Operating System:||All||
Discussion:
{{{
Fri 27 Apr 2007 10:14:45 AM UTC, comment #2:
This patch was over simplistic and should have been verified better
before checking in. There were two problems with it:
a) it used the 'L' length modifier which is supposed to be used
with floating point data types as opposed to integers. Yes, glibc
allows it but it is noted that such use should be considered a bug.
b) it didn't care about the actual size of off_t
I've checked in a patch which fixes both problems:
http://cvs.sv.gnu.org/viewcvs/mc/mc/vfs/fish.c?sortby=dater2=1.117r1=1.116diff_format=u
Pavel Tsekov ptsekov
Project Administrator
Fri 27 Jan 2006 07:43:38 PM UTC, comment #1:
A patch has just been submitted to the debian BTS.
Anonymous
Tue 24 Jan 2006 06:03:58 PM UTC, original submission:
Hi,
Someone reported the bug on the debian bts: http://bugs.debian.org/349390.
After inspecting fish.c it seems that there are 31 bits limitations
everywhere and in particular in:
- fish_linear_start(): ... sscanf( reply_str, %d, ...
- fh-u.fish.total : declared as an int
Cheers,
Ludo
}}}
--
Ticket URL: http://www.der-winnie.de/trac/ticket/123
Midnight Commander www.midnight-commander.org
Midnight Development Center
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #113: savannah: make tabs and trailing spaces visible
#113: savannah: make tabs and trailing spaces visible
-+--
Reporter: slavazanko | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: mc-core | Version: 4.6.1
Resolution: |Keywords:
Blocking: | Blockedby:
-+--
Description changed by slavazanko:
Old description:
Original: http://savannah.gnu.org/bugs/?13146
||Submitted by:||Oswald Buddenhagen ossi||Submitted on:||Sat 21 May
2005 07:25:17 PM UTC||
||Category:||Editor||Severity:||3 - Normal||
||Status:||In Progress||Privacy:||Public||
||Assigned to:||None||Open/Closed:||Open||
||Release:||current (CVS or snapshot)||Operating System:||All||
Discussion:
{{{
Sun 06 Jul 2008 04:12:04 PM UTC, comment #24:
I noticed I cannot just use the Unicode characters (like p-ch = 0xB7),
as that does not take into account terminals that are not in UTF-8. But
the fix is simple enough (p-ch = SLsmg_Is_Unicode ? 0xB7 : .).
BTW, I also implemented the MS Word-style tabs, i.e. printing a right-
arrow in the middle of a tab. I sort of prefer it over the tabs.
It is a patch that currently replaces the existing tab mechanism, but
IMHO this should all be made configurable once the maintainers decide to
wake up and give me some sort of ok...
(file #16007)
Jan Engelhardt hirogen2
Sun 06 Jul 2008 01:24:09 PM UTC, comment #23:
Patch #4 -- cedit-symbol-prefs.diff
This patch changes the space fill character to some Unicode dot (·) [this
one is also available on the text console], and makes the -- tab
filler into the Unicode ◀──▶ too.
(file #16006)
Jan Engelhardt hirogen2
Sun 06 Jul 2008 01:21:22 PM UTC, comment #22:
Patch #3 -- cedit-fix-whitespace.diff
We definitely need to set MOD_WHITESPACE or the space between tab stops
is drawn with some random color.
(file #16005)
Jan Engelhardt hirogen2
Sun 06 Jul 2008 01:19:54 PM UTC, comment #21:
Patch #2 -- cedit-eol-mark.diff
This patch implements comment #8's suggestion to use ¶ as an EOL marker.
It can be toggled using the OptionsHighlight options dialog, or, of
course, by editing ~/.mc/config directly.
(file #16004)
Jan Engelhardt hirogen2
Sun 06 Jul 2008 01:17:43 PM UTC, comment #20:
Ok since nobody replied here are some patches of my own.
They require that mc(edit) has COMPLETE support for UTF-8!, which is not
the case in the mc source distribution. The openSUSE .src.rpm has the
required utf8 bits. Will try to make them submit theirs.
Patch #1 -- cedit-configurable-highlight.diff
This is for comment #19; it allows to switch highlighting. Firstly, it
adds a dialog (Options Highlight options) where you can precisely
select what to highlight
[ ] Global syntax highlighting
[ ] Tab highlighting (those -- markers, which, btw, can get very
ugly if you have lots of code)
[ ] Whitespace highlighting (dots at the end-of-line, and, if tab
highlighting is disabled, anywhere on the line)
One can already toggle Syntax highlighting with Ctrl-S in mc 4.6.2, for
the latter two, I added Ctrl-V as a hotkey which cycles through the
possibilities. My personal preference is to have Tab highlight OFF and
Whitespace highlight ON.
(file #16003)
Jan Engelhardt hirogen2
Fri 29 Feb 2008 07:16:33 PM UTC, comment #19:
Oh, god... I just updated my Debian box, and I now run MC 4.6.2-pre1 (as
outputted by mcedit --version). It appears that this patch is included in
this version of mcedit. I really dislike it. Besides suffering from the
'cursor disappearing' thingy, I just think its ugly. But that's my humble
opinion :)
How can I disable it? The patches attached to this report don't seem to
make a new configurable parameter available in the configuration dialogs.
Jurrie Overgoor leadpumper
Tue 04 Sep 2007 05:29:40 AM UTC, comment #18:
Pavel, I applied your patch to vte-0.16.8. It works.
Andrew Borodin a_borodin
Mon 03 Sep 2007 01:15:42 PM UTC, comment #17:
Ok. I tracked the bug to vte_terminal_determine_colors() in the vte
package. To request brighter colors one forces the terminal into bold
mode. It seems that in this mode vte allows only the foreground color to
be bright. In vte's terms a bright color is the same color as the normal
one but with a special flag set. So what happens is that when the time
comes for the cursor to blink vte switches the current forground color
with the current background color and vice versa... As I said above
both colors are indentified in the same way but one has a special flag,
however vte uses this flag to brighten the foreground color so at the end
we end up as if nothing happened. It's hard to say whether this is the
desired behaviour .. I'll attach a simple patch which changes vte
[Midnight Commander] #124: Test ticker foo
#124: Test ticker foo ---+ Reporter: Enrico Weigelt weig...@metux.de | Owner: Type: defect | Status: new Priority: major | Milestone: Component: mc-core| Version: 4.6.1 Keywords: |Blocking: Blockedby: | ---+ test 123 -- Ticket URL: /ticket/124 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #92: Adds 7zip extfs descriptor
#92: Adds 7zip extfs descriptor --+- Reporter: slavazanko | Owner: slavazanko Type: enhancement | Status: accepted Priority: trivial | Milestone: 4.6.2 Component: vfs | Version: 4.6.1 Resolution: |Keywords: Blocking: | Blockedby: --+- Changes (by slavazanko): * owner: = slavazanko * priority: major = trivial * version: = 4.6.1 * status: new = accepted * milestone: = 4.6.2 Comment: 7zip-ext-add.patch, mc-4.6.1-alt-u7z.patch and fedora10-mc-7zip.patch - it's present patches from different distros. mc-4.6.1-alt-u7z.patch - must apply to 4.6.1, but it contain anoter algoritm of u7z shell-plugin. My puprose: don't change exists file u7z, but apply some things from another patches. See next attach. -- Ticket URL: http://www.midnight-commander.org/ticket/92#comment:2 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #94: Some fixups for large file support (64bit sizes) on 32bit systems
#94: Some fixups for large file support (64bit sizes) on 32bit systems
-+--
Reporter: slavazanko | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: mc-core | Version:
Resolution: |Keywords:
Blocking: | Blockedby:
-+--
Comment(by slavazanko):
Patch may be apply only partially (for example, in 'master' branch
directory 'intl' is absent).
Also patch contains a code:
{{{
#if GLIB_MAJOR_VERSION = 2
# define my_g_malloc g_try_malloc
#else
# define my_g_malloc g_malloc
#endif
}}}
This is a great idea, but it has no place in the src/view.c
IMHO, you need to create a separate ticket and attach patch with the full
implementation of this idea.
--
Ticket URL: http://www.der-winnie.de/trac/ticket/94#comment:1
Midnight Commander www.midnight-commander.org
Midnight Development Center
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: HAVE_MMAP still necessary ?
* MP singular...@gmail.com schrieb: We could have some get that file into memory call, that will try to use mmap if possible and store pointer to freeing the block (that would call munmap, free or some other method depending on how the block was acquired) Exactly :) The actual fs (and only it) should be responsible for getting the block into memory and later freeing it again - the clients even don't have to know that something like mmap exists at all. Such an interface could be very useful for everyone who just needs some file area in memory and doesnt want to care about sequential reading. Let's first try it out libmvfs, once it works fine, we can add it to mcvfs ... But we need to cope with situations, where the file won't fit in RAM and won't fit in virtual memory either. For example 8gb file on i386 architecture with 2 gb of ram. The vfs call will simply return an appropriate error if there's not enough memory available (whether virtual or physical is out the client's scope). 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: automatic symlink maintenance [WAS: Removing myself from the project]
* Janek Kozicki janek_li...@wp.pl schrieb: IMHO, such a feature clearly doesn't belong into mc itself - it's a filesystem issue ;-P You are right! Thanks, it never occurred to me. I'm going to ask ext3 developers about that. Filesystem doesnt necessarily mean disk-filesystem. It's a job for some overlaying FS. (9P is your friend ;-P) 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: Reporting Bugs via mail works now (with drawbacks)
* Enrico Weigelt weig...@metux.de schrieb: Hi, It's possible to add tickets, add comments to existing tickets and the emails will get carbon-copied back to the mc-devel list. opening a ticket seems to work now, but I didn't get any mail back yet. Okay, answers also come back now. But the server still tends to be overloaded. 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
* Roland Illig roland.il...@gmx.de schrieb: 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. Okay, I'm trying to hack up something. This will also be my first reallife learning experience w/ git ;-) Please give me some hint how to send back my changes for review (directly via git). 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
* Slava Zanko slavaza...@gmail.com schrieb:
Hi,
lib - in my mind must be sources of library(es) of project.
What we see in directory lib?
ACK. Currently, it contains lots of stuff which clearly don't belong
there, but instead something like man/doc/shared-data/whatever.
My purpose (in far-near future):
doc
man (current ${src_root}/doc)
contributor (contributor manuals)
developer (developers manual)
What exactly is the difference between developer and contributor ?
user (all README-files, readme about hotkeys, all other
user-related)
contrib
contrib/extfs (current ${src_root}/vfs/extfs)
Why do extfs scripts belong into contrib ?
BTW: they should be installed into ${libexecdir}/mc, not
${datarootdir}/mc. Same w/ the stuff in ${datarootdir}/mc/bin.
The global menu configs belong into ${sysconfdir}/mc. Hintfiles
are locale stuff, so belong somewhere below ${datarootdir}/locale/ ..
contrib/lib (current ${src_root}/lib, except mc.hint.* and
README.xterm)
And the lib/ChangeLog should be merged with the one in the toplevel dir.
contrib/syntax (current ${src_root}/syntax)
Why are the syntaxfiles contrib stuff ?
lib/slang
Why should we carry an own branch of slang at all ?
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: Reporting Bugs via mail works now (with drawbacks)
* Slava Zanko slavaza...@gmail.com schrieb: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Enrico Weigelt wrote: Okay, answers also come back now. But the server still tends to be overloaded. Yes, 'database is locking'... :( ACK. Got the same error all the time. Any idea what's up w/ the server ? 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
On Sat, 3 Jan 2009 17:34:19 +0100 Enrico Weigelt wrote:
Why do extfs scripts belong into contrib ?
BTW: they should be installed into ${libexecdir}/mc, not
${datarootdir}/mc. Same w/ the stuff in ${datarootdir}/mc/bin.
Why? ${datarootdir}/mc contains arch-independent files and
mc-specific files. It's correct place in terms of FHS.
The global menu configs belong into ${sysconfdir}/mc.
I agree.
Hintfiles are locale stuff, so belong somewhere below
${datarootdir}/locale/.
Hintfiles are private data of mc. ${datarootdir}/mc is correct place
for it.
--
Regards,
Andrew.
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: bundled intl stuff necessary
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Enrico Weigelt wrote:
My purpose (in far-near future):
doc
man (current ${src_root}/doc)
contributor (contributor manuals)
developer (developers manual)
What exactly is the difference between developer and contributor ?
Developer docs:
- - style of project sources;
- - descriptions of internal functions (library related, may be via doxygen)
- - UML-like schemas... or in plain text :)
- - other doc-stuff related to developers
Contributor... gm... may be I'm mistaken with word... 'maintainer' more
like.
- - How make packages in rpm, deb, tgz(Slackware) and other
package-oriented distros
- - How compile on *BSD/MaCOS, Cygwin/MinGW
- - How compile on embedded systems
- - ... other maintainer-related stuff
contrib
contrib/extfs (current ${src_root}/vfs/extfs)
Why do extfs scripts belong into contrib ?
contrib/syntax (current ${src_root}/syntax)
Why are the syntaxfiles contrib stuff ?
this not a part of mc executable and must be in conrtib area, IMHO
BTW: they should be installed into ${libexecdir}/mc, not
${datarootdir}/mc. Same w/ the stuff in ${datarootdir}/mc/bin.
The global menu configs belong into ${sysconfdir}/mc. Hintfiles
are locale stuff, so belong somewhere below ${datarootdir}/locale/ ..
This already applyed in Fedora-10 patch. Later I will publish this patch
in trac.
contrib/lib (current ${src_root}/lib, except mc.hint.* and
README.xterm)
And the lib/ChangeLog should be merged with the one in the toplevel dir.
ACK.
lib/slang
Why should we carry an own branch of slang at all ?
For embedded systems with less of memory, IMHO...
... P.S. May be, in future mc will work on my iPhone... ;)
WBR. Slavaz.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAklfmUYACgkQb3oGR6aVLponugCdGMWhLVP0yiEaaY0Ibgs6Gt34
4roAnRCOM49isy6Cs5qFSUZZBIlHPvgG
=OsnN
-END PGP SIGNATURE-
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: bundled intl stuff necessary
* Andrew Borodin aboro...@vmail.ru schrieb:
On Sat, 3 Jan 2009 17:34:19 +0100 Enrico Weigelt wrote:
Why do extfs scripts belong into contrib ?
BTW: they should be installed into ${libexecdir}/mc, not
${datarootdir}/mc. Same w/ the stuff in ${datarootdir}/mc/bin.
Why? ${datarootdir}/mc contains arch-independent files and
mc-specific files. It's correct place in terms of FHS.
Are you *absolutely* sure they're always arch-independent and
ever will be ?
Hintfiles are locale stuff, so belong somewhere below
${datarootdir}/locale/.
Hintfiles are private data of mc. ${datarootdir}/mc is correct place
for it.
Yeah, same way private as .mo files, and they also serve almost
the purpose: language specific messages.
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: Reporting Bugs via mail works now (with drawbacks)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Enrico Weigelt wrote: ACK. Got the same error all the time. Any idea what's up w/ the server ? Winnie fry on a fire, which will burned from the hot processor of server... :) Patrick, sorry, I don't want to offend. ;) WBR, Slavaz. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAklfnOUACgkQb3oGR6aVLppGtwCeJBVRquRJyZuSB67R/DIZ3pUo UQEAn2exEsbzXbDuD/txVjMCD5duSK5Z =WPiB -END PGP SIGNATURE- ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: bundled intl stuff necessary
* Slava Zanko slavaza...@gmail.com schrieb:
Contributor... gm... may be I'm mistaken with word... 'maintainer' more
like.
- - How make packages in rpm, deb, tgz(Slackware) and other
package-oriented distros
- - How compile on *BSD/MaCOS, Cygwin/MinGW
- - How compile on embedded systems
- - ... other maintainer-related stuff
hmm, isn't that just normal doc stuff ? ;-o
(perhaps under the packager/ subdir)
Why do extfs scripts belong into contrib ?
contrib/syntax (current ${src_root}/syntax)
Why are the syntaxfiles contrib stuff ?
this not a part of mc executable and must be in conrtib area, IMHO
They're needed by mcedit at runtime, same as shared libs, configs, etc.
IMHO, contrib means: from external sources and not officially
maintained by the upstream. I don't see that we really have this
situation yet (besides distro-specific buildfiles, etc).
BTW: they should be installed into ${libexecdir}/mc, not
${datarootdir}/mc. Same w/ the stuff in ${datarootdir}/mc/bin.
The global menu configs belong into ${sysconfdir}/mc. Hintfiles
are locale stuff, so belong somewhere below ${datarootdir}/locale/ ..
This already applyed in Fedora-10 patch. Later I will publish this patch
in trac.
Ok.
lib/slang
Why should we carry an own branch of slang at all ?
For embedded systems with less of memory, IMHO...
Already suspected something like that. IMHO an stupid idea:
Embedded maintainers should use an trimmed-down slang or do
static linking, etc. BTW: the change of unnecessarily bloating
up the system w/ bundled slang is quite good - just takes one
more slang-using app and all benefit's gone.
My vote is to completely dropping the bundled slang and let the
embedded folks do the trim-down on their own.
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: Further Midnight Commander development
* Slava Zanko slavaza...@gmail.com schrieb: Hi, you meant: mcvfs = model ? No. model = any data source. mcvfs - one of sources for mc. Which other datasources do you have in mind ? yeah, even sockets: cat tcp://somehost:port/ (I'll add this to libmvfs in the next days ...) Cool. I'm waiting now this patch. :) Hmm, will take some time ... you can check out the open libmvfs branches (svn://anonymous:anonym...@nibiru.metux.de/public/libmvfs/) to see what's coming. Primary libmvfs-mcvfs bridging is already done in mc-9p branch (svn://nibiru.metux.de/public/mc-9p/), all it takes now is adding a new vfs_class structure per libmvfs-supported fs :) (perhaps we could invent some more automatic mapping someday ?) certain certain DE's ? Well, perhaps it would be even better to just directly support well-known DE's shortcut files ? But if file will open by DE, mc don't handle data from 'shorcut'. No, I meant, mc shall be able to understand certain DE's shortcut files and do the right things. For example, if the shortcut points to some ftp:// url, it just cd's to this url and let's ftpfs do the dirty work. 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
git+patch workflow [WAS: bundled intl stuff necessary]
* Slava Zanko slavaza...@gmail.com wrote: (bouncing back to the list ;-p) Hi, I not fully understand... How automate process of patch submission, in your mind? Okay, let's take an example: I'm currently working on some sub-project. Now I've did my work, everything seems okay for me and I'd like to publish it. All I now (ideally) would have to do is enter some quick command line (eg. including some description) and the rest goes automatic: my work is published, ticket opened, etc. Coming from the other side, it would be cool to have some command get me the changes from ticket xyz, so we don't have to download and apply the patches manually. The best solution - use git branches for tracking patches, IMHO. hmm, heard of that, but never used it. How does it work ? hmm, do my changes then go to the current branch (assuming I've cloned from there) ? Yes, your changes will applyed to the main branch (named 'master'). You may create any count of commits (via git-commit), but this commits placed only in your local copy of repro. You may delete some of this commits, verge, revert commits... Okay, that's just normal working in the local repo ... but if you will run command 'git-push', all of your commits will frozen for changes. Because this commits transferred in parent repro and will see by any developer (via git-pull). git-pull will get latest changes from parent repro (like svn up, or full command: svn update). But this commits directly to our master repo, thus breaking our workflow, right ? If you want to have own 'sandbox' with some patches (not included in 'master'), you may create new local branch: Can I freely create branches within the master repo ? And more important: *should* I do this ? 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: [r...@rover.dkm.cz: [repo.or.cz] midnight-commander clone completed]
Quoting Enrico Weigelt weig...@metux.de: JFYI: just created a git mirror ... ... http://repo.or.cz/m/editproj.cgi?name=midnight-commander What's the point? I could have given you full access to the mc repository on the same site. After all, it's just a mirror. You could have rewritten the whole repository. Now we have two competing mirrors for the same project. I'm not going to keep it this way. I'll ask the admins to get mc offline. I can tell from my experience that failure to cooperate is destructive for any project. Creating a mirror without asking others is an example of such failure. Sure, you saved a day or two by not asking me and not waiting for my reply. But by not asking, you made a little step towards excluding others from the development. If people see that their opinion doesn't matter, they stop participating. This leads to a one-person project, which stops when that person gets tired. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [r...@rover.dkm.cz: [repo.or.cz] midnight-commander clone completed]
* Pavel Roskin pro...@gnu.org schrieb: Hi, What's the point? I could have given you full access to the mc repository on the same site. After all, it's just a mirror. You could have rewritten the whole repository. Now we have two competing mirrors for the same project. I'm not going to keep it this way. Hey, it's just dumb *readonly* mirror. nobody can commit there (not even me) - it just syncs itself from the master periodically. the idea behind is nothing more to have yet another publically available copy to keep some unncessary traffic from the weak mc.o server. and in case something bad happens to the server, we've got an backup. It's not a fork or anything like that. I really don't see the problem. 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
* Andrew Borodin aboro...@vmail.ru schrieb:
On Sat, 3 Jan 2009 18:14:21 +0100 Enrico Weigelt wrote:
* Andrew Borodin schrieb:
${datarootdir}/mc contains arch-independent files and
mc-specific files. It's correct place in terms of FHS.
Are you *absolutely* sure they're always arch-independent
At current time -- yes.
and ever will be ?
Who knows? :-)
That's the point. Some day someone writes an extfs in C (which
is evrything but improbable) and the hassle begins. I'd prefer
to keep such trouble out of the way even before it starts.
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
