Parrot 1.0 Released | parrot.org | 380 RTs left!
Set by moderator on 28 March 2009.
mikehh If it was it got unfixed - it fails for me at r38059 00:00
Whiteknight urg
Somebody told me that It was passing as of r38052, so now I need to double-check whether that information was reliable 00:01
Coke (i386) see also "feather.perl6.nl"
mikehh let me do a new build
Whiteknight Coke: What on that site am I looking at? 00:02
(I've never even looked at feather before)
Coke it's a machine that juerd can give you an account on.
juerd?
purl rumour has it juerd is root or at juerd.nl/ or mailto:juerd@juerd.nl
Coke some folks here may even have the ability. it's a 386 linux box. 00:03
Tene I can do it. 00:04
Whiteknight smolder?
purl hmmm... smolder is sourceforge.net/projects/smolder or web-based smoke test aggregator used by developers and testers to upload (automated or manually) and view smoke/regression tests using the Test Anything Protocol (TAP). or smolder.plusthree.com/app/public_pr..._reports/8
kid51 tries r38052 for t/pmc/nci.t 00:07
Whiteknight thanks kid51++
Tene Whiteknight: let me know if you want an account on feather
cotto Whiteknight, I think the jit code needs to do the same thing as e.g. the end of pcf_v_V inc src/nci.c
Whiteknight cotto: I was pretty sure it is doing that now 00:08
of course, my i386 assembly foo isn't as strong as it once was
cotto It's calling get_pointer, but it also needs to call set_pointer after the nci call.
Whiteknight ah, that might be what I'm missing then
Tene jonathan: if you're around, do you want to review my line-number patch before commit?
00:09 AndyA joined
cotto I suspect so, at least. I'll be glad to test a patch. 00:09
Whiteknight we need LLVM desperately, the current JIT system is terrible
Tene Whiteknight: my HLL line number patch is causing some C warnings... want to look at them for me? 00:10
Or should I just commit?
cotto Whiteknight, agree 100%.
Whiteknight Tene: I'll be happy to help you with anything, you're helping me with my mess 00:11
nopaste "tene" at 166.70.38.237 pasted "Line numbers on uncaught exceptions patch for WhiteKnight++" (91 lines) at nopaste.snit.ch/16250
"tene" at 166.70.38.237 pasted "warnings for WhiteKnight++" (11 lines) at nopaste.snit.ch/16251
Tene Wait, what mess am I helping with?
Whiteknight Tene: You can commit that stuff, I'll fix up the errors. They don't look like they're build-breakers 00:13
Tene do I need to futz with headers somewhere for the new function I made? 00:14
Whiteknight did you run headerizer?
Tene No. Should I?
Whiteknight yeah, definitely do 00:15
Tene just 'make headerizer'?
Whiteknight yep, it's that easy
Tene kk
thanks. :)
Whiteknight no problem
Tene purl: msg pmichaud Committing HLL line number in uncuaght exceptions message. If you can get filename annotations, I can add those too. 00:16
purl Message for pmichaud stored.
Tene Whiteknight: headerizer made some changes to string_funcs.h too... 00:18
is that likely to be okay?
Whiteknight yeah, it will make changes everywhere. Try to build again to double-check, but should be nothing
Tene yeah, build is fine.
Now working on anonymous roles for rakudo. 00:19
dalek rrot: r38068 | tene++ | trunk (3 files):
[exceptions]: Add the HLL line number to the message printed for uncaught exceptions.
 00:20
nopaste "kid51" at 68.237.18.252 pasted "r38052: t/pmc/nci.t: Linux/i386; tests were not fixed here" (55 lines) at nopaste.snit.ch/16252 00:24
Whiteknight Thanks kid51++. Let me see what I can do to fix it. 00:26
mikehh kid51: looking at the smolder reports the test is NOT failing on darwin i386 00:30
kid51 mikehh: Noted. I've only been looking at Linux i386. 00:32
mikehh kid51: you get a SIGNAL 6 from test 66 and a SIGNAL 11 from test 69? 00:34
kid51 mikehh: I had to make realclean because I ran out of disk space while doing the bisections. 00:35
So whatever you see in my original TT report was what I got at HEAD at that point. 00:36
Am reconfiguring now.
Actually, checking my original report, I *did* get those SIGNALs. 00:39
trac.parrot.org/parrot/ticket/551
Whiteknight I don't think I know how to fix this
well, let me rephrase that. I don't think I know a good way to fix it 00:40
cotto It looks like it'll be tricky, especially for multiple out params 00:41
Whiteknight yeah, that's what I'm thinking. 00:42
cotto I'm about to commit a test for that.
dalek rrot: r38069 | cotto++ | trunk (3 files):
[NCI] add a test (plus supporting stuff) for multiple out params
 00:43
