Re: [gentoo-user] eselect python cleanup
On Sun, 24 Mar 2019 23:12:36 +, Mick wrote: > > > stopped appearing on my "emerge update world" commands. Perhaps you > > > Neil tested further for failure and Jack and I should as well. > > > > No, I tested exactly the same: > > > > emerge world gives warning > > run eselect python cleanup > > emerge world gives warning > > run eselect python cleanup > > emerge world gives no warning > > > > I should have examined /etc/python-exec/python-exec.conf beforehand, > > maybe it included two mentions of python3.4. > > In my case /etc/python-exec/python-exec.conf included python 3.4 and > 3.5, while 'eselect python list' showed them as "(uninstalled)". After > running 'eselect python cleanup' only 3.6 is shown now in > python-exec.conf, although python list also shows 2.7 as a fallback. Both warnings were about python3.4. Looking at a btrfs snapshot from yesterday, I see what happened. python-exec.conf contained python2.7 python3.5 python3.6 python3.4 I only have 2.7 and 3.6 installed. Running eselect clean the first time must have removed only the pythong3.5 entry, hence the identical warning about 3.4, then that entry was removed on the second run. It appears, as suggested elsewhere, that eselect python clean cleans only one entry at a time. -- Neil Bothwick Nobody's perfect and since I'm nobody...! pgpns5T9N5vjT.pgp Description: OpenPGP digital signature
Re: [gentoo-user] eselect python cleanup
On Sunday, 24 March 2019 22:23:40 GMT Neil Bothwick wrote: > On Sun, 24 Mar 2019 17:04:25 -0400, allan gottlieb wrote: > > >> > Am I correct in believing that I should now execute > > >> > > > >> >eselect python cleanup > > >> > > >> I just ran into the same problem, and that solution seems to have > > >> worked for me. > > > > > > It worked for me, but only after I ran it twice. This was > > > reproducible on several systems. > > > > It worked for me running only once on each of two systems. > > By worked I mean the error msg > > > > python-exec: Invalid impl in /etc/python-exec/python-exec.conf: > > python3.4 > > > > stopped appearing on my "emerge update world" commands. Perhaps you > > Neil tested further for failure and Jack and I should as well. > > No, I tested exactly the same: > > emerge world gives warning > run eselect python cleanup > emerge world gives warning > run eselect python cleanup > emerge world gives no warning > > I should have examined /etc/python-exec/python-exec.conf beforehand, > maybe it included two mentions of python3.4. In my case /etc/python-exec/python-exec.conf included python 3.4 and 3.5, while 'eselect python list' showed them as "(uninstalled)". After running 'eselect python cleanup' only 3.6 is shown now in python-exec.conf, although python list also shows 2.7 as a fallback. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] eselect python cleanup
On Sun, 24 Mar 2019 17:04:25 -0400, allan gottlieb wrote: > >> > Am I correct in believing that I should now execute > >> >eselect python cleanup > > > >> I just ran into the same problem, and that solution seems to have > >> worked for me. > > > > It worked for me, but only after I ran it twice. This was > > reproducible on several systems. > > It worked for me running only once on each of two systems. > By worked I mean the error msg > > python-exec: Invalid impl in /etc/python-exec/python-exec.conf: > python3.4 > > stopped appearing on my "emerge update world" commands. Perhaps you > Neil tested further for failure and Jack and I should as well. No, I tested exactly the same: emerge world gives warning run eselect python cleanup emerge world gives warning run eselect python cleanup emerge world gives no warning I should have examined /etc/python-exec/python-exec.conf beforehand, maybe it included two mentions of python3.4. -- Neil Bothwick When puns are outlawed only outlaws will have puns. pgpN6Xs5nmJqi.pgp Description: OpenPGP digital signature
Re: [gentoo-user] eselect python cleanup
On Sun, Mar 24, 2019 at 5:04 PM allan gottlieb wrote: > On Sun, Mar 24 2019, Neil Bothwick wrote: > > > On Sat, 23 Mar 2019 18:08:09 -0400, Jack wrote: > > > >> > Am I correct in believing that I should now execute > >> >eselect python cleanup > > > >> I just ran into the same problem, and that solution seems to have > >> worked for me. > > > > It worked for me, but only after I ran it twice. This was reproducible on > > several systems. > > It worked for me running only once on each of two systems. > By worked I mean the error msg > > python-exec: Invalid impl in /etc/python-exec/python-exec.conf: > python3.4 > > stopped appearing on my "emerge update world" commands. Perhaps you Neil > tested further for failure and Jack and I should as well. > > allan > > I found that each invocation of “eselect python cleanup” cleaned up only one instance of an uninstalled python interpreter. I had 2 such instances on my boxes, so 2 invocations did the trick for me. Cleanup doesn’t (apparently) clean everything up. John Blinka
Re: [gentoo-user] eselect python cleanup
On Sun, Mar 24 2019, Neil Bothwick wrote: > On Sat, 23 Mar 2019 18:08:09 -0400, Jack wrote: > >> > Am I correct in believing that I should now execute >> >eselect python cleanup > >> I just ran into the same problem, and that solution seems to have >> worked for me. > > It worked for me, but only after I ran it twice. This was reproducible on > several systems. It worked for me running only once on each of two systems. By worked I mean the error msg python-exec: Invalid impl in /etc/python-exec/python-exec.conf: python3.4 stopped appearing on my "emerge update world" commands. Perhaps you Neil tested further for failure and Jack and I should as well. allan
Re: [gentoo-user] New network cards default to "Y" with "make oldconfig"
Rich Freeman wrote: > On Sun, Mar 24, 2019 at 3:34 PM Dale wrote: >> Rich Freeman wrote: >>> On Sun, Mar 24, 2019 at 1:02 PM Dale wrote: Rich Freeman wrote: > Suppose you have an Acme model 1234 network card. You've previously > answered Yes to enabling its driver, and No to enabling the Acme model > 2345 card. > > Now a new option comes along to show/hide all the Acme cards. That is > a new option, so it has no existing value as far as the config > database design goes. If you answer No, then you disable your model > 1234 card (without even being asked, because that isn't a new option). > If you answer yes then effectively your previous choices remain in > effect (model 1234 remains enabled, and model 2345 remains disabled). > One would think it should ask if you want any ACME drivers first. If you say yes then ask which ones you want. If you answer no then disable them all and move to the Better-than-nothing drivers next in the list, assuming the are alphabetical. >>> This is exactly what it is doing. There is a new question about >>> whether you want any ACME drivers. It defaults to Yes. If you answer >>> Yes then it prompts you for each individual driver, though it will >>> skip those prompts since you've already answered them. >>> >>> If you answer No then it will set all the individual drivers to No >>> (including the ones you previously set to Yes), and not prompt you >>> further. >>> Once you get past that driver, nothing else should disable the drivers you wanted. >>> But the drivers you wanted WERE Acme drivers, so if you answered No to >>> that question why would it prompt for those? >>> >> The point I was making is once set to yes, then questions after that >> should not go back and disable what you said yes too. If a person goes >> to the trouble of saying yes, then nothing after that should reverse >> that option back to no. From what I understand, if it asks a question >> later on and you say no, it reverses a previous yes even if you want >> that first one included. > The new question comes before the old question in sequence. > > Before the questions were: > > 1. Do you want to install the Acme 1234 driver? > 2. Do you want to install the Acme 2345 driver? > > After the upgrade the questions are: > > 0. Do you want to install any Acme drivers? > 1. Do you want to install the Acme 1234 driver? > 2. Do you want to install the Acme 2345 driver? > > So, if you answer question 0 with a no, then it sets 1/2 to a no as > well. These questions come AFTER question 0, even if you had already > answered them in an earlier kernel version that was missing question > 0. > > Again, I'm not saying it is ideal. However, this is why question 0 > defaults to yes. If you accidentally answer Yes for question 0 when > you intended no, the only effect is asking questions 1/2, which won't > actually get asked since you had previously answered them anyway. > Question 0 doesn't actually change the kernel build - it just controls > whether questions 1/2 get asked, and if you answer it no then it sets > 1/2 to no as well. It is a design compromise so that they didn't have > to rethink the entire kernel config design. > This sounds like one of those situations where there is no ideal method to doing it. If it is done one way, it can cause confusion or a person to think something is enabled when it isn't. If done another way, another group of people are going to be confused. Either way, someone is going to want it another way therefore there is no easy way to do it. Sort of reminds me of six of one, half a dozen of the other. ;-) Unless some code geek can come up with a way to satisfy everyone, some of us are just going to have to get used to it being like it is. Dale :-) :-)
Re: [gentoo-user] New network cards default to "Y" with "make oldconfig"
On Sun, Mar 24, 2019 at 3:34 PM Dale wrote: > > Rich Freeman wrote: > > On Sun, Mar 24, 2019 at 1:02 PM Dale wrote: > >> Rich Freeman wrote: > >>> Suppose you have an Acme model 1234 network card. You've previously > >>> answered Yes to enabling its driver, and No to enabling the Acme model > >>> 2345 card. > >>> > >>> Now a new option comes along to show/hide all the Acme cards. That is > >>> a new option, so it has no existing value as far as the config > >>> database design goes. If you answer No, then you disable your model > >>> 1234 card (without even being asked, because that isn't a new option). > >>> If you answer yes then effectively your previous choices remain in > >>> effect (model 1234 remains enabled, and model 2345 remains disabled). > >>> > >> One would think it should ask if you want any ACME drivers first. If > >> you say yes then ask which ones you want. If you answer no then disable > >> them all and move to the Better-than-nothing drivers next in the list, > >> assuming the are alphabetical. > > This is exactly what it is doing. There is a new question about > > whether you want any ACME drivers. It defaults to Yes. If you answer > > Yes then it prompts you for each individual driver, though it will > > skip those prompts since you've already answered them. > > > > If you answer No then it will set all the individual drivers to No > > (including the ones you previously set to Yes), and not prompt you > > further. > > > >> Once you get past that driver, nothing > >> else should disable the drivers you wanted. > > But the drivers you wanted WERE Acme drivers, so if you answered No to > > that question why would it prompt for those? > > > > The point I was making is once set to yes, then questions after that > should not go back and disable what you said yes too. If a person goes > to the trouble of saying yes, then nothing after that should reverse > that option back to no. From what I understand, if it asks a question > later on and you say no, it reverses a previous yes even if you want > that first one included. The new question comes before the old question in sequence. Before the questions were: 1. Do you want to install the Acme 1234 driver? 2. Do you want to install the Acme 2345 driver? After the upgrade the questions are: 0. Do you want to install any Acme drivers? 1. Do you want to install the Acme 1234 driver? 2. Do you want to install the Acme 2345 driver? So, if you answer question 0 with a no, then it sets 1/2 to a no as well. These questions come AFTER question 0, even if you had already answered them in an earlier kernel version that was missing question 0. Again, I'm not saying it is ideal. However, this is why question 0 defaults to yes. If you accidentally answer Yes for question 0 when you intended no, the only effect is asking questions 1/2, which won't actually get asked since you had previously answered them anyway. Question 0 doesn't actually change the kernel build - it just controls whether questions 1/2 get asked, and if you answer it no then it sets 1/2 to no as well. It is a design compromise so that they didn't have to rethink the entire kernel config design. -- Rich
Re: [gentoo-user] New network cards default to "Y" with "make oldconfig"
Rich Freeman wrote: > On Sun, Mar 24, 2019 at 1:02 PM Dale wrote: >> Rich Freeman wrote: >>> Suppose you have an Acme model 1234 network card. You've previously >>> answered Yes to enabling its driver, and No to enabling the Acme model >>> 2345 card. >>> >>> Now a new option comes along to show/hide all the Acme cards. That is >>> a new option, so it has no existing value as far as the config >>> database design goes. If you answer No, then you disable your model >>> 1234 card (without even being asked, because that isn't a new option). >>> If you answer yes then effectively your previous choices remain in >>> effect (model 1234 remains enabled, and model 2345 remains disabled). >>> >> One would think it should ask if you want any ACME drivers first. If >> you say yes then ask which ones you want. If you answer no then disable >> them all and move to the Better-than-nothing drivers next in the list, >> assuming the are alphabetical. > This is exactly what it is doing. There is a new question about > whether you want any ACME drivers. It defaults to Yes. If you answer > Yes then it prompts you for each individual driver, though it will > skip those prompts since you've already answered them. > > If you answer No then it will set all the individual drivers to No > (including the ones you previously set to Yes), and not prompt you > further. > >> Once you get past that driver, nothing >> else should disable the drivers you wanted. > But the drivers you wanted WERE Acme drivers, so if you answered No to > that question why would it prompt for those? > > You can see how defaulting to No on these sorts of questions can be > more dangerous, because it can cause you to reverse decisions you > previously made, while defaulting to Yes on the big questions (that > don't actually build anything), and defaulting to No on the little > questions (which do build things) has the result that if you accept > all the defaults you keep the same kernel build you had before. > > If you answer Yes to whether you want ACME drivers it won't actually > build any drivers - you have to enable those individually, and those > questions presumably still default to No. > The point I was making is once set to yes, then questions after that should not go back and disable what you said yes too. If a person goes to the trouble of saying yes, then nothing after that should reverse that option back to no. From what I understand, if it asks a question later on and you say no, it reverses a previous yes even if you want that first one included. If nothing else, maybe it should point out a conflict so that a person can check into it further. As with anything tho, if it is done any other way, it to would cause confusion too. This is nothing new really. It's like having a option hidden until you enable some other option in another part of the config screen. You know where the option you want to enable is supposed to be but it is hidden because a option somewhere else isn't enabled. Then you have to find out what to enable so that you can see the one you want. I've ran into that a couple times and it is fun to figure out. lol Dale :-) :-)
Re: [gentoo-user] New network cards default to "Y" with "make oldconfig"
On Sun, Mar 24, 2019 at 1:02 PM Dale wrote: > > Rich Freeman wrote: > > > > Suppose you have an Acme model 1234 network card. You've previously > > answered Yes to enabling its driver, and No to enabling the Acme model > > 2345 card. > > > > Now a new option comes along to show/hide all the Acme cards. That is > > a new option, so it has no existing value as far as the config > > database design goes. If you answer No, then you disable your model > > 1234 card (without even being asked, because that isn't a new option). > > If you answer yes then effectively your previous choices remain in > > effect (model 1234 remains enabled, and model 2345 remains disabled). > > > > One would think it should ask if you want any ACME drivers first. If > you say yes then ask which ones you want. If you answer no then disable > them all and move to the Better-than-nothing drivers next in the list, > assuming the are alphabetical. This is exactly what it is doing. There is a new question about whether you want any ACME drivers. It defaults to Yes. If you answer Yes then it prompts you for each individual driver, though it will skip those prompts since you've already answered them. If you answer No then it will set all the individual drivers to No (including the ones you previously set to Yes), and not prompt you further. > Once you get past that driver, nothing > else should disable the drivers you wanted. But the drivers you wanted WERE Acme drivers, so if you answered No to that question why would it prompt for those? You can see how defaulting to No on these sorts of questions can be more dangerous, because it can cause you to reverse decisions you previously made, while defaulting to Yes on the big questions (that don't actually build anything), and defaulting to No on the little questions (which do build things) has the result that if you accept all the defaults you keep the same kernel build you had before. If you answer Yes to whether you want ACME drivers it won't actually build any drivers - you have to enable those individually, and those questions presumably still default to No. -- Rich
[gentoo-user] Re: Quad UART PCIe Adapter (Oxford-Chipset) seems (not?) to work? Check?
On 2019-03-24, tu...@posteo.de wrote: > Hi, > > In my PC there is a quad uart PCIe-adapter with Oxford Chipset. > With lspci it is listed as: > 04:00.0 Serial controller: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 > UART) function 0 (Uart) > and > 04:00.1 Bridge: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) > function 1 (8bit bus) > > I have a DAUP9-cable, which connects the serial port to the FBUS/MBUS > of my NOKIA 3310 (2001). > > I cannot speak to my NOKI handy via gammu/gnokii: Timeout > > To minimize the number of variables in this equitation I would like to > ensure, that at least the UART adapter is working. > > The modules loaded by now are: [...] > Do I miss a driver? > Is there any kind of check or test (without using another serial > thingy, which I do not have), to test the UART adapter is working as > expected? The output of "lspci -k" is probably useful to check whether the device was picked up by some driver. It will also show drivers which are not modules. Does it show any driver name for that UART controller? -- Nuno Silva
Re: [gentoo-user] Quad UART PCIe Adapter (Oxford-Chipset) seems (not?) to work? Check?
On Sunday, 24 March 2019 17:06:48 GMT k...@aspodata.se wrote: > Meino: > > In my PC there is a quad uart PCIe-adapter with Oxford Chipset. > > ... > > > To minimize the number of variables in this equitation I would like to > > ensure, that at least the UART adapter is working. > > ... > > Try > setserial -g /dev/ttyS? /dev/ttyS1? > and see if it shows up there. > > You can get pin status with > statserial /dev/ttyS9 > > Connect a null modem cable from one port to the next > open two terminals > in first term. do cu -l /dev/ttyS8 -s 9600 > in second term. do cu -l /dev/ttyS9 -s 9600 > or similar, and see if you can talk with yourself. > > Regards, > /Karl Hammar Or you may want to try infrared or bluetooth with gnokii. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] eselect python cleanup
On Sat, 23 Mar 2019 18:08:09 -0400, Jack wrote: > > Am I correct in believing that I should now execute > >eselect python cleanup > I just ran into the same problem, and that solution seems to have > worked for me. It worked for me, but only after I ran it twice. This was reproducible on several systems. -- Neil Bothwick "A hundred years of forgetting and it all comes rushing back..." pgpH79pg7r2dS.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Quad UART PCIe Adapter (Oxford-Chipset) seems (not?) to work? Check?
Meino: > In my PC there is a quad uart PCIe-adapter with Oxford Chipset. ... > To minimize the number of variables in this equitation I would like to > ensure, that at least the UART adapter is working. ... Try setserial -g /dev/ttyS? /dev/ttyS1? and see if it shows up there. You can get pin status with statserial /dev/ttyS9 Connect a null modem cable from one port to the next open two terminals in first term. do cu -l /dev/ttyS8 -s 9600 in second term. do cu -l /dev/ttyS9 -s 9600 or similar, and see if you can talk with yourself. Regards, /Karl Hammar
Re: [gentoo-user] New network cards default to "Y" with "make oldconfig"
Rich Freeman wrote: > On Sun, Mar 24, 2019 at 3:46 AM Peter Humphrey wrote: >> On Sunday, 24 March 2019 01:03:23 GMT Walter Dnes wrote: >>> When setting up a new kernel with "make oldconfig", almost all new >>> device drivers default to "N". The glaring exception is network cards. >>> They all seem to default to "Y". Is this a bug or a "feature"? >> It seems to be just to reveal the individual cards by that manufacturer. I >> don't see why it should differ from any other hardware options. Perhaps it's >> a >> leftover from a day long ago that no-one's thought to change. >> > I suspect it is because these options basically work opposite normal > ones. They're phased as "Do you want to see Acme network cards?" with > a default of Yes. However, they way they effectively work is "Do you > want to disable all Acme network cards?" with a default of No. > > Suppose you have an Acme model 1234 network card. You've previously > answered Yes to enabling its driver, and No to enabling the Acme model > 2345 card. > > Now a new option comes along to show/hide all the Acme cards. That is > a new option, so it has no existing value as far as the config > database design goes. If you answer No, then you disable your model > 1234 card (without even being asked, because that isn't a new option). > If you answer yes then effectively your previous choices remain in > effect (model 1234 remains enabled, and model 2345 remains disabled). > > Now, obviously a more elegant solution would be to look at all the > models of Acme cards in the database and see if you've selected any, > and use that to set the default. However, that would require a change > to how the entire config system works most likely. > > I might have a detail wrong and lkml is definitely where to go for the > full answer, but I suspect this was the rationale behind this design > decision. Those options effectively don't do anything but expose more > options, so defaulting them to Yes probably made more sense, because > defaulting to no would disable anything that depends on them. > > In any case, this is purely an upstream kernel issue, so you can > always try to convince Linus that he has it wrong. :) > One would think it should ask if you want any ACME drivers first. If you say yes then ask which ones you want. If you answer no then disable them all and move to the Better-than-nothing drivers next in the list, assuming the are alphabetical. Once you get past that driver, nothing else should disable the drivers you wanted. That way makes more sense but as you say, that could require some code that is either buggy, difficult to implement or something. That something could include, I never thought of doing it that way. LOL I need to remember to watch out for this when I build a new kernel. I know I'm going to forget tho. :/ Dale :-) :-)
Re: [gentoo-user] New network cards default to "Y" with "make oldconfig"
On Sun, Mar 24, 2019 at 3:46 AM Peter Humphrey wrote: > > On Sunday, 24 March 2019 01:03:23 GMT Walter Dnes wrote: > > When setting up a new kernel with "make oldconfig", almost all new > > device drivers default to "N". The glaring exception is network cards. > > They all seem to default to "Y". Is this a bug or a "feature"? > > It seems to be just to reveal the individual cards by that manufacturer. I > don't see why it should differ from any other hardware options. Perhaps it's a > leftover from a day long ago that no-one's thought to change. > I suspect it is because these options basically work opposite normal ones. They're phased as "Do you want to see Acme network cards?" with a default of Yes. However, they way they effectively work is "Do you want to disable all Acme network cards?" with a default of No. Suppose you have an Acme model 1234 network card. You've previously answered Yes to enabling its driver, and No to enabling the Acme model 2345 card. Now a new option comes along to show/hide all the Acme cards. That is a new option, so it has no existing value as far as the config database design goes. If you answer No, then you disable your model 1234 card (without even being asked, because that isn't a new option). If you answer yes then effectively your previous choices remain in effect (model 1234 remains enabled, and model 2345 remains disabled). Now, obviously a more elegant solution would be to look at all the models of Acme cards in the database and see if you've selected any, and use that to set the default. However, that would require a change to how the entire config system works most likely. I might have a detail wrong and lkml is definitely where to go for the full answer, but I suspect this was the rationale behind this design decision. Those options effectively don't do anything but expose more options, so defaulting them to Yes probably made more sense, because defaulting to no would disable anything that depends on them. In any case, this is purely an upstream kernel issue, so you can always try to convince Linus that he has it wrong. :) -- Rich
Re: [gentoo-user] Genlop problem?
On Sun, 24 Mar 2019 15:48:59 +, Neil Bothwick wrote: > It's been reported and the bug includes a fix. > > https://bugs.gentoo.org/show_bug.cgi?id=677890 I meant, of course, that the bug report includes a fix. The bug is just a bug. I just thought I'd clarify that before one of the list pedants chimes in ;-) -- Neil Bothwick Fragile. Do not turn umop ap1sdn! pgpsVF6Fgtj1p.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Genlop problem?
On Sun, 24 Mar 2019 15:01:11 +0100, Alarig Le Lay wrote: > > Has anyone else noticed that genlop -c duplicates every entry? It's > > been doing that here for some time, on more than one machine. > > I also noticed it, but not dug to know where it comes from. I have some > machines where I still have the clean output. It's been reported and the bug includes a fix. https://bugs.gentoo.org/show_bug.cgi?id=677890 -- Neil Bothwick If at first you don't suceed, try the switch marked "Power" pgp30cqL_mKSB.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: New network cards default to "Y" with "make oldconfig"
* Grant Edwards: > If the old config file didn't have drivers for that vendor enabled, > why should I have to see all the options now? Indeed. There must have been some working network device driver included in the old kernel to get the system running. If one feels the need for additional drivers in the new kernel, enable them manually. -Ralph
[gentoo-user] Re: New network cards default to "Y" with "make oldconfig"
On 2019-03-24, Peter Humphrey wrote: > On Sunday, 24 March 2019 01:03:23 GMT Walter Dnes wrote: >> When setting up a new kernel with "make oldconfig", almost all new >> device drivers default to "N". The glaring exception is network cards. >> They all seem to default to "Y". Is this a bug or a "feature"? > > It seems to be just to reveal the individual cards by that manufacturer. Yes, and that's wrong. The default should be to build a kernel with the same features/drivers as the old .config file. If the old config file didn't have drivers for that vendor enabled, why should I have to see all the options now? > I don't see why it should differ from any other hardware options. > Perhaps it's a leftover from a day long ago that no-one's thought to > change. Unless a new feature is some sort of safety or reliabiliyt fix, it should default to "same as the old .config file". -- Grant
[gentoo-user] Re: New network cards default to "Y" with "make oldconfig"
On 2019-03-24, Andrew Udvare wrote: > > >> On Mar 23, 2019, at 21:03, Walter Dnes wrote: >> >> When setting up a new kernel with "make oldconfig", almost all new >> device drivers default to "N". The glaring exception is network cards. >> They all seem to default to "Y". Is this a bug or a "feature"? > > This has been a 'feature' for a while. I find it very annoying. Extrememly so. -- Grant
[gentoo-user] Quad UART PCIe Adapter (Oxford-Chipset) seems (not?) to work? Check?
Hi, In my PC there is a quad uart PCIe-adapter with Oxford Chipset. With lspci it is listed as: 04:00.0 Serial controller: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 0 (Uart) and 04:00.1 Bridge: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 1 (8bit bus) I have a DAUP9-cable, which connects the serial port to the FBUS/MBUS of my NOKIA 3310 (2001). I cannot speak to my NOKI handy via gammu/gnokii: Timeout To minimize the number of variables in this equitation I would like to ensure, that at least the UART adapter is working. The modules loaded by now are: Module Size Used by vfat 24576 1 fat77824 1 vfat usb_storage57344 1 snd_seq69632 0 snd_seq_device 16384 1 snd_seq nvidia_modeset 1048576 2 iptable_nat16384 0 nf_nat_ipv416384 1 iptable_nat nf_nat 32768 1 nf_nat_ipv4 nf_conntrack 106496 2 nf_nat,nf_nat_ipv4 nf_defrag_ipv6 20480 1 nf_conntrack nf_defrag_ipv4 16384 1 nf_conntrack cdc_subset 16384 0 cdc_eem16384 0 snd_hda_codec_via 24576 1 cdc_ether 16384 0 usbnet 32768 3 cdc_eem,cdc_subset,cdc_ether snd_hda_codec_generic77824 3 snd_hda_codec_via g_ether16384 0 usb_f_rndis24576 1 g_ether snd_hda_intel 32768 1 u_ether20480 2 usb_f_rndis,g_ether snd_hda_codec 110592 3 snd_hda_codec_generic,snd_hda_intel,snd_hda_codec_via libcomposite 53248 2 usb_f_rndis,g_ether udc_core 24576 3 usb_f_rndis,u_ether,libcomposite snd_hwdep 16384 1 snd_hda_codec snd_hda_core 57344 4 snd_hda_codec_generic,snd_hda_intel,snd_hda_codec,snd_hda_codec_via 8250_pci 45056 0 snd_pcm98304 3 snd_hda_intel,snd_hda_codec,snd_hda_core nvidia_uvm823296 0 ohci_pci 16384 0 8250 28672 1 8250_pci xhci_pci 16384 0 ehci_pci 16384 0 ohci_hcd 40960 1 ohci_pci ehci_hcd 57344 1 ehci_pci xhci_hcd 147456 1 xhci_pci snd_timer 32768 2 snd_seq,snd_pcm snd77824 11 snd_hda_codec_generic,snd_seq,snd_seq_device,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_timer,snd_hda_codec_via,snd_pcm 8250_base 36864 2 8250,8250_pci serial_core36864 2 8250,8250_base nvidia_drm 16384 0 nvidia 17129472 102 nvidia_uvm,nvidia_modeset vboxpci28672 0 vboxnetadp 28672 0 vboxnetflt 32768 0 vboxdrv 421888 3 vboxpci,vboxnetadp,vboxnetflt Do I miss a driver? Is there any kind of check or test (without using another serial thingy, which I do not have), to test the UART adapter is working as expected? Any is very appreciated ... thank you very much in advance! Cheers! Meino
Re: [gentoo-user] Genlop problem?
Hello Peter, On dim. 24 mars 13:37:06 2019, Peter Humphrey wrote: > Hello list, > > Has anyone else noticed that genlop -c duplicates every entry? It's been > doing > that here for some time, on more than one machine. I also noticed it, but not dug to know where it comes from. I have some machines where I still have the clean output. -- Alarig
[gentoo-user] Genlop problem?
Hello list, Has anyone else noticed that genlop -c duplicates every entry? It's been doing that here for some time, on more than one machine. -- Regards, Peter.
Re: [gentoo-user] New network cards default to "Y" with "make oldconfig"
On Sunday, 24 March 2019 01:03:23 GMT Walter Dnes wrote: > When setting up a new kernel with "make oldconfig", almost all new > device drivers default to "N". The glaring exception is network cards. > They all seem to default to "Y". Is this a bug or a "feature"? It seems to be just to reveal the individual cards by that manufacturer. I don't see why it should differ from any other hardware options. Perhaps it's a leftover from a day long ago that no-one's thought to change. -- Regards, Peter.
