obviously, i need more beer. without it, i add extra commas. no one should do this stuff without beer fixed ... Index: uplcom.c =================================================================== RCS file: /cvs/src/sys/dev/usb/uplcom.c,v retrieving revision 1.53 diff -u uplcom.c --- uplcom.c 24 Sep 2010 08:33:59 -0000 1.53 +++ uplcom.c 16 Nov 2010 22:02:55 -0000 @@ -164,6 +164,7 @@ { USB_VENDOR_PROLIFIC, USB_PRODUCT_PROLIFIC_PL2303X }, { USB_VENDOR_PROLIFIC, ...

[IMAGE] Si vous ne visualisez pas correctement ce mail, veuillez cliquer ici [IMAGE] COMPARK FRANCE Avenue de GalilC)e 86360 FUTUROSCOPE TC)l.: 05 49 49 00 41 Click logo Communicate and Identify your parking spaces The Com'Park is the first outdoor advertising display for the floor. It fits perfectly into its urban surroundings. Patented product. En application de la loi Informatique et LibertC)s en date du 6 janvier 1978, vous disposez d'un droit d'accC(s, de ...

(Feel myself like a spammer today... :-\ ) And now with fixed rule reference counting in if_pfsync.c (modelled after pf_test_rule()): if (rtr != NULL && rtr != r) { /* * We need to keep the routing rule in case of changes, * so add a reference. * * XXX: Need accounting for other match rules? */ SLIST_INIT(&st->match_rules); if ((ri = pool_get(&pf_rule_item_pl, pool_flags)) == NULL) goto cleanup; ri->r = rtr; SLIST_INSERT_HEAD(&st->match_rules, ri, ...

Thanks, committed.

Si vous ne lisez pas correctement ce mail vous devez le visualiser en html

Third try. Looks like we don't need to cope with pfsync at all, as the rule information was used only for state accounting, which is done already. BTW, pflog(4) page needs update after recent pflog changes too, so I did not touched it this time. Index: sys/net/if_pflog.c =================================================================== RCS file: /cvs/src/sys/net/if_pflog.c,v retrieving revision 1.32 diff -u -p -r1.32 if_pflog.c --- sys/net/if_pflog.c 21 Sep 2010 22:49:14 -0000 1.32 +++ ...

Uhmmm... It's still failing for me with libpthread.so.13.1 and glib2-2.26.1. Thunar only works if you compile it using "-O0", which is also strange. Btw, It's the same failure reported here: https://labs.omniti.com/labs/reconnoiter/lists/users/2010-August/000510.html And here: http://marc.info/?l=openbsd-ports&m=128785324016639 Ciao, David

If you are having trouble viewing this message, please click here. E-mail Security Information. Chase Logo Welcome to your new Chase Platinum Visa(R) Card Make managing your account quick and easy. Try Chase Online(SM) today! Sign Up for Chase Online(SM) at www.chase.com/creditcards View Account Activity Pay Your Bill Get Online Statements Transfer Balances Activate Account Alerts Set Up Automatic Payments Access Your Account Online Access your account on the go with ...

On 2010/11/16 04:50, Vadim Zhukov wrote: [..] Great stuff, this has annoyed me for a while :) I can't test today but Afaik the strictest requirements on any arch we support is that a data type must be aligned to the size of that data type. 32-bit I might be mistaken but I think this will break compatibility with the pfsync wire format used by earlier versions.

I don't think so. It's the compiler's job to align the struct fields properly. As long as you do not access the field using pointer tricks you're safe. I do not know if pf is doing that. Another reason to do "manual" layout is when the struct is used on the wire. There is a guideline to lay out structs starting with the biggest field and then working to smaller ones. This guideline is ambiguous since the size of fields is depedent on the target. Still, some effort wrt this is preferred ...

Second try. Fixes (thank you, Henning, for fast, actual comments): - Old and new pfsync should now co-operate smoothly, assuming you do not use routing options on "match" rules until all firewalls got updated. If you will not, you'll shoot yourself in the foot: stats and traffic may get screwed, not checked if that may cause panics. Again: pfsync was NOT tested in real environment. - More style(9) compliance. Not sure about struct pf_state change, though: will it ever ...

There is no stem in there. A pkgpath is something different. For a pkgspec, the - does makes some sense, because we go from screen-3.0.2 to screen->=3.0.2 but in misc/screen there's never been any -, so misc/screen>=3.02 should be okay. That said, it's likely that more verifications for valid specs might save some people some head-scratching...