cotto That'll require running Configure.pl to update src/call_list.txt. 00:44
kid51 mikehh: At r36068, I got all tests passing on t/pmc/nci.t on Darwin/PPC 00:55
So why is Darwin the odd man out?
mikehh probably because it's BSD based not linux 00:56
cotto kid51_at_dinner, probably because the NCI subs aren't jitted 00:58
on ppc 00:59
mikehh I am getting some failures in t/op/exceptions.t and t/pmc/exception.t at r38068 as well 01:00
Whiteknight the stack-handling in the JIT call frame building code is a little strange 01:04
mikehh t/op/exceptions.t - Failed tests: 10-11, 16, 22, t/pmc/exception.t - Failed tests: 11-12, 17, 24 - make test 01:05
Whiteknight where the hell is tewk when you need him? 01:06
Tene ack, that might have been me.
mikehh that's as well as the t/pmc/nci.t failures
Tene mikehh: thank you
mikehh: the problem was that I forgot to update the tests to match a change in exceptions 01:14
I'm committing a fix shortly 01:15
01:17 AndyA joined
dalek rrot: r38070 | tene++ | trunk/t (2 files):
[t]: Update uncaught exception text in tests.
 01:20
Tene ack, that broke a lot of other things too, I guess. 01:21
>< 01:22
bacek Hi there. What is the best place for small pir file used in few tests? If I put it into t/pmc/ it got removed by make realclean... 01:24
kid51 bacek: In many cases where I needed sample files for tests, I created a t/foo/testlib/ directory one level down from the tests themselves. 01:34
01:34 amoc joined
bacek kid51: o! thanks 01:34
kid51 We have a lot of new test failures between 38067 and 38069. 01:37
At r38069: smolder.plusthree.com/app/public_pr...ails/19793 01:38
shorten kid51's url is at xrl.us/beoo6r
bacek kid51: exceptions? I think Tene already fixed them.
may be not all of them. 01:39
kid51 Rebuilding and retesting.
Tene bacek: no, not all of them. 01:40
bacek anyway, testing text of exception isn't good idea...
Tene I really don't want to dig through all of those... 01:41
bacek Someone have to :) 01:42
Tene I don't even know if that's the text we really want.
It was my first draft. I didn't expect the text of the message to be tested. 01:43
bacek Those tests are quite old. They probably should be reimplemented using push_eh/pop_eh instead of checking text. 01:45
Tene yeah?
bacek We need "exception expert" to fix them. O WAIT.
Tene The exception expert apparently needs the tests expert to tell him how the tests should be fixed. 01:46
wtf segfault? 01:47
purl well don't DO that, then.
bacek Tene: check t/pmc/class.t for example 01:48
$I0 = 1; push_eh handler; <do something evil>; $I0 = 0; handler: ok($I0, "Evil was stopped") 01:49
mikehh I did a make realclean and a lot of those tests seem to be passing now 01:50
kid51 r38070 only fixed 8 failures. 01:51
Tene t/op/cc_params.t ew, generated tests. I need to actually *read* it...
mikehh I pass all the op and pmc tests (except t.pmc.nci.t)
Tene kid51: yes, the problem was that I changed the text printed on uncaught exceptions
nopaste "kid51" at 70.85.31.226 pasted "r38070 test failures on Linux i386" (57 lines) at nopaste.snit.ch/16253 01:53
Tene Oh, and I'm getting segfaults from this somehow: 01:55
kid51 Would it be worth it to back out the changes and work on them in a branch?
Tene Parrot_io_eprintf(interp, " at line %d", VTABLE_get_integer(interp, line));
kid51: Sure.
mikehh I pass all the tests except for the 2 t/pmc/nci.t tests at r38070
smolder.plusthree.com/app/public_pr...ails/19795 01:56
shorten mikehh's url is at xrl.us/beoo8t
Tene argh, I don't know how to do this with svn... 01:57
mikehh sorry I also fail test 70 - so 3 failures
Tene ah, I do it with git 01:58
dalek rrot: r38071 | tene++ | trunk (5 files):
Revert recent changes from Tene--

