| View previous topic :: View next topic |
| Author |
Message |
xentric
Guru
Joined: 16 Mar 2003
Posts: 410
Location: Netherlands
|
 Posted: Sun Aug 01, 2004 8:41 pm Post subject: |
 |
|
| mtwnet wrote: | | Any ideas as to what's going on? |
Try removing the cfg-update-1.6.tar.gz from /usr/portage/distfiles
then remove all files and directories, except the ebuild itself, from
/usr/local/portage/app-portage/cfg-update and then try the digest
command again...
_________________
When all else fails, read the manual...
Registered Linux User #340626 |
|
| Back to top |
|
 |
mtwnet
n00b
Joined: 31 Jul 2004
Posts: 18
|
| Posted: Mon Aug 02, 2004 12:32 am Post subject: |
|
|
| Still nothing. I actually didn't have a cfg-update in the /usr/portage/distfiles dir. |
|
| Back to top |
|
|
whyttiger9
n00b
Joined: 04 Aug 2004
Posts: 1
|
| Posted: Wed Aug 04, 2004 2:21 am Post subject: trouble |
|
|
| I'm getting the same error as mtwnet and have tried removing any files as you suggested (no files were there). I'm just trying to follow the directions line by line. Are there any packages that I should have installed first, or anything else I should have done? |
|
| Back to top |
|
|
xentric
Guru
Joined: 16 Mar 2003
Posts: 410
Location: Netherlands
|
| Posted: Wed Aug 04, 2004 6:28 pm Post subject: Re: trouble |
|
|
| whyttiger9 wrote: | | I'm getting the same error as mtwnet and have tried removing any files as you suggested (no files were there). I'm just trying to follow the directions line by line. Are there any packages that I should have installed first, or anything else I should have done? |
I recently changed the ebuild because the textutils package was integrated
into the coreutils package. I bet this change is causing the problem. What
happends when you use this older 1.6 ebuild?
Edit: The error could also be caused if you cut&paste the ebuild text from
a browser window, you should just right-click the ebuild link and choose
"save link as".
_________________
When all else fails, read the manual...
Registered Linux User #340626 |
|
| Back to top |
|
|
steve_p
n00b
Joined: 07 Aug 2004
Posts: 1
Location: soon to be in az
|
| Posted: Sat Aug 07, 2004 10:05 am Post subject: xxdiff illedgible |
|
|
Hi,
I followed the install instuctions and when I run cfg-update xxdiff launches but I can't read what it says...looks cyrillic or something like that. Launcing xxdiff alone is in english.
Please help.
Thanks |
|
| Back to top |
|
|
xentric
Guru
Joined: 16 Mar 2003
Posts: 410
Location: Netherlands
|
| Posted: Sat Aug 07, 2004 12:57 pm Post subject: Re: xxdiff illedgible |
|
|
| steve_p wrote: | | I followed the install instuctions and when I run cfg-update xxdiff launches but I can't read what it says...looks cyrillic or something like that. Launcing xxdiff alone is in english. |
This is weird, but as cfg-update starts xxdiff with a parameter to set the
Keramic theme. It could be that the theme is causing the characters to
change into cyrillic or something.
You can edit the script (/usr/lib/cfg-update/cfg-update.pl) yourself, just look for this line:
| Quote: | | if ($tool =~ "xxdiff") { $cmd = "xxdiff --style Keramik --resource \'Show.PaneMergedView:true Show.Toolbar:true\' $file1 $file2 2>/dev/null"; } |
and change it to:
| Quote: | | if ($tool =~ "xxdiff") { $cmd = "xxdiff --resource \'Show.PaneMergedView:true Show.Toolbar:true\' $file1 $file2 2>/dev/null"; } |
That should give you a standard xxdiff theme...
_________________
When all else fails, read the manual...
Registered Linux User #340626 |
|
| Back to top |
|
|
mtwnet
n00b
Joined: 31 Jul 2004
Posts: 18
|
| Posted: Mon Aug 09, 2004 7:29 pm Post subject: Re: trouble |
|
|
| xentric wrote: | I recently changed the ebuild because the textutils package was integrated
into the coreutils package. I bet this change is causing the problem. What
happends when you use this older 1.6 ebuild? |
I used this new file and I finally got it to work, although I have to sudo to do it. I still can't get it to work after su'ing. Running it with sudo is fine, right? |
|
| Back to top |
|
|
xentric
Guru
Joined: 16 Mar 2003
Posts: 410
Location: Netherlands
|
| Posted: Tue Aug 10, 2004 3:36 pm Post subject: Re: trouble |
|
|
| mtwnet wrote: | I used this new file and I finally got it to work, although I have to sudo to do it.
I still can't get it to work after su'ing. Running it with sudo is fine, right? |
It's ok to use sudo but it should work with su too.
Just read the troubleshooting section below the
installation steps, it deals with these problems.
_________________
When all else fails, read the manual...
Registered Linux User #340626 |
|
| Back to top |
|
|
tightcode
Tux's lil' helper
Joined: 23 Mar 2004
Posts: 110
|
| Posted: Sun Aug 29, 2004 4:33 pm Post subject: Another one... |
|
|
Just wanted to let you know like mtwnet and the other lad, the new ebuild is failing. I am trying the old ebuild right now and it worked. I will see how the rest goes.
[edit 2004-09-11 10.00 UTC+1]
Well the rest went quite well. It's a shame the new ebuild fails though. I have actually not set this up on my other machines yet because of the hastle. If either these problems are fixed or I get some spare time I may go ahead and do it though. It works nicely I must say, quite pleased with it.
[/edit]
Cheers,
TightCode |
|
| Back to top |
|
|
David_Escott
l33t
Joined: 12 Jan 2003
Posts: 952
Location: Boston, MA
|
| Posted: Sun Nov 07, 2004 3:00 am Post subject: |
|
|
| I would like to try cfg-update because once again etc-update has screwed stuff up for me. But I have a chicken and egg problem. I use gnome and dont have kde installed so I didnt want to install xxdiff so I simply deleted it (I'll try to use meld). The problem is that when I try to run cfg-update -c to change the preference it complains that it can't find xxdiff. I don't know where any of the cfg-update config files are so I can't manually change things. Anything that can be done about this? |
|
| Back to top |
|
|
xentric
Guru
Joined: 16 Mar 2003
Posts: 410
Location: Netherlands
|
| Posted: Sun Nov 07, 2004 10:33 pm Post subject: |
|
|
| David_Escott wrote: | | The problem is that when I try to run cfg-update -c to change the preference it complains that it can't find xxdiff. I don't know where any of the cfg-update config files are so I can't manually change things. Anything that can be done about this? |
Try this first:
| Quote: | root@yourbox / $ cd /usr/bin
root@yourbox /usr/bin $ touch xxdiff
root@yourbox /usr/bin $ chmod +x xxdiff
root@yourbox /usr/bin $ cfg-update -c
(and change the default editor into meld...)
root@yourbox /usr/bin $ rm -rf /usr/bin/xxdiff
|
There isn't a configuration file as cfg-update is a script that can
modify itself. You can also change the default editor by directly
editing the script: /usr/lib/cfg-update/cfg-update.pl
Change the following line:
| Quote: | | my $GUI_tool = "xxdiff"; |
into
| Quote: | | my $GUI_tool = "meld"; |
(it only needs meld to be in /usr/bin so create a link in that
directory if the executable doesn't exist in that location.)
Then further down the script you can optionally add custom
commandline options for meld:
| Quote: | sub launch_tool {
my $cmd = "$tool $file1 $file2";
if ($tool =~ "xxdiff") { $cmd = "xxdiff... and it's commandline options }
if ($tool =~ "sdiff") { $cmd = "sdiff... and it's commandline options }
ADD YOUR TOOL HERE...
|
As you can see the default command "$tool $file1 $file2" is being
replaced by custom commands for xxdiff and sdiff, so you can
add your own command for meld if it needs more options than
the default command...
You can use $file1, $file2 and $file5 where:
$file1 = /path/filename
$file2 = /path/._cfg????_filename
$file3 = (used in backup routine) /path/._old-cfg_filename
$file4 = (used in backup routine) /path/._new-cfg_filename
$file5 = /path/filename.merge
I can't check the exact commandline for meld because my
gentoo/linux box is dead...
But if meld can accept a "save merged result as filename" option
I would recommend using $file5 as the merged result filename
because cfg-update will automatically replace the original file
with this merged result after it has made a backup of the
original file.
_________________
When all else fails, read the manual...
Registered Linux User #340626 |
|
| Back to top |
|
|
barefootcoder
Tux's lil' helper
Joined: 09 Jan 2004
Posts: 93
|
| Posted: Tue Nov 09, 2004 9:48 pm Post subject: |
|
|
Well, xentric, I think you've got a really good idea here. Interestingly enough, I don't really care about the GUI functionality--which I'm sure is the main draw of cfg-update for most--I'm just interested in its ability to distinguish config files you've changed from config files you haven't. That alone is worth the price of admission for me. So perhaps I can offer some help.
First thing I'm looking at is the installation (i.e., the ebuild). I made a couple of tweaks that you might want to incorporate:
| Code: | sigil cfg-update # diff cfg-update-1.6.ebuild cfg-update-1.6-r1.ebuild
7c7
< SRC_URI="http://people.zeelandnet.nl/mboven79/${PF}.tar.gz"
---
> SRC_URI="http://people.zeelandnet.nl/mboven79/${P}.tar.gz"
10c10
< IUSE=""
---
> IUSE="X"
16c16
< >=dev-util/xxdiff-2.9
---
> X? ( >=dev-util/xxdiff-2.9 )
20c20
< unpack ${PF}.tar.gz
---
> unpack ${P}.tar.gz
|
The ${P}/${PF} distinction is fairly minor, although I personally think it's better practice (i.e., a "-r?" ebuild theoretically doesn't involve any changes to the code being installed, just to the layout/installation of it). The important bit is now xxdiff is conditional to the X use flag. Therefore it won't try to drag in xxdiff if the user doesn't have X, and even if they do, they can use /etc/portage/package.use to disable it if they want to (which is what I did). This would simplify your installation instructions a bit, methinks.
The other place where the installation instructions can be a bit frightening for the newbies is with the whole emerge alias thing. If we're pretty sure that the only problem this engenders is not being able to use XXX="xxx" in front of emerge, that seems to be moderately easy to fix. On the whole, though, aliasing emerge seems a bit dicey on general principle (not that I can think of any problem in particular, mind you; it just makes me a bit nervous on principle) and I wonder if there's a way around this. Just something to chew on.
But, in the meantime, to fix the obvious problem, why not make a separate script and alias to that? I.e., the script (called "emerge-with-cfg-update" or whatever) would basically be a two-liner, and then the alias would just point emerge at this new script. After all, the problem with the alias approach is that
| Code: | | XXX="xxx" emerge fred |
gets turned into
| Code: | | XXX="xxx" cfg-update --index ; emerge fred |
which means that your env settings don't last past the semi. But with my proposed solution, the alias would render roughly
| Code: | | XXX="xxx" emerge-with-cfg-update fred |
and the two-line script properly inherits the env. Problem solved (or it should be anyway; I didn't actually try this out).
Anyways, hope that helps a bit. Perhaps I can look at the script itself and offer more suggestions, if you're amenable. |
|
| Back to top |
|
|
xentric
Guru
Joined: 16 Mar 2003
Posts: 410
Location: Netherlands
|
| Posted: Wed Nov 10, 2004 8:00 pm Post subject: |
|
|
| barefootcoder wrote: | | The ${P}/${PF} distinction is fairly minor, although I personally think it's better practice (i.e., a "-r?" ebuild theoretically doesn't involve any changes to the code being installed, just to the layout/installation of it). |
You are right, I should use -r ebuild versions for minor updates to the
installation or layout changes. I have tried this a couple of times but
couldn't get it to work. Perhaps it will work with ${P}...
| Quote: | | The important bit is now xxdiff is conditional to the X use flag. Therefore it won't try to drag in xxdiff if the user doesn't have X, and even if they do, they can use /etc/portage/package.use to disable it if they want to (which is what I did). This would simplify your installation instructions a bit, methinks. |
Methinks, why didn't I think of this meself  Thanks! But I need to fix
a small bug in the cfg-update script (see David_Escott's message)
The script checks if xxdiff is in /usr/bin because the default GUI-editor
is set to xxdiff by default. In non-X systems this would cause problems
so it needs to be changed before I can add the IUSE="X" flag to the
ebuild.
| Quote: | | The other place where the installation instructions can be a bit frightening for the newbies is with the whole emerge alias thing. |
I agree, I didn't like to alias emerge either but I couldn't figure out a way
to keep the checksum-index uptodate with every emerge action. Your
solution to the XXX="xxx" problem makes sense though, but is not needed
when the alias is replaced by a different solution. I have been thinking
about it and came up with the following:
A cronjob that runs cfg-update with a new (to be added) option --sync
All "cfg-update --sync" has to do is check the emerge log every minute or
so. If the emerge log has changed it must re-index the checksums.
| Quote: | | Anyways, hope that helps a bit. Perhaps I can look at the script itself and offer more suggestions, if you're amenable. |
Barefootcoder, you are welcome to review the script and discuss points
you'd like to see changed. Be warned, I'm not a programmer for a living
so my (pseudo)code can use some weird methods to accomplish very
simple things...
After screwing up an etc-update session myself I found that many people
made the same mistake. But with my Turbo Pascal coding background
I had to choose a new programming language. I basically learned Perl
while writing this script. I really liked the fact that the linux system has
a lot of tools that can do stuff faster than self-written code. That's why
I call it pseudo-code, the script heavily depends on common linux tools.
Also, to be honest I haven't worked on cfg-update for a long time because
I have very minimal spare time at the moment. (and my portage is
severly damaged after losing the /var partition) So I need some time
to re-install Gentoo and implement these changes into cfg-update.
_________________
When all else fails, read the manual...
Registered Linux User #340626 |
|
| Back to top |
|
|
David_Escott
l33t
Joined: 12 Jan 2003
Posts: 952
Location: Boston, MA
|
| Posted: Wed Nov 10, 2004 8:13 pm Post subject: |
|
|
| Instead of having use X? (>=xxdiff) whatever I would suggest use qt? (>=xxdiff) since those with X probably dont want to pull in all of qt for just this one script. |
|
| Back to top |
|
|
xentric
Guru
Joined: 16 Mar 2003
Posts: 410
Location: Netherlands
|
| Posted: Wed Nov 10, 2004 8:21 pm Post subject: |
|
|
| David_Escott wrote: | | Instead of having use X? (>=xxdiff) whatever I would suggest use qt? (>=xxdiff) since those with X probably dont want to pull in all of qt for just this one script. |
That's even better!
Btw, did you get cfg-update to work with meld? If so, maybe the following
could be an option:
qt? (>=xxdiff)
gtk? (>=meld)
(don't know if "gtk?" is the correct name)
_________________
When all else fails, read the manual...
Registered Linux User #340626 |
|
| Back to top |
|
|
David_Escott
l33t
Joined: 12 Jan 2003
Posts: 952
Location: Boston, MA
|
| Posted: Wed Nov 10, 2004 8:55 pm Post subject: |
|
|
meld doesn't have the necessary options. I was trying to think how this might be best done. To be honest it seems that the easiest thing to do would be to have cfg-update copy the current config to the .merge so suppose we are editing the file current.cfg
cp current.cfg current.cfg.merge
diffprog current.cfg.merge ._cfg0001-current.cfg
That way the user can use any diff program even if it doesnt support the merge to a third file functionality (which I suspect many programs would lack). And the default would then be to merge back in the existing config file without changes. Perhaps this has been discussed before, and I'm just not aware of the reasons for the current setup.
[edit: I just filed a feature request in bugs.gentoo of relevance to this thread, and will let you know what I hear. https://bugs.gentoo.org/show_bug.cgi?id=70704 ] |
|
| Back to top |
|
|
xentric
Guru
Joined: 16 Mar 2003
Posts: 410
Location: Netherlands
|
| Posted: Wed Nov 10, 2004 9:53 pm Post subject: |
|
|
| David_Escott wrote: | | That way the user can use any diff program even if it doesnt support the merge to a third file functionality (which I suspect many programs would lack). |
I basically modelled the script around xxdiff, but after realising it needed
to work in non-X setups too, I added support for sdiff just like etc-update.
I used the "third file" option in sdiff to figure out if a user had finished
merging the complete file... If the third file is not present, after returning
from sdiff back into cfg-update, it means that the merge was not completed
and cfg-update has to remove the backups it made before it opened sdiff.
I then changed the xxdiff instructions from "save as left/original file" to
"save as merged file" because xxdiff has a handy "M" button which saves
the merged result as filename.merge
So I created the $file5 variable and used it in sdiff too...
I now realise that this step severely limits cfg-update ability to work with
other tools, as many can't save the merged result with a given name but
simply overwrite the original file. (first file mentioned on the commandline)
I will try to find a solution for this... thanks for bringing it to my attention!
_________________
When all else fails, read the manual...
Registered Linux User #340626
Last edited by xentric on Wed Nov 10, 2004 9:58 pm; edited 1 time in total |
|
| Back to top |
|
|
xentric
Guru
Joined: 16 Mar 2003
Posts: 410
Location: Netherlands
|
| Posted: Wed Nov 10, 2004 9:56 pm Post subject: |
|
|
I just read it... Wow, that would be a nice and clean solution !
_________________
When all else fails, read the manual...
Registered Linux User #340626 |
|
| Back to top |
|
|
barefootcoder
Tux's lil' helper
Joined: 09 Jan 2004
Posts: 93
|
| Posted: Fri Nov 12, 2004 5:24 am Post subject: |
|
|
| Quote: | | I agree, I didn't like to alias emerge either but I couldn't figure out a way to keep the checksum-index uptodate with every emerge action. |
Well, perhaps we need to think even further outside the box ...
What I'd really like to see is some way of keeping the previous config file from the emerge. That way you have 3 copies of any given config: the unmodified from the previous ebuild (let's call it P), the current, possibly modified (let's call it C), and the unmodified from the new ebuild (let's call it N). That way, the problem we're discussing is easily solved by comparing P to C: if they match, we can just replace with N. But the real advantage here is being able to use something like diff3 to perform a merge à la CVS or Subversion. Theoretically, we could automatically generate all the configs with this method, although of course we would have to allow the user to verify files merged in this way, and there would also be potential conflicts to deal with.
| Quote: | | Be warned, I'm not a programmer for a living so my (pseudo)code can use some weird methods to accomplish very simple things... |
Heh. Well, as it happens, I am a programmer for a living, so perhaps I can offer some suggestions. For instance, a previous poster suggested the grep | awk sequences could be done with a single awk, but you could actually go even further: you have several cat | grep | awk sequence, which could be condensed to merely awk, and, really, you could condense them all the way down to doing it all in Perl. A function such as (warning: typed in off the top of my head; no warranties of accuracy or fitness for a particular purpose):
| Code: | sub pseudo_awk
{
my ($file, $pattern, $print) = @_;
open(IN, $file) or return '';
my @lines;
while ( <IN> )
{
next unless /$pattern/;
if ($print)
{
my @F = split;
my $line = $print;
$line =~ s/\$0/$_/g;
$line =~ s/\$(\d+)/$F[$1-1]/g;
push @lines, $line;
}
else
{
push @lines, $_;
}
}
close(IN);
return @lines;
} |
would allow you to replace:
| Code: | | $_ = `cat /etc/make.globals | grep CONFIG_PROTECT= 2>/dev/null`; |
with:
| Code: | | $_ = pseudo_awk('/etc/make.globals', qr/CONFIG_PROTECT=/); |
and replace:
| Code: | | `cat /var/db/pkg/*/*/CONTENTS | grep '^obj ' | awk '{ print \$2" "\$3 }' >>$index`; |
with:
| Code: | open(IDX, ">>$index") or return;
print IDX pseudo_awk($_, qr/^obj /, '$2 $3') foreach glob('/var/db/pkg/*/*/CONTENTS');
close(IDX); |
But those are just performance enhancements (although I suppose it removes a few dependencies in the ebuild as well). The more important aspect is probably to get the overall strategy down.
Anyways, I don't have a huge amount of spare time myself, but I'd be happy to do whatever I can to help out. I think this is a great idea you have here, and I'm glad someone else besides myself sees the need for it. |
|
| Back to top |
|
|
xentric
Guru
Joined: 16 Mar 2003
Posts: 410
Location: Netherlands
|
| Posted: Fri Nov 12, 2004 7:23 pm Post subject: |
|
|
| barefootcoder wrote: | | What I'd really like to see is some way of keeping the previous config file from the emerge. That way you have 3 copies of any given config: the unmodified from the previous ebuild (let's call it P), the current, possibly modified (let's call it C), and the unmodified from the new ebuild (let's call it N). That way, the problem we're discussing is easily solved by comparing P to C: if they match, we can just replace with N. |
I agree, theoretically this method works... but only after a package has
been updated. So there's no possibility to update configfiles automatically
until the package, that the configfile belongs to, has been updated at least
once.
With the current method I can determine if it's safe to overwrite a configfile
without knowledge about previous configfiles. I just match the current checksum
against the checksum that Portage recorded when it installed that file...
If it's not the same, the user must have modified it after it was installed
by portage and thus not safe to overwrite automatically.
The downside is that you need to keep the checksum index current, but
David has proposed a cool solution... He filed a bugreport with a feature
request for Portage. It would be very simple to add run-before-emerge
and run-after-emerge scripts to Portage, this would solve the alias problem.
| Quote: | | But the real advantage here is being able to use something like diff3 to perform a merge à la CVS or Subversion. Theoretically, we could automatically generate all the configs with this method, although of course we would have to allow the user to verify files merged in this way, and there would also be potential conflicts to deal with. |
I don't know if you have already tried dispatch-conf, I guess it's installed
by default just like etc-update. It can use rcs on the configfiles. I'm unfamiliar
with CVS/Subversion type of merging, I only know the basic principles of
CVS, but not how it actually works... But dispatch-conf may have exactly
what you need. Just check it out if you haven't tried it before. I've read
lot's of positive reactions about dispatch-conf.
See: Dispatch-conf with colordiff howto
| Quote: | Heh. Well, as it happens, I am a programmer for a living, so perhaps I can offer some suggestions. For instance, a previous poster suggested the grep | awk sequences could be done with a single awk, but you could actually go even further: you have several cat | grep | awk sequence, which could be condensed to merely awk, and, really, you could condense them all the way down to doing it all in Perl.
...
But those are just performance enhancements (although I suppose it removes a few dependencies in the ebuild as well). The more important aspect is probably to get the overall strategy down. |
It would be best to have everything coded in pure perl so it has no
dependencies except for the diff/merge tool(s). My strategy was to make
a tool that only requires userinput when absolutely necessary, the backups
are just to be safe when you've made a mistake.
A complete cvs/rcs/subversion implementation seemed like overkill to me
and makes things unnecessarily complicated for lot's of users. And there's
always dispatch-conf for those who insist on using such a method to keep
control over their configfiles.
| Quote: | | Anyways, I don't have a huge amount of spare time myself, but I'd be happy to do whatever I can to help out. I think this is a great idea you have here, and I'm glad someone else besides myself sees the need for it. |
I gotta get my system back together so I can work out the new ideas.
I was already working on version 1.7 when things went wrong on my
system. Version 1.7 isn't fully functional yet but as soon as it's working
I'll let you review the code. I'd like to get rid of unnecessary dependencies
but the functionality has priority over the little enhancements.
I'll keep you posted on my progress... (I expect it will take a couple of
weeks because I'm in the middle of a career deciding moment. I'm finally
having a chance of getting a job as a First Officer (copilot) on a Boeing 737
with a major airliner. So studying for the assessment and flight-training is
my absolute first priority!)
_________________
When all else fails, read the manual...
Registered Linux User #340626 |
|
| Back to top |
|
|
chipi
n00b
Joined: 05 Oct 2003
Posts: 62
Location: Israel
|
| Posted: Sat Jan 15, 2005 12:06 pm Post subject: |
|
|
| Umm, so there's so Meld support at the time? |
|
| Back to top |
|
|
xentric
Guru
Joined: 16 Mar 2003
Posts: 410
Location: Netherlands
|
| Posted: Sat Jan 15, 2005 7:11 pm Post subject: |
|
|
| chipi wrote: | | Umm, so there's so Meld support at the time? |
Well, I haven't got my hands on meld yet but you can help me find out if
it works if you answer these questions:
- Can meld save the merged result as "file.merge" ?
- Can you start meld from the commandline with an outputfile parameter?
- If none of the above, how does meld save the merged result?
_________________
When all else fails, read the manual...
Registered Linux User #340626 |
|
| Back to top |
|
|
chipi
n00b
Joined: 05 Oct 2003
Posts: 62
Location: Israel
|
| Posted: Sat Jan 15, 2005 11:01 pm Post subject: |
|
|
So, I went ahead and emerged Meld and cfg-update, and this is the situation:
Well, Meld does open the right files (the orignal and the new one), and let's you merge from one to each other. This thing is that there's no option to save the 'merged file' (there two, actually, since you have both the new-file-edited and the original-file-edited) as *.merged - you can save the old file with its changes, and you can save the new file with its changes, but there's no option to save one of them as *.merged.
Because of this, I can say it's half working. You can use cfg-update with Meld in order to update your files, but since cfg-update will find no .merged file, it will think that no updates were made. |
|
| Back to top |
|
|
xentric
Guru
Joined: 16 Mar 2003
Posts: 410
Location: Netherlands
|
| Posted: Sun Jan 16, 2005 10:05 pm Post subject: |
|
|
| chipi wrote: | So, I went ahead and emerged Meld and cfg-update, and this is the situation:
you can save the old file with its changes, and you can save the new file with its changes, but there's no option to save one of them as *.merged.
Because of this, I can say it's half working. You can use cfg-update with Meld in order to update your files, but since cfg-update will find no .merged file, it will think that no updates were made. |
Ok, cool... thanks for this information! I'm working on version 1.7 at the moment and I'm going
to fix this for you guys.
I want meld to become the default diff/merge tool for systems with gtk and xxdiff for systems
with qt and if neither is installed or wanted (ebuild use flags), it will simply use the interactive
sdiff merge. This way users don't have to install qt on gnome systems, gtk on kde systems
and this also makes it easier to install cfg-update on non-X systems.
Keep an eye on this page, I will probably have it ready in 3-4 days!
_________________
When all else fails, read the manual...
Registered Linux User #340626 |
|
| Back to top |
|
|
Mattwolf7
n00b
Joined: 14 Mar 2004
Posts: 73
|
| Posted: Thu Jan 20, 2005 3:38 pm Post subject: |
|
|
I am having some problems getting cfg-update working with kdm.
I have all of the /root/ files edited but when I run the script it shows the config files then when I hit 'y' to modify them it
| Code: | (1/1) /etc/samba/smb.conf [modified]
Update file : /etc/samba/smb.conf ? [y|n|q|?] y
(GUI tool) : when done, use the save button with the M on it !
(GUI tool) : you have not saved your selections as /etc/samba/smb.conf.merge !
Update cancelled... |
Now looking at my /var/log/kdm.log I see
| Code: | | AUDIT: Thu Jan 20 10:35:53 2005: 8672 X: client 18 rejected from local host |
How do I let kdm realize that I should be able to run apps as root? And this needs to be add to the post.
EDIT: It was working before I started using kdm
Thanks Matt |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Other Things Gentoo
