Re: [gentoo-user] Browsers cannot access WWW while ping and host utilities work as expected.
I somehow missed this post, so excuse me for the late reply. 2013/8/5 Mick michaelkintz...@gmail.com: On Monday 05 Aug 2013 07:06:08 gevisz wrote: My thanks to all who replied to my question. The problem was with my local router, which I also used as DNS. After excluding it from /etc/resolv.config and /etc/init.d/net files, Firefox started to work as expected. Hmm ... I wonder if this is related to my earlier comment about malformed packets. Somewhere, you hinted that the problem may be with the routers and suggested to experiment with it. Before that, I strongly believed that, if I listed 3 different routers in my resolv.conf, the system should proceed with the next router if something is wrong with the previous one, but unfortunately it did not. The response of the first router contained an error that prevented all the other applications to use it, the system knew about it (for example from the output of the host utility) but, nevertheless did not proceeded with the next router listed in resolv.conf. I do undersand that this may be because of the layered structure of the networked software. But, nevertheless, I think that something is fundamentally wrong with this. Once more, thank you for your help. A few following remarks are minor and so, you can stop your reading here. May be worth trying a different firmware for this router. I have already changed the firmware after purchasing it but now I cannot afford it as I need its uninterupted functioning. Suggestions of Michael Kintzios This is the new kernel naming scheme of NICs. Which-ever nomenclature you decide to use, check that that's the only one having a symlink in /etc/init.d to net.lo Yes, there is only enp2s15 links to lo in /etc/init.d The idea here is that you need consistent naming of your iface. If you have settled on the kernel naming of enp2s15, then stick with this throughout your configuration. Yes, I did. After deleting all but my lan router DNS from /etc/conf.d/net and /etc/resolv.conf files, I had the same problem as before but, in addition, the host utility reports an additional error. Please, see the full response below. You should not need to manually alter anything in your /etc/resolv.conf, which will be completed with the DNS server name(s) you have set up in your /etc/conf.d/net. Actually, I changed it in both files simultaneously, but -- as I have already explained it above, yes, I should not do it but had to. :^) # host www.google.com www.google.com has address 74.125.232.52 www.google.com has address 74.125.232.48 www.google.com has address 74.125.232.49 www.google.com has address 74.125.232.50 www.google.com has address 74.125.232.51 ;; Warning: query response not set ;; Warning: query response not set I think this means that the DNS server response is incorrectly formed (or that the server respond code does not include a 4 bit RCODE as it should - more detail for DNS geeks can be found here: http://www.ietf.org/rfc/rfc2136.txt) Thank you, for the referrence. I will study it later. Host www.google.com not found: 4(NOTIMP) The RFC says: The name server does not support the specified Opcode. I would reflash the firmware, or try any OpenSource alternatives if available for your router. It is a small router device. I have already changed its firmware after purchasing it to a newer one. I do not know if its open source alternative exists and, anyway, I cannot change it now because I cannot afford any interruption of the router functioning. After leaving in /etc/conf.d/net and /etc/resolv.conf files only the DNS of my service provider, Firefox started to work as predicted. Thank you! This may not be ideal (it will introduce some latency in your requests) but if you can't fix your router, it'll have to do for now. Can you please show us: ip route show ip addr show ip link show $ ip route show default via 192.168.0.1 dev enp2s15 metric 2 127.0.0.0/8 via 127.0.0.1 dev lo scope link 192.168.0.0/24 dev enp2s15 proto kernel scope link src 192.168.0.9 This says that your IP address us 192.168.0.9, but see below. $ ip addr show [snip ...] 2: enp2s15: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether MAC_address_of_my_Ethernet_card brd ff:ff:ff:ff:ff:ff inet 192.168.0.7/24 brd 192.168.0.255 scope global enp2s15 This says that your ip address is 192.168.0.7 - did you get a different IP address between the two commands? Your /etc/conf.d/net showed that you had set up a static address as config_enp2s15=192.168.0.9 ... so why is this here? Sorry, it happened only because of my stupid attempt to eliminate all the real IP addresses... $ ip link show [snip ...] 2: enp2s15: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000 link/ether MAC_address_of_my_Ethernet_card brd ff:ff:ff:ff:ff:ff OK, this looks good. Suggestions of Kurian
Re: [gentoo-user] about LIBRARY_PATH
On 12/08/13 05:49, 东方巽雷 wrote: It seems that this variable is hard-code by gcc.I cannot change it any more.When I use gcc -m32 to compile a 32bit program,gcc is looking for /usr/lib rather than /usr/lib32.But in my system,/usr/lib is a symlink to /usr/lib64.The real 32bit librarys is in /usr/lib32.The linker is always complaining about i386:x86-64 architecture of input file `/usr/lib/gcc/x86_64-pc-linux-gnux32/4.7.3/../../../../lib/crt1.o' is You have a x32 system? incompatible with i386 output..Why does it not search /usr/lib32?
Re: [gentoo-user] Browsers cannot access WWW while ping and host utilities work as expected.
On 12/08/2013 09:13, gevisz wrote: The response of the first router contained an error that prevented all the other applications to use it, the system knew about it (for example from the output of the host utility) but, nevertheless did not proceeded with the next router listed in resolv.conf. I do undersand that this may be because of the layered structure of the networked software. But, nevertheless, I think that something is fundamentally wrong with this. What kind of error did you get? If complete garbage came back, I'm not sure what the resolver does with that (oddly enough, I never tested that) The more usual case is you get a proper DNS result of NXDOMAIN which indicates the query is valid, but the entry is not in DNS. It's pointless trying another cache as per DNS, they should all then return that result. This is why the router did not try the other entries in resolv.conf - that usually only happens when a cache does not respond. So the behaviour you saw is probably correct albeit not the behaviour you wanted. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Moving from old udev to eudev
On 2013-08-11 2:38 PM, Samuli Suominen ssuomi...@gentoo.org wrote: On 11/08/13 21:13, Neil Bothwick wrote: There was a blocker (small b) because virtual/udev needed sys-fs/udev and that gave a blocker that uninstalled eudev. I believe it's 'b' if user doesn't have sys-fs/eudev in /var/lib/portage/world, but 'B' if he does As in, difference is soft and hard blocker depending if the wanted implementation is recorded in the world file or not Well, in my opinion, that just seems wrong. Why does it prefer udev, if *neither* is in the world file? In my opinion, it should be a 'B' blocker in both cases. It absolutely should not automatically uninstall eudev and install udev, potentially leaving the system in an unbootable state. But... as long as the conflict is there (for those who actually look for such things) and I can deal with it appropriately - ie, if a small b blocker and it wants to remove eudev and install udev, I just wait until ... Hmmm... so is it eudev that would need to be updated to 'fix' this? Or virtual/udev? Or both?
SOLVED: Re: [gentoo-user] Question re: make.conf/profile location change
On 2013-08-11 1:48 PM, Marc Joliet mar...@gmx.de wrote: Am Sun, 11 Aug 2013 13:30:57 -0400 schrieb Tanstaafl tansta...@libertytrek.org: I just tried changing it eselect profile set 3 eselect profile set 1 and it didn't create the link in /etc/portage, it is still in /etc... Ah, then it *preserves* the current location. I have it in /etc/portage and eselect profile kept it there, too. However, I just checked and if you delete make.profile and then re-create it with eselect profile it is created in /etc/portage. So, to do this manually just: ~ ln -s make.profile /usr/portage/profiles/default/linux/amd64/13.0 ~ rm /etc/make.profile I guess so. Or rm /etc/make.profile eselect profile set whatever as described above. Ok, thanks all, makes sense now...
Re: [gentoo-user] Question re: make.conf/profile location change
Am Sun, 11 Aug 2013 21:29:41 +0200
schrieb Alan McKinnon alan.mckin...@gmail.com:
[...]
No. That links a file in /etc/portage to something that doesn't exist
(arguments wrong way round), and the .. parent directory doesn't belong
there at all:
cd /etc/portage
ln -s $POSTDIR/profiles/path/to/profile/you/want profile.conf
[...]
new overrides old in this case
Damn, you would think ln -s ${TARGET} ${NEWFILE} would be easily remembered as
link to target via new file, but no, I keep forgetting :( .
[Perhaps because the first (wrong) mnemonic I usually think of is link target
to new file, which is backwards, because you're linking the new file to the
target. Maybe I've been confusing myself that way ;) .]
--
Marc Joliet
--
People who think they know everything really annoy those of us who know we
don't - Bjarne Stroustrup
signature.asc
Description: PGP signature
Re: [gentoo-user] Moving from old udev to eudev
On 12/08/2013 12:19, Tanstaafl wrote: On 2013-08-11 2:38 PM, Samuli Suominen ssuomi...@gentoo.org wrote: On 11/08/13 21:13, Neil Bothwick wrote: There was a blocker (small b) because virtual/udev needed sys-fs/udev and that gave a blocker that uninstalled eudev. I believe it's 'b' if user doesn't have sys-fs/eudev in /var/lib/portage/world, but 'B' if he does As in, difference is soft and hard blocker depending if the wanted implementation is recorded in the world file or not Well, in my opinion, that just seems wrong. Why does it prefer udev, if *neither* is in the world file? In my opinion, it should be a 'B' blocker in both cases. It absolutely should not automatically uninstall eudev and install udev, potentially leaving the system in an unbootable state. But... as long as the conflict is there (for those who actually look for such things) and I can deal with it appropriately - ie, if a small b blocker and it wants to remove eudev and install udev, I just wait until ... Hmmm... so is it eudev that would need to be updated to 'fix' this? Or virtual/udev? Or both? It has to do with how virtuals work. If you have the virtual in @world, and none of the packages that satisfy the virtual are in world, then portage is free to do whatever it deems correct to satisfy the virtual. This is what it did, and it is rather important you understand why this is so. If you have the virtual in world, and one of the packages that satisfy the virtual are in world, then portage will not uninstall that package and instead obey your instruction. Portage does not work according to whatever we think ought to be logical. Portage works according to the PMS spec. In this case, it did what you asked, which is not what you wanted. -- Alan McKinnon alan.mckin...@gmail.com
Re: SOLVED: Re: [gentoo-user] Question re: make.conf/profile location change
On 12/08/2013 12:21, Tanstaafl wrote: On 2013-08-11 1:48 PM, Marc Joliet mar...@gmx.de wrote: Am Sun, 11 Aug 2013 13:30:57 -0400 schrieb Tanstaafl tansta...@libertytrek.org: I just tried changing it eselect profile set 3 eselect profile set 1 and it didn't create the link in /etc/portage, it is still in /etc... Ah, then it *preserves* the current location. I have it in /etc/portage and eselect profile kept it there, too. However, I just checked and if you delete make.profile and then re-create it with eselect profile it is created in /etc/portage. So, to do this manually just: ~ ln -s make.profile /usr/portage/profiles/default/linux/amd64/13.0 ~ rm /etc/make.profile I guess so. Or rm /etc/make.profile eselect profile set whatever as described above. Ok, thanks all, makes sense now... Please read the man page for ln. You have the arguments in reverse. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Moving from old udev to eudev
On 12/08/13 13:19, Tanstaafl wrote: On 2013-08-11 2:38 PM, Samuli Suominen ssuomi...@gentoo.org wrote: On 11/08/13 21:13, Neil Bothwick wrote: There was a blocker (small b) because virtual/udev needed sys-fs/udev and that gave a blocker that uninstalled eudev. I believe it's 'b' if user doesn't have sys-fs/eudev in /var/lib/portage/world, but 'B' if he does As in, difference is soft and hard blocker depending if the wanted implementation is recorded in the world file or not Well, in my opinion, that just seems wrong. Why does it prefer udev, if *neither* is in the world file? Because it's the default in virtual/udev (/usr/portage/virtual/udev/udev-206-r2.ebuild) As in, sys-fs/udev is the default of Gentoo In my opinion, it should be a 'B' blocker in both cases. It absolutely should not automatically uninstall eudev and install udev, potentially leaving the system in an unbootable state. Portage doesn't work like that. If you step outside of the defaults, you need to record them in your world. It's sort of the logical step to do. But... as long as the conflict is there (for those who actually look for such things) and I can deal with it appropriately - ie, if a small b blocker and it wants to remove eudev and install udev, I just wait until ... Hmmm... so is it eudev that would need to be updated to 'fix' this? Or virtual/udev? Or both? When new version of sys-fs/udev is released with incompabilities with sys-fs/eudev, then new virtual version is created and dependencies inside of it set to compatible versions And if there is no compatible version available, then the version is set to non-existing future-version number that /will be/ compatible with it Which is exactly what happened earlier and will happen again - Samuli
Re: [gentoo-user] Moving from old udev to eudev
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/02/2013 05:01 AM, Samuli Suominen wrote: On 02/08/13 05:48, Dale wrote: Samuli Suominen wrote: Huh? USE=firmware-loader is optional and enabled by default in sys-fs/udev Futhermore predictable network interface names work as designed, not a single valid bug filed about them. Stop spreading FUD. Looking forward to lastrite sys-fs/eudev just like sys-apps/module-init-tools already was removed as unnecessary later on. So your real agenda is to kill eudev? Maybe it is you that is spreading FUD instead of others. Like others have said, udev was going to cause issues, eudev has yet to cause any. Yes, absolutely sys-fs/eudev should be punted from tree since it doesn't bring in anything useful, and it reintroduced old bugs from old version of udev, as well as adds confusing to users. And no, sys-fs/udev doesn't have issues, in fact, less than what sys-fs/eudev has. Like said earlier, the bugs assigned to udev-bugs@g.o apply also to sys-fs/eudev and they have even more in their github ticketing system. And sys-fs/udev maintainers have to constantly monitor sys-fs/eudev so it doesn't fall too much behind, which adds double work unnecessarily. They don't keep it up-to-date on their own without prodding. Really, this is how it has went right from the start and the double work and user confusion needs to stop. - Samuli * you are not telling the whole story about what happened and why the fork came into life in the first place. It's not as simple as you seem to suggest. There were good reasons at that point. Some changes were merged by udev upstream and there are still more differences than you point out. That has been discussed numerous of times. * claiming that eudev didn't improve anything is wrong and can be proven * that eudev is behind udev most of the time is correct * that it causes tons of breakage for users... well, I don't know, not for me since almost the beginning * eudev will not be treecleaned until the gentoo devs who maintain it agree (at best, it may be masked) and even if eudev will be obsolete at some point, then it has been a success * I don't understand why you add those rants all over different mailing lists. I have seen it numerous of times and your precision about explaining the situation does not improve. If you think that people need to be warned about eudev, then you should provide a reason to mask it or drop it back to ~arch. Anything else is not constructive and causes confusion. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSCMjkAAoJEFpvPKfnPDWz4/cH/1k5tyYetIZp0t+5BE2ytCFS 0FldL3IxIbOe16rfNP9LH5yqe/RnhabUbeja//rqhmMTeDGEEGbM/YgY6Tqo4q6Y usUQueYpwsVFAL9AL93+CLyQMC3cS6F1EFBeP98vcvErqHFPu9N/k2CXCQTWVlbe Vnbb+X9m2enso1rvSm/MBjtykJRzLw+Mq6gdVS9Pthb+UU78dX109z1Xtt9pSrUB Fa/NLvmQELu5QOb3+m6XXas8SoXUgjvKZ3xGgRjVmeCITBpjfsIf4KdvW0gqzOdE XjuIlNMPpLMZiWDV8yYMq2OVzRDwm8jTvSG/S4j45rHmBvTZj6km8979HAihtaQ= =Gnsu -END PGP SIGNATURE-
Re: [gentoo-user] Moving from old udev to eudev
On 2013-08-12 6:48 AM, Alan McKinnon alan.mckin...@gmail.com wrote: On 12/08/2013 12:19, Tanstaafl wrote: Hmmm... so is it eudev that would need to be updated to 'fix' this? Or virtual/udev? Or both? It has to do with how virtuals work. If you have the virtual in @world, and none of the packages that satisfy the virtual are in world, then portage is free to do whatever it deems correct to satisfy the virtual. This is what it did, and it is rather important you understand why this is so. If you have the virtual in world, and one of the packages that satisfy the virtual are in world, then portage will not uninstall that package and instead obey your instruction. Ok, I'm getting there... I just confirmed that while I do have sys-fs/udev in world, but I *do* have virtual/udev. So, based on what Samuli said about sys-fs/udev being the gentoo default (where is this documented by the way?), seems the simplest thing to do is add sys-fs/eudev to @world, but is this really the most appropriate 'gentoo way'? Or, maybe just remove virtual/udev from @world? Or both (add sys-fs/eudev, remove virtual/udev)? Actually, since udev/eudev are more appropriately @system packages, it would make more sense to add them there - except @system is defined not by a file but by the profile, and so would require a USE flag to define this, but if I recall, adding a USE flag for this was decided against (why I don't know)...
Re: SOLVED: Re: [gentoo-user] Question re: make.conf/profile location change
On 2013-08-12 6:48 AM, Alan McKinnon alan.mckin...@gmail.com wrote: On 12/08/2013 12:21, Tanstaafl wrote: So, to do this manually just: ~ ln -s make.profile /usr/portage/profiles/default/linux/amd64/13.0 Please read the man page for ln. You have the arguments in reverse. Yeah, already noticed that, thanks... :)
Re: [gentoo-user] Moving from old udev to eudev
On 2013-08-12 7:37 AM, Tanstaafl tansta...@libertytrek.org wrote: I just confirmed that while I do have sys-fs/udev in world, but I *do* have virtual/udev. Crap... I meant I do NOT have sys-fs/eudev (or sys-fs/udev) in @world...
Re: [gentoo-user] Moving from old udev to eudev
On 12/08/13 14:37, hasufell wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/02/2013 05:01 AM, Samuli Suominen wrote: On 02/08/13 05:48, Dale wrote: Samuli Suominen wrote: Huh? USE=firmware-loader is optional and enabled by default in sys-fs/udev Futhermore predictable network interface names work as designed, not a single valid bug filed about them. Stop spreading FUD. Looking forward to lastrite sys-fs/eudev just like sys-apps/module-init-tools already was removed as unnecessary later on. So your real agenda is to kill eudev? Maybe it is you that is spreading FUD instead of others. Like others have said, udev was going to cause issues, eudev has yet to cause any. Yes, absolutely sys-fs/eudev should be punted from tree since it doesn't bring in anything useful, and it reintroduced old bugs from old version of udev, as well as adds confusing to users. And no, sys-fs/udev doesn't have issues, in fact, less than what sys-fs/eudev has. Like said earlier, the bugs assigned to udev-bugs@g.o apply also to sys-fs/eudev and they have even more in their github ticketing system. And sys-fs/udev maintainers have to constantly monitor sys-fs/eudev so it doesn't fall too much behind, which adds double work unnecessarily. They don't keep it up-to-date on their own without prodding. Really, this is how it has went right from the start and the double work and user confusion needs to stop. - Samuli * you are not telling the whole story about what happened and why the fork came into life in the first place. It's not as simple as you seem True, I didn't mention people were needlessly unwilling to join the Gentoo udev team despite being invited to. to suggest. There were good reasons at that point. Some changes were merged by udev upstream and there are still more differences than you point out. That has been discussed numerous of times. * claiming that eudev didn't improve anything is wrong and can be proven I can easily prove eudev is nothing but udev and deleted code, plus restored broken 'rule generator', plus useless kept static nodes creation which was moved to kmod, plus needlessly changed code for uclibc support -- uclibc now has the functions udev needs. * that eudev is behind udev most of the time is correct * that it causes tons of breakage for users... well, I don't know, not for me since almost the beginning * eudev will not be treecleaned until the gentoo devs who maintain it agree (at best, it may be masked) and even if eudev will be obsolete at some point, then it has been a success * I don't understand why you add those rants all over different mailing lists. I have seen it numerous of times and your precision about explaining the situation does not improve. If you think that people need to be warned about eudev, then you should provide a reason to mask it or drop it back to ~arch. Anything else is not constructive and causes confusion. True, it won't be dropped for long as people are maintaining it. That's how maintainership works. But trying to lie to people it's somehow solving something currently is annoying as 'ell and should be corrected where seen. - Samuli
Re: [gentoo-user] Moving from old udev to eudev
On 2013-08-12 8:06 AM, Samuli Suominen ssuomi...@gentoo.org wrote: True, it won't be dropped for long as people are maintaining it. That's how maintainership works. But trying to lie to people it's somehow solving something currently is annoying as 'ell and should be corrected where seen. It is solving the problem of *when* (not if - if the words I have read from the systemd maintainers can be taken at face value) the systemd maintainers decide to pull the plug on the ability to have a systemd-less udev...
Re: [gentoo-user] Moving from old udev to eudev
On Mon, Aug 12, 2013 at 3:17 PM, Tanstaafl tansta...@libertytrek.org wrote: On 2013-08-12 8:06 AM, Samuli Suominen ssuomi...@gentoo.org wrote: True, it won't be dropped for long as people are maintaining it. That's how maintainership works. But trying to lie to people it's somehow solving something currently is annoying as 'ell and should be corrected where seen. It is solving the problem of *when* (not if - if the words I have read from the systemd maintainers can be taken at face value) the systemd maintainers decide to pull the plug on the ability to have a systemd-less udev... Correct. And because that we endorse it. Look what happened with the logind.
Re: [gentoo-user] Moving from old udev to eudev
On 12/08/2013 13:37, Tanstaafl wrote: On 2013-08-12 6:48 AM, Alan McKinnon alan.mckin...@gmail.com wrote: On 12/08/2013 12:19, Tanstaafl wrote: Hmmm... so is it eudev that would need to be updated to 'fix' this? Or virtual/udev? Or both? It has to do with how virtuals work. If you have the virtual in @world, and none of the packages that satisfy the virtual are in world, then portage is free to do whatever it deems correct to satisfy the virtual. This is what it did, and it is rather important you understand why this is so. If you have the virtual in world, and one of the packages that satisfy the virtual are in world, then portage will not uninstall that package and instead obey your instruction. Ok, I'm getting there... I just confirmed that while I do have sys-fs/udev in world, but I *do* have virtual/udev. So, based on what Samuli said about sys-fs/udev being the gentoo default (where is this documented by the way?), seems the simplest thing to do is add sys-fs/eudev to @world, but is this really the most appropriate 'gentoo way'? Or, maybe just remove virtual/udev from @world? Or both (add sys-fs/eudev, remove virtual/udev)? Actually, since udev/eudev are more appropriately @system packages, This is incorrect. @system is the minimal set of packages for a Gentoo system to work at all, and consists mostly of baselayout, toolchain and various packages used by the toolchain. A Gentoo system does NOT have to have a device manager to function, you can accomplish that easily with static device nodes. What is in @system is virtual/dev-manager which has this RDEPEND: RDEPEND=|| ( virtual/udev sys-apps/busybox[mdev] sys-fs/devfsd sys-fs/static-dev sys-freebsd/freebsd-sbin ) So you are free to install any of those methods you choose and thereby have working device nodes. To back up what Samuli said, if you want to GUARANTEE a certain device manager then you need to put it in @world, just like you already do for all the other packages you have. udev is in no way special in this regard. it would make more sense to add them there - except @system is defined not by a file but by the profile, and so would require a USE flag to define this, but if I recall, adding a USE flag for this was decided against (why I don't know)... -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] about LIBRARY_PATH
I think the gcc version with x32 abi is faster.So I install a x32 version on amd64.Now I have solved my problem by creating a new gcc specs file.Thank you all the same. 2013/8/12 Samuli Suominen ssuomi...@gentoo.org On 12/08/13 05:49, 东方巽雷 wrote: It seems that this variable is hard-code by gcc.I cannot change it any more.When I use gcc -m32 to compile a 32bit program,gcc is looking for /usr/lib rather than /usr/lib32.But in my system,/usr/lib is a symlink to /usr/lib64.The real 32bit librarys is in /usr/lib32.The linker is always complaining about i386:x86-64 architecture of input file `/usr/lib/gcc/x86_64-pc-linux-**gnux32/4.7.3/../../../../lib/**crt1.o' is You have a x32 system? incompatible with i386 output..Why does it not search /usr/lib32?
Re: [gentoo-user] Moving from old udev to eudev
On 12/08/13 15:17, Tanstaafl wrote: On 2013-08-12 8:06 AM, Samuli Suominen ssuomi...@gentoo.org wrote: True, it won't be dropped for long as people are maintaining it. That's how maintainership works. But trying to lie to people it's somehow solving something currently is annoying as 'ell and should be corrected where seen. It is solving the problem of *when* (not if - if the words I have read from the systemd maintainers can be taken at face value) the systemd maintainers decide to pull the plug on the ability to have a systemd-less udev... Then we will carry a minimal patchset on top of sys-fs/udev that will keep it working without systemd for long as it's sustainable. And at this point it's pointless to talk of forking yet, it should be done only when it's required. - Samuli
Re: [gentoo-user] Moving from old udev to eudev
On Mon, Aug 12, 2013 at 3:33 PM, Samuli Suominen ssuomi...@gentoo.org wrote: On 12/08/13 15:17, Tanstaafl wrote: On 2013-08-12 8:06 AM, Samuli Suominen ssuomi...@gentoo.org wrote: True, it won't be dropped for long as people are maintaining it. That's how maintainership works. But trying to lie to people it's somehow solving something currently is annoying as 'ell and should be corrected where seen. It is solving the problem of *when* (not if - if the words I have read from the systemd maintainers can be taken at face value) the systemd maintainers decide to pull the plug on the ability to have a systemd-less udev... Then we will carry a minimal patchset on top of sys-fs/udev that will keep it working without systemd for long as it's sustainable. And at this point it's pointless to talk of forking yet, it should be done only when it's required. It is done ahead so it won't be too late, as you say... eudev is minimal patch set over systemd. Someone should have forked the logind as well ahead, so the whole gmone discussion was irrelevant.
Re: [gentoo-user] Moving from old udev to eudev
On 12/08/13 15:19, Alon Bar-Lev wrote: On Mon, Aug 12, 2013 at 3:17 PM, Tanstaafl tansta...@libertytrek.org wrote: On 2013-08-12 8:06 AM, Samuli Suominen ssuomi...@gentoo.org wrote: True, it won't be dropped for long as people are maintaining it. That's how maintainership works. But trying to lie to people it's somehow solving something currently is annoying as 'ell and should be corrected where seen. It is solving the problem of *when* (not if - if the words I have read from the systemd maintainers can be taken at face value) the systemd maintainers decide to pull the plug on the ability to have a systemd-less udev... Correct. And because that we endorse it. Look what happened with the logind. They made it clear from the start that logind is not going to work for non-systemd and that Ubuntu is doing something utter crazy. We were going to ride with that horse at the expense of Ubuntu folks for a while, but dropped the effort as futile. Now Ubuntu is stuck at logind-204 and it's unclear what will they do next. Don't try to twist it into anything it's not, it's not comparable w/ udev.
Re: [gentoo-user] Moving from old udev to eudev
On 12/08/13 15:38, Alon Bar-Lev wrote: On Mon, Aug 12, 2013 at 3:33 PM, Samuli Suominen ssuomi...@gentoo.org wrote: On 12/08/13 15:17, Tanstaafl wrote: On 2013-08-12 8:06 AM, Samuli Suominen ssuomi...@gentoo.org wrote: True, it won't be dropped for long as people are maintaining it. That's how maintainership works. But trying to lie to people it's somehow solving something currently is annoying as 'ell and should be corrected where seen. It is solving the problem of *when* (not if - if the words I have read from the systemd maintainers can be taken at face value) the systemd maintainers decide to pull the plug on the ability to have a systemd-less udev... Then we will carry a minimal patchset on top of sys-fs/udev that will keep it working without systemd for long as it's sustainable. And at this point it's pointless to talk of forking yet, it should be done only when it's required. It is done ahead so it won't be too late, as you say... eudev is minimal patch set over systemd. Someone should have forked the logind as well ahead, so the whole gmone discussion was irrelevant. It's not too late to fork logind in anyway, it's down to 204 in git and then review commits from there up to current w/ the required patches Ubuntu carries for non-systemd operation (yes, logind from 204 never worked without patching either but the patches were just a lot less than what 206 would need). But nobody has been willing to do the work. It was propably for the best we didn't ever adopt it at all since it's not sane to package software you can't then keep maintained. - Samuli
Re: [gentoo-user] Moving from old udev to eudev
On 08/12/2013 02:06 PM, Samuli Suominen wrote: On 12/08/13 14:37, hasufell wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/02/2013 05:01 AM, Samuli Suominen wrote: On 02/08/13 05:48, Dale wrote: Samuli Suominen wrote: Huh? USE=firmware-loader is optional and enabled by default in sys-fs/udev Futhermore predictable network interface names work as designed, not a single valid bug filed about them. Stop spreading FUD. Looking forward to lastrite sys-fs/eudev just like sys-apps/module-init-tools already was removed as unnecessary later on. So your real agenda is to kill eudev? Maybe it is you that is spreading FUD instead of others. Like others have said, udev was going to cause issues, eudev has yet to cause any. Yes, absolutely sys-fs/eudev should be punted from tree since it doesn't bring in anything useful, and it reintroduced old bugs from old version of udev, as well as adds confusing to users. And no, sys-fs/udev doesn't have issues, in fact, less than what sys-fs/eudev has. Like said earlier, the bugs assigned to udev-bugs@g.o apply also to sys-fs/eudev and they have even more in their github ticketing system. And sys-fs/udev maintainers have to constantly monitor sys-fs/eudev so it doesn't fall too much behind, which adds double work unnecessarily. They don't keep it up-to-date on their own without prodding. Really, this is how it has went right from the start and the double work and user confusion needs to stop. - Samuli * you are not telling the whole story about what happened and why the fork came into life in the first place. It's not as simple as you seem True, I didn't mention people were needlessly unwilling to join the Gentoo udev team despite being invited to. That's a bit unrelated. It wasn't just about the gentoo ebuild. to suggest. There were good reasons at that point. Some changes were merged by udev upstream and there are still more differences than you point out. That has been discussed numerous of times. * claiming that eudev didn't improve anything is wrong and can be proven I can easily prove eudev is nothing but udev and deleted code, plus restored broken 'rule generator', plus useless kept static nodes creation which was moved to kmod, plus needlessly changed code for uclibc support -- uclibc now has the functions udev needs. Wonder why udev upstream merged back changes if it was all that bad. * that eudev is behind udev most of the time is correct * that it causes tons of breakage for users... well, I don't know, not for me since almost the beginning * eudev will not be treecleaned until the gentoo devs who maintain it agree (at best, it may be masked) and even if eudev will be obsolete at some point, then it has been a success * I don't understand why you add those rants all over different mailing lists. I have seen it numerous of times and your precision about explaining the situation does not improve. If you think that people need to be warned about eudev, then you should provide a reason to mask it or drop it back to ~arch. Anything else is not constructive and causes confusion. True, it won't be dropped for long as people are maintaining it. That's how maintainership works. But trying to lie to people it's somehow solving something currently is annoying as 'ell and should be corrected where seen. Who lied?
Re: [gentoo-user] Moving from old udev to eudev
On 12/08/13 16:39, hasufell wrote: On 08/12/2013 02:06 PM, Samuli Suominen wrote: On 12/08/13 14:37, hasufell wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/02/2013 05:01 AM, Samuli Suominen wrote: On 02/08/13 05:48, Dale wrote: Samuli Suominen wrote: Huh? USE=firmware-loader is optional and enabled by default in sys-fs/udev Futhermore predictable network interface names work as designed, not a single valid bug filed about them. Stop spreading FUD. Looking forward to lastrite sys-fs/eudev just like sys-apps/module-init-tools already was removed as unnecessary later on. So your real agenda is to kill eudev? Maybe it is you that is spreading FUD instead of others. Like others have said, udev was going to cause issues, eudev has yet to cause any. Yes, absolutely sys-fs/eudev should be punted from tree since it doesn't bring in anything useful, and it reintroduced old bugs from old version of udev, as well as adds confusing to users. And no, sys-fs/udev doesn't have issues, in fact, less than what sys-fs/eudev has. Like said earlier, the bugs assigned to udev-bugs@g.o apply also to sys-fs/eudev and they have even more in their github ticketing system. And sys-fs/udev maintainers have to constantly monitor sys-fs/eudev so it doesn't fall too much behind, which adds double work unnecessarily. They don't keep it up-to-date on their own without prodding. Really, this is how it has went right from the start and the double work and user confusion needs to stop. - Samuli * you are not telling the whole story about what happened and why the fork came into life in the first place. It's not as simple as you seem True, I didn't mention people were needlessly unwilling to join the Gentoo udev team despite being invited to. That's a bit unrelated. It wasn't just about the gentoo ebuild. That's all it was. to suggest. There were good reasons at that point. Some changes were merged by udev upstream and there are still more differences than you point out. That has been discussed numerous of times. * claiming that eudev didn't improve anything is wrong and can be proven I can easily prove eudev is nothing but udev and deleted code, plus restored broken 'rule generator', plus useless kept static nodes creation which was moved to kmod, plus needlessly changed code for uclibc support -- uclibc now has the functions udev needs. Wonder why udev upstream merged back changes if it was all that bad. Merged back what changes? That'd be news to me. I think you might be confusing something. * that eudev is behind udev most of the time is correct * that it causes tons of breakage for users... well, I don't know, not for me since almost the beginning * eudev will not be treecleaned until the gentoo devs who maintain it agree (at best, it may be masked) and even if eudev will be obsolete at some point, then it has been a success * I don't understand why you add those rants all over different mailing lists. I have seen it numerous of times and your precision about explaining the situation does not improve. If you think that people need to be warned about eudev, then you should provide a reason to mask it or drop it back to ~arch. Anything else is not constructive and causes confusion. True, it won't be dropped for long as people are maintaining it. That's how maintainership works. But trying to lie to people it's somehow solving something currently is annoying as 'ell and should be corrected where seen. Who lied? Let's rephrase lying with FUD for correctness.
Re: [gentoo-user] Strange segfaults during PHP emerge - during .configure phase I believe...
On Sat, Aug 10, 2013 at 2:25 PM, Tanstaafl tansta...@libertytrek.org wrote: Anyone ever seen/can explain these? I had 3 of them, again, apparently during the .configure phase: 2013-08-10T15:08:36-04:00 myhost kernel: conftest[12233]: segfault at 1 ip 7f1fc65e8e47 sp 7690d6e0 error 4 in libc-client.so.1.0.0[7f1fc65a8000+102000] 2013-08-10T15:10:04-04:00 myhost kernel: conftest[23852]: segfault at 1 ip 7fb1e5887e47 sp 7fff7f03f4a0 error 4 in libc-client.so.1.0.0[7fb1e5847000+102000] 2013-08-10T15:11:32-04:00 myhost kernel: conftest[3249]: segfault at 1 ip 7f0077cd6e47 sp 7fff70306050 error 4 in libc-client.so.1.0.0[7f0077c96000+102000] Yes, I have seen them all the time on multiple boxes. AFAIK this is perfectly normal behavior, I think it comes from autoconf trying -- on purpose -- to find broken configuration options so it knows what to avoid.
Re: [gentoo-user] Strange segfaults during PHP emerge - during .configure phase I believe...
On 2013-08-12 11:24 AM, Paul Hartman paul.hartman+gen...@gmail.com wrote: On Sat, Aug 10, 2013 at 2:25 PM, Tanstaafl tansta...@libertytrek.org wrote: Anyone ever seen/can explain these? I had 3 of them, again, apparently during the .configure phase: 2013-08-10T15:08:36-04:00 myhost kernel: conftest[12233]: segfault at 1 ip 7f1fc65e8e47 sp 7690d6e0 error 4 in libc-client.so.1.0.0[7f1fc65a8000+102000] 2013-08-10T15:10:04-04:00 myhost kernel: conftest[23852]: segfault at 1 ip 7fb1e5887e47 sp 7fff7f03f4a0 error 4 in libc-client.so.1.0.0[7fb1e5847000+102000] 2013-08-10T15:11:32-04:00 myhost kernel: conftest[3249]: segfault at 1 ip 7f0077cd6e47 sp 7fff70306050 error 4 in libc-client.so.1.0.0[7f0077c96000+102000] Yes, I have seen them all the time on multiple boxes. AFAIK this is perfectly normal behavior, I think it comes from autoconf trying -- on purpose -- to find broken configuration options so it knows what to avoid. Ok, cool, thanks Paul. It was the first time I'd seen them, so its reassuring that I'm not alone... Would be good to be documented somewhere though... Thanks again
Re: [gentoo-user] I don't want portage to update Libreoffice......
On 08/11/13 01:16, Daniel Frey wrote: On 08/10/2013 09:27 AM, Andrew Lowe wrote: Hi all, As per usual an update of Libre Office is failing and causing all sorts of build troubles. I have an install, the previous version, of Libre Office working so how do I stop portage from trying to update to the latest. [ebuild UD ] app-office/libreoffice-4.0.4.2 [4.1.0.1] What do I have to fiddle so that portage won't want to upgrade libreoffice? This is stopping my -NuD world from completing so I need to suppress libreoffice for the time being and come back to it later. Any thoughts, greatly appreciated, Andrew You can use the --exclude parameter (I think?) and it will ignore it for the one command, then after everything is updated you can solve it further. Try: emerge --exclude app-office/libreoffice -NuD world This is not a permanent change but it will allow you to complete your update, then you can set the masking afterwards. Dan It worked. Thanks. Now to get this all sorted out and Libre Office to build at leisure. Andrew
Re: [gentoo-user] I don't want portage to update Libreoffice......
Op dinsdag 13 augustus 2013 01:54:00 schreef Andrew Lowe: On 08/11/13 01:16, Daniel Frey wrote: On 08/10/2013 09:27 AM, Andrew Lowe wrote: Hi all, As per usual an update of Libre Office is failing and causing all sorts of build troubles. I have an install, the previous version, of Libre Office working so how do I stop portage from trying to update to the latest. [ebuild UD ] app-office/libreoffice-4.0.4.2 [4.1.0.1] What do I have to fiddle so that portage won't want to upgrade libreoffice? This is stopping my -NuD world from completing so I need to suppress libreoffice for the time being and come back to it later. Any thoughts, greatly appreciated, Andrew You can use the --exclude parameter (I think?) and it will ignore it for the one command, then after everything is updated you can solve it further. Try: emerge --exclude app-office/libreoffice -NuD world This is not a permanent change but it will allow you to complete your update, then you can set the masking afterwards. Dan It worked. Thanks. Now to get this all sorted out and Libre Office to build at leisure. Andrew FWIW, I had initially unmasked a bunch of stuff (suggested by portage) to get the first 4.x version of LO to compile. Upgrading to 4.0.4.2 only worked after I had upgraded boost and boost-build from 1.52 to 1.53. Portage had nothing to say about it, the build just failed with some weird boost errors. Cheers Paul
Re: [gentoo-user] I don't want portage to update Libreoffice......
On 12/08/2013 20:05, Paul Klos wrote: Op dinsdag 13 augustus 2013 01:54:00 schreef Andrew Lowe: On 08/11/13 01:16, Daniel Frey wrote: On 08/10/2013 09:27 AM, Andrew Lowe wrote: Hi all, As per usual an update of Libre Office is failing and causing all sorts of build troubles. I have an install, the previous version, of Libre Office working so how do I stop portage from trying to update to the latest. [ebuild UD ] app-office/libreoffice-4.0.4.2 [4.1.0.1] What do I have to fiddle so that portage won't want to upgrade libreoffice? This is stopping my -NuD world from completing so I need to suppress libreoffice for the time being and come back to it later. Any thoughts, greatly appreciated, Andrew You can use the --exclude parameter (I think?) and it will ignore it for the one command, then after everything is updated you can solve it further. Try: emerge --exclude app-office/libreoffice -NuD world This is not a permanent change but it will allow you to complete your update, then you can set the masking afterwards. Dan It worked. Thanks. Now to get this all sorted out and Libre Office to build at leisure. Andrew FWIW, I had initially unmasked a bunch of stuff (suggested by portage) to get the first 4.x version of LO to compile. Upgrading to 4.0.4.2 only worked after I had upgraded boost and boost-build from 1.52 to 1.53. Portage had nothing to say about it, the build just failed with some weird boost errors. You should log that as a bug, chances are good the devs are not aware of it. They can't test every combination and so rely on us users to report combinations shown to not work. -- Alan McKinnon Systems Engineer^W Technician Infrastructure Services Internet Solutions +27 11 575 7585 -- Alan McKinnon alan.mckin...@gmail.com