text of the uncaught exception message.		 02:00
rrot: r38072 | tene++ | branches/report_hll_info:
Branch trunk to work with printing the HLL info on an uncaught exception.
 02:07
rrot: r38073 | tene++ | branches/report_hll_info (3 files):
[exceptions]

  * Many tests fail due to the changed text on uncaught exceptions.
Tene Thank you everyone for catching that.
mikehh I think we have to be really careful on tests that generate .pir or .pasm files because if you do not do a make realclean you get errononeous results 02:09
or at least remove the ,pir etc files before retesting 02:11
cotto It sounds like the tests are broken then. 02:13
Tene purl: msg allison Can I get some guidance on what HLL info Parrot should report on an uncaught exception? See the report_hll_info branch. 02:15
purl Message for allison stored.
Tene Speaking of failing tests, I'm getting a sigbus in t/pmc/codestring.
kid51 So now, at r38071, on Linux I'm back to just the nci.t tests failing: smolder.plusthree.com/app/public_pr...ails/19796 02:17
shorten kid51's url is at xrl.us/beopai
kid51 Tene: whiteknight reported problems with that file in trac.parrot.org/parrot/ticket/550 -- but there wasn't a lot of detail there and I was unable to reproduce. 02:19
moderator Parrot 1.0 Released | parrot.org | 367 RTs left! 02:20
Tene kid51: looks icu-related, and I'm on 64-bit linux, which I remember hearing has issues with ICU? 02:20
mikehh I am not convinced - I got the same results at r38070 - smolder.plusthree.com/app/public_pr...ails/19795
shorten mikehh's url is at xrl.us/beoo8t
kid51 Tene: Haven't been following ICU discussion lately. 02:21
Tene mikehh: I reverted the changes in r38071
mikehh I know - that's why I say I am not sure - I did a make realclean before running the tests and got the same results as kid51 at r37081 on r37080 02:23
71 and 70
purl 141
mikehh I know that I there was an update on Ubuntu for libicu a couple of days ago 02:26
AFAIK the ICU discussion was related to pmichaud getting a whole bunch of tests to pass on rakudo (about 2000) 02:28
Tene those don't work for me either 02:30
02:36 janus joined
mikehh you need libicu installed 02:36
and libicu-dev
site.icu-project.org/ 02:39
Tene Yes, I have them installed. 02:40
mikehh Tene: what is your platform? 02:46
Tene mikehh: 64-bit linux
mikehh I have been working on i386 for a while now - I think I might switch and test on my 74 bit platform 02:48
my problem is I am not running a VM and have to reboot 02:49
s/74/64/ above
02:52 Andy joined
bacek tired of ATTR scaffolding... 02:56
kid51 must sleep 03:04
purl $kid51->sleep(8 * 3600);
cotto bacek, you can mess with them directly too
PARROT_SOMEPMC(SELF)->attr
I agree that it gets old fast.
03:29 Tene joined
mikehh gonna switch now - cul8r 03:42
:quit
03:42 mikehh left 05:27 Tene_ joined 05:31 mikehh joined
mikehh Tene_: I am also failing t/pmc/codestring.t - Failed 15/38 subtests on Ubuntu Intrepid Amd64 05:35
purl okay, mikehh.
mikehh Bad plan. You planned 38 tests but ran 23 05:38
cotto sounds like a 64-bit issue. it works fine on 32-bit 05:48
Infinoid has just added some more info on that to TT #550. 05:52
mikehh: What's your version of ICU?
I think pmichaud was testing on x86-64 when he developed the patch which caused this issue, if that's so, its not just x86-64 05:54
09:21 <@pmichaud> fwiw, icu on my system appears to be 3.8-6ubuntu0.1
mikehh I think mine is the same - let me check 05:55
I've got 3.8.1-2ubuntu0.1 05:58
Infinoid ah. if you can track down the other version and see a difference in behavior with it, you might have found the missing piece of the puzzle. 05:59
anyway, I've had a long and exhausting day... time to tackle my bed and pass out for several hours
night all
bacek cotto: I mean VTABLE init, mark, destroy... 06:28
06:36 TiMBuS joined 07:31 flh joined 08:02 Counterspell joined
dalek rrot: r38074 | bacek++ | branches/packfile_revamp (2 files):
Implement PackfileAnnotation
 08:04
