Re: [patch] fsdb cleanup
On Thu, Mar 21, 2013 at 6:50 PM, David Hill wrote: > use %u for unsigned (ino_t). Mumble mumble 64bit ino_t in the future mumble mumble
Re: rthread suspension
On Fri, Mar 22, 2013 at 11:19:43PM -0400, James Turner wrote: > On Fri, Mar 22, 2013 at 10:05:49PM -0500, Kurt Miller wrote: > > On Friday 22 March 2013 4:08:47 pm James Turner wrote: > > > On Thu, Mar 21, 2013 at 10:01:42PM -0500, Kurt Miller wrote: > > [snip] > > > > > I stalled on submitting them with upstream. I ran into a snafu. > > > > However, I > > > > do have an update for boehm-gc that can be tested. There's one i386 > > > > machine in my cluster that doesn't behave which is one of the reasons > > > > I haven't moved this forward yet. It is on my todo list which I'm > > > > chipping > > > > away at little by little. > > > > > > > > -Kurt > > > > > > boehm-gc built and packaged fine on mips64el but all tests failed > > > miserably. > > > > > > > Thanks for the report. Does the 7.0 one in ports current work or fail too? > > > > -Kurt > > > > It's currently marked as NOT_FOR_ARCHS. The current version does build, > but fails all tests as well. So no change really and probably not worth > removing from NOT_FOR_ARCHS. > > -- > James Turner > Sent this to ports@ by mistake. Moving back to tech@. -- James Turner
Re: rthread suspension
On Friday 22 March 2013 4:08:47 pm James Turner wrote: > On Thu, Mar 21, 2013 at 10:01:42PM -0500, Kurt Miller wrote: > > On Thursday 21 March 2013 7:47:34 am Brad Smith wrote: > > > On Thu, Mar 21, 2013 at 11:43:15AM +, Stuart Henderson wrote: > > > > On 2013/03/21 12:32, Taylan Ulrich B. wrote: > > > > > Stuart Henderson writes: > > > > > > > > > > > As I said, "perhaps the uthread workarounds that we used to have > > > > > > in the port got committed upstream and now need to be reverted?" > > > > > > > > > > > > i.e. _used_ to have, before the change to rthreads. > > > > > > > > > > Oh sorry, I understand now. Indeed, the patches in e.g. 5.0 ports > > > > > seem > > > > > equivalent to what is now upstream (although not exactly identical). > > > > > > > > > > In your opinion, should upstream Boehm GC try to support pre-rthreads > > > > > OpenBSD versions as well, or drop that and only support rthreads? > > > > > (Or do > > > > > the new patches work for both?) > > > > > > > > As far as I'm concerned it's not really worth supporting both, but > > > > this depends on their usual policies.. > > > > > > Upstream insisted on supporting both. > > > > > > > > Any way, the new patches will have to be integrated to master. Would > > > > > anyone like to take that job? If not, I'd like to try, although I > > > > > don't > > > > > know how long it would take for me. > > > > > > > > I don't want that job ;) > > > > > > AFAIK Kurt was talking about this recently and he was working with > > > upstream > > > to have the patches integrated. > > > > I stalled on submitting them with upstream. I ran into a snafu. However, I > > do have an update for boehm-gc that can be tested. There's one i386 > > machine in my cluster that doesn't behave which is one of the reasons > > I haven't moved this forward yet. It is on my todo list which I'm chipping > > away at little by little. > > > > -Kurt > > boehm-gc built and packaged fine on mips64el but all tests failed > miserably. > Thanks for the report. Does the 7.0 one in ports current work or fail too? -Kurt
Re: rthread suspension
On 03/22/13 08:35, Stuart Henderson wrote: > On 2013/03/21 22:01, Kurt Miller wrote: >> I stalled on submitting them with upstream. I ran into a snafu. However, I >> do have an update for boehm-gc that can be tested. There's one i386 >> machine in my cluster that doesn't behave which is one of the reasons >> I haven't moved this forward yet. It is on my todo list which I'm chipping >> away at little by little. > > Regression tests all pass on macppc, i386, amd64, and I've tried w3m > a bit on these 3 arches (w3m has had problems in the past even though > regression tests were all OK); no problems noted there. > > It would be good if someone could do similar tests on other arch, > in particular hppa if it hasn't already been tested. > Thanks Stuart. I sent the diff before I reviewed the old patches and I removed two patches that should stay: patch-bdw-gc_pc_in patch-doc_gc_man Well actually the gc man patch needs to be updated since it refers to header file that no longer exists. I'll send a new revision when I get back from a short family vacation. Thanks, -Kurt
F21->F24 escape codes in wsemul_vt100_keys.c
Hi Miod,
We need to generate escape codes for the extra function keys,
otherwise wsemul_vt100_keys.c tries to generate an ASCII code from
the keysym value, which gives us ^T ^U ^V ^W, which is not
particularly helpful.
There are no standard escape codes, and those for F1-F5 don't match
our defaults in xterm anyway, so I've just continued the sequence,
and am working on an updated termcap to support them anyway.
--- wsemul_vt100_keys.c.origFri Mar 22 17:46:29 2013
+++ wsemul_vt100_keys.c Fri Mar 22 17:50:00 2013
@@ -58,6 +58,10 @@
"\033[32~",
"\033[33~",
"\033[34~", /* F20 */
+ "\033[35~", /* F21 */
+ "\033[36~", /* F22 */
+ "\033[37~", /* F23 */
+ "\033[38~", /* F24 */
};
static const char *vt100_pfkeys[] = {
@@ -86,11 +90,11 @@
struct wsemul_vt100_emuldata *edp = cookie;
static char c;
- if (in >= KS_f1 && in <= KS_f20) {
+ if (in >= KS_f1 && in <= KS_f24) {
*out = vt100_fkeys[in - KS_f1];
return (5);
}
- if (in >= KS_F1 && in <= KS_F20) {
+ if (in >= KS_F1 && in <= KS_F24) {
*out = vt100_fkeys[in - KS_F1];
return (5);
}
--
Creamy
Re: UPDATE: xkeyboard-config 2.8
On Wed, Mar 20, 2013 at 12:03:34AM +0600, Alexandr Shadchin wrote: > Hi, > > This update xkeyboard-config to the latest release 2.8. > http://koba.devio.us/distfiles/xkeyboard-config-2.8.diff > > Change: > * 18 bugs fixed > * Most important change: a lot of materials updated from Oracle (Sun > keyboards) > * Updated translations > > Tested on amd64. > > Comments ? OK ?. I'm a bit worried that this update seem to remove all old Sun keyboard definitions and only keep type 6 & 7. We have users still using type 3 & 4, and a lot of type 5 keyboards. I haven't tried it on an actual sparc yet to confirm the issue. -- Matthieu Herrb
Re: rthread suspension
On Thu, Mar 21, 2013 at 10:01:42PM -0500, Kurt Miller wrote: > On Thursday 21 March 2013 7:47:34 am Brad Smith wrote: > > On Thu, Mar 21, 2013 at 11:43:15AM +, Stuart Henderson wrote: > > > On 2013/03/21 12:32, Taylan Ulrich B. wrote: > > > > Stuart Henderson writes: > > > > > > > > > As I said, "perhaps the uthread workarounds that we used to have > > > > > in the port got committed upstream and now need to be reverted?" > > > > > > > > > > i.e. _used_ to have, before the change to rthreads. > > > > > > > > Oh sorry, I understand now. Indeed, the patches in e.g. 5.0 ports seem > > > > equivalent to what is now upstream (although not exactly identical). > > > > > > > > In your opinion, should upstream Boehm GC try to support pre-rthreads > > > > OpenBSD versions as well, or drop that and only support rthreads? (Or > > > > do > > > > the new patches work for both?) > > > > > > As far as I'm concerned it's not really worth supporting both, but > > > this depends on their usual policies.. > > > > Upstream insisted on supporting both. > > > > > > Any way, the new patches will have to be integrated to master. Would > > > > anyone like to take that job? If not, I'd like to try, although I don't > > > > know how long it would take for me. > > > > > > I don't want that job ;) > > > > AFAIK Kurt was talking about this recently and he was working with upstream > > to have the patches integrated. > > I stalled on submitting them with upstream. I ran into a snafu. However, I > do have an update for boehm-gc that can be tested. There's one i386 > machine in my cluster that doesn't behave which is one of the reasons > I haven't moved this forward yet. It is on my todo list which I'm chipping > away at little by little. > > -Kurt boehm-gc built and packaged fine on mips64el but all tests failed miserably. -- James Turner
Re: amd64 ports failures with new binutils
(2) A whole bunch of ports fail along the lines of ld: foo.o: relocation R_X86_64_PC32 against `bar' can not be used when making a shared object; recompile with -fPIC A similar issue compiling a program in current was discussed here: https://groups.google.com/forum/?fromgroups=#!topic/OpenBSD-Colombia/Qi2X9Yyh3xc Sergio solved it by adding -Wl,-non_shared in LDFLAGS Helps? -- Dios, gracias por tu amor infinito. -- Vladimir Támara Patiño. http://vtamara.pasosdeJesus.org/ http://www.pasosdejesus.org/dominio_publico_colombia.html
Re: /usr.bin/colldef and collation tables
On Fri, Mar 22, 2013 at 05:56:50AM -0500, Vladimir Támara Patiño wrote: > I reworked collation support based on: > http://marc.info/?l=openbsd-tech&m=136283674512235&w=4 > > Here I'm attaching a first part consisting of: > > * The program colldef based on FreeBSD (similar to mklocale that is > based on NetBSD). This programa generates files LC_COLLATE good > only for single-byte encondings. > * Collation tables based on FreeBSD (similar to ctype case that is > based on NetBSD) for all the single-byte locales that OpenBSD > currently support (and some other that could be added or ignored). > * Header lib/libc/locale/collate.h required by colldef and for next > part of collation support. Thanks! I've reviewed this but haven't tried running it yet. It looks like a good starting point. The colldef.1 man page contains typos. And it doesn't pass mandoc -Tlint and that alone would break the build. realloc() calls in parse.y violate best practice rules explained in the malloc(3) man page. It seems parse.y also contains some macros to support compilers other than gcc, I don't think it's worth adding these yet. The __printflike() macro should be dropped, it is used to redefine yyerror(). Please change this to look like in other parse.y files in the OpenBSD src tree (e.g. look at bgpd). The parse.y file also contains some indentation style issues, but those can be fixed later. The file share/locale/colldef/Makefile contains comments that explain differences to FreeBSD. Such comments make some sense in email you send to tech@ but they don't need to be in the source code. The file also lists locales which do not have corresponding ctype locale defintions yet. Please do not add them to LC_COLLATE just yet. We can add them later if needed. For now they just clutter your diff and add additional files to the installation sets, which is something we should discuss separately (see the other tech@ discussion about your ctype Makefile diff). Adding new locales and adding support for LC_COLLATE are difference concerns and should be done in separate diffs in my opinion. The collate.h files seems to contain definitions not used by colldef. Can we please start out with a header file that only contains things which are actually used?
Re: Typos in net/bpf.h
On Fri, Mar 22, 2013 at 10:38:25AM -0600, Theo de Raadt wrote: > > On 03/22/13 17:25, Philip Guenther wrote: > > > On Fri, Mar 22, 2013 at 7:53 AM, Gabriel Linder > > > wrote: > > >> - * bpf understands a program iff kernel_major == filter_major && > > >> + * bpf understands a program if kernel_major == filter_major && > > > Not a typo: "iff" is a shorthand for "if and only if" that was > > > inherited from the mathematics community. > > > > I did not know that, thanks. Maybe it should be spelled in full letters > > then ? > > iff is a useful technical word which avoids us typing it out in full > every time. iff you know what it means :-) -- Creamy
Re: Typos in net/bpf.h
On 03/22/13 17:38, Theo de Raadt wrote: >> On 03/22/13 17:25, Philip Guenther wrote: >>> On Fri, Mar 22, 2013 at 7:53 AM, Gabriel Linder >>> wrote: - * bpf understands a program iff kernel_major == filter_major && + * bpf understands a program if kernel_major == filter_major && >>> Not a typo: "iff" is a shorthand for "if and only if" that was >>> inherited from the mathematics community. >> I did not know that, thanks. Maybe it should be spelled in full letters then >> ? > iff is a useful technical word which avoids us typing it out in full > every time. > > If we replaced such simple words everytime someone didn't understand them, > eventually our in-line code would be full of babytalk. > Makes sense. What about the rest of the diff ? Index: bpf.h === RCS file: /cvs/src/sys/net/bpf.h,v retrieving revision 1.43 diff -u -r1.43 bpf.h --- bpf.h 26 Mar 2012 19:37:42 - 1.43 +++ bpf.h 22 Mar 2013 16:44:35 - @@ -73,12 +73,12 @@ }; /* - * Struct return by BIOCVERSION. This represents the version number of + * Struct returned by BIOCVERSION. This represents the version number of * the filter language described by the instruction encodings below. * bpf understands a program iff kernel_major == filter_major && * kernel_minor >= filter_minor, that is, if the value returned by the * running kernel has the same major number and a minor number equal - * equal to or less than the filter being downloaded. Otherwise, the + * to or greater than the filter being downloaded. Otherwise, the * results are undefined, meaning an error may be returned or packets * may be accepted haphazardly. * It has nothing to do with the source code version.
Re: Typos in net/bpf.h
> On 03/22/13 17:25, Philip Guenther wrote: > > On Fri, Mar 22, 2013 at 7:53 AM, Gabriel Linder > > wrote: > >> - * bpf understands a program iff kernel_major == filter_major && > >> + * bpf understands a program if kernel_major == filter_major && > > Not a typo: "iff" is a shorthand for "if and only if" that was > > inherited from the mathematics community. > > I did not know that, thanks. Maybe it should be spelled in full letters then ? iff is a useful technical word which avoids us typing it out in full every time. If we replaced such simple words everytime someone didn't understand them, eventually our in-line code would be full of babytalk.
Re: Typos in net/bpf.h
On 03/22/13 17:25, Philip Guenther wrote: > On Fri, Mar 22, 2013 at 7:53 AM, Gabriel Linder wrote: >> - * bpf understands a program iff kernel_major == filter_major && >> + * bpf understands a program if kernel_major == filter_major && > Not a typo: "iff" is a shorthand for "if and only if" that was > inherited from the mathematics community. I did not know that, thanks. Maybe it should be spelled in full letters then ?
Re: Typos in net/bpf.h
On Fri, Mar 22, 2013 at 03:53:07PM +0100, Gabriel Linder wrote: > While learning how to use BPF I fumbled on this, clarification is needed imho. > > ok ? > > Index: sys/net/bpf.h > === > RCS file: /cvs/src/sys/net/bpf.h,v > retrieving revision 1.43 > diff -u -r1.43 bpf.h > --- sys/net/bpf.h26 Mar 2012 19:37:42 -1.43 > +++ sys/net/bpf.h22 Mar 2013 14:48:21 - > @@ -73,12 +73,12 @@ > }; > > /* > - * Struct return by BIOCVERSION. This represents the version number of > + * Struct returned by BIOCVERSION. This represents the version number of > * the filter language described by the instruction encodings below. > - * bpf understands a program iff kernel_major == filter_major && > + * bpf understands a program if kernel_major == filter_major && This is not exactly a typo, I believe it means, 'if and only if'. However, iff is a bad term to use precisely for this reason, so please spell it out in full :-). -- Creamy
Re: Typos in net/bpf.h
On Fri, Mar 22, 2013 at 7:53 AM, Gabriel Linder wrote: > - * bpf understands a program iff kernel_major == filter_major && > + * bpf understands a program if kernel_major == filter_major && Not a typo: "iff" is a shorthand for "if and only if" that was inherited from the mathematics community.
Re: LC_CTYPE for spanish speaking countries
On Fri, Mar 22, 2013 at 12:29:19PM +0100, Stefan Sperling wrote: > On Fri, Mar 22, 2013 at 09:55:01AM +, Creamy wrote: > > Are you suggesting to add individual locales as and when a significant > > number of translations exist in ports, (good idea), or to select a > > few South-American dialects to represent the whole continent, (very > > bad idea)? > > A mix of the two. I don't want to make technical decisions based > on politics. Agreed. > I'd like to recognize and fix situations where people > are missing functionality from the system because their language > of choice is not represented properly. It's not a black and white > decision, it's a trade-off. Agreed - as pointed out in a previous message in this thread, for the time being, more benefit would come from improving es_ES. Any Spanish speaker who doesn't understand English would benefit significantly from this, and in any case, they are in the best position to provide us with a further translation for their local dialect. > Also, I think that extending the locale implementation (such as > adding support for LC_TIME, LC_COLLATE, etc) is much more important > at this stage than adding additional files to /usr/share/locale. Yes. > > There is often more difference between South-American dialects of > > Spanish than between any one of them and Castillian Spanish. How would > > you decide which country is going to represent the whole of the continent? > > That's a tough question, and I really don't mean to alienate people > who speak any of these dialects. But I'd like to avoid the situation > where typing the name of a locale is something that people associate > with their own identity. Because then, there would be no reason at > all to stop adding more locales until the /usr filesystem is full. I strongly agree here... > Systems like Debian ask their users to generate some selection of > locales during the installation process. I don't think it is a good > idea to ask users to make that kind of choice during system installation. > But it's a consequence of the fact that Debian has too many locales. ... and here ... > > > No offence, but to me, the name of a locale is just... a name. > > > Let's try to make useful functional changes to the system. > > > Adding locales for purely patriotic reasons seems like a waste of time > > > to me. > > > > I agree, especially as there will always be awkward individuals like me > > who live in one country, but speak mostly foreign languages, and use > > date formats and keyboard layouts which don't correspond to any standard > > locale either for the country they reside in, or the foreign languages > > they speak. > > Exactly. I'm a native speaker of German, but learned a significant > amount of English in Ireland during my teenage years forcing me to > slowly recover some chunks of my memory of German when I got back. > All my computers speak English to me and I speak English to them, > whether or not people around me speak German to me. I type on a US > keyboard (cannot type on German ones for the life of me), and prefer > to read dates with days given before months because that is what I'm > used to. > > My preferred personal locale would probably be called something > like en_IE_de_DE_kbd_US.UTF-8. ... for that exact reason! I think that there are broadly two types of people who are interested in internationalisation - those who are monolingual and only speak a language other than English, and those who work in mixed environments on a regular basis. Each group will have different views on what is a priority and what isn't. If you have ever been asked to type Spanish on a badly configured Japanese keyboard, on an old version of Windows NT which doesn't allow any real customisation of the keymap, you will understand. (Amasingly, typing Japanese on the keyboard was easy, despite it being mis-configured, as it was handled by a proprietary userland application). > > It only makes sense to add them if there is a real intention to use > > them. Why not just add individual locales as and when a significant number > > of translations exist in ports, as it gives people an incentive to translate > > in to their local language. > > I'd like to avoid making up a set of rules about when new locales can be > added. I think we should discuss this on a case-by-case basis, and allow > people who are genuinely missing functionality to make their case. Sure, but obviously the existance of a large number of translations adds weight to their case. -- Creamy
Typos in net/bpf.h
While learning how to use BPF I fumbled on this, clarification is needed imho. ok ? Index: sys/net/bpf.h === RCS file: /cvs/src/sys/net/bpf.h,v retrieving revision 1.43 diff -u -r1.43 bpf.h --- sys/net/bpf.h26 Mar 2012 19:37:42 -1.43 +++ sys/net/bpf.h22 Mar 2013 14:48:21 - @@ -73,12 +73,12 @@ }; /* - * Struct return by BIOCVERSION. This represents the version number of + * Struct returned by BIOCVERSION. This represents the version number of * the filter language described by the instruction encodings below. - * bpf understands a program iff kernel_major == filter_major && + * bpf understands a program if kernel_major == filter_major && * kernel_minor >= filter_minor, that is, if the value returned by the * running kernel has the same major number and a minor number equal - * equal to or less than the filter being downloaded. Otherwise, the + * to or greater than the filter being downloaded. Otherwise, the * results are undefined, meaning an error may be returned or packets * may be accepted haphazardly. * It has nothing to do with the source code version.
Re: i386 ports failures / new binutils
On Fri, Mar 22, 2013 at 3:01 PM, David Coppa wrote: > On Thu, Mar 21, 2013 at 11:34 PM, Stuart Henderson > wrote: >> On 2013/03/21 21:54, Miod Vallat wrote: >>> > - www/chromium - OSError: [Errno 8] Exec format error >>> >>> Please make the binary available to me offlist, as well as its linking >>> command (or build log, whatever suits you). >> >> Well this is very strange because if I run the program which generates >> the error message under ktrace -i, there is no ENOEXEC... >> >> python ../tools/protoc_wrapper/protoc_wrapper.py --include "" --protobuf >> "/usr/obj/chromium-25.0.1364.173/chromium-25.0.1364.173/out/Release/obj/gen/protoc_out/chrome/common/metrics/proto/chrome_experiments.pb.h" >> --proto-in-dir common/metrics/proto --proto-in-file >> "chrome_experiments.proto" "--use-system-protobuf=0" -- >> "/usr/obj/chromium-25.0.1364.173/chromium-25.0.1364.173/out/Release/protoc" >> --cpp_out >> "/usr/obj/chromium-25.0.1364.173/chromium-25.0.1364.173/out/Release/obj/gen/protoc_out/chrome/common/metrics/proto" >> --python_out >> "/usr/obj/chromium-25.0.1364.173/chromium-25.0.1364.173/out/Release/pyproto/chrome/common/metrics/proto" > > I think this is related to a binutils bug with "-Wl,--gc-sections". > > This BZ may be related: http://sourceware.org/bugzilla/show_bug.cgi?id=13195 > > With binutils-2.15, you have: > > $ g++ test.C -ffunction-sections -Wl,--gc-sections > /usr/bin/ld: Warning: gc-sections option ignored > > And the resulting binary seems sane. > > With 2.17 instead: > > $ g++ test.C -ffunction-sections -Wl,--gc-sections > $ > > But the resulting binary is crap: > > $ ldd a.out > a.out: > a.out: Exec format error > a.out: exit status 1 > $ > > $ ./a.out[1]: ELF: not found > ./a.out[7]: cannot open > ÑuõH ZþL dÐøHƒûÿt ff ff Hƒë I‹ ƒì ÿÐHƒûÿuì[AÉÃfff ff UH‰åSHƒì H‹ ˆ 0H…Àt H : > No such file or directory > ./a.out[7]: : not found > ./a.out: syntax error: `)' unexpected > ./a.out[7]: 0fff ÿÐH‹C HƒÃ H…ÀuñHƒÄ [ÉÃfff ff ff U‹ Í @H‰å…Àt ÉÃÇ º @ Éë£ff > U‹ © @H‰å…Òt ÉÃH 5¹ @H =z Ç ˆ @ è ÿÿÿHƒ=[ : > not found > ./a.out[7]: ÿïÿX Œÿïÿx Îÿïÿ˜ zR x $ ÈüïÿâA † C > DŒ Dƒ D ýïÿ A † C > d€ýïÿYA † K > Cƒ Œ „Àýïÿ6A † C > Eƒ ¤àýïÿ A † I > Äàýïÿ_A † I >zPLR x ›} 0 $þïÿ+ A † C > D þïÿA GA † C > d.þïÿ: not found > ./a.out[7]: 7 ° @ Ø ø 8 À: not found > ./a.out[7]: T: not found > ./a.out[8]: : not found > ./a.out[9]: syntax error: `&' unexpected > > > cheers, > David Hi again, Revision 244600 from FreeBSD fixes this problem: http://svnweb.freebsd.org/base?view=revision&revision=244600 "Fix a bug in ld --gc-sections: it strips out .note sections, while it should never do so. This can cause global constructors and destructors to not be executed at run-time, resulting in crashes and other strange behaviour." Attached you have the diff for our tree. ciao, David elflink.patch Description: Binary data
amd64 ports failures with new binutils
The results of the first amd64 bulk build with binutils-2.17 are in. Triage shows two systematic problems: (1) ld --as-needed fails with undefined references, although the symbols are all there. editors/vim,no_x11,perl,python,ruby --as-needed graphics/ffmpeg --as-needed sysutils/coreutils --as-needed (2) A whole bunch of ports fail along the lines of ld: foo.o: relocation R_X86_64_PC32 against `bar' can not be used when making a shared object; recompile with -fPIC except that foo.o _is_ compiled with -fPIC. audio/swh-plugins relocation R_X86_64_PC32 audio/xmms-mad relocation R_X86_64_PC32 audio/xmms-tremor relocation R_X86_64_PC32 databases/xapian-core relocation R_X86_64_PC32 devel/luaprofiler relocation R_X86_64_PC32 devel/luarexlib relocation R_X86_64_PC32 devel/py-subvertpy relocation R_X86_64_PC32 devel/spidermonkey relocation R_X86_64_PC32 devel/xulrunner/1.9 relocation R_X86_64_PC32 emulators/mupen64plus/video-arachnoid relocation R_X86_64_PC32 games/ooliterelocation R_X86_64_PC32 graphics/exiv2 relocation R_X86_64_PC32 lang/swi-prolog relocation R_X86_64_PC32 lang/tinyscheme relocation R_X86_64_PC32 mail/mozilla-thunderbirdrelocation R_X86_64_PC32 mail/smtp-vilter,ldap relocation R_X86_64_PC32 net/honeyd relocation R_X86_64_PC32 net/isc-bindrelocation R_X86_64_PC32 net/trickle relocation R_X86_64_PC32 productivity/sunbirdrelocation R_X86_64_PC32 www/fennec relocation R_X86_64_PC32 www/firefox36 relocation R_X86_64_PC32 www/mongrel2relocation R_X86_64_PC32 www/yawsrelocation R_X86_64_PC32 x11/byzirelocation R_X86_64_PC32 x11/kmplayerrelocation R_X86_64_PC32 x11/ogrerelocation R_X86_64_PC32 -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Collation support (minimal)
On Sat, Mar 09, 2013 at 02:45:00PM +0100, Stefan Sperling wrote: I'd like to concentrate on collation. To properly review your diff, I need to understand what needs to be added to OpenBSD' locale implementation. I hope the attached patch helps. Instead, you should consider OpenBSD's code as your starting point. And add to that _only_ what needs to be done to support collation. Not so easy, because the implementation of collations that I know is the one of FreeBSD (by the way mklocale and the ctype catalogues come from NetBSD, as well as part of the libc implementation --both from citrus). In future would be nice to implement collation in UTF-8 complete, but at least here something for single-byte encondings and UTF-8 translatable to ISO8859-1. By the way to support UTF-8 translatable to ISO8859-1 I changed the functions in collate.c with respect to the implementation of FreeBSD. I don't have a FreeBSD at hand, but I guess it doesn't support collations in locales like es_CO.UTF-8, while the attached implementation does. Adding new functions like strxfrm_l() etc. just doesn't make sense to me. You shouldn't need to add any new functions. We already have strcoll() and strxfrm(). Those are interfaces from C89, so they're a bit dated. But they should be good enough for getting some basic collation support going. We can talk about adding support for newer interfaces later, but those should not matter for the initial implementation. Those functions were removed (but I left the credit of the implementations that I used). You have other unrelated changes in there, such as shuffling of MLINKS lists. Those add noise to the diff and make it harder to review. Other changes I sent in separate emails (including man pages for wcscoll and wcsxfrm). If there is interest in xlocale support after this or after having other kind of collation support in OpenBSD, please let me know. I also want to advance in other LC_* implementations. Best regards. -- Dios, gracias por tu amor infinito. -- Vladimir Támara Patiño. http://vtamara.pasosdeJesus.org/ http://www.pasosdejesus.org/dominio_publico_colombia.html diff -ruN -x obj -x CVS -x *~ src53orig/lib/libc/locale/Makefile.inc src/lib/libc/locale/Makefile.inc --- src53orig/lib/libc/locale/Makefile.inc Sat Mar 9 11:16:47 2013 +++ src/lib/libc/locale/Makefile.incTue Mar 19 05:52:30 2013 @@ -9,7 +9,7 @@ wcstombs.c wctob.c wctomb.c wcstof.c wcstod.c wcstold.c wcstol.c \ wcstoul.c wcstoll.c wcstoull.c wcstoimax.c wcstoumax.c \ setrunelocale.c runeglue.c rune.c runetable.c ___runetype_mb.c \ - _wctrans.c wcsxfrm.c + _wctrans.c wcsxfrm.c collate.c MAN+= nl_langinfo.3 setlocale.3 iswalnum.3 towlower.3 \ btowc.3 mblen.3 mbrlen.3 mbrtowc.3 mbsinit.3 mbsrtowcs.3 \ diff -ruN -x obj -x CVS -x *~ src53orig/lib/libc/locale/collate.c src/lib/libc/locale/collate.c --- src53orig/lib/libc/locale/collate.c Wed Dec 31 19:00:00 1969 +++ src/lib/libc/locale/collate.c Mon Mar 18 07:24:12 2013 @@ -0,0 +1,430 @@ +/*- + * Copyright (c) 1995 Alex Tatmanjants + * at Electronni Visti IA, Kiev, Ukraine. + * All rights reserved. + * + * Copyright (c) 2011 The FreeBSD Foundation + * All rights reserved. + * Portions of this software were developed by David Chisnall + * under sponsorship from the FreeBSD Foundation. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + *notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + *notice, this list of conditions and the following disclaimer in the + *documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ +/** + * Public domain according to Colombian Legislation. + * http://www.pasosdejesus.org/dominio_publico_colombia.html + * 2013. vtam...@pasosdejesus.org. + */ + + +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "rune.h" +#include "runetype.
Re: i386 ports failures / new binutils
On Thu, Mar 21, 2013 at 11:34 PM, Stuart Henderson wrote: > On 2013/03/21 21:54, Miod Vallat wrote: >> > - www/chromium - OSError: [Errno 8] Exec format error >> >> Please make the binary available to me offlist, as well as its linking >> command (or build log, whatever suits you). > > Well this is very strange because if I run the program which generates > the error message under ktrace -i, there is no ENOEXEC... > > python ../tools/protoc_wrapper/protoc_wrapper.py --include "" --protobuf > "/usr/obj/chromium-25.0.1364.173/chromium-25.0.1364.173/out/Release/obj/gen/protoc_out/chrome/common/metrics/proto/chrome_experiments.pb.h" > --proto-in-dir common/metrics/proto --proto-in-file > "chrome_experiments.proto" "--use-system-protobuf=0" -- > "/usr/obj/chromium-25.0.1364.173/chromium-25.0.1364.173/out/Release/protoc" > --cpp_out > "/usr/obj/chromium-25.0.1364.173/chromium-25.0.1364.173/out/Release/obj/gen/protoc_out/chrome/common/metrics/proto" > --python_out > "/usr/obj/chromium-25.0.1364.173/chromium-25.0.1364.173/out/Release/pyproto/chrome/common/metrics/proto" I think this is related to a binutils bug with "-Wl,--gc-sections". This BZ may be related: http://sourceware.org/bugzilla/show_bug.cgi?id=13195 With binutils-2.15, you have: $ g++ test.C -ffunction-sections -Wl,--gc-sections /usr/bin/ld: Warning: gc-sections option ignored And the resulting binary seems sane. With 2.17 instead: $ g++ test.C -ffunction-sections -Wl,--gc-sections $ But the resulting binary is crap: $ ldd a.out a.out: a.out: Exec format error a.out: exit status 1 $ $ ./a.out[1]: ELF: not found ./a.out[7]: cannot open ÑuõH ZþL dÐøHƒûÿt ff ff Hƒë I‹ ƒì ÿÐHƒûÿuì[AÉÃfff ff UH‰åSHƒì H‹ ˆ 0H…Àt H : No such file or directory ./a.out[7]: : not found ./a.out: syntax error: `)' unexpected ./a.out[7]: 0fff ÿÐH‹C HƒÃ H…ÀuñHƒÄ [ÉÃfff ff ff U‹ Í @H‰å…Àt ÉÃÇ º @ Éë£ff U‹ © @H‰å…Òt ÉÃH 5¹ @H =z Ç ˆ @ è ÿÿÿHƒ=[ : not found ./a.out[7]: ÿïÿX Œÿïÿx Îÿïÿ˜ zR x $ ÈüïÿâA † C DŒ Dƒ D ýïÿ A † C d€ýïÿYA † K Cƒ Œ „Àýïÿ6A † C Eƒ ¤àýïÿ A † I Äàýïÿ_A † I zPLR x ›} 0 $þïÿ+ A † C D þïÿA GA † C d.þïÿ: not found ./a.out[7]: 7 ° @ Ø ø 8 À: not found ./a.out[7]: T: not found ./a.out[8]: : not found ./a.out[9]: syntax error: `&' unexpected cheers, David
Re: rthread suspension
On 2013/03/21 22:01, Kurt Miller wrote: > I stalled on submitting them with upstream. I ran into a snafu. However, I > do have an update for boehm-gc that can be tested. There's one i386 > machine in my cluster that doesn't behave which is one of the reasons > I haven't moved this forward yet. It is on my todo list which I'm chipping > away at little by little. Regression tests all pass on macppc, i386, amd64, and I've tried w3m a bit on these 3 arches (w3m has had problems in the past even though regression tests were all OK); no problems noted there. It would be good if someone could do similar tests on other arch, in particular hppa if it hasn't already been tested.
Re: LC_CTYPE for spanish speaking countries
On Fri, Mar 22, 2013 at 7:12 AM, Stefan Sperling wrote: > On Fri, Mar 22, 2013 at 06:54:24AM -0430, Andres Perera wrote: >> Instead of perpetuating the idea that the number of locales is a >> precious resource tied to directory entries, the routines could parse >> the user supplied string instead of working with a table of all >> possible permutations of ll_CC.CTYPE. This means simplification for >> the build system, simplification for those reasoning about what the >> structure representing a locale should look like, and it also adds >> features without calling for a cliche, tower of babel discussion. >> >> Every field enclosed in brackets denotes the parameter(s) to the LC_ >> function on the LHS: >> >> LC_COLLATE=[ll]_CC.[CTYPE] >> LC_CTYPE=ll_CC.[CTYPE] >> LC_MONETARY=ll_[CC].CTYPE >> LC_NUMERIC=ll_[CC].CTYPE >> LC_TIME=ll_[CC].CTYPE >> LC_MESSAGES=[ll]_[CC].CTYPE >> >> That means that they can be indices to separate flat tables. > > Where is your patch series that implements this in a backwards-compatible > fashion, in small steps that get us from here to there? > > I like the idea of uncoupling locales names from the /usr filesystem a lot. Well, that's just the incentive I needed! > But if it is just an idea it is not as tangible as the patches that Vladimir > is submitting, so it isn't something I can afford to pay attention to > during the limited amount of time I have for OpenBSD development. > As you've picked up on, I have nothing to show for now... hopefully my changes won't interfere.
Re: LC_CTYPE for spanish speaking countries
On Fri, Mar 22, 2013 at 06:54:24AM -0430, Andres Perera wrote: > Instead of perpetuating the idea that the number of locales is a > precious resource tied to directory entries, the routines could parse > the user supplied string instead of working with a table of all > possible permutations of ll_CC.CTYPE. This means simplification for > the build system, simplification for those reasoning about what the > structure representing a locale should look like, and it also adds > features without calling for a cliche, tower of babel discussion. > > Every field enclosed in brackets denotes the parameter(s) to the LC_ > function on the LHS: > > LC_COLLATE=[ll]_CC.[CTYPE] > LC_CTYPE=ll_CC.[CTYPE] > LC_MONETARY=ll_[CC].CTYPE > LC_NUMERIC=ll_[CC].CTYPE > LC_TIME=ll_[CC].CTYPE > LC_MESSAGES=[ll]_[CC].CTYPE > > That means that they can be indices to separate flat tables. Where is your patch series that implements this in a backwards-compatible fashion, in small steps that get us from here to there? I like the idea of uncoupling locales names from the /usr filesystem a lot. But if it is just an idea it is not as tangible as the patches that Vladimir is submitting, so it isn't something I can afford to pay attention to during the limited amount of time I have for OpenBSD development.
Re: LC_CTYPE for spanish speaking countries
On Fri, Mar 22, 2013 at 09:55:01AM +, Creamy wrote: > Are you suggesting to add individual locales as and when a significant > number of translations exist in ports, (good idea), or to select a > few South-American dialects to represent the whole continent, (very > bad idea)? A mix of the two. I don't want to make technical decisions based on politics. I'd like to recognize and fix situations where people are missing functionality from the system because their language of choice is not represented properly. It's not a black and white decision, it's a trade-off. Also, I think that extending the locale implementation (such as adding support for LC_TIME, LC_COLLATE, etc) is much more important at this stage than adding additional files to /usr/share/locale. > There is often more difference between South-American dialects of > Spanish than between any one of them and Castillian Spanish. How would > you decide which country is going to represent the whole of the continent? That's a tough question, and I really don't mean to alienate people who speak any of these dialects. But I'd like to avoid the situation where typing the name of a locale is something that people associate with their own identity. Because then, there would be no reason at all to stop adding more locales until the /usr filesystem is full. Systems like Debian ask their users to generate some selection of locales during the installation process. I don't think it is a good idea to ask users to make that kind of choice during system installation. But it's a consequence of the fact that Debian has too many locales. > > No offence, but to me, the name of a locale is just... a name. > > Let's try to make useful functional changes to the system. > > Adding locales for purely patriotic reasons seems like a waste of time > > to me. > > I agree, especially as there will always be awkward individuals like me > who live in one country, but speak mostly foreign languages, and use > date formats and keyboard layouts which don't correspond to any standard > locale either for the country they reside in, or the foreign languages > they speak. Exactly. I'm a native speaker of German, but learned a significant amount of English in Ireland during my teenage years forcing me to slowly recover some chunks of my memory of German when I got back. All my computers speak English to me and I speak English to them, whether or not people around me speak German to me. I type on a US keyboard (cannot type on German ones for the life of me), and prefer to read dates with days given before months because that is what I'm used to. My preferred personal locale would probably be called something like en_IE_de_DE_kbd_US.UTF-8. > It only makes sense to add them if there is a real intention to use > them. Why not just add individual locales as and when a significant number > of translations exist in ports, as it gives people an incentive to translate > in to their local language. I'd like to avoid making up a set of rules about when new locales can be added. I think we should discuss this on a case-by-case basis, and allow people who are genuinely missing functionality to make their case.
Re: LC_CTYPE for spanish speaking countries
Instead of perpetuating the idea that the number of locales is a precious resource tied to directory entries, the routines could parse the user supplied string instead of working with a table of all possible permutations of ll_CC.CTYPE. This means simplification for the build system, simplification for those reasoning about what the structure representing a locale should look like, and it also adds features without calling for a cliche, tower of babel discussion. Every field enclosed in brackets denotes the parameter(s) to the LC_ function on the LHS: LC_COLLATE=[ll]_CC.[CTYPE] LC_CTYPE=ll_CC.[CTYPE] LC_MONETARY=ll_[CC].CTYPE LC_NUMERIC=ll_[CC].CTYPE LC_TIME=ll_[CC].CTYPE LC_MESSAGES=[ll]_[CC].CTYPE That means that they can be indices to separate flat tables. N.B. POSIX says that locales don't need to map to directories, so why try to fit this into an expanded hierarchical structure when it's clearly not made for it?
Re: LC_CTYPE for spanish speaking countries
On 22/03/13(Fri) 05:08, Abel Abraham Camarillo Ojeda wrote: > On Fri, Mar 22, 2013 at 3:55 AM, Creamy wrote: > > > > There is often more difference between South-American dialects of > > Spanish than between any one of them and Castillian Spanish. How would > > you decide which country is going to represent the whole of the continent? I can imagine your frustration about not being able to set your own variant of the Spanish language, but because we are trying to add new functionalities to the libc, can we please postpone this discussion after collation support is added? Would it be possible to concentrate our efforts on adding support for es_ES first, then talk about the best way/how-to support other Spanish variants? Martin
Re: LC_CTYPE for spanish speaking countries
On Fri, Mar 22, 2013 at 3:55 AM, Creamy wrote: > > There is often more difference between South-American dialects of > Spanish than between any one of them and Castillian Spanish. How would > you decide which country is going to represent the whole of the continent? > +1 > It only makes sense to add them if there is a real intention to use > them. Why not just add individual locales as and when a significant number > of translations exist in ports, as it gives people an incentive to translate > in to their local language. > +1 Just my opinion as a Mexican and spanish speaker.
Re: rthread suspension
Kurt Miller writes: > I stalled on submitting them with upstream. I ran into a snafu. However, I > do have an update for boehm-gc that can be tested. There's one i386 > machine in my cluster that doesn't behave which is one of the reasons > I haven't moved this forward yet. It is on my todo list which I'm chipping > away at little by little. > > -Kurt Thanks in advance. If I find time, I'll look into it too; although it will be more of an educational challenge for me, and I can't promise any results. Regards, Taylan
Re: rthread suspension
Ted Unangst writes: > On Thu, Mar 21, 2013 at 11:03, Taylan Ulrich B. wrote: >> I'm a GNU Guile 2.0 user, whose latest versions require latest >> versions of the Boehm garbage collector. This uses the functions >> pthread_suspend_np and pthread_resume_np, when built on OpenBSD, which >> don't exist in rthreads. > > Right. Early working version of librthread had them, but all the ports > that needed these functions (boehm, java, ...) switched to using a > system based on signals. > >> Any general tips on how an application using the old API should be >> ported to the new one are also welcome. One question would be, should >> OpenBSD try to support functions from the old API on top of the new >> one (would patches in this nature be desirable), or should >> applications check for OpenBSD versions? > > Besides the existing boehm port, look at the history of the jdk port. > > We are not planning on adding the _np functions back. As the name > implies, they are not portable, so it's better to come up with a > different solution. Thank you for the information. Regards, Taylan
Re: LC_CTYPE for spanish speaking countries
> I believe we need more than one Spanish locale, because I know that > spoken and written Spanish differs between Europe and South America > in several ways. Unfortunately I don't know any Spanish so I can't > really judge how big these difference are. > > Do we really need _21_ locales for Spanish, like in your diff? > Wouldn't adding one or two locales for South-American dialects of > Spanish be enough to cover these differences, at least where it > makes a difference in terms of OpenBSD's limited functionality, > and where it affects a significant chunk of ports? Are you suggesting to add individual locales as and when a significant number of translations exist in ports, (good idea), or to select a few South-American dialects to represent the whole continent, (very bad idea)? There is often more difference between South-American dialects of Spanish than between any one of them and Castillian Spanish. How would you decide which country is going to represent the whole of the continent? > > Why spanish is treated differently? > > No reason. There was simply nobody so far who was bothered by the lack > of other Spanish locales. You are the first person to complain about > this. That's all. > > > Finally I don't live in Spain but in Colombia, so I should be able to > > use es_CO. How do you translate 'kernel panic' in to Quechua? :-) > No offence, but to me, the name of a locale is just... a name. > Let's try to make useful functional changes to the system. > Adding locales for purely patriotic reasons seems like a waste of time > to me. I agree, especially as there will always be awkward individuals like me who live in one country, but speak mostly foreign languages, and use date formats and keyboard layouts which don't correspond to any standard locale either for the country they reside in, or the foreign languages they speak. It only makes sense to add them if there is a real intention to use them. Why not just add individual locales as and when a significant number of translations exist in ports, as it gives people an incentive to translate in to their local language. -- Creamy
