Re: libGGI
On Sat, Jan 15, 2000 at 12:22:55AM +0100, Andres wrote: > > I apologize if this is not the right list to post to, but i didn't know > where else to do it so here goes: [EMAIL PROTECTED] would be your best bet. Followups redirected. > is anyone interested/currently working on a libGGI port ? or currently > using libGGI on FreeBSD ? There's one in the queue at: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=15936(libgii) http://www.FreeBSD.org/cgi/query-pr.cgi?pr=15938(libggi) from the http://www.ggi-project.org/ people. Both of these will need a little tweaking before they get committed (they install .la libtool turds which can be got rid of easily enough) but may do what you want. Knowing absolutely nothing about GGI, I wouldn't presume to comment any further. -aDe -- Ade Lovett, Austin, TX. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Shared memory - Was: 2 Queries
On Tue, Feb 29, 2000 at 01:41:43PM -0500, Christopher Masto wrote: > > In any case, one major offender is imlib. Since I've recently gone > Gnome, I've had to turn off imlib's "MIT-SHM shared memory" option > or things would go bad after a few minutes or hours of use. Can you expand a bit on "go bad"? I have a couple of machines here running with GNOME for days on end with no shared memory problems. The only thing I've tweaked is to add the following options into my kernel config: options SHMMAX="(64*1024*1024)" options SHMMNI=4096 options SHMSEG=256 these were taken from a Solaris/sparc person running GNOME who had made equivalent changes to his /etc/system to get rid of lots of annoying shared-memory warnings in .xsession-errors I'm not seeing any leaks, though: viper 17% uptime 3:53PM up 5 days, 34 mins, 19 users, load averages: 2.81, 2.85, 2.84 (take off a couple of minutes for boot up, launching xdm, logging in and launching GNOME) viper 18% ipcs -bp Message Queues: T ID KEYMODE OWNERGROUP QBYTES LSPID LRPID Shared Memory: T ID KEYMODE OWNERGROUP SEGSZ CPID LPID m 655362622055 --rw-r--r-- rootwheel 1048576298298 m 41615362 792064 --rw-rw-rw- adestaff 4 12549 12549 Semaphores: T ID KEYMODE OWNERGROUP NSEMS s 65536 2622057 --rw-rw-rw- rootwheel 14 -aDe -- Ade Lovett, Austin, TX. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
OpenSSH b0rked 6/11
>From today's buildworld: [...] cc -O -pipe -DLIBWRAP -DLOGIN_ACCESS -I/usr/src/secure/usr.sbin/sshd/../../../usr.bin/login -DSKEY -c /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c: In function `do_exec_pty': /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c:651: warning: passing arg 2 of `auth_ttyok' from incompatible pointer type /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c: In function `do_child': /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c:866: syntax error before `*' /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c:868: `lc' undeclared (first use in this function) /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c:868: (Each undeclared identifier is reported only once /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c:868: for each function it appears in.) *** Error code 1 Following patch fixes it: Index: session.c === RCS file: /home/src/FreeBSD/src/crypto/openssh/session.c,v retrieving revision 1.5 diff -u -r1.5 session.c --- session.c 2000/06/10 22:32:57 1.5 +++ session.c 2000/06/11 18:52:35 @@ -857,14 +857,15 @@ extern char **environ; struct stat st; char *argv[10]; +#ifdef LOGIN_CAP + login_cap_t *lc; +#endif /* login(1) is only called if we execute the login shell */ if (options.use_login && command != NULL) options.use_login = 0; #ifdef LOGIN_CAP - login_cap_t *lc; - lc = login_getpwclass(pw); if (lc == NULL) lc = login_getclassbyname(NULL, pw); -aDe -- Ade Lovett, Austin, TX. [EMAIL PROTECTED] FreeBSD: The Power to Serve http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping perl
[cc's trimmed] On Mon, Jun 26, 2000 at 10:08:58PM +0200, Mark Murray wrote: > > Message to others for bootstrapping: > > > > Checkout perl (contrib/perl5 and gnu/usr.bin/perl) from -D 2624, > > build and install it manually, then update both dirs to HEAD and do a > > world with the new perl in place. > > Now you can colour me flummoxed. :-(. > > Have you a script(1) of that? Just for the record, I tried that.. (my laptop is at 06/20 -current right now) -- coredump 15# cvs checkout -PA -D 2624 src/contrib/perl5 src/gnu/usr.bin/perl[...] coredump 16# cd src/gnu/usr.bin/perl coredump 17# make depend all install [...] coredump 18# cd /usr/src coredump 19# rm -rf src/contrib/perl5 src/gnu/usr.bin/perl coredump 20# cd /usr/src/contrib && cvs update -PAd . [...] coredump 21# cd /usr/src/gnu/usr.bin && cvs update -PAd . [...] coredump 22# rm -rf /usr/obj/* [...] coredump 23# make buildworld [...] ------ It crapped out in exactly the same place. -aDe -- Ade Lovett, Austin, TX. [EMAIL PROTECTED] FreeBSD: The Power to Serve http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping perl
On Tue, Jun 27, 2000 at 09:48:59PM +0200, Mark Murray wrote:
> > Just for the record, I tried that.. (my laptop is at 06/20 -current
> > right now)
>
> What "right now"? I committed some fixes about 4 hours ago. Do you
> have those?
"right now" as in "it's running kernel and userland from 06/20"
The contents of /usr/src are up to date as of 0300 CDT this morning.
> (Look for lots of ${MINIPERL} in place of "miniperl").
Ok. I'll re-cvsup now and take a peek.
-aDe
--
Ade Lovett, Austin, TX. [EMAIL PROTECTED]
FreeBSD: The Power to Serve http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping perl
On Tue, Jun 27, 2000 at 02:52:51PM -0500, Ade Lovett wrote:
> Mark wrote:
> > (Look for lots of ${MINIPERL} in place of "miniperl").
>
> Ok. I'll re-cvsup now and take a peek.
Got all the ${MINIPERL} stuff, and I now have a successful
buildworld. Took 7 minutes longer than the last time though...
-aDe
--
Ade Lovett, Austin, TX. [EMAIL PROTECTED]
FreeBSD: The Power to Serve http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
perl5 ports and perl5.006
Got a couple of issues with perl5.006 that just went into -current
in terms of perl5 ports.
The first one is relatively straightforward, being a simple
versioning problem. Following patch fixes that (OSVERSION
may be slightly wrong, but it corresponds to what I have
in my up-to-date src tree):
Index: bsd.port.mk
===
RCS file: /home/src/FreeBSD/ports/Mk/bsd.port.mk,v
retrieving revision 1.340
diff -u -r1.340 bsd.port.mk
--- bsd.port.mk 2000/06/16 21:52:40 1.340
+++ bsd.port.mk 2000/06/27 23:59:03
@@ -764,12 +764,17 @@
.endif
.endif
+.if ${OSVERSION} >= 56
+PERL_VERSION= 5.006
+PERL_VER= 5.006
+.else
+PERL_VER= 5.005
.if ${OSVERSION} >= 30
PERL_VERSION= 5.00503
.else
PERL_VERSION= 5.00502
+.endif
.endif
-PERL_VER= 5.005
PERL_ARCH= ${ARCH}-freebsd
PLIST_SUB+=PERL_VERSION=${PERL_VERSION} \
PERL_VER=${PERL_VER} \
The next one is a little more obscure, at least to my limited
perl knowledge.
Take a perl5 port at random.. I chose converters/p5-Convert-UU
I had to make the following (kludgy) hack to the PLIST to make
things package properly:
Index: PLIST
===
RCS file: /home/src/FreeBSD/ports/converters/p5-Convert-UU/pkg/PLIST,v
retrieving revision 1.6
diff -u -r1.6 PLIST
--- PLIST 1999/01/11 15:33:32 1.6
+++ PLIST 2000/06/27 23:54:22
@@ -1,5 +1,5 @@
bin/puudecode
bin/puuencode
lib/perl5/site_perl/%%PERL_VER%%/Convert/UU.pm
-lib/perl5/site_perl/%%PERL_VER%%/%%PERL_ARCH%%/auto/Convert/UU/.packlist
-@dirrm lib/perl5/site_perl/%%PERL_VER%%/%%PERL_ARCH%%/auto/Convert/UU
+lib/perl5/site_perl/%%PERL_VER%%/mach/auto/Convert/UU/.packlist
+@dirrm lib/perl5/site_perl/%%PERL_VER%%/mach/auto/Convert/UU
Notice how things appear to be being installed in a mach/ subdirectory,
as opposed to the previous {i386,alpha}-freebsd/ subdirectories.
Also, when making the port, it complains about not being able to
find pod2man (to make the manual pages), even though it successfully
does this elsewhere.
This appears to be affect most (if not all) of the perl5 ports.
Any solutions for this problem?
-aDe
--
Ade Lovett, Austin, TX. [EMAIL PROTECTED]
FreeBSD: The Power to Serve http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: perl5 ports and perl5.006
On Tue, Jun 27, 2000 at 07:05:39PM -0500, Ade Lovett wrote:
> Take a perl5 port at random.. I chose converters/p5-Convert-UU
> I had to make the following (kludgy) hack to the PLIST to make
> things package properly:
>
> Index: PLIST
> ===
> RCS file: /home/src/FreeBSD/ports/converters/p5-Convert-UU/pkg/PLIST,v
> retrieving revision 1.6
> diff -u -r1.6 PLIST
> --- PLIST 1999/01/11 15:33:32 1.6
> +++ PLIST 2000/06/27 23:54:22
> @@ -1,5 +1,5 @@
> bin/puudecode
> bin/puuencode
> lib/perl5/site_perl/%%PERL_VER%%/Convert/UU.pm
> -lib/perl5/site_perl/%%PERL_VER%%/%%PERL_ARCH%%/auto/Convert/UU/.packlist
> -@dirrm lib/perl5/site_perl/%%PERL_VER%%/%%PERL_ARCH%%/auto/Convert/UU
> +lib/perl5/site_perl/%%PERL_VER%%/mach/auto/Convert/UU/.packlist
> +@dirrm lib/perl5/site_perl/%%PERL_VER%%/mach/auto/Convert/UU
>
> Notice how things appear to be being installed in a mach/ subdirectory,
> as opposed to the previous {i386,alpha}-freebsd/ subdirectories.
Bingo! Found the problem.
Comparing src/gnu/usr.bin/perl/libperl/config.SH-elf.i386 between
-STABLE and -CURRENT we find:
(-CURRENT)
installsitearch='/usr/local/lib/perl5/site_perl/5.006/mach'
(-STABLE)
installsitearch='/usr/local/lib/perl5/site_perl/5.005/i386-freebsd'
This is what's causing the port PLISTs to malfunction.. -current
needs to be fixed appropriately, replacing 'mach' with
'{i386,alpha}-freebsd' as appropriate.
It also affects the threaded config file in the same directory.
No idea on the exact fix.. The perl mangling seems to be
"interesting" to say the least :)
Perhaps this will give Mark the ammo he needs to fix it.
That, and the patch to bsd.port.mk I gave should fix the perl
transition problem for ports.
-aDe
--
Ade Lovett, Austin, TX. [EMAIL PROTECTED]
FreeBSD: The Power to Serve http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Perl 5.6.0 & pod2man & ports
On Mon, Jul 10, 2000 at 06:32:22PM +0200, Sheldon Hearn wrote:
> But you didn't update /usr/ports/Mk, did you? :-)
This is nothing to do with parts of /usr/ports being out of date
and has already been mentioned on both -ports and -current.
>From my -current box, which is most definitely up to date
(both src/ and ports/ from 7/9):
[choose random p5 port]
coredump 278# make
===> Extracting for p5-Convert-UU-0.40
expr in free(): warning: modified (chunk-) pointer.
>> Checksum OK for Convert-UU-0.40.tar.gz.
===> Patching for p5-Convert-UU-0.40
===> Configuring for p5-Convert-UU-0.40
Checking if your kit is complete...
Looks good
Warning: I could not locate your pod2man program. Please make sure,
your pod2man program is in your PATH before you execute 'make'
Writing Makefile for Convert::UU
===> Building for p5-Convert-UU-0.40
[...]
The following (untested, by me) patch from
MANTANI Nobutaka <[EMAIL PROTECTED]> apparently fixes this.
--- /usr/src/contrib/perl5/lib/ExtUtils/MM_Unix.pm.orig Tue Jul 4 10:33:51 2000
+++ /usr/src/contrib/perl5/lib/ExtUtils/MM_Unix.pm Tue Jul 4 10:34:33 2000
@@ -1353,7 +1353,7 @@
if (defined $self->{PERL_SRC}) {
$pod2html_exe = $self->catfile($self->{PERL_SRC},'pod','pod2html');
} else {
- $pod2html_exe = $self->catfile($Config{scriptdirexp},'pod2html');
+ $pod2html_exe = $self->catfile($Config{bin},'pod2html');
}
unless ($pod2html_exe = $self->perl_script($pod2html_exe)) {
# No pod2html but some HTMLxxxPODS to be installed
@@ -2608,7 +2608,7 @@
if (defined $self->{PERL_SRC}) {
$pod2man_exe = $self->catfile($self->{PERL_SRC},'pod','pod2man');
} else {
- $pod2man_exe = $self->catfile($Config{scriptdirexp},'pod2man');
+ $pod2man_exe = $self->catfile($Config{bin},'pod2man');
}
unless ($pod2man_exe = $self->perl_script($pod2man_exe)) {
# Maybe a build by uninstalled Perl?
-aDe
--
Ade Lovett, Austin, TX. [EMAIL PROTECTED]
FreeBSD: The Power to Serve http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Lucent Orinoco Gold PCCard?
On Tue, Dec 05, 2000 at 01:46:51PM -0700, Warner Losh wrote: > In message <[EMAIL PROTECTED]> Doug Ambrisko writes: > : BTW I saw ADDTRON http://www.addtron.com/ has a base station for around > : $220 that can do 128 bit encryption, has an antenna and is Web administered. > : I haven't used it but it looks interesting. > > I'll have to check this out as well. FWIW, I ordered one of these today.. I'll pass on my discoveries with my various wireless cards (mostly Lucent) if y'all are interested.. -aDe [today's toy is powered by the letters 'I', 'R' and 'S'] -- Ade Lovett, Austin, TX. [EMAIL PROTECTED] FreeBSD: The Power to Serve http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libgtop on CURRENT
On Thu, Feb 15, 2001 at 09:48:13PM +0900, Akinori MUSHA wrote: > It is necessary to update libgtop for CURRENT as attached. I haven't > yet got an idea how to fix it to shut up the following error messages, > though. My -current box was a victim of -current a while back. It's currently on R&R before I threaten it again. > LibGTop-Server: kvm_getargv (12): Undefined error: 0 > LibGTop-Server: kvm_getargv (11): Undefined error: 0 > LibGTop-Server: kvm_getargv (10): Undefined error: 0 Hmm.. looks like the whole enchilada needs to have kvm calls ripped out of it. I'll look at your patches, and try and integrate them into the new release. -aDe -- Ade Lovett, Austin, TX.[EMAIL PROTECTED] FreeBSD: The Power to Serve http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Merge of binutils 2.17
On Jan 07, 2011, at 15:41 , Doug Barton wrote: > On 01/07/2011 13:29, Dimitry Andric wrote: >> >> Yes, I submitted an exp-run request Nov 15, 2010: >> http://www.freebsd.org/cgi/query-pr.cgi?pr=152268 >> Unfortunately, there has been little or no interest. > > Fair enough, that sounds to me like portmgr is volunteering to clean up the > mess then. Most likely it's low priority given all the other exp-runs that affect 7.x/8.x, tweaking things for an 6.x-EOL-tagged tree, and a bunch of other infrastructure stuff. Not to mention the impending 7- and 8- RELEASEs. Then of course there's the issue (which is certainly getting better) of finding a point in time along the -CURRENT path where the tree is stable (sic) enough to get through a full ports run (which is one of the bigger internal stress tests we have of the system). IMO, the best approach would be to make sure it does the right thing with 'make universe' (twice, naturally, the second time being when all traces of the previous binutils has been purged from the building system). Once that's done, commit (please bump __FreeBSD_version as part of this, in case ports OSVERSION hacks are eventually needed), and then give the exp-run a whirl -- with all of the above, this should be nicely after 7.4/8.2 -aDe ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: Merge of binutils 2.17
On Jan 07, 2011, at 17:37 , Doug Barton wrote: > On 01/07/2011 13:54, Ade Lovett wrote: >> >> Most likely it's low priority given all the other exp-runs that >> affect 7.x/8.x, tweaking things for an 6.x-EOL-tagged tree, and a >> bunch of other infrastructure stuff. Not to mention the impending 7- >> and 8- RELEASEs. Before I start on this, I would like a few things noted for the record: 1. I have set Reply-To to developers@ (this should be a major hint) 2. I am not a current member of portmgr@ 3. I requested, and served, for a very short time, on the first portmgr > That may very well be the case, but if so then it's incumbent on portmgr to > communicate that. If you check the audit trail you will find that they did > not. Horsecrap. You are taking an individual PR history without reference to the whole host of things that were also going on at the same time. Like it or not, when it comes to ports, -STABLE wins over -CURRENT every single time. > IMO this is a total red herring, and has been for several years now. I run > -current every day on my real-work system, and barring the occasional hiccup > it's been buildable nearly every time I've tried. Apologies for not being able to drive my email client appropriately. The issue at hand is one of running -CURRENT. There is a distinct, and fundamental difference between running -CURRENT on a single system, as opposed to a cluster of systems that are tightly interlinked. I do not doubt that -CURRENT works for you on your individual machines. If you would like a taste of how heavily package build clusters stress out whatever host system they are running on, then I urge you to install one of the two tinderbox ports under ports-mgmt, proceed to add, let's say, x11/gnome2 or x11/kde4, and run the build. make buildworld/buildkernel/installworld/installkernel plus associated steps is in fact an exceptionally tiny subset of what FreeBSD actually does on a daily basis. Even more so when it comes to the bulk building of packages that apparently a lot of folks rely on. > The way I would approach the problem of building packages for -current is to > pick a day to update the src tree, then do the following: Sadly, the only thing I can say to your 4-step procedure, and with utmost politeness, is that your src-centric views are completely missing the point. "4. start building ports" is in fact a 20- or 30-step process to ensure no cross-contamination. Even a cursory glance at /usr/ports/Tools/portbuild would verify this. No-one really likes having massive clusters, requiring continual attention (hardware failures and so on). Really. > But the current system of "don't do anything" just isn't cutting it. I look forward to your input and total solutions on how to make this better. I do. This may sound sarcastic, but I am absolutely, positively, 100-percent looking for better solutions, particularly in situations where, to take a random example, the entire existing compiler base is removed and replaced with something better. Doug, you have comprehensively shown that in its current (sic) instantiation, the package building cluster is completely, utterly, and totally incapable of keeping up with the sandbox that is -CURRENT. I for one look forward to your proposed solutions to this righteous problem. Regards, -aDe ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: BSDInstall: merging to HEAD
On Jan 14, 2011, at 19:31 , Marcel Moolenaar wrote: > On Jan 14, 2011, at 10:26 AM, Nathan Whitehorn wrote: > >> The final architecture on which we use sysinstall, ia64, is currently >> unsupported, because I don't know how to set up booting on those systems -- >> patches to solve this are very much welcome. > > Don't let this stop you. I'll work with you on this after the dust > has settled. Just out of random curiosity. Seriously. Exactly why, short of "of course it runs", in which case NetBSD is --> way, why are we even trying to handle ia64 as a platform, regardless of tier, when it is patently obvious that it is going absolutely _nowhere_ in terms of a viable platform? I ask the question in all seriousness. Ports/Packages, well, a decent amount of them won't work on anything less than (i386|amd64) but that's nothing new. But even spending time building them for, what, the <200 (I'm being generous) folks that run FreeBSD/ia64. We _have_ a 64-bit platform. It's /amd. The fact that even as we speak, random chip manufacturers are banging out new P4/Xeon processors conforming to this standard, years after they had a vague chance to steal the server market, indicates that this line is dead. _dead_. DEAD. At least I can pick up a box for <$50 from ebay and run /sparc64 on it. Say the same for /ia64? Didn't think so. Nuke it. From orbit. With extreme prejudice. -aDe ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
5.2-BETA USB woes
The full tale of woe can be found at: http://www.lovett.com/~ade/freebsd.html The executive summary is that after some unfortunate hardware failures, I picked up an ASUS A7V8X-X motherboard with a 6 USB 2.0 ports. GENERIC doesn't appear to have ehci in it, so not a great deal happened. I then took the GENERIC kernel, ripped out all of the USB code from the kernel and enabled usbd(8) to hopefully do the right thing. There's a single USB device connected up (an MS optical cordless wheelmouse, which works just fine with XP and Gentoo Linux, and is seen by 4.9-RELEASE, though nothing much happens with moused). Here's what happened: uhci0: port 0xb000-0xb01f irq 21 at device 16.0 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xa800-0xa81f irq 21 at device 16.1 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhub0: port error, restarting port 1 uhub0: port error, giving up port 1 uhci2: port 0xa400-0xa41f irq 21 at device 16.2 on pci0 usb2: on uhci2 usb2: USB revision 1.0 uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhub1: port error, restarting port 1 uhub1: port error, giving up port 1 uhub1: port error, restarting port 2 uhub1: port error, giving up port 2 ehci0: mem 0xf100-0xf1ff irq 21 at device 16.3 on pci0 ehci_pci_attach: companion usb0 ehci_pci_attach: companion usb1 ehci_pci_attach: companion usb2 usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 uhub0: port error, restarting port 2 uhub0: port error, giving up port 2 uhub0: port error, restarting port 1 uhub0: port error, giving up port 1 usb3: on ehci0 usb3: USB revision 2.0 uhub3: (0x1106) EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: 6 ports with 6 removable, self powered uhub2: port error, restarting port 1 uhub2: port error, giving up port 1 uhub2: port error, restarting port 2 uhub2: port error, giving up port 2 No mouse detected, usbd is running, but all the ports are dead. Disconnecting and reconnecting the mouse has absolutely no effect whatsoever. If a friendly USB guru happens to be around, I can provide ssh and root access to the box, or if there are further diagnostics I can run, please let me know. -aDe ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.2-BETA USB woes
On Nov 24, 2003, at 10:56, Ade Lovett wrote:
The executive summary is that after some unfortunate hardware
failures, I picked up an ASUS A7V8X-X motherboard with a 6 USB 2.0
ports.
Just as an addendum, on the advice of someone on irc, I tried booting
both NetBSD (1.6.1) and OpenBSD (3.4) on this machine. Relevant
dmesg(8) as follows:
NetBSD 1.6.1 (INSTALL) #0: Tue Apr 8 12:46:48 UTC 2003
[EMAIL PROTECTED]:/autobuild/netbsd-1-6/i386/OBJ/autobuild/
netbsd-1-6/src/sys/arch/i386/compile/INSTALL
cpu0: AMD K7 (Athlon) (686-class), 2166.54 MHz
[...]
uhci0 at pci0 dev 16 function 0: vendor 0x1106 product 0x3038 (rev.
0x80)
uhci0: interrupting at irq 3
usb0 at uhci0: USB revision 1.0
uhub0 at usb0
uhub0: vendor 0x1106 UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhci1 at pci0 dev 16 function 1: vendor 0x1106 product 0x3038 (rev.
0x80)
uhci1: interrupting at irq 3
usb1 at uhci1: USB revision 1.0
uhub1 at usb1
uhub1: vendor 0x1106 UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhci2 at pci0 dev 16 function 2: vendor 0x1106 product 0x3038 (rev.
0x80)
uhci2: interrupting at irq 3
usb2 at uhci2: USB revision 1.0
uhub2 at usb2
uhub2: vendor 0x1106 UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
vendor 0x1106 product 0x3104 (USB serial bus, interface 0x20, revision
0x82) at pci0 dev 16 function 3 not configured
[...]
uhub0: port error, restarting port 1
uhub0: port error, giving up port 1
uhub1: port error, restarting port 1
uhub1: port error, giving up port 1
uhub1: port error, restarting port 2
uhub1: port error, giving up port 2
uhub2: port error, restarting port 1
uhub2: port error, giving up port 1
uhub2: port error, restarting port 2
uhub2: port error, giving up port 2
uhidev0 at uhub0 port 1 configuration 1 interface 0
uhidev0: Microsoft Microsoft Wireless Optical MouseÆ 1.0A, rev
2.00/0.17, addr 2, iclass 3/1
uhidev0: 2 report ids
uhid at uhidev0 reportid 1 not configured
uhid at uhidev0 reportid 2 not configured
uhub0: port error, restarting port 2
uhub0: port error, giving up port 2
So, NetBSD does something fairly similar to FreeBSD, but at least
manages to find a mouse, before completely flaking out.
On to OpenBSD:
OpenBSD 3.4 (RAMDISK_CD) #0: Tue Oct 21 19:29:29 BST 2003
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/RAMDISK_CD
cpu0: AMD Athlon XP Model 8 (Thoroughbred) ("AuthenticAMD" 686-class)
2.17 GHz
[...]
uhci0 at pci0 dev 16 function 0 "VIA VT83C572 USB" rev 0x80: irq 3
usb0 at uhci0: USB revision 1.0
uhub0 at usb0
uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhci1 at pci0 dev 16 function 1 "VIA VT83C572 USB" rev 0x80: irq 3
usb1 at uhci1: USB revision 1.0
uhub1 at usb1
uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhci2 at pci0 dev 16 function 2 "VIA VT83C572 USB" rev 0x80: irq 3
usb2 at uhci2: USB revision 1.0
uhub2 at usb2
uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
[...]
uhidev0 at uhub0 port 1 configuration 1 interface 0
uhidev0: Microsoft Microsoft Wireless Optical Mouse\M-. 1.0A, rev
2.00/0.17, addr 2, iclass 3/1
uhidev0: 2 report ids
uhid at uhidev0 reportid 1 not configured
uhid at uhidev0 reportid 2 not configured
After installing, the mouse is unresponsive.
Hoping this helps turn on a light bulb :)
-aDe
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
__FreeBSD_version bump for loss of perl
Could we have a __FreeBSD_version bump for the diking out of perl from the base system please? A chunk of ports work needs to be done to conditionally use perl vs sed for in-line replacements on lots of Makefiles. Thanks, -aDe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: __FreeBSD_version bump for loss of perl
On 05/16/02 17:46, "Maxime Henrion" <[EMAIL PROTECTED]> wrote:
> I agree that a __FreeBSD_version bump is appropriate, but why not always
> simply use sed for this ?
Because not everyone using the ports system has the in-place editing feature
of sed that was recently added, and thus it needs to be conditional on
${OSVERSION}.
-aDe
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Perl script rewrites - progress (2)
On 05/18/02 12:05, "Mark Murray" <[EMAIL PROTECTED]> wrote: > Hi all > > The perl script rewrite is going really well! > > Here is my progress file, as it currently stands: To add one to the list.. /usr/sbin/mergemaster has two calls to perl in it, to extract file/directory permissions -- anyone (doug?) working on this? -aDe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP: ports/ and 10.0-CURRENT
With the advent of the conversion of HEAD to 10.0-CURRENT and, as to be expected, ports/ is going to be essentially unusable for a while. The issue stems from configure scripts (to choose something completely at random) assuming that FreeBSD would never jump to a double-digit major version number, and as such, various regexps for "freebsd1*" (ie: FreeBSD 1.1.x) are now matching "freebsd10". This is going to be some fairly fundamental breakage. However, until such time as 9.0-RELEASE is completely out of the door, with autotools hat on, I will _not_ be committing any changes to infrastructural ports to "fix" this. That is to say, until 9.0-R happens, and for some considerable period afterwards, ya'll can pretty much expect ports/ to be non-functional on HEAD. PRs mentioning this will be gleefully closed referencing this message. -aDe Reply-To set to me. Please honor it. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: ports/ and 10.0-CURRENT
> It just means that folks didn't plan ahead and didn't think up > proper contingency plans. First off, apologies to Garrett, I'm not picking on you directly, but I kinda knew this would come up. The undeniable fact is that configure scripts in general have chosen to do things a certain way. Unfortunately for us (us being FreeBSD), we have now broken these conceptions by moving to a dual-digit major release. Emails have been passed around (somewhere starting around the 7.x series when it became obvious we would be hitting 10.x a lot sooner than expected). It is no-one's fault that 23,000+ third party applications couldn't be tweaked prior to a trivial change in /sys/conf/newvers.sh that resulted in this "oops". The message I wanted to set across is that until such time as us ports folks have had a chance to really work out the damage, and start on fixing it, then for those running 10-CURRENT, things are likely to be non-linear for a while. Our primary responsibility right now is to ensure that a proper set of packages gets built for the impending 9.0-RELEASE. We haven't forgotten you bleeding edge folks, it's just that right now, you're somewhat down the food chain. Make no mistake. This move to a double-digit major version number is going to cause serious pain. We will do our best to fix, hack, slash, and whatever around it, but right now the focus is the last of our remaining single-digit releases. Until that is out the door, do not be expecting tree-wide commits to fix things. -aDe ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: setting CC/CXX/CPP unconditionally in src.conf
On 2/28/2012 14:11, Alexander Best wrote:
any chance we can have a CFLAGS.gcc and CFLAGS.clang in the future? that would
make certain things a lot easier. dealing with gcc specific options, such as
-mpreferred-stack-boundary=2 would simply work by setting
CFLAGS.gcc=-mpreferred-stack-boundary=2 e.g.
You already can:
CFLAGS.cc= cc_cflags_here
CFLAGS.clang= clang_cflags_here
CFLAGS+=generic_cflags_here
CFLAGS+=${CFLAGS.${CC}}
-aDe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: setting CC/CXX/CPP unconditionally in src.conf
On 2/28/2012 16:08, Chuck Burns wrote:
On 2/28/2012 4:55 PM, Ade Lovett wrote:
On 2/28/2012 14:11, Alexander Best wrote:
any chance we can have a CFLAGS.gcc and CFLAGS.clang in the future?
that would
make certain things a lot easier. dealing with gcc specific options,
such as
-mpreferred-stack-boundary=2 would simply work by setting
CFLAGS.gcc=-mpreferred-stack-boundary=2 e.g.
You already can:
CFLAGS.cc= cc_cflags_here
CFLAGS.clang= clang_cflags_here
CFLAGS+= generic_cflags_here
CFLAGS+= ${CFLAGS.${CC}}
-aDe
I think was asking for adding a third...
.cc for base gcc
.clang for .. clang..
and .gcc for ports gcc4x
..
At least, thats how I read it, I could be wrong, it's happened before.
CFLAGS.gcc46=
CFLAGS.gcc47=
...
it's entirely extensible.
-aDe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