bacek incoming
purl ...flowers on the razor wire...
rrot: r38075 | bacek++ | branches/packfile_revamp/t/pmc/packfile.t:
Fix test plan
rrot: r38076 | bacek++ | branches/packfile_revamp/t/pmc/packfiledirectory.t:
Fix packfiledirectory.t
 08:05
rrot: r38077 | bacek++ | branches/packfile_revamp (3 files):
Add PackfileSegment.(set|get)_directory.

AnnotationKeys holds index in ConstantTable.
bacek purl: forget incoming
purl bacek: I forgot incoming
rrot: r38078 | bacek++ | branches/packfile_revamp/src/pmc/packfileannotations.pmc:
PackfileAnnotations scaffolding - add attributes, GC housekeeping, accessors.
rrot: r38079 | bacek++ | branches/packfile_revamp/t/pmc/packfile.t:
Add test for uuid equals to '\\0'
08:08 iblechbot joined 09:36 rafl joined
Casan rakudo: classmyclass { method mymethod () returns Str { my Int $number = 1;return $number; } } my $myclass = myclass.new(); say $myclass.mymethod(); 09:43
rakudo: class myclass { method mymethod () returns Str { my Int $number = 1;return $number; } } my $myclass = myclass.new(); say $myclass.mymethod(); 09:44
09:49 wayland76 joined
dalek rrot: r38080 | bacek++ | branches/packfile_revamp/t/pmc/packfileannotations.t:
Convert packfileannotations.t to PIR.
 09:54
rrot: r38081 | bacek++ | branches/packfile_revamp/src/pmc/packfileannotationkeys.pmc:
PackfileAnnotationKeys scaffolding and reader interface.
rrot: r38082 | bacek++ | branches/packfile_revamp/src/pmc/packfileannotationkeys.pmc:
Small changes to PackfileAnnotationKeys.

  * Rename set_const_table to get_constant_table for consistency sake.
09:56 mikehh joined
dalek rrot: r38083 | bacek++ | branches/packfile_revamp/src/pmc/packfileannotations.pmc:
Fix PackfileAnnotations.get_keys_list to be proper METHOD.
 09:57
rrot: r38084 | bacek++ | branches/packfile_revamp/t/pmc/packfileannotationkeys.t:
Rewrite packfileannotationkey.t into PIR
rrot: r38085 | bacek++ | branches/packfile_revamp (3 files):
Override PackfileAnnotations.set_diretory method.

Also add small description for rationale of this behaviour.
cotto bacek, src/pmc/packfileannotations.pmc says "ownershit" 10:12
bacek cotto: oops. I'll fix it :) 10:13
cotto I can only hope it's a typo.
good night
bacek Sometimes vim is too smart in completions...
cotto: good night 10:14
dalek rrot: r38086 | bacek++ | branches/packfile_revamp/src/pmc/packfileannotations.pmc:
Fix type spotted by cotto++
 10:17
