Re: laptop PS2 External Mouse in X
Hi, Riccardo Mottola wrote: Hi, an apparently trivial question. On my ThinkPad 600x, I can only use the internal track-point with X11. If I attach an external PS/2 mouse, it does not get used. I don't have xorg.conf, I am accustomed that with other OS's it just works. I also tried plugging it in earlier, even at boot time. The light of the optical mouse works, thus it gets powered up. let me clarify. If I stick in the external mouse at boot time, it will be recognized and only the external mouse will work (it actually stopped working with a some error messages I will report below) and the internal trackpoint si inactive, even if i remove the external mouse. If I start with no mouse, the internal trackpoint works, but not the external mouse. With both setups, dmesg spits out the same: pms0 at pckbc0 (aux slot) pckbc0: using irq 12 for aux slot wsmouse0 at pms0 mux 0 I'm accustomed from other OS's (not just windows, but also Linux, FreeBSD.. I will check NetBSD) that I can just plug-in/plug-out an external mouse, This is very convenient in laptop usage. I know it doesn't work with desktops, but with laptops yes. Or could this be a limitation not of the OS but of this particular laptop? On a forum I found this (referred to a guy tryin gto attach a keyboard and not a mouse) The problem is that the port on the 600 series is a mouse port and not internally wired as a true PS2 port. You can overcome the problem by either using a PS2 splitter or a USB keyboard. Is this bogus or could this be a problem? Riccardo
Re: laptop PS2 External Mouse in X
On Sep 06 09:23:56, riccardo.mott...@libero.it wrote: an apparently trivial question. On my ThinkPad 600x, I can only use the internal track-point with X11. If I attach an external PS/2 mouse, it does not get used. I don't have xorg.conf, I am accustomed that with other OS's it just works. I also tried plugging it in earlier, even at boot time. The light of the optical mouse works, thus it gets powered up. let me clarify. If I stick in the external mouse at boot time, it will be recognized and only the external mouse will work (it actually stopped working with a some error messages I will report below) and the internal trackpoint si inactive, even if i remove the external mouse. If I start with no mouse, the internal trackpoint works, but not the external mouse. This is how it's supposed to work, right? http://en.wikipedia.org/wiki/PS/2_connector#Hotplugging With both setups, dmesg spits out the same: pms0 at pckbc0 (aux slot) pckbc0: using irq 12 for aux slot wsmouse0 at pms0 mux 0 Looks fine. I'm accustomed from other OS's (not just windows, but also Linux, FreeBSD.. I will check NetBSD) that I can just plug-in/plug-out an external mouse, You mean, these OSes on this very same laptop? With this mouse (not an USB mouse)? This is very convenient in laptop usage. I know it doesn't work with desktops, but with laptops yes. It's not a matter of a desktop vs a laptop. Or could this be a limitation not of the OS but of this particular laptop? Try the other OSes where it works on this laptop with this mouse and find out. On a forum I found this (referred to a guy tryin gto attach a keyboard and not a mouse) The problem is that the port on the 600 series is a mouse port and not internally wired as a true PS2 port. Could you please describe the difference bwtween a mouse port and a true PS2 port? You can overcome the problem by either using a PS2 splitter or a USB keyboard. Is this bogus or could this be a problem? USB mouses and keyboards you sholud be able to plug in and out as you wish.
A suggestion for snapshots
Quite often the snapshot of the packages and the base system are out of sync, because naturally, the base has to be built before packages. For example in this moment, as I write this, Firefox can not be installed in a new system installed from snapshots, as the packages are compiled against an older snapshot (amd64) If there are just space on the ftp servers, I would suggest keeping two snapshots: one complete with both base and packages (always in sync) and one with just the newest base. This would make life easier for people following snapshots. Regards, Lasse
ISAKMPD NAT/Traversal
Hello, list, from a remark by Stuart Henderson on an older thread http://marc.info/?l=openbsd-miscm=134849 788026722w=2 back in September 2012,I understood that NAT-T support in openBSD was not complete at that time, especially the handling of the 'ENCAPSULATION_MODE' attribute in the phase 2 'TRANSFORM'. Sometimes this gets set to a value incompatible with other equipment ( cisco ). Can someone please point me to where I can find more information on this matter. Has anything changed in openBSD with regard to this, will openBSD follow RFC3947 with regard to the encapsulation modes ( or is RFC3947 deas, it seems to be a standard proposal since 2005 ). Mit freundlichen Grüßen Christoph Leser SP Computersysteme GmbH Zettachring 4 70567 Stuttgart Fasanenhof EMail: le...@sup-logistik.de
Re: A suggestion for snapshots
On Fri, Sep 06, 2013 at 03:14:44PM +0300, Lars Engblom wrote: For example in this moment, as I write this, Firefox can not be installed in a new system installed from snapshots, as the packages are compiled against an older snapshot (amd64) Known issue. If there are just space on the ftp servers, I would suggest keeping two snapshots: That's the problem. Requiring that would put a lot of mirrors out of the game. There are also bottlenecks in fanning out from the actual build machines. Ports bulk builders are aware of the issues. These take time to solve.
Re: A suggestion for snapshots
On Fri, Sep 06, 2013 at 06:59:29PM +0200, Marc Espie wrote: There are also bottlenecks in fanning out from the actual build machines. Ports bulk builders are aware of the issues. These take time to solve. Would additional fast build machines help? Is that a large part of the problem? Bryan
Re: A suggestion for snapshots
On Fri, Sep 06, 2013 at 01:19:02PM -0700, Bryan Vyhmeister wrote: On Fri, Sep 06, 2013 at 06:59:29PM +0200, Marc Espie wrote: There are also bottlenecks in fanning out from the actual build machines. Ports bulk builders are aware of the issues. These take time to solve. Would additional fast build machines help? Is that a large part of the problem? Bryan Nope, I think that network bandwidth and topology is part of the current problem, and lack of time from some of the people involved to fix it.
Re: ISAKMPD NAT/Traversal
On 2013-09-06, Christoph Leser le...@sup-logistik.de wrote: Hello, list, from a remark by Stuart Henderson on an older thread http://marc.info/?l=openbsd-miscm=134849 788026722w=2 back in September 2012,I understood that NAT-T support in openBSD was not complete at that time, especially the handling of the 'ENCAPSULATION_MODE' attribute in the phase 2 'TRANSFORM'. Sometimes this gets set to a value incompatible with other equipment ( cisco ). Can someone please point me to where I can find more information on this matter. Has anything changed in openBSD with regard to this, will openBSD follow RFC3947 with regard to the encapsulation modes ( or is RFC3947 deas, it seems to be a standard proposal since 2005 ). Mit freundlichen Gr��en Christoph Leser SP Computersysteme GmbH Zettachring 4 70567 Stuttgart Fasanenhof EMail: le...@sup-logistik.de You misunderstand. OpenBSD uses the proper assigned encapsulation mode values from the newer internet-drafts and the published RFC: http://tools.ietf.org/html/draft-ietf-ipsec-nat-t-ike-04#section-5.1 http://tools.ietf.org/html/rfc3947#section-5.1 It is Cisco who use the old encapsulation mode values from the early versions of the internet-draft (marked XXX CHANGE here): http://tools.ietf.org/html/draft-ietf-ipsec-nat-t-ike-03#section-5.1
Re: A suggestion for snapshots
On Fri, Sep 6, 2013 at 7:14 AM, Lars Engblom lars.engb...@kimitotelefon.fiwrote: Quite often the snapshot of the packages and the base system are out of sync, because naturally, the base has to be built before packages. For example in this moment, as I write this, Firefox can not be installed in a new system installed from snapshots, as the packages are compiled against an older snapshot (amd64) If there are just space on the ftp servers, I would suggest keeping two snapshots: one complete with both base and packages (always in sync) and one with just the newest base. This would make life easier for people following snapshots. Regards, Lasse The problem with ports is that even with a build farm, the ports guy has to make sure dpb runs to the end. In the best case, a dpb run WITHOUT problems to the end takes atleast a day with a fast quad core machine. gcc4, JDK 1.6 + 1.7, GTK+2, GTK+3, Qt4, Webkit, Firefox are some of the worst ports in terms of build time and the largest offender Libreoffice which alone takes 4-6 hrs of all quad cores (Xeon E3-1230v2 3.3GHz). I might have missed some offenders, I just built a subset, experienced porters who handle the whole tree know better than me which ones are also worthy candidates. Finding and fixing port problems takes a minimum of 2 and I am guessing typically 4 days to pump out a wholly built ports tree, on a extremely fast arch like amd64. By which time the userland, kernel and xenocara have changed a lot underneath. Hence, you get these mismatches from time to time. It is not catastrophic, solution is to wait for the next snap. Even if the ports build machine untars userland, kernel, xenocara, running dpb again may force rebuilds or sometimes not.
Re: php sending mail via sendmail
I did the tcpdump and I think the following should be the reason?
---
500 5.5.1 Command unrecognized: AUTH LOGIN..
---
it tries to open the session with:
---
250-mydomain Hello www@mydomain [x.x.x.x], pleased to meet
you..250-ENHANCEDSTATUSCODES..250-PIPELINING..250-8BITMIME..250-SIZE..250-DSN..250-ETRN..250-DELIVERBY..250HELP..
---
On Thu, Sep 5, 2013 at 2:18 PM, Stuart Henderson s...@spacehopper.orgwrote:
On 2013-09-02, Tony Berth tonybe...@googlemail.com wrote:
well the script does talk to google mail correctly so somehow it should
work.
If the script is talking to google mail, it is going to be making
SMTP connections directly itself. Given the log entry you showed, I would
probably try sniffing the TCP connection (maybe something like
tcpdump -A -s 1500 -i lo0 port 25 will do).
I think all these open source php based solutions use the same way to
send e-mails.
No, they don't.
Sending mail from PHP is a right mess, there is the mail() function
but it's rather limited (on unix, it just pipes to a program and can't
do smtp-auth), also some server hosts disable it, so in practice most
larger PHP apps have another way of sending mail where they either
execute sendmail, or handle the socket connections themselves, or use a
library (phpmailer etc).
@owner ${DRUPAL_OWNER}
Re: A suggestion for snapshots
On Fri, Sep 6, 2013 at 7:14 AM, Lars Engblom lars.engb...@kimitotelefon.fiwrote: Quite often the snapshot of the packages and the base system are out of sync, because naturally, the base has to be built before packages. For example in this moment, as I write this, Firefox can not be installed in a new system installed from snapshots, as the packages are compiled against an older snapshot (amd64) If there are just space on the ftp servers, I would suggest keeping two snapshots: one complete with both base and packages (always in sync) and one with just the newest base. This would make life easier for people following snapshots. Regards, Lasse The problem with ports is that even with a build farm, the ports guy has to make sure dpb runs to the end. In the best case, a dpb run WITHOUT problems to the end takes atleast a day with a fast quad core machine. gcc4, JDK 1.6 + 1.7, GTK+2, GTK+3, Qt4, Webkit, Firefox are some of the worst ports in terms of build time and the largest offender Libreoffice which alone takes 4-6 hrs of all quad cores (Xeon E3-1230v2 3.3GHz). I might have missed some offenders, I just built a subset, experienced porters who handle the whole tree know better than me which ones are also worthy candidates. Finding and fixing port problems takes a minimum of 2 and I am guessing typically 4 days to pump out a wholly built ports tree, on a extremely fast arch like amd64. By which time the userland, kernel and xenocara have changed a lot underneath. Hence, you get these mismatches from time to time. It is not catastrophic, solution is to wait for the next snap. Even if the ports build machine untars userland, kernel, xenocara, running dpb again may force rebuilds or sometimes not. Anyone want to pay for a faster network link? Step up -- then we can solve this problem easily.
BSD Podcast
There's a new BSD podcast that's just started. First episode was really good, thought I'd share with the list. Interviews, tutorials, news, lots of fun stuff. http://www.bsdnow.tv/about Our very own phessler@ is the first guest.
