Re: SL7x and the 'epel' repo
On Thu, Mar 26, 2015 at 7:28 AM, Nico Kadel-Garcia nka...@gmail.com wrote: On Thu, Mar 26, 2015 at 5:59 AM, Tom H tomh0...@gmail.com wrote: On Tue, Mar 24, 2015 at 4:13 PM, Orion Poplawski or...@cora.nwra.com wrote: The ultimate cause of this issue was an upgrade of glib2 by RedHat in RHEL 7.1. And because the glib2 library does not use symbol versioning, rpm cannot automatically add the proper requires/provides to avoid installing incompatible libraries. So, this has nothing to do with EPEL, per se, but just normal issues that can occur with any update to RHEL. Rex Dieter (who's a Fedora and EPEL developer; it's too bad that the RH bugzilla instance doesn't add a dev icon to developers' names like the Gentoo one) explains in comments 5 and 7 why they don't do this. They don't need to because sticking to a specific point release is an SL quirk that's not supported by RHEL. So a RHEL user wouldn't hit this qtwebkit/glib problem and EPEL's developers don't waste their time ensuring that's it works. What? No, SL and CentOS *inherit* this behavior from Red Hat's minor point releases. Our favorite upstream vendor has moved away from the old practice, long before RHEL, of the point releases being supported individually long term, but they certainly publish new installation media with the new point releases. The big difference is that SL and CentOS continue to publish the point releases in different web accessible directories, so you can still see the point releases and updates segregated by time, and releases they were compatible with. RHEL publishes all the updates since the first point release in a giant pool, more like the SL 6x and 7x repositories: it can provide some really useful information about the point releases to compare thei contents among them. I agree with your last point. RHEL and CentOS use the equivalent of SL's 6x/7x by default and don't give the option of using 6.y/7.z. Point releases are just a snapshot of the packages at a certain point in time, like Debian 6.x/7.x and Ubuntu 12.04.x/14.04.x. RHEL offers its customers an EUS program for them to remain at a point release and get security updates but it doesn't publish the EUS sources in the same way that it doesn't publish the ELS sources.
Re: SL7x and the 'epel' repo
On 27/03/15 08:53, Tom H wrote: On Thu, Mar 26, 2015 at 7:28 AM, Nico Kadel-Garcia nka...@gmail.com wrote: On Thu, Mar 26, 2015 at 5:59 AM, Tom H tomh0...@gmail.com wrote: On Tue, Mar 24, 2015 at 4:13 PM, Orion Poplawski or...@cora.nwra.com wrote: The ultimate cause of this issue was an upgrade of glib2 by RedHat in RHEL 7.1. And because the glib2 library does not use symbol versioning, rpm cannot automatically add the proper requires/provides to avoid installing incompatible libraries. So, this has nothing to do with EPEL, per se, but just normal issues that can occur with any update to RHEL. Rex Dieter (who's a Fedora and EPEL developer; it's too bad that the RH bugzilla instance doesn't add a dev icon to developers' names like the Gentoo one) explains in comments 5 and 7 why they don't do this. They don't need to because sticking to a specific point release is an SL quirk that's not supported by RHEL. So a RHEL user wouldn't hit this qtwebkit/glib problem and EPEL's developers don't waste their time ensuring that's it works. What? No, SL and CentOS *inherit* this behavior from Red Hat's minor point releases. Our favorite upstream vendor has moved away from the old practice, long before RHEL, of the point releases being supported individually long term, but they certainly publish new installation media with the new point releases. The big difference is that SL and CentOS continue to publish the point releases in different web accessible directories, so you can still see the point releases and updates segregated by time, and releases they were compatible with. RHEL publishes all the updates since the first point release in a giant pool, more like the SL 6x and 7x repositories: it can provide some really useful information about the point releases to compare thei contents among them. I agree with your last point. RHEL and CentOS use the equivalent of SL's 6x/7x by default and don't give the option of using 6.y/7.z. Point releases are just a snapshot of the packages at a certain point in time, like Debian 6.x/7.x and Ubuntu 12.04.x/14.04.x. RHEL offers its customers an EUS program for them to remain at a point release and get security updates but it doesn't publish the EUS sources in the same way that it doesn't publish the ELS sources. - But my original point was that glib2-2.36.3-5, which I see in SL7x, was incompatible with the new (in epel-testing) qtwebkit, which needed glib2-2.40.0-4 from SL7rolling built off TUV's 7.1 It seems that what I see as SL7x is still 7.0. The naming of the download sites may have me confused. I'm using yumex.
Re: USB point to point computer communications link
On 03/26/2015 06:51 PM, Kevin K wrote: On Mar 26, 2015, at 6:37 PM, Yasha Karant ykar...@csusb.edu wrote: My desktop workstation (currently X86-64 SL 7) has only one 802.3 physical port. At my university, the IT gestapo will not allow the use of a local 802.3 repeater (switch or hub) but requires a valid NIC MAC address and will disconnect any changes. I have no 802.11 WNIC on my desktop workstation. I just have obtained a new HP Zbook to run X86-64 Linux to replace my old mobile workstation (laptop) that was underprovisioned for 64 bit operation, had a worn out keyboard and pointing device, etc. (I regret to state that I am experimenting with OpenSUSE 13.2 on that machine for reasons beyond the subject matter of this post.) The IT gestapo will not allow my workstation to serve as a HTTP server, etc. -- one cannot use scp, sftp, etc., for file transfer over the IT network from a desktop workstation (not a designated server). I could attempt to transfer all of the files to the research network that has much less IT gestapo control -- but this is as tedious as what I am now doing. H ence, a question: Is there a software application utility that will convert a USB network between two machines running standard open systems protocols to allow file transfer between the two machines? I am not referring to the methods used with an Android device, but with a regular Linux workstation. A cursory search of such things on the web did not provide any insight. At one time, UUCP would do this over a RS232 point-to-point link (cable) -- will this approach still work over a USB (not RS232) link? Is there something better than UUCP? Are you wanting to do a one time transfer between the two computers? Or be able to get both on the net at the same time? For 1 time use, I would suggest a crossover cable. Configure one to allow the SSH daemon to run, and copy files using scp or sftp. If you want both to connect to the net at the same time, and be able to talk to each other, then an inexpensive NAT router should do the trick. Unless they are running special software that can detect that you have multiple computers attached to it, there should be no issue. You still wouldn’t be able to connect BACK to your computer from outside if servers aren’t allowed. Behind NAT, your workstation should be able to be a server to the zbook. If all you are looking for is file transfer, is there a any reason why a USB drive is not a viable option? With USB length limits, it sounds like the 2 machines will be in the same room with physical access. Have you considered just adding a second NIC to the desktop for use with the laptop? I recall seeing USB link devices for migrating Windows systems between computers several years ago, but do not have any experience with them.
Re: SL7x and the 'epel' repo
On Fri, Mar 27, 2015 at 9:02 AM, Tim Kanuka tim.kan...@lightsource.ca wrote: I think having a EPEL mirror in the way described by Steve is an excellent idea. It exactly parallels my own requirement (and I suppose any site's requirement) of managing updates to many machines. The only way to guarantee that you are not going to break something with an update is to test your applications on an updated *test* environment. The only way to guarantee that your *production* environment is updated in the same way as the *test* environment is to have a mirror repo that is not changing unexpectedly. I'd like to note that EPEL is not the only 3rd party repository. :-) In the case of ELRepo, it was also debated when to release the 7.1-based packages. They are all built against RHEL 7.1 like EPEL's. One thing that is different from EPEL is that ELRepo's el7.1 packages that are _not_ backward compatible will not install on systems 7.1. yum will complain. My understanding is that EPEL packages do not have such 'Requires'. Akemi
Re: SL7x and the 'epel' repo
In that case, I'm thinking that it could be useful to maintain an EPEL mirror that does not get updated between TUV's release and the SL release. I could do that for my own use or it could be a community effort. Thoughts? Steve Gaarder System Administrator, Dept of Mathematics Cornell University, Ithaca, NY, USA gaar...@math.cornell.edu On Fri, 27 Mar 2015, Akemi Yagi wrote: On Fri, Mar 27, 2015 at 7:47 AM, Steve Gaarder gaar...@math.cornell.edu wrote: Thinking about this some more, I assume that EPEL is actually built against the latest from TUV, so 7.1 in this case. Correct? Yes, that is correct. There is a similar discussion thread on the CentOS mailing list: http://lists.centos.org/pipermail/centos/2015-March/150945.html Akemi
RE: SL7x and the 'epel' repo
I think having a EPEL mirror in the way described by Steve is an excellent idea. It exactly parallels my own requirement (and I suppose any site's requirement) of managing updates to many machines. The only way to guarantee that you are not going to break something with an update is to test your applications on an updated *test* environment. The only way to guarantee that your *production* environment is updated in the same way as the *test* environment is to have a mirror repo that is not changing unexpectedly. Tim Kanuka Canadian Light Source -Original Message- From: owner-scientific-linux-us...@listserv.fnal.gov [mailto:owner-scientific-linux-us...@listserv.fnal.gov] On Behalf Of Steve Gaarder Sent: Friday, March 27, 2015 09:45 To: Akemi Yagi Cc: SL Users Subject: Re: SL7x and the 'epel' repo In that case, I'm thinking that it could be useful to maintain an EPEL mirror that does not get updated between TUV's release and the SL release. I could do that for my own use or it could be a community effort. Thoughts? Steve Gaarder System Administrator, Dept of Mathematics Cornell University, Ithaca, NY, USA gaar...@math.cornell.edu On Fri, 27 Mar 2015, Akemi Yagi wrote: On Fri, Mar 27, 2015 at 7:47 AM, Steve Gaarder gaar...@math.cornell.edu wrote: Thinking about this some more, I assume that EPEL is actually built against the latest from TUV, so 7.1 in this case. Correct? Yes, that is correct. There is a similar discussion thread on the CentOS mailing list: http://lists.centos.org/pipermail/centos/2015-March/150945.html Akemi
Re: USB point to point computer communications link
Yasha, this is getting tiresome - your continuing use of this mailing list to obtain free technical support for (imho) bizarre problems or wishes - most of them complete with pity pledges please help me, our IT nazi would give me no soup (as in Soup Nazi, http://en.wikipedia.org/wiki/The_Soup_Nazi, not the other, bad, nazis). If your IT problems are real, and if they negatively affect your work productivity, why don't you have the boss of your boss have a talk with the boss of the boss of the IT departement's boss to straighten it all out? If you work at a university, you must know how this works. K.O. On Thu, Mar 26, 2015 at 04:37:34PM -0700, Yasha Karant wrote: My desktop workstation (currently X86-64 SL 7) has only one 802.3 physical port. At my university, the IT gestapo will not allow the use of a local 802.3 repeater (switch or hub) but requires a valid NIC MAC address and will disconnect any changes. I have no 802.11 WNIC on my desktop workstation. I just have obtained a new HP Zbook to run X86-64 Linux to replace my old mobile workstation (laptop) that was underprovisioned for 64 bit operation, had a worn out keyboard and pointing device, etc. (I regret to state that I am experimenting with OpenSUSE 13.2 on that machine for reasons beyond the subject matter of this post.) The IT gestapo will not allow my workstation to serve as a HTTP server, etc. -- one cannot use scp, sftp, etc., for file transfer over the IT network from a desktop workstation (not a designated server). I could attempt to transfer all of the files to the research network that has much less IT gestapo control -- but this is as tedious as what I am now doing. Hence, a question: Is there a software application utility that will convert a USB network between two machines running standard open systems protocols to allow file transfer between the two machines? I am not referring to the methods used with an Android device, but with a regular Linux workstation. A cursory search of such things on the web did not provide any insight. At one time, UUCP would do this over a RS232 point-to-point link (cable) -- will this approach still work over a USB (not RS232) link? Is there something better than UUCP? Yasha Karant -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: USB point to point computer communications link
That second NIC appears to be my only option. A colleague down the hall does exactly that. If I did attempt NAT, as was suggested, unless the device actually attached to the RJ-45 802.3 LAN port in the wall has the exact same MAC address, etc., as the NIC on my workstation, the local IT gestapo will disconnect my wall port and block all traffic -- until such time as the IT gestapo is instructed to detect the replacement NIC. This presents problems whenever there is a NIC failure or a replacement workstation. Instead, our illustrious gestapo requires us to use Eduroam over 802.11 -- but refuses to allow any standard server daemons on a workstation for file transfer. I can upload and download to a remote server as required -- is there a secure remote server that will allow mutli-Gbyte transfers and will allow https initiated download access via a web browser? I do NOT want to put files on a site that may corrupt, infect, or redistribute these. I was hoping to use USB 3 rather than 802.3 as the transfer. A USB stick does work, but then one is back to sneaker-net. Thanks for the suggestions. Yasha Karant On 03/27/2015 07:18 AM, Ken Teh wrote: I was about to suggest Mark's point about the second nic in the desktop. It seems to me the easiest and most versatile. And a small switch to connect the laptop and the desktop (on the second nic). No cross-over cable. A small disjoint lan with hard-wired addresses in /etc/hosts. You can add as many machines as you have ports on the switch. You could even turn your desktop into a NAT gateway if you wish. On 03/27/2015 08:38 AM, Mark Stodola wrote: On 03/26/2015 06:51 PM, Kevin K wrote: On Mar 26, 2015, at 6:37 PM, Yasha Karant ykar...@csusb.edu wrote: My desktop workstation (currently X86-64 SL 7) has only one 802.3 physical port. At my university, the IT gestapo will not allow the use of a local 802.3 repeater (switch or hub) but requires a valid NIC MAC address and will disconnect any changes. I have no 802.11 WNIC on my desktop workstation. I just have obtained a new HP Zbook to run X86-64 Linux to replace my old mobile workstation (laptop) that was underprovisioned for 64 bit operation, had a worn out keyboard and pointing device, etc. (I regret to state that I am experimenting with OpenSUSE 13.2 on that machine for reasons beyond the subject matter of this post.) The IT gestapo will not allow my workstation to serve as a HTTP server, etc. -- one cannot use scp, sftp, etc., for file transfer over the IT network from a desktop workstation (not a designated server). I could attempt to transfer all of the files to the research network that has much less IT gestapo control -- but this is as tedious as what I am no w doing. H ence, a question: Is there a software application utility that will convert a USB network between two machines running standard open systems protocols to allow file transfer between the two machines? I am not referring to the methods used with an Android device, but with a regular Linux workstation. A cursory search of such things on the web did not provide any insight. At one time, UUCP would do this over a RS232 point-to-point link (cable) -- will this approach still work over a USB (not RS232) link? Is there something better than UUCP? Are you wanting to do a one time transfer between the two computers? Or be able to get both on the net at the same time? For 1 time use, I would suggest a crossover cable. Configure one to allow the SSH daemon to run, and copy files using scp or sftp. If you want both to connect to the net at the same time, and be able to talk to each other, then an inexpensive NAT router should do the trick. Unless they are running special software that can detect that you have multiple computers attached to it, there should be no issue. You still wouldn’t be able to connect BACK to your computer from outside if servers aren’t allowed. Behind NAT, your workstation should be able to be a server to the zbook. If all you are looking for is file transfer, is there a any reason why a USB drive is not a viable option? With USB length limits, it sounds like the 2 machines will be in the same room with physical access. Have you considered just adding a second NIC to the desktop for use with the laptop? I recall seeing USB link devices for migrating Windows systems between computers several years ago, but do not have any experience with them.
Re: SL 7.1 schedule? (was Re: SL7x and the 'epel' repo)
On 03/27/2015 01:39 PM, Steve Gaarder wrote: It would be very helpful to me if I could have some idea of when SL 7.1 is likely to emerge. That will tell me whether I can just wait or need to come up with some kind of workaround for the EPEL problem. thanks, Steve Gaarder System Administrator, Dept of Mathematics Cornell University, Ithaca, NY, USA gaar...@math.cornell.edu The BETA build was just posted for testing on March 23. It doesn't look like much has changed, so I would expect it out in the very near future, unless testing shows problems of course.
Re: SL7x and the 'epel' repo
On 27/03/15 18:01, Steve Gaarder wrote: On Fri, 27 Mar 2015, Akemi Yagi wrote: One thing that is different from EPEL is that ELRepo's el7.1 packages that are _not_ backward compatible will not install on systems 7.1. yum will complain. My understanding is that EPEL packages do not have such 'Requires'. Au contraire - right now, for example, I cannot install marco from EPEL: Packages presumably vary, but the bugzilla comments indicated that the only real condition now for EPEL is compatibility with RHEL 7.1; what concerned me was that there was no warning during installation that qtwebkit would fail. In fact the failure was total, but with other (hypothetical) packages it might not have been so clearcut.
Re: USB point to point computer communications link
It isn’t so much the USB. USB as a design is a master/slave relationship. So you cannot connect 2 normal computers together with an USB cable. It doesn’t matter what you are wanting to do with it. There have been special USB cables in the past with some smarts in the middle so each computer thinks that it is talking to the middle, and it connects the 2. Whether they emulated serial cables, or LAN, I don’t recall. It has been years, and I never needed one. The 2 best suggestions so far has been to put in a second NIC in the desktop, and configure the Linux desktop to act as the NAT gateway for the portable. Or just get a NAT router, and have it clone the desktop’s MAC address so it doesn’t look any different to the IT department. Neither of these are a solution if you are in an environment where you don’t own the connected computers. On Mar 27, 2015, at 5:30 PM, Yasha Karant ykar...@csusb.edu wrote: The university system at which I am tenured has limited practical respect for Faculty but much lipservice to the concept -- that is the reality. I simply was asking if such a utility existed within EL or Linux in general -- it evidently does not. UUCP does not easily work over USB although at one time it did work for point-to-point RS-232 connections. In the future, I will omit the background as to why I post such a request for a utility, merely that I need such a utility if it exists. In the best of all possible worlds -- not this one -- I would have a grad student, or even a talented undergrad, see if UUCP could be modified. For now, I am using the modern equivalent of sneaker net. Sorry to have bothered you. Yasha Karant On 03/27/2015 12:37 PM, Konstantin Olchanski wrote: Yasha, this is getting tiresome - your continuing use of this mailing list to obtain free technical support for (imho) bizarre problems or wishes - most of them complete with pity pledges please help me, our IT nazi would give me no soup (as in Soup Nazi, http://en.wikipedia.org/wiki/The_Soup_Nazi, not the other, bad, nazis). If your IT problems are real, and if they negatively affect your work productivity, why don't you have the boss of your boss have a talk with the boss of the boss of the IT departement's boss to straighten it all out? If you work at a university, you must know how this works. K.O. On Thu, Mar 26, 2015 at 04:37:34PM -0700, Yasha Karant wrote: My desktop workstation (currently X86-64 SL 7) has only one 802.3 physical port. At my university, the IT gestapo will not allow the use of a local 802.3 repeater (switch or hub) but requires a valid NIC MAC address and will disconnect any changes. I have no 802.11 WNIC on my desktop workstation. I just have obtained a new HP Zbook to run X86-64 Linux to replace my old mobile workstation (laptop) that was underprovisioned for 64 bit operation, had a worn out keyboard and pointing device, etc. (I regret to state that I am experimenting with OpenSUSE 13.2 on that machine for reasons beyond the subject matter of this post.) The IT gestapo will not allow my workstation to serve as a HTTP server, etc. -- one cannot use scp, sftp, etc., for file transfer over the IT network from a desktop workstation (not a designated server). I could attempt to transfer all of the files to the research network that has much less IT gestapo control -- but this is as tedious as what I am now doing. Hence, a question: Is there a software application utility that will convert a USB network between two machines running standard open systems protocols to allow file transfer between the two machines? I am not referring to the methods used with an Android device, but with a regular Linux workstation. A cursory search of such things on the web did not provide any insight. At one time, UUCP would do this over a RS232 point-to-point link (cable) -- will this approach still work over a USB (not RS232) link? Is there something better than UUCP? Yasha Karant
Re: USB point to point computer communications link
On Fri, Mar 27, 2015 at 6:51 PM, Kevin K kevi...@fidnet.com wrote: It isn’t so much the USB. USB as a design is a master/slave relationship. So you cannot connect 2 normal computers together with an USB cable. It doesn’t matter what you are wanting to do with it. Use two USB ethernet ports. They're cheap, most of them work quite well with Linux, they're handy for other uses, and easily configured for little private, non-routable VLAN. Since most modern such ports are GigE compatible, the connections are hermaphroditic, and you won't even need a crossover cable. And the USB ethernet ports are invaluable when confronted with broken wireless environments. I always keep one in my emergency computer widgets bin.