10:20 Counterspell joined 11:01 barney joined 11:04 TiMBuS joined
mikehh I submitted a possible patch to TT#550 on Amd64 11:06
I get a Bus Error on the test - t/pmc/codestring.t 11:08
but removing the test works for the rest of the tests 11:09
11:11 wayland76 joined
mikehh There was a security patch for libicu to prevent cross-site scripting attacks via invalid characters 11:12
11:48 kid51 joined 12:16 Whiteknight joined 12:19 eternaleye joined 13:02 amoc joined
mikehh bacek: re your .pir problem earlier t/pmc/codestring.t is bascically pir 13:21
Whiteknight mikeh++ 13:47
13:50 Tene joined
Infinoid mikehh: do you think we can solve the crash somehow without reducing test coverage? 14:00
mikehh infinoid: I don't at the moment see how - using invalid unicode seems to generate a Bus error - at least on Ubuntu Intrepid Amd64 14:03
not on Kubuntu Intrepid i386 however
Infinoid I think it is important that we handle invalid characters gracefully. If some specific pir code can crash parrot, removing the test isn't really a "fix"
I realize this isn't really parrot's fault, it's icu's fault. But I think I'd rather fix icu 14:04
mikehh the icu patch was to prevent invalid code being used in scripting attacks apparently 14:05
although it should not generate a Bus error - I'll try and look into that 14:06
Infinoid hmm. was that bug somehow related to regexps? 14:07
the Gentoo 3.8.1-r1 package applies two patches: icu-3.8-regexp-CVE-2007-4770+4771.diff and icu-3.8-setBreakType-public.diff
I can pretty easily remove them and see if icu still crashes, one moment 14:08
mikehh the code was $I0 = code.'charname_to_ord'('<no such symbol>') 14:10
Infinoid Do you have a link to the security fix you mentioned earlier? 14:11
mikehh I pulled it out of the changelog in /usr/shared/docs/libicu38 14:13
Infinoid the gentoo package patches were intended to fix bugs.gentoo.org/show_bug.cgi?id=208001 and bugs.icu-project.org/trac/ticket/5498
oh, ok
mikehh debian/patches/03-cve-2008-1036.patch 14:15
Infinoid thanks. note gentoo doesn't apply that, and yet I can reproduce the SIGBUS crash too 14:16
hmm. a straight build from icu4c-3_8_1-src.tgz with no patches crashes too 14:22
mikehh I had not actually run the pmichaud's test on Amd64 before the last time I ran on Amd64 was March 31 14:29
14:30 Theory joined
Infinoid pmichaud: ping # were you testing this on amd64, or i386? 14:30
If 3.8 works on amd64 but 3.8.1 breaks, we could just blacklist 3.8.1 14:31
mikehh the last updates to the file were on April 7 14:32
I think he uses darwin
Infinoid I'm pretty sure he's on some flavor of ubuntu 14:34
mikehh I know this works on Kubuntu Intrepid i86
with the same libicu update 14:35
Infinoid is testing icu 4.0.1
unfortunately, gentoo doesn't have a 3.8 (non-.1) package I can test with
mikehh I think I have the source for that 14:36
Infinoid bus error in the same place with 4.0.1 14:37
mikehh a bus error does not really make sense when calling a library - I think we need to look at the test more closely 14:40
doesn't a bus error come from mis-alligned code/data 14:41
Infinoid yeah, I'm sure it's a bug in the icu internals
mikehh let me isolate the test and see what happens 14:42
Infinoid ok 14:43
mikehh when 1 test out of many fails - I tend to think the test is at fault somewhere
Infinoid I tend to think the feature the test is testing doesn't work :) 14:44
bus error in the same place with 3.6 14:50
Whiteknight is it a new test? 15:03
15:05 rurban joined
pmichaud Infinoid: I was testing on i386 15:06
Whiteknight I've checked all the arguments on this end, all our pointers are properly aligned going into ICU
mikehh pmichaud added a whole lot of stuff to test icu to the test a couple of days ago - one subtest is failing on Amd64 linux with a bus error
pmichaud afaict, it's an ICU bug.
I think we have three options 15:07
(a) we can adjust the test to not tickle the icu bug. The icu bug is still there, but at least it's not as exposed
(b) we can try to determine what sorts of keys tickle the icu bug, and detect them in CodeString so that we don't tickle the bug 15:08
(c) we can declare that whatever versions of icu have the bug aren't supported
Whiteknight Can we work down a very minimal test case, without even using Parrot, to prove that the error is in ICU? 15:09
mikehh It is a bug in the Amd64 implementation of icu not the i386 implementation
Whiteknight then we can pass the test case on to the ICU people and have them fix it
mikehh he he 15:10
pmichaud I've never written a standalone icu program, but I can do it.
it's likely _very_ simple to reproduce. Just a sec.
(er, more like a minute)
mikehh I reduced it to just that test and it still fails with a Bus error 15:11
damn nopast seems to offline 15:12
be 15:13
Whiteknight nopaste?
clunker3 pasta.test-smoke.org/ or paste.husk.org/ or nopaste.snit.ch:8001/ or rafb.net/paste or poundperl.pastebin.com/ or paste.scsys.co.uk/
purl hmmm... nopaste is at nopaste.snit.ch/ (ask TonyC for new channels) or rafb.net/paste or poundperl.pastebin.com/ or paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at www.extpaste.com/ or paste.scsys.co.uk (for #catalyst, #dbix-class, #moose and others)
Whiteknight there are a few nopastes, at least one of them should be working
nopaste "pmichaud" at 72.181.176.220 pasted "icu test" (26 lines) at nopaste.snit.ch/16254 15:15
pmichaud can someone on amd64 run that test?
nopaste "mikehh" at 90.209.206.246 pasted "icu failures with Amd64" (34 lines) at nopaste.snit.ch/16255 15:16
"pmichaud" at 72.181.176.220 pasted "icu test compile + output on x86" (32 lines) at nopaste.snit.ch/16256 15:17
pmichaud I should note that "error in u_charFromName" is the desired output of icutest.c . I'm curious to know if it segfaults. 15:18
mikehh icutest.c:19: warning: format ‘%ld’ expects type ‘long int’, but argument 2 has type ‘UChar32’ 15:21
pmichaud okay, maybe change it to %d
mikehh running icutest gives Bus error
pmichaud that's not really important, though.
"Bus error" --> bug in ICU.
nopaste "pmichaud" at 72.181.176.220 pasted "revised icutest.c script (more descriptive, eliminates warning)" (33 lines) at nopaste.snit.ch/16257 15:30
Tene pmichaud: you add context vars to rakudo yet, or just the dynop and plans? 15:37
pmichaud ...dynop? 15:38
Tene I also get sigbus, and I'm on intel 64-bit, not amd64
pmichaud I added an opcode, yes.
"amd64" is *ubuntu's generic name for any 64-bit platform
Tene erm, opcode.
ah
pmichaud I haven't done context vars yet -- I'm still deciding exactly how I want to do that. I'm thinking of two lexical symbols. I might also need another opcode for Perl 6's notion of contextual vars. 15:39
unfortunately Parrot's find_lex opcode throws exceptions if the requested lexical isn't found 15:40
(I'd prefer that it just return PMCNULL, like most other "not found" sorts of operations)
mikehh still gives me a Bus error 15:41
pmichaud mikehh: okay, it's an icu bug then.
if both Tene and mikehh get errors on my icutest program, I think we can definitively declare this to be a bug in ICU. 15:42
I'm not sure how Parrot should handle that. See my a,b,c options above :-)
mikehh I think we need to go for b myself but check for Amd64 on the test as i386 works 15:44
Infinoid if b is even possible... 15:45
mikehh I think I saw somewhere that darwin Amd64 passed the test
maybe in smolder
pmichaud I don't know if (b) is possible. I'd go for (a) for the time being. 15:47
Infinoid mikehh++ has attached a patch to TT #550 which implements (a) by just removing the test 15:48
pmichaud in the test file, try changing "<no such symbol>" to "no such symbol" (i.e., removing the angle brackets) and see if that avoids the bus error.
Infinoid can do, one moment 15:49
ok 24 - <no such symbol>
mikehh BTW I tested the bug I found in TT#412 and it seems to have gone away at least on Ubuntu Intrepid Amd64
pmichaud I suggest making that change, then.
at least we won't get test errors in Parrot. The case of angles showing up in normal code are very unlikely anyway. 15:50
and hopefully icutest will get fixed.
er, icu
Infinoid angles should be fairly easy to detect 15:51
pmichaud but I don't know if it's just angles
Infinoid true.
pmichaud and I don't want to spend a lot of time working around it in Parrot.
(or code)
Infinoid well, I can check in this fix for now
mikehh maybe we should test for Amd64 with a todo or skip
pmichaud since ICU is now at 4.0, we can just hope that it (a) fixes the bug and (b) that people will start using it within the next 12 months
(whereas most of us seem to be using ICU 3.8.* 15:52
Infinoid I have reproduced the crash in 3.6, 3.8.1 and 4.0.1
pmichaud oh. Then we should report it to the ICU folks.
15:55 AndyA joined
Infinoid mikehh: r38087 fixes it for me with icu 4.0.1. Does it help with your 3.8.x? 15:56
dalek rrot: r38087 | Infinoid++ | trunk/t/pmc/codestring.t:
[t] Work around a crash in the ICU library.
 15:57
mikehh yep it worl as 'no such string'
s/worl/works/ 15:58
Infinoid if anyone wants to submit that bug to the icu guys, they have a trac at bugs.icu-project.org/trac 15:59
pmichaud I'll submit it, but I need to upgrade my os to 64-bit first, I think. 16:04
and that may be a few days
so if someone wants to beat me to it, that'd be great.
16:07 iblechbot joined
mikehh infinoid: you have tested on different versions of ICU :-} 16:09
sorry 16:11
Infinoid: you have tested on different versions of ICU :-}
Anyway I am going to try TT#412 on Kubuntu Intrepid - which I have to update and stuff - cu in a bit 16:16
16:24 rurban_ joined
dalek kudo: 679e480 | pmichaud++ | docs/spectest-progress.csv:
spectest-progress.csv update: 359 files, 10298 passing, 5 failing

   S32-hash/reverse.t aborted 5 test(s)		 16:29
shorten dalek's url is at xrl.us/beoqjv
16:49 flh joined 17:04 davidfetter joined 17:34 tetragon joined 17:43 tetragon_ joined 18:31 tetragon joined 18:50 tetragon joined 19:07 tetragon joined 19:13 tetragon joined 19:23 Eevee joined 19:25 tetragon_ joined 19:40 klapperl joined, riffraff joined 19:44 Casan joined 20:19 allison joined 20:29 Tene joined 20:46 contingencyplan joined 21:33 amoc joined 22:00 Theory joined 22:04 tetragon joined
bacek good morning 22:48
22:51 mikehh joined 22:59 TiMBuS joined 23:15 wayland76 joined
wayland76 ping allison 23:18
purl I can't find allison in the DNS.
allison wayland76: hi 23:19
wayland76 Hi. I'm told you're the person to ask about whether I need to do anything else to ticket trac.parrot.org/parrot/ticket/503 to help it progress
allison wayland76: okay, I'll take a look 23:20
hmmm... I have serious doubts about how possible it's going to be to have one specfile for all the different distributions
they have such extremely different requirements 23:21
and, the people who are maintaining one have no clue what the other needs
and vice versa
wayland76 agreed, mostly
my expectation is that each actual distro will come up with their own spec...
allison and no one is testing all the specfiles for all the distributions
wayland76 and that this will be for people who want to use newer code than the distro packages 23:22
Yes, I agree about the testing problem
allison wayland76: yes, I expect the distributions will all have separate specs
what I want is to check the specfiles for each distribution into ports/
and just delete the top-level parrot.spec 23:23
wayland76 Good idea. Is there anything I can do to help that happen? :)
allison so, if someone builds a custom, up-to-date RPM for their distribution, it will be using the exact same specfile as the distribution 23:24
23:24 s1n joined
allison I'll copy my comment into the ticket 23:24
which distribution are you working on?
wayland76 ok.
I'm on Fedora 10 23:25
allison wayland76: because the best thing you can do to help is contribute a patch for that distribution
say, adding ports/fedora/parrot.spec
wayland76 I can send you the file that Jerome Quelin did for the other one (Mandriva?) as well
allison yes, make a patch for that ports/mandriva/parrot.spec 23:26
I think someone contributed one for suse too, but would have to dig around to find it
wayland76 ok, I can do that. Note that the current Fedora one does both Fedora and SuSE
allison wayland76: okay
wayland76 (ie. even without my patch)
allison doesn't it have some checks for the distribution, do do things differently for each? 23:27
"to do", I mean
wayland76 Yes. And so does my patched version
allison wayland76: so, I'd split those out into two, to reduce complexity
wayland76 You mean, the original as both SuSE and Fedora? 23:28
allison instead of checking the conditions, just make the specfile for each do the right thing for that platform
wayland76 ok. I don't like the amount of duplicate code, though
allison I mean ports/suse/parrot.spec and ports/fedora/parrot.spec
wayland76 And it means that if something needs fixing, it probably means it needs fixing in multiple places
allison if they were doing exactly the same thing, I'd agree
but they're not 23:29
and, it's easy to run a diff on the two and see where they're different
wayland76 Wouldn't we be better off auto-generating them all, with some stuff common, and some stuff different?
allison shrug, sure, if they were more complicated, but they're pretty simple files
wayland76 anyway, I'll go with what you said unless you change your mind :)
allison I do the Debian and Ubuntu packaging files this way and it works well 23:30
wayland76 (I'm assuming we'll want to auto-generate them anyway)
allison I don't see much need to generate them, all we want is a record of whatever the distribution is using for packaging 23:31
it helps with the "bus factor" if the existing package maintainer for a particular platform disappears
we can always pick up where they left off
wayland76 Well, I was thinking if we auto-generated, then we could a) automatically update the version, and b) update the files list from the MANIFEST without having to do that manually too
allison except that the files list doesn't actually match the MANIFEST 23:32
wayland76 In what way?
allison (because packages pick and choose files or put files in custom locations)
and, the version is one line
wayland76 I agree about the version being simple if that's the only thing 23:33
But when you have to update it for 7 or 8 different spec files... :)
allison in debian/ubuntu the list of installed files are each in separate files, so I use the same ones for both debian and ubuntu packages 23:34
in RPMs it's all one monolithic file 23:35
what to other RPM packages do for generated files?
in debian/ubuntu we use the convention of "filename.in"
wayland76 Not sure.
I think there's some way of reading an external files list 23:36
allison which has some substitution variables in it that get replaced in the generated file
so, parrot.spec.in would be checked in for each distribution, then generated as parrot.spec
okay, so that's your second task
wayland76 Ok, wait, I may not've understood 23:37
allison step 1) create a patch with static specfiles for fedora/mandriva/suse
step 2) research prior art on RPM packaging with generated specfiles
wayland76 awaits step 2 :)
Ah, ok, I see the answer to the question
bacek step 4) Profit! :)
wayland76 :)
allison bacek: :) 23:38
wayland76 My impression is that most other packages do what I did: monolithic spec file with conditional sections for each distro
allison wayland76: for now we'll just check in the static versions
wayland76 (monolithic static specfile, I should've said)
Anyway, I'm happy to go with whatever works for you. 23:39
I'll submit different patches
allison for me it's a matter of what works for the actual distributions (and for getting reliable testing for the various distributions)
wayland76 I'd also be interested in seeing if you have feedback on trac.parrot.org/parrot/ticket/442 as well 23:40
allison wayland76: okay, will take a look at that next
wayland76 thanks :)
mikehh Hi I am still getting some weird results on Kubuntu Intrepid Amd64 - TT#412 23:46
even more weird the tests pass on Ubuntu Intrepid Amd64 on the same computer
on the Kubuntu if I use --configure_trace the tests pass, but if not they fail 23:48
allison wayland76: okay, generally approved on TT #442, but I'm changing the name of the flag to -Y instead of -S (-D and -E are already taken or I'd use those) 23:53
wayland76: also, I'm adding long versions of each --include --library and --dynext
wayland76 All fine by me, but thanks for the heads up 23:54
allison++ :)
allison mikehh: that is extremely odd 23:55
mikehh: you get the same failures with and without --optimize? 23:57
mikehh: and do you know when the failures started?
mikehh allison: exceedingly so - it started when I managed to get --optimize to first run on Amd64 about 5 weeks ago at r37128 23:59

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!