Re: 802.1X - WPA enterprise mode not yet supported ?
On Mon, Jun 28, 2010 at 08:00:34PM +0200, Christopher Zimmermann wrote: it just took me 2 hours to figure out that OpenBSD does not yet support the WPA enterprise mode (aka 802.1X). Is this actually true? If yes, please include the patch below to make this clear in the man page. yes, see ifconfig.8 cvs log -r1.55: revision 1.155 date: 2008/04/16 18:32:15; author: damien; state: Exp; lines: +137 -6 Kernel implementation of the 4-way handshake and group-key handshake protocols (both supplicant and authenticator state machines) as defined in the IEEE 802.11i standard. Software implementation of the TKIP (Temporal Key Integrity Protocol) and CCMP (CTR with CBC-MAC Protocol) protocols. This diff doesn't implement any of the 802.1X authentication protocols and thus only PSK authentication (using pre-shared keys) is currently supported. ... = i've updated the man page. jmc
shared libs and ports, maybe a proposal
each time xenocara farts, we get new libs (or less libs). in order for updates to work, we *should* propagate those changes to @wantlib in each port. This currently isn't done automatically... check-lib-depends is sloooww (needs to check every file before packaging) and not even flawless. I'm beginning to think we should split *most* of the related info info a separate file, so that updates can be done automatically (for the most part). Briefly, the only info that changes is - p* numbers (e.g., PKGNAME = somethingpN) - WANTLIB for the affected package. As much as I don't like adding, as naddy would put it, more magic, I think the p* numbers could live in a separate file, along with most WANTLIB. e.g., we would have something like: REVISION-main = 5 REVISION-a = 2 WANTLIB-main += foo bar WANTLIB-a += x z in a separate file (say libinfo) (or we can even have this in the main Makefile, with proper markers for auto-update). Each time check-lib-depends runs, it would update this file... People could also update the REVISION* numbers carefully. (having WANTLIB += is because in some cases, we do need to have basic wantlib first) I'm going to see if I can make check-lib-depends perfect. I'd like a bit of input about this scheme...
acpi woes on recent ASUS laptops
Hi t...@!
acpiac(4) and acpibat(4) on my ASUS UL30A laptop are not working
correctly. On load, both devices return 'not present'. However, when the
embedded controller fires a GPE event on ac/battery insertion/removal,
they suddenly appear and apm(8) reports their status correctly.
Under Linux/FreeBSD, both devices work as expected without physically
removing or inserting the devices. My initial thought was that I had a
broken DSDT that Linux/FreeBSD had some magical workaround for. Looking
through their implementations, the only quirk I've found for ASUS
machines is for certain models that have a broken ECDT.
Looking through the control methods for the simplest device, the AC
adapter, I find this:
Scope(_SB_.PCI0) {
Device(AC0_) {
Name(_HID, ACPI0003)
Method(_PSR) {
Return(^^SBRG.EC0_.ACAP())
}
Name(_PCL, Package(0x1) {
PCI0,
})
}
}
SBRG.EC0_.ACAP() looks like this:
Method(ACAP, 0, Serialized) {
Return(ACPF)
}
And ACPF is defined in:
OperationRegion(RAMW, SystemMemory, RAMB, 0x0100)
Field(RAMW, AnyAcc, NoLock, Preserve) {
--- SNIP
ACPF, 8,
--- SNIP
}
RAMB:
OperationRegion(ECMS, SystemIO, 0x72, 0x2)
Field(ECMS, ByteAcc, Lock, Preserve) {
EIND, 8,
EDAT, 8
}
IndexField(EIND, EDAT, ByteAcc, NoLock, Preserve) {
Offset(0x48),
IKFG, 8,
FRPN, 16,
RAMB, 32,
--- SNIP ---
}
Greping through a dmesg of a kernel built with ACPI_DEBUG, it turns out
that ACPF has a (garbage?) value of 0x8c. Is the OS responsible for
running control methods to populate these fields with the right values, or
is this something the BIOS handles?
As stated above, once the GPE event handler runs the query method (_QA0)
for the device, the fields get the right value (PSR_ONLINE, PSR_OFFLINE).
Any help at where to look next would be appreciated.
The full DSDT for this machine can be found at:
http://orskaug.org/acpidump.out
Re: shared libs and ports, maybe a proposal
On Thu, Jul 08, 2010 at 12:03:47PM +0100, Stuart Henderson wrote: On 2010/07/08 11:50, Marc Espie wrote: each time xenocara farts, we get new libs (or less libs). in order for updates to work, we *should* propagate those changes to @wantlib in each port. This currently isn't done automatically... check-lib-depends is sloooww (needs to check every file before packaging) and not even flawless. I'm beginning to think we should split *most* of the related info info a separate file, so that updates can be done automatically (for the most part). Briefly, the only info that changes is - p* numbers (e.g., PKGNAME = somethingpN) - WANTLIB for the affected package. As much as I don't like adding, as naddy would put it, more magic, I think the p* numbers could live in a separate file, along with most WANTLIB. e.g., we would have something like: REVISION-main = 5 REVISION-a = 2 WANTLIB-main += foo bar WANTLIB-a += x z in a separate file (say libinfo) (or we can even have this in the main Makefile, with proper markers for auto-update). Each time check-lib-depends runs, it would update this file... People could also update the REVISION* numbers carefully. (having WANTLIB += is because in some cases, we do need to have basic wantlib first) I'm going to see if I can make check-lib-depends perfect. I'd like a bit of input about this scheme... I like having REVISION defined separately from PKGNAME, it will definitely makes it easier to update in batches, and removes a source of possible errors. I'm less keen on having this in a separate file - I see why you want to do this but I think the disadvantages outweigh it - slower checkouts, more inodes, cvs conflicts in more files, and until every existing port is moved over I think the inconsistency between different ports will be a source of confusion.. I would be happy to have this in the main Makefile with markers (and also to require certain standards for WANTLIB entries there to allow automated updates - e.g. I think requiring separate += lines rather than \ continuations is probably a good idea here). Of course we need to cater for other WANTLIB entries e.g. for the cases when a flavour adds new wantlib. I expect that specific FLAVORS will still require manual intervention. That's one reason for the WANTLIB += adding extra stuff if it's not detected is very simple. Separate file vs same file: + upstream-specific churn will show up only in that file + easier to update automatically - more inodes. - cvs conflicts (I doubt it will matter that much). I guess I can make a combination of introspection (reading existing values directly with make show=VALUE) + automatic modification (touch only a part of the Makefile that's explicitly # XXX don't touch) to put things in the same file...
Re: shared libs and ports, maybe a proposal
On Thu, Jul 08, 2010 at 11:50:39AM +0200, Marc Espie wrote: each time xenocara farts, we get new libs (or less libs). in order for updates to work, we *should* propagate those changes to @wantlib in each port. For the base and xenocara libs, wouldn't it make sense to have some modules centralizing the version info (and even some dependencicies) so that instead of WANTLIB declaratons you coud have .include libX11.dep.mk .include libc.dep.mk or something similar? Then only one central fil would need to be updated when revisions changes. And even if libX11 gains new depencies, you would not be reqired to add the manually to a zillon of ports's Makefiles. -- Matthieu Herrb
Re: shared libs and ports, maybe a proposal
On Thursday 08 July 2010 02:03:41 pm Matthieu Herrb wrote: On Thu, Jul 08, 2010 at 11:50:39AM +0200, Marc Espie wrote: each time xenocara farts, we get new libs (or less libs). in order for updates to work, we *should* propagate those changes to @wantlib in each port. For the base and xenocara libs, wouldn't it make sense to have some modules centralizing the version info (and even some dependencicies) so that instead of WANTLIB declaratons you coud have .include libX11.dep.mk .include libc.dep.mk or something similar? Then only one central fil would need to be updated when revisions changes. And even if libX11 gains new depencies, you would not be reqired to add the manually to a zillon of ports's Makefiles. And that would maybe allow to have ARCH dependent stuff in those files to handle availability libs on different archs, i.e. at least VAX doesn't have pthread-stubs and xcb, don't know about others. cheers, Sebastian
Planes bajo CUIT Con Equipos y Abonos Bonificados - tech
Es Simple, Es Claro. Descubra la mejor y mas econsmica manera de comunicarse. Comunicacisn entre los equipos de su flota gratuita e ilimitada en todo el pams. Equipos totalmente bonificados. === Porque queremos que usted tambiin sea parte de la compaqma N01 de comunicaciones en Amirica. Para que tenga la mas amplia cobertura, el mejor precio y la mayor variedad de servicios. Le acercamos las mejores opciones del mercado en telefonma celular para clientes con CUIT en flotas PYME y Corporativas. OPCISN 1. PLANES TRADICIONALES Lmneas Plan Costo Minuto Incluido. Minutos Totales. Costo Total por Flota. Costo Minuto Excdente. Equipos 100% Bonificados. Bonificaciones Especiales 6 $29 $0.26 660 $174 $0.26 6 del rango B 50% de la primer factura 6 $39 $0.25 930 $234 $0.25 6 del rango B 50% de la primer factura 10 $29 $0.23 1250 $290 $0.23 10 del rango B 50% de la primer factura + 100 SMS gratis por lmnea por un aqo 10 $39 $0.22 1800 $390 $0.22 10 del rango B 50% de la primer factura + 100 SMS gratis por lmnea por un aqo 20 $29 $0.22 2600 $580 $0.20 3 del rango M + 17 del rango B 50% de las primeras dos facturas + 100 SMS gratis por lmnea por un aqo + 10 destinos virtuales por lmnea a costo $0 (*) 20 $39 $0.19 4200 $780 $0.20 1 del rango P + 2 del rango A + 4 del rango M + 13 del rango B 50% de las primeras dos facturas + 100 SMS gratis por lmnea por un aqo + 10 destinos virtuales por lmnea a costo $0 (*) 60 $29 $0.21 8400 $1740 $0.20 9 del rango M + 51 del rango B 50% de las primeras cuatro facturas + 200 SMS gratis por lmnea por un aqo + 10 destinos virtuales por lmnea a costo $0 (*) 60 $39 $0.17 13800 $2340 $0.20 3 del rango P + 6 del rango A + 12 del rango M + 39 del rango B 50% de las primeras cuatro facturas + 200 SMS gratis por lmnea por un aqo + 10 destinos virtuales por lmnea a costo $0 (*) Los precios no incluyen IVA. Los nzmeros Claro fuera de la flota deben ser nzmeros Claro Pospagos (no pueden ser ni Prepagos ni Cuenta Segura). La bonificacisn sobre la factura incluye solo los abonos. (*) Requiere el servicio de VPN. EQUIPOS EN SUBSIDIO TOTAL (click sobre el nombre para ver la descripcisn del equipo) RANGO A RANGO B RANGO M RANGO P LG kp570 LG 105 Sony W205 Xperia X1 Samsung 3410 Nokia 1208 Samsung E215 Samsung F480 ZTE I766 Samsung E1086 Motorola U9 Nokia E71 LG KP 330 Pantech 1410 Alcatel OT 701 BlackBerry 8220 Los modelos de los equipos son a eleccisn del cliente aunque, lsgicamente, estan tambiin sujetos a disponibilidad de stock. CONSULTE TAMBIEN POR OTROS MODELOS DE EQUIPOS DISPONIBLES OPCISN 2. PLAN ZNICO Es un nuevo concepto en flotas corporativas. Usted contrata una bolsa de minutos que puede repartir en la cantidad de lmneas que necesite. La activacisn de estos planes es INMEDIATA (presentando sslo fotocopia de DNI, Inscripcisn o exencisn en IIBB y fotocopia de un servicio a su nombre).Recibe, de acuedo al plan contratado, un monto de dinero libre que puede utilizar para adquirir los equipos que prefiera. Este monto es renovable cada 24 meses, es decir que, cada 24 meses recibira nuevamente este monto para poder volver a utilizarlo y renovar sus equipos. Cantidad Maxima de lmneas Monto Plan Unico (MENSUAL) Rendimiento de minutos Precio minuto incluido Monto disp. equipos (PRECIO DE LISTA) Cantidad Maxima de lmneas Monto Plan Unico (MENSUAL) Rendimiento de minutos Precio minuto incluido Monto disp. equipos (PRECIO DE LISTA) 3 $ 147 432 $ 0,34 $ 780 34 $ 1.666 8330 $ 0,20 $ 8.150 5 $ 245 845 $ 0,29 $ 1.300 39 $ 1.911 9555 $ 0,20 $ 8.350 7 $ 343 1183 $ 0,29 $ 1.745 49 $ 1.990 9950 $ 0,20 $ 8.500 9 $ 441 1633 $ 0,27 $ 2.200 59 $ 2.490 12450 $ 0,20 $ 12.500 14 $ 686 2541 $ 0,27 $ 3.260 69 $ 2.990 16611 $ 0,18 $ 15.000 19 $ 990 4125 $ 0,24 $ 4.200 79 $ 3.424 19022 $ 0,18 $ 17.000 24 $ 1.176 4900 $ 0,24 $ 6.500 89 $ 3.856 21422 $ 0,18 $ 19.000 29 $ 1.490 7450 $ 0,20 $ 7.800 99 $ 4.290 23833 $ 0,18 $ 21.200 Si usted ya es cliente de Claro contactese con nosotros para recibir una propuesta de optimizacisn de su cuenta. Beneficios de las Flotas Claro 7 Comunicacisn gratuita, libre e ilimitada entre todos los miembros de la flota desde y hacia cualquier lugar del pams. 7 Bolsa de minutos (clearing) para repartir los minutos totales de su flota en los telifonos que quiera e incluso dejar parte de la flota solo para comunicacisn interna y que no generen consumo. 7 Tarifa Plana y Nacional. No importa si llama a un fijo o a un celular, si es corta distancia o larga distancia. El minuto siempre rinde lo mismo y no paga ningun concepto de red, LDN, tierra, etc. 7 Red Privada Virtual, herramienta que sirve para administrar los telefonos como si fueran internos de su
Re: shared libs and ports, maybe a proposal
On Thu, 8 Jul 2010, Marc Espie wrote: On Thu, Jul 08, 2010 at 02:03:41PM +0200, Matthieu Herrb wrote: On Thu, Jul 08, 2010 at 11:50:39AM +0200, Marc Espie wrote: each time xenocara farts, we get new libs (or less libs). in order for updates to work, we *should* propagate those changes to @wantlib in each port. For the base and xenocara libs, wouldn't it make sense to have some modules centralizing the version info (and even some dependencicies) so that instead of WANTLIB declaratons you coud have .include libX11.dep.mk .include libc.dep.mk or something similar? Then only one central fil would need to be updated when revisions changes. And even if libX11 gains new depencies, you would not be reqired to add the manually to a zillon of ports's Makefiles. Nope, because it does not do half the work: bumping pkgnames. Doing stuff automatically every time will mean you will get to update a lot of packages. Basically, if you have two packages with the same name, and differing WANTLIB, how do you know which one is the newest ? the one with the highest CVS revision ID attached? The CVS revision number is guaranteed atomically increasing and only relevant if it's used as a tie breaker against two otherwise similar versions. there's probably an obvious reason why this is a bad idea. Sam -- Talk does not cook rice - Chinese Proverb
Re: shared libs and ports, maybe a proposal
Marc Espie es...@nerim.net wrote: Briefly, the only info that changes is - p* numbers (e.g., PKGNAME = somethingpN) - WANTLIB for the affected package. As much as I don't like adding, as naddy would put it, more magic, I think the p* numbers could live in a separate file, along with most WANTLIB. I think both sthen@ and I have mentioned before that we really like how FreeBSD has the revision in a separate PORTREVISION variable that is much easier and less error prone to increment than pX suffixes in PKGNAME. e.g., we would have something like: REVISION-main = 5 REVISION-a = 2 Yes. And consider putting vX in a separate variable as well while you're there (` la FreeBSD's PORTEPOCH). WANTLIB-main += foo bar WANTLIB-a += x z in a separate file (say libinfo) I'm not keen on a separate file. -- Christian naddy Weisgerber na...@mips.inka.de
