Re: [gentoo-user] slot conflict for media-libs/x264-0.0
On Monday, 18 June 2018 21:28:38 BST allan gottlieb wrote: > On Mon, Jun 18 2018, Mick wrote: > > Hi Allan, > > > > On Monday, 18 June 2018 18:52:31 BST allan gottlieb wrote: > >> On Sun, Jun 17 2018, Mick wrote: > >> > On Sunday, 17 June 2018 22:04:50 BST allan gottlieb wrote: > >> >> (I have been offline for a few months and apologize if this has been > >> >> covered.) > >> >> > >> >> I had not synced for about 3 months (fear of new, incompatible > >> >> gnucash) > >> >> but have now done so. Unsurprisingly my normal update world shows > >> >> many > >> >> entries and also unsurprising is a blocker (slot conflict). > > > > As a first step I suggest you go through the 'eselect news read new'. > > > > There was a profile change sometime late last year. The profile change > > enews is important and you should deal with it first. It is titled: > > > > 'New 17.0 profiles in the Gentoo repository' > > > > and it involves updating gcc as part of it and perhaps changing your > > profile if it is due to be deprecated. > > I had done the upgrade to 17.0 months ago. > 17.1 is unstable so I believe 17.0 is the right profile for me. > > > Once you've been through all this give it another spin, but use > > --backtrack=99 to see if portage resolves the conflicts. > > backtrack=99 didn't change the situation, but adding in addition > --autounmask-backtrack=y did! Interesting! What did it autounmask? > > I can't see a [B] in the list you provided, all are small blocks [b] which > > portage will deal with on its own. > > The list I provided was for my update world. That has little b's. The > only blockage I have is the slot conflict I mentioned originally. The > big B's happened when I tried > >emerge -1pDv media-video/ffmpeg Well, media-libs/x264-0.0.20130506 is no longer in the tree. media-video/ ffmpeg-3.3.6 does not require it and works fine with media-libs/ x264-0.0.20160712. This is why I suggested that manual removal and update earlier on. Unless something else is blocking ffmpeg (you've got a long update list there which might influence it) there shouldn't be a problem with my suggested workaround. Nevertheless, getting portage to pontificate and resolve the dependency graph is invariably a safer option. ;-) -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: syslog-ng stopped showing kernel messages
On 2018-06-18, Grant Edwards wrote: > For some reason, syslog-ng recently stopped showing kernel messages. > I can't figure out why. I don't rememver ever having klogd running, > nor did I ever touch the default syslog-ng config file. This appears to be a problem with the 4.18-rc1 kernel Dropping back to 4.17 shows kernel messages in /var/log/messages using the default syslog.ng config file just like it always used to. [The 4.18 kernel was built from the .config file that was used for the 4.17 kernel.] -- Grant Edwards grant.b.edwardsYow! at BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI- gmail.com
[gentoo-user] syslog-ng stopped showing kernel messages
For some reason, syslog-ng recently stopped showing kernel messages.
I can't figure out why. I don't rememver ever having klogd running,
nor did I ever touch the default syslog-ng config file.
I tried adding file("/proc/kmsg") to the syslog-ngl.conf file's src()
statement:
source src { system(); internal(); file("/proc/kmsg"); };
That doesn't work -- it appears to read /proc/kmsg once on startup,
then never again.
How does one get syslog-ng to show kernel messages?
--
Grant Edwards grant.b.edwardsYow! Does someone from
at PEORIA have a SHORTER
gmail.comATTENTION span than me?
Re: [gentoo-user] slot conflict for media-libs/x264-0.0
On Mon, Jun 18 2018, Mick wrote: > Hi Allan, > > On Monday, 18 June 2018 18:52:31 BST allan gottlieb wrote: >> On Sun, Jun 17 2018, Mick wrote: >> > On Sunday, 17 June 2018 22:04:50 BST allan gottlieb wrote: >> >> (I have been offline for a few months and apologize if this has been >> >> covered.) >> >> >> >> I had not synced for about 3 months (fear of new, incompatible gnucash) >> >> but have now done so. Unsurprisingly my normal update world shows many >> >> entries and also unsurprising is a blocker (slot conflict). > > As a first step I suggest you go through the 'eselect news read new'. > > There was a profile change sometime late last year. The profile change enews > is important and you should deal with it first. It is titled: > > 'New 17.0 profiles in the Gentoo repository' > > and it involves updating gcc as part of it and perhaps changing your profile > if it is due to be deprecated. I had done the upgrade to 17.0 months ago. 17.1 is unstable so I believe 17.0 is the right profile for me. > Once you've been through all this give it another spin, but use > --backtrack=99 > to see if portage resolves the conflicts. backtrack=99 didn't change the situation, but adding in addition --autounmask-backtrack=y did! > I can't see a [B] in the list you provided, all are small blocks [b] which > portage will deal with on its own. The list I provided was for my update world. That has little b's. The only blockage I have is the slot conflict I mentioned originally. The big B's happened when I tried emerge -1pDv media-video/ffmpeg Thank you again. allan
Re: [gentoo-user] slot conflict for media-libs/x264-0.0
Hi Allan, On Monday, 18 June 2018 18:52:31 BST allan gottlieb wrote: > On Sun, Jun 17 2018, Mick wrote: > > On Sunday, 17 June 2018 22:04:50 BST allan gottlieb wrote: > >> (I have been offline for a few months and apologize if this has been > >> covered.) > >> > >> I had not synced for about 3 months (fear of new, incompatible gnucash) > >> but have now done so. Unsurprisingly my normal update world shows many > >> entries and also unsurprising is a blocker (slot conflict). As a first step I suggest you go through the 'eselect news read new'. There was a profile change sometime late last year. The profile change enews is important and you should deal with it first. It is titled: 'New 17.0 profiles in the Gentoo repository' and it involves updating gcc as part of it and perhaps changing your profile if it is due to be deprecated. Once you've been through all this give it another spin, but use --backtrack=99 to see if portage resolves the conflicts. If it still doesn't, then try updating 10 packages at a time and see if the problem goes away. I can't see a [B] in the list you provided, all are small blocks [b] which portage will deal with on its own. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] slot conflict for media-libs/x264-0.0
On Sun, Jun 17 2018, Mick wrote: > On Sunday, 17 June 2018 22:04:50 BST allan gottlieb wrote: >> (I have been offline for a few months and apologize if this has been >> covered.) >> >> I had not synced for about 3 months (fear of new, incompatible gnucash) >> but have now done so. Unsurprisingly my normal update world shows many >> entries and also unsurprising is a blocker (slot conflict). However, I >> am confused by the message which reads >> >> !!! Multiple package instances within a single package slot have been pulled >> !!! into the dependency graph, resulting in a slot conflict: >> >> media-libs/x264:0 >> >> (media-libs/x264-0.0.20170701:0/152::gentoo, ebuild scheduled for merge) >> pulled in by (no parents that aren't satisfied by other packages in this >> slot) >> >> (media-libs/x264-0.0.20160712:0/148::gentoo, installed) pulled in by >> >> >=media-libs/x264-0.0.20130506:0/148=[abi_x86_64(-)] >> >> required by (media-video/ffmpeg-3.3.6:0/55.57.57::gentoo, installed) >> >> Why is this a conflict since the first one 0/152 seems to permit other >> solutions. Is the (unstated) point that the second one 0/148 is not one >> of the acceptable "other packages in this slot". >> >> Also I seem some advice. Should I be first working on this blockage. >> Or should I instead try to deal with some of the easy updates. >> >> thanks in advance, >> allan > > Since you have the latest ffmpeg installed, this is how I would go about this: > > emerge --depclean -a -v media-libs/x264 > emerge -1aDv '=media-libs/x264-0.0.20170701' > emerge -1aDv media-video/ffmpeg It is apparently more complicated than I expected (at the end of this msg I give the *long* full output of my update world). 1. emerge --depclean -a -v media-libs/x264 will not remove x264 since it is used by ffmpeg and mplayer 2. emerge --depclean -a -v media-libs/x264 shows many blocks (capital B). My attempt at a full update world had the blocks, but with a lower case b) 3. emerge -1aDv media-video/ffmpeg also has many capital B blocks. It seems clear that I erred in not giving the original output. It is almost 50KB so, in addition to appending it to this msg, I have put it on my website https://cs.nyu.edu/~gottlieb/E6430 Thank you, allan These are the packages that would be merged, in reverse order: Calculating dependencies . . done! [nomerge ] gnome-base/gnome-3.24.2 [nomerge ] gnome-base/gnome-extra-apps-3.24.2 [nomerge ] gnome-extra/gnome-user-share-3.18.3 [nomerge ]www-apache/mod_dnssd-0.6-r1 [ebuild U ] net-dns/avahi-0.7-r1 [0.7] USE="qt5%*" [nomerge ] net-print/hplip-3.17.10 [ebuild U ] media-gfx/sane-backends-1.0.27-r1 [1.0.27] [ebuild U ] www-client/firefox-52.8.0 [52.6.0] [ebuild U ] www-client/chromium-67.0.3396.62 [64.0.3282.167] USE="(-system-ffmpeg*)" [ebuild U ] app-portage/elogviewer-2.7-r2 [2.7] [ebuild U ] x11-base/xorg-x11-7.4-r3 [7.4-r2] USE="fonts%*" [ebuild U ] app-office/libreoffice-6.0.3.2 [5.4.5.1] USE="-gtk2%" [nomerge ] gnome-extra/gnome-shell-extensions-3.24.3 [nomerge ] app-eselect/eselect-gnome-shell-extensions-20180306 [20120911] [nomerge ] gnome-base/gnome-shell-3.24.3 [nomerge ]gnome-extra/nm-applet-1.8.10-r1 [1.8.6] USE="gcr*" [nomerge ] net-misc/networkmanager-1.8.4 [ebuild U ] net-wireless/wpa_supplicant-2.6-r6 [2.6-r3] USE="-eapol_test% -privsep%" [nomerge ] x11-drivers/xf86-input-synaptics-1.9.1 [1.9.0] [nomerge ] x11-base/xorg-server-1.19.5-r2 [1.19.5] USE="-kdrive*" [nomerge ] x11-base/xorg-drivers-1.19 [ebuild U ]x11-drivers/xf86-input-evdev-2.10.6 [2.10.5] [ebuild U ]x11-drivers/xf86-video-intel-2.99.917_p20180214-r1 [2.99.917_p20170313] [ebuild U ]x11-drivers/xf86-input-synaptics-1.9.1 [1.9.0] [nomerge ] www-client/firefox-52.8.0 [52.6.0] [nomerge ] virtual/ffmpeg-9-r2 [nomerge ] media-video/ffmpeg-3.3.6 [ebuild U ]media-libs/libsdl2-2.0.8-r1 [2.0.4] USE="(-aqua) -libsamplerate%" [ebuild U ] app-editors/emacs-25.3-r4 [25.3-r1] [nomerge ] gnome-base/gnome-extra-apps-3.24.2 [nomerge ] gnome-extra/gnome-tweak-tool-3.24.1 [nomerge ] gnome-base/gnome-shell-3.24.3 [ebuild U ]gnome-base/gnome-control-center-3.24.4 [3.24.3] [nomerge ] gnome-base/gnome-extra-apps-3.24.2 [nomerge ] media-sound/sound-juicer-3.24.0 [nomerge ] app-cdr/brasero-3.12.2-r1 [ebuild U ]gnome-base/gvfs-1.32.2 [1.32.1-r1] [ebuild U ] sys-process/procps-3.3.15-r1 [3.3.12-r1] [nomerge ] net-print/hplip-3.17.10 [ebuild U ] dev-python/PyQt5-5.9.2 [5.7.1] [ebuild U ] dev-qt/qtbluetooth-5.9.4 [5.7.1] [ebuild U ]dev-qt/qtconcurrent-5.9.4 [5.7.1] [ebuild U ] dev-qt/qtprintsupport-5.9.4 [5.7.1] [ebuild U ] dev-qt/qtopengl-5.9.4 [5.7.1] [ebuild U ]
Re: [gentoo-user] Re: default CONFIG_PROTECT behavior
On Mon, Jun 18, 2018 at 3:27 AM Neil Bothwick wrote: > > There are other config managers that handle this differently, if you > don't like etc-update try another. I tried a few some years ago and > settled on conf-update, others swear by cfg-update. Since nobody else is shilling it, I will. I don't think I could stand Gentoo without cfg-update. When I run Arch in a container it makes me want to port it (maybe Arch has a similar solution - I don't use it enough to know). With the automatic 3-way merges 95% of the time I don't even look at config file changes. If the parts of the files I've customized haven't changed, then the diff gets re-applied. Once in a while I get a merge conflict and then meld pops up showing me a 3-way diff. I'll admit that it has a few issues. One is that it isn't obvious how to handle manual 3-way merges. The right version is the new upstream file. The left version is your current file. The middle is the previous upstream file, so the diffs on the left show what you changed before, and the diffs on the right show what upstream changed. Chances are you'll want to pass through some of those, so just hit all the merge-to-left buttons on those. I usually just save the new file and don't touch the previous two, so that cfg-update correctly saves the original upstream file for re-use. However, perhaps I should be saving a new middle version merged with the upstream. I haven't confirmed exactly how it behaves. Upstream is largely dead on cfg-update, and I'm basically nursing it along since I can't live without it. Feel free to give it a shot. In the beginning it won't be much better than dispatch-conf, until it builds up its library of past changes. Oh, the other tool you'll want to use is etckeeper to manage /etc in a git repo and auto-commit changes/etc with package manager hooks. That is a cross-distro tool, and will save your butt if you mess something up. -- Rich
Re: [gentoo-user] Enable "regular" network traffic when using VPN
On 06/18/2018 04:30 AM, Mick wrote: Hi Grant, Hi Mick, I am not overly familiar with networkmanager and the OP has not shared any screenshots or tab-by-tab NM settings, but had a look on a Gnome desktop and when hovering over the "Use only for resources on this connection" setting in the IPv4 Routes tab, it offers this tip: "If enabled, this connection will never be used as the default network connection." This tip alone hints that enabling it ought to create a split tunnel, for any subnets defined within this tab to be routed via the VPN, but everything else to be routed via the default route. Agreed. When Hilco enabled it he obtained this route table: … The above does not offer him a route into the company's LAN and he cannot connect to the servers *.i.company.com. Small nuance that routes don't deal with names and that names must be translated to IPs. But that does require making sure there are routes to the proper name server to do said translation. When the above setting is left disabled, then Hilco can access the company domain, but not the Internet - a full tunnel. His route table now shows tun0 as being the default NIC: It seems like you're using "full tunnel" to mean that everything is routed through the tunnel. Save for the VPN tunnel traffic itself. I figured that's what you meant, but I wanted to ask and be sure. My understanding of a "split tunnel" or "split horizon" as you call it involves two routes: 1. Route for connections via the VPN tunnel: One route is used to direct datagrams from a local subnet or a virtual VPN IP allocated by the remote VPN gateway, e.g. $SOME_COMPANY_IP_1, via the VPN tunnel (tun0) to the remote company's LAN. 2. Route for all other connections, outside the VPN tunnel: A second route is typically the default route of the PC for all other connections and it is used to route datagrams outside the VPN tunnel. Agreed. Though there may be more routes for additional subnets routed through the VPN. This is what I think Hilco is wanting to do. Some VPN clients add a new routing policy rule table (e.g. strongswan), but others (e.g. racoon) add routes for the VPN tunnel in the main routing policy rule table. I was not aware that any VPNs used alternate routing tables and rules to use them. But that does make sense. Programmatically, that may be simpler to maintain and clean up after the VPN is shut down too. I.e. assume that anything in the routing table is for the VPN and safe to remove, along with the single predictable rule referencing said table. In contrast, a "full tunnel" directs all outgoing datagrams from any local subnet via the VPN. I agree at a high level. The nuanced nitpicks don't matter at this point. I appreciate what I describe above is inverse to what the setting "Use only for resources on this connection" is meant to do, but I merely go by the route tables Hilco has provided. My not-yet-awake brain doesn't see the inverse issue that you're referring to. But I'm used to dealing with VPNs, so maybe something is instinctive for me. Hmm ... prompted by your question in this post I had to give it a second thought, and I've come up with this hypothesis: IF no specific subnet routes are defined on the NM routes tab AND the "Use only for resources on this connection" is selected, then it may be that networkmanager translates no subnet entry to mean 0.0.0.0/0 - ALL routes will be tunneled via the VPN, leaving nothing for the default route. Using a (translated or not) route of "0.0.0.0/0" seems antithetical to "Use only for resources on this connection". Without more information on NM's specific settings I'm not sure why routing is screwed up like this. :-) I don't think it is screwed up. Enabling "Use only for resources on this connection" doesn't change the default route. Disabling "Use only for resources on this connection" does change the default route. It does look like NetworkManager has the concept of additional routes that should be routed through the VPN. However when hovering over the box that I think you enter them in, "Editing IPv4 routes for VPN connection $NAME", I get a tool tip balloon that says "IP addresses identify your computer on the network. Click the Add button to add an IP address.". Which makes one think the dialog box is for enter IP addresses. However I suspect that's an artifact of how the dialog box is constructed and re-using the same code as for entering IPs. The Address, Netmask, Gateway, and Metric fields do sound like routes. Though I question the wisdom of a static gateway in this case verses the tunnel device. Nevertheless, adding a route manually for the remote LAN subnet as per my previous post should deliver a 'split tunnel/horizon', assuming the DNS nameservers are also somehow sorted out. I suspect that the client needs to be directed to use the DNS servers on the corporate LAN and ensure that their
Re: [gentoo-user] Re: default CONFIG_PROTECT behavior
On 06/17/18 15:38, Peter Humphrey wrote: > I don't have any of those problems. I still use etc-update, and if there are > complex updates I edit the original file myself, using the diff as a guide. > > I never did get to grips with the more "modern" ways of doing it. > Same here, I tried dispatch-conf once and was like "WTF is it doing" and went back to etc-update... Dan
Re: [gentoo-user] Enable "regular" network traffic when using VPN
Hi Grant, On Monday, 18 June 2018 03:59:32 BST Grant Taylor wrote: > On 06/17/2018 03:05 PM, Mick wrote: > > TBH I wouldn't select "Use only for resources on this connection", > > I thought "Use only for resources on this connection" would enable (what > I know as) "split horizon", which is what I thought the OP wanted to do. > In other words route company traffic through the VPN and route > everything not to the company via the ISP. I am not overly familiar with networkmanager and the OP has not shared any screenshots or tab-by-tab NM settings, but had a look on a Gnome desktop and when hovering over the "Use only for resources on this connection" setting in the IPv4 Routes tab, it offers this tip: "If enabled, this connection will never be used as the default network connection." This tip alone hints that enabling it ought to create a split tunnel, for any subnets defined within this tab to be routed via the VPN, but everything else to be routed via the default route. When Hilco enabled it he obtained this route table: $ ip route default via 192.168.151.1 dev eth0 proto static metric 100 $SOME_COMPANY_IP_1 dev tun0 proto kernel scope link src $SOME_COMPANY_IP_1 metric 50 127.0.0.0/8 via 127.0.0.1 dev lo 192.168.151.0/24 dev eth0 proto kernel scope link src 192.168.151.103 metric 100 192.168.151.1 dev eth0 proto static scope link metric 100 $VPN_GATEWAY via 192.168.151.1 dev eth0 proto static metric 100 The above does not offer him a route into the company's LAN and he cannot connect to the servers *.i.company.com. When the above setting is left disabled, then Hilco can access the company domain, but not the Internet - a full tunnel. His route table now shows tun0 as being the default NIC: $ ip route default dev tun0 proto static scope link metric 50 default via 192.168.151.1 dev eth0 proto static metric 100 $SOME_COMPANY_IP_2 dev tun0 proto kernel scope link src $SOME_COMPANY_IP_2 metric 50 127.0.0.0/8 via 127.0.0.1 dev lo 192.168.151.0/24 dev eth0 proto kernel scope link src 192.168.151.103 metric 100 192.168.151.1 dev eth0 proto static scope link metric 100 $VPN_GATEWAY via 192.168.151.1 dev eth0 proto static metric 100 > > because this creates a full tunnel. > > What does "full tunnel" mean to you? > > I would think that it's the same tunnel, just different traffic routed > through it. My understanding of a "split tunnel" or "split horizon" as you call it involves two routes: 1. Route for connections via the VPN tunnel: One route is used to direct datagrams from a local subnet or a virtual VPN IP allocated by the remote VPN gateway, e.g. $SOME_COMPANY_IP_1, via the VPN tunnel (tun0) to the remote company's LAN. 2. Route for all other connections, outside the VPN tunnel: A second route is typically the default route of the PC for all other connections and it is used to route datagrams outside the VPN tunnel. Some VPN clients add a new routing policy rule table (e.g. strongswan), but others (e.g. racoon) add routes for the VPN tunnel in the main routing policy rule table. In contrast, a "full tunnel" directs all outgoing datagrams from any local subnet via the VPN. I appreciate what I describe above is inverse to what the setting "Use only for resources on this connection" is meant to do, but I merely go by the route tables Hilco has provided. Hmm ... prompted by your question in this post I had to give it a second thought, and I've come up with this hypothesis: IF no specific subnet routes are defined on the NM routes tab AND the "Use only for resources on this connection" is selected, then it may be that networkmanager translates no subnet entry to mean 0.0.0.0/0 - ALL routes will be tunneled via the VPN, leaving nothing for the default route. Without more information on NM's specific settings I'm not sure why routing is screwed up like this. :-) Nevertheless, adding a route manually for the remote LAN subnet as per my previous post should deliver a 'split tunnel/horizon', assuming the DNS nameservers are also somehow sorted out. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: default CONFIG_PROTECT behavior
On Monday, 18 June 2018 03:35:05 BST Ian Zimmerman wrote: > On 2018-06-17 18:12, Mick wrote: > > From the fine manual: > > z Zap (delete) the new config file and continue. > > So what do you do if the merge of this file is too hard and you want to > do it another time? The answer seems to be q (quit) or n (next), but > _nothing_ in the documentation says this is safe. I see what you mean. The responsibility of not breaking your system, especially in gentoo, belongs to you, but we could all do with a bit of help from the devs. Most of these config file update commands do not tell you if you will be breaking your system when you adopt or reject some new config file content or syntax change, although enotices tend to be informative enough in this respect. Regarding the various options in dispatch-conf, this is my understanding of their relative safety: zap - deletes the new config file with its default content. You can't go back to review it to see what the devs are now proposing/mandating. If the changes between your old config and the newly emerged config are significant, you could have application/system breakage and/or missing functionality since you have not configured it. Applications and daemons you have set to start up in some runlevel can now fail at boot time - e.g. sshd - and leave you stranded. You can still re-emerge the package with --noconfmem to pull in afresh the new config file. quit - will just exit dispatch-conf. The new config files will be available for you to update to, next time you run dispatch-conf, or etc-update. The previous points regarding safety also apply to this action. Some changes in the config file can affect your system, or applications. next - will not deal at all with the current config file, just load the next config file in the queue for you to review. If there is no other config file waiting for an update it will exit dispatch-conf. Next time you run dispatch- conf the file you skipped will be there for you to review. The previous points regarding safety also apply to this action. > > For files which have a lot of changes, some of which I wish to reject > > and some to accept, I tend to use m (for merging). Again from the > > fine manual: > > > > m Interactively merge the current and new config files. > > The problem (or multiple problems) here is that it doesn't say what is > being merged into what (no, its not symmetric), and to compound that it > doesn't just leave this file alone and quit or go on to the next file; > it shows some diff again. What does this new diff mean? I can't make > sense of it without answering my other questions. While you're merging the new config content into your existing, a new temporary merge_file is created, a hybrid of the two. Until you accept it, it will not replace your old config. The second diff that comes up (if you press l) shows the changes you have accepted/rejected. It gives you a chance to change your mind and abort this merge, so you can try it again, or to return another time to review the changes. If you abort the merge_file is deleted. > To clarify: I don't think this is simply a usability problem that can be > addressed by using better or more verbose English. I think there is a > "big picture", a concept of what is being done, and this concept has not > found its way into the documentation or the UI itself. > > In particular, I suspect the developers think of it as merging my mods > into the "official" packaged versions, while I want to handle it the > other way: I see my version as the "master" or "trunk", and I want to > merge the package mods into it. > > But I really don't know. I am confused :-P I'm not sure if this is how the devs have been thinking config file updates are meant to be handled, but TBH I can't see much of a difference in the concept. When you use m to merge the files, left is your own/old configuration settings and right is the devs default settings. Until you accept/reject all or some of these your own config file stays as is. I haven't found a major difference between dispatch-conf and etc-update in their usage, the former uses letters, the latter numbers in their menu of actions. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: default CONFIG_PROTECT behavior
On Sun, 17 Jun 2018 19:35:05 -0700, Ian Zimmerman wrote: > The problem (or multiple problems) here is that it doesn't say what is > being merged into what (no, its not symmetric), and to compound that it > doesn't just leave this file alone and quit or go on to the next file; > it shows some diff again. What does this new diff mean? I can't make > sense of it without answering my other questions. > > To clarify: I don't think this is simply a usability problem that can be > addressed by using better or more verbose English. I think there is a > "big picture", a concept of what is being done, and this concept has not > found its way into the documentation or the UI itself. There are other config managers that handle this differently, if you don't like etc-update try another. I tried a few some years ago and settled on conf-update, others swear by cfg-update. conf-update lets you configure the diff and merge programs it uses but I stuck with the defaults except for using colordiff. Merging is interactive so you can choose whether you accept your old setting or the new default for each change. Like you, I treat my settings as the default and generally only merge in new additions to the config or changed defaults. -- Neil Bothwick Microbiology: staph only. pgpj_gSbM912_.pgp Description: OpenPGP digital signature
