| hansg has joined this channel (n=hans@ip32-174-211-87.adsl2.static.versatel.nl).
|
11:03
|
| * rdieter owes svahl another adult beverage of choice
|
11:04
|
| hansg
|
Hi all, I'm present for the fpc meeting.
|
11:04
|
| * spot looks around for FPC members
|
11:04
|
| f13
|
I'm lurking today
|
11:04
|
| * spot sees abadger1999, tibbs|h, rdieter, Rathann
|
11:06
|
| spot
|
and hansg, of course. ;)
|
11:06
|
| abadger1999
|
I'm here.
|
11:06
|
| * rdieter puts fpc hat on
|
11:06
|
| Rathann
|
present
|
11:06
|
| hansg
|
Hi all, sorry for all the missed meetings, my schedule just does not seem to align properly with the fpc meetings
|
11:07
|
| spot
|
ubertibbs: ping
|
11:07
|
| ubertibbs
|
Yep.
|
11:07
|
| racor has joined this channel (n=rc040203@HSI-KBW-078-043-127-065.hsi4.kabel-badenwuerttemberg.de).
|
11:07
|
| spot
|
there's racor
|
11:07
|
| ubertibbs
|
Sorry, just had to get someone out of my office.
|
11:07
|
| abadger1999
|
heh
|
11:07
|
| racor
|
yep, I am here ... at least for the next couple of minutes ;)
|
11:08
|
| spot
|
okay, lets get the easy one out of the way first
|
11:08
|
| spot
|
http://overholt.fedorapeople.org/EclipsePlugins.diff
|
11:08
|
| Topicubertibbs sets the channel topic to "Packaging Committee Meeting".
|
11:08
|
| spot
|
basically, andrew overholt asked for changes to the eclipse guidelines to reflect the changes in eclipse 3.4
|
11:08
|
| ubertibbs
|
This is simply necessary to adapt to changes in the underlying software (and to fix a couple of typos); I think we should just do it.
|
11:09
|
| spot
|
ubertibbs: yep.
|
11:09
|
| spot
|
+1 from me
|
11:09
|
| rdieter
|
+1
|
11:09
|
| abadger1999
|
+1
|
11:09
|
| racor
|
+1
|
11:09
|
| ubertibbs
|
+1
|
11:10
|
| spot
|
okay, thats +5
|
11:10
|
| Rathann
|
+1
|
11:10
|
| spot
|
next item: http://fedoraproject.org/wiki/PackagingDrafts/RubyGem_with_C_code
|
11:10
|
| spot
|
mtasaka made a new draft at the bottom of that page which is a lot cleaner
|
11:10
|
| hansg
|
+1
|
11:11
|
| hansg
|
That +1 is for the eclipse changes, man you are all fast
|
11:11
|
| spot
|
under "Revised proposition"
|
11:11
|
| spot
|
for me, this revised proposition is a lot clearer and simpler
|
11:12
|
| ubertibbs
|
That whole thing is confusing.
|
11:13
|
| ubertibbs
|
Are we only considering the part between "Revised proposition" and "Note"?
|
11:13
|
| spot
|
ubertibbs: and the example
|
11:13
|
| Rathann
|
it says [SOLVED] but I don't see a clear solution to "Installed C Codes"
|
11:13
|
| spot
|
hmm, i think this may make things a bit simpler
|
11:16
|
| spot
|
https://fedoraproject.org/wiki/PackagingDrafts/RubyGem_with_C_code_spot
|
11:16
|
| spot
|
those would be the guideline changes
|
11:16
|
| * hansg thinks we need to tell them just to fix the gem buildsystem, or hack around it
|
11:16
|
| abadger1999
|
Rathann: I think that's here: " Installed C codes (usually under %{geminstdir}/etc) may be removed even if gem contents %{gemname} reports that installed C codes should be found there. "
|
11:17
|
| hansg
|
Installing under builddir so as to avoid having buildroot coded into the binaries is completely fscked up, we want neither the buildroot nor the builddir encoded into the binaries !!!
|
11:17
|
| Rathann
|
hansg: +1
|
11:17
|
| ubertibbs
|
I have to agree.
|
11:18
|
| ubertibbs
|
I mean, we could just build normally and then call sed on the binaries to pass the check if that's all we care about.
|
11:18
|
| warren has joined this channel (n=warren@redhat/wombat/warren).
|
11:18
|
| Rathann
|
and what's with the compilation-on-install?
|
11:18
|
| ubertibbs
|
The bottom line is that we're dealing with a broken system here. How do we address that?
|
11:19
|
| * hansg votes for sending this back to the drawing board
|
11:19
|
| spot
|
also, we have gems in Fedora right now
|
11:19
|
| hansg
|
ubertibbs, patch the hell out of it until it does what we want
|
11:19
|
| spot
|
so presumably, things are worse than this in the current guidelines
|
11:19
|
| ubertibbs
|
We have plenty of gems, but how many of them have compiled C code in them?
|
11:19
|
| hansg
|
or even better explain very patiently and clearly to upstream and ask them to add a switch which does what we want ?
|
11:19
|
| ubertibbs
|
There's no question for regular gems that contain only Ruby code.
|
11:20
|
| Rathann
|
I guess we could approve it as a temporary workaround of the current problems
|
11:20
|
| Rathann
|
but only if the maintainer promises to work with upstream to resolve these problems
|
11:20
|
| ubertibbs
|
And another question: should the check that all of this hacks around simply be disabled?
|
11:20
|
| hansg
|
Rathann, small +1 (its just so d*mn ugly)
|
11:20
|
| ubertibbs
|
I mean, what are we working around here?
|
11:20
|
| ubertibbs
|
The produced binaries include the buildroot as a string somewhere. Is this actually something we care about?
|
11:21
|
| hansg
|
ubertibbs, we are working around a check, which checks that no compilation was done during %install, something which can be very bad when there is no DESTDIR, and thus we redefine PREFIX to get installed to the right place
|
11:21
|
| ubertibbs
|
Yes, the rpm check is there to catch potential breakage. But is there actual breakage in this case?
|
11:21
|
| ubertibbs
|
So is the point of this to work around the check, or is is to force the broken build system to do its building in %build instead of %install?
|
11:22
|
| hansg
|
ubertibbs, it may happen to just work here, but its *wrong wrong wrong* and the debuginfo will be completely fscked up because of this
|
11:23
|
| ubertibbs
|
Because honestly the included example doesn't look all that bad to me.
|
11:23
|
| * Rathann has no idea about ruby and its gems
|
11:23
|
| spot
|
no, i think this is because the "gem" command embeds the install path passed to it in compiled libraries
|
11:23
|
| spot
|
if i run: gem install --local --install-dir %{buildroot}%{gemdir
|
11:23
|
| spot
|
then "%{buildroot}%{gemdir}" is going to get embedded into libraries
|
11:24
|
| spot
|
whereas, if i run: gem install --local --install-dir ./%{gemdir}
|
11:24
|
| hansg
|
spot, so you think that the source file paths in the debuginfo will be right?
|
11:24
|
| spot
|
hansg: i have no idea, but again, i'm not sure if the debuginfo is useful anyways for ruby gems
|
11:24
|
| spot
|
having the %{buildroot} embedded in C libraries is obviously bad
|
11:25
|
| hansg
|
spot, well if they have native code, it might be useful
|
11:25
|
| spot
|
hansg: only if a debugger can parse it sanely
|
11:25
|
| hansg
|
hmm, it seems we are not alone with this problem, see: http://pkg-ruby-extras.alioth.debian.org/rubygems.html
|
11:27
|
| hansg
|
and: http://pkg-ruby-extras.alioth.debian.org/upstream-devs.html
|
11:27
|
| ubertibbs
|
So, honestly, looking at the provided example spec, I don't see anything stomach churning.
|
11:27
|
| spot
|
yeah. it is a hack, but its not the worst hack ever.
|
11:28
|
| hansg
|
I think we should ask the Fedora ruby guys to team up with the debian ruby guys and try to get this improved upstream
|
11:28
|
| spot
|
hansg: yes, but i'd also like to let them document this interim workaround
|
11:28
|
| hansg
|
I can live with this, under the condition that some serous attempts are made to remedy this properly
|
11:29
|
| Rathann
|
well, as long as the final result is sane I'm not against this
|
11:29
|
| abadger1999
|
ubertibbs: +1
|
11:29
|
| ubertibbs
|
I don't know how we can put conditions on a guideline like that.
|
11:29
|
| Rathann
|
although I find it odd that passing install-dir relative to current dir matters somehow
|
11:30
|
| ubertibbs
|
Now, what I would really like to see is a package that does this, so we can look at the result and make sure it is actually sane.
|
11:30
|
| spot
|
i think the best we can do is to vote on this and request that the ruby folks (mamoru and david lutterkort) try to get this fixed upstream
|
11:30
|
| Rathann
|
ubertibbs: +1, I too would like to have a testable src.rpm
|
11:31
|
| abadger1999
|
lutter owns the rubygem package as well.
|
11:31
|
| spot
|
we can ask for an example SRPM
|
11:31
|
| ubertibbs
|
So, I hate to make them go through the cycle again.
|
11:31
|
| spot
|
as do i, but if you guys are uncomfortable with the draft as is...
|
11:32
|
| ubertibbs
|
Based on what I can see, I can vote for this but my concern is that we approve it and then rpm goes and does something bizarre with it.
|
11:32
|
| spot
|
fwiw, i'm +1 on this, with the request to fix this properly in the gem install command
|
11:32
|
| hansg
|
+1 (also with the request to fix this properly in the gem install command)
|
11:33
|
| abadger1999
|
I'm willing to vote +1. For a hack it's pretty clean and it's an improvement on where we are today.
|
11:33
|
| rdieter
|
+1 (ditto)
|
11:33
|
| Rathann
|
+1 as well
|
11:33
|
| ubertibbs
|
We need to ask in the future that guidelines changes come with an actual package attached so that we can look over things.
|
11:33
|
| abadger1999
|
<nod>
|
11:33
|
| ubertibbs
|
Anyway, +1 to the proposal.
|
11:33
|
| spot
|
okay, there is +5 in there
|
11:34
|
| spot
|
it passes with the request
|
11:34
|
| spot
|
Next item: http://fedoraproject.org/wiki/PackagingDrafts/Fonts_packaging_automation
|
11:34
|
| spot
|
there are a few things in here
|
11:34
|
| spot
|
the first one is a followup from http://fedoraproject.org/wiki/PackagingDrafts/Fonts_spec_template_correction:_fontconfig_(2008-10-12))
|
11:35
|
| spot
|
we approved it, pending upstream feedback
|
11:35
|
| ubertibbs
|
Personally I have no real problem with magicalness in specs and hiding things behind macros.
|
11:35
|
| ubertibbs
|
But I know that others here have disagreed in the past.
|
11:35
|
| spot
|
well, in the case of fonts, this is already happening
|
11:36
|
| spot
|
this effort is to standardize the macros
|
11:36
|
| ubertibbs
|
It isn't as if we haven't approved GHC and Java guidelines in the past after asking them to hide more things behind macros.
|
11:36
|
| abadger1999
|
spot:agreed. The macros have already happened.
|
11:36
|
| ubertibbs
|
I do with the "set of font packages" links actually had some spec files I could look at.
|
11:37
|
| hansg
|
Fonts_packaging_automation, +1 (I'm assuming the actual macros will get vetted during the review of the package)
|
11:37
|
| spot
|
I'm +1 here as well
|
11:37
|
| ubertibbs
|
hansg: I don't think it is safe to assume that.
|
11:37
|
| abadger1999
|
+1
|
11:37
|
| hansg
|
ubertibbs, even then I'm still +1, I don't want the fpc to go vetting each and every macro ever introduced / used
|
11:38
|
| Rathann
|
I remember reading that earlier on the mailing list, I liked it and I see my comments have been taken into account, so +1
|
11:38
|
| racor
|
-1
|
11:38
|
| Rathann
|
however I think it should be named fonts-* not fontpackages-*
|
11:38
|
| * hansg wonders whats in a name
|
11:39
|
| ubertibbs
|
I'm getting blown over by the bureaucracy here. Can this whole thing be condensed to "We want to add five macros"?
|
11:39
|
| racor
|
to me, using the package is a massive mistake
|
11:39
|
| spot
|
ubertibbs: and take into account the avail.d/ changes we saw before
|
11:39
|
| racor
|
ubertibbs: Yes and move it to fedora-rpm-config
|
11:40
|
| ubertibbs
|
racor: Can you articulate your objections? I would really like to hear them, but I'm concerned that IRC is not a good medium for that.
|
11:40
|
| racor
|
I am objecting the macros
|
11:40
|
| ubertibbs
|
Where do you actually see the macros?
|
11:41
|
| racor
|
once a macro is in, you can hardly ever get rid of them
|
11:41
|
| ubertibbs
|
It's like this proposal is a long-winded document but doesn't actually include the changes they want to make.
|
11:41
|
| racor
|
they are part of the src.rpm
|
11:41
|
| * f13 wonders what racor suggests as an alternative
|
11:41
|
| ubertibbs
|
I guess I'll go unpack it now. They should be in the actual proposal.
|
11:42
|
| f13
|
mass cut/paste ?
|
11:42
|
| spot
|
http://fpaste.org/paste/143
|
11:43
|
| Rathann
|
f13: python and perl package specfiles define python and perl paths themselves, so there is a precedent
|
11:43
|
| ubertibbs
|
racor: Are you objecting to things like %_fontbasedir %{_datadir}/fonts
|
11:43
|
| racor
|
ubertibbs: yes.
|
11:43
|
| ubertibbs
|
Thinking instead that packages should just use %{_datadir}/fonts if that's what they mean?
|
11:43
|
| f13
|
Rathann: precedent, or lazyness?
|
11:43
|
| spot
|
f13: precedent. these macros are useful.
|
11:43
|
| racor
|
furthermore you would have to BR: fontpackages-devel in all fonts*specs
|
11:43
|
| spot
|
(well, at least the python/perl ones)
|
11:43
|
| f13
|
spot: I meant precedent to leaving them in the top of .spec files rather than putting them in redhat-rpm-config
|
11:44
|
| ubertibbs
|
racor: Then do you object to, say, the %{_R_make_search_index} macro from the R guidelines?
|
11:44
|
| Rathann
|
well, fontbasedir seems redundant, it's used only once
|
11:44
|
| spot
|
f13: the point being that having standardized macros makes it easier for new packagers
|
11:44
|
| f13
|
spot: I don't think you're seeing my argument.
|
11:44
|
| ubertibbs
|
Or the %ghc_preinst_script macro from the Haskell guidelines?
|
11:44
|
| f13
|
spot: I wasn't buying the macros being in the top of python spec files as 'precedent for not having site wide macros'
|
11:44
|
| Rathann
|
f13: I meant it as a bad example :)
|
11:45
|
| Rathann
|
they should be moved out of these specs into rpm config
|
11:45
|
| racor
|
the perl macros are implemented in *-rpm-config, not in a separate package
|
11:45
|
| Rathann
|
not necessarily a separate package
|
11:45
|
| spot
|
racor: so, you'd be okay with these macros in *-rpm-config ?
|
11:46
|
| racor
|
... and you can hardly get rid of them
|
11:46
|
| Rathann
|
well, racor has a point about not adding BR: fontpackages-devel to every font package
|
11:46
|
| rdieter
|
it's not uncommon for initial implementations to start elsewhere, and once proven, move into -rpm-config.
|
11:46
|
| racor
|
spot: no, I am against any vendor-proprietary macros.
|
11:46
|
| ubertibbs
|
I'm just trying to understand racor's objection. Is it that we shouldn't be adding macros, ever? Or that these macros don't add enough value? Or is it something else?
|
11:46
|
| racor
|
I am not opposed to upstream rpm providing macros
|
11:47
|
| rdieter
|
Rathann: that's a policy decision made by font sig, if that's what they want.
|
11:47
|
| * hansg watches the clock
|
11:47
|
| spot
|
so, basically, the only thing for FPC here is whether we approve the macros and use of avail.d
|
11:47
|
| Rathann
|
rdieter: sure, if someone takes care of that, then it's fine, but I do object slightly to adding "just one line" to every font spec
|
11:48
|
| rdieter
|
Rathann: also, font sig's job, imo, to "take care of that". :)
|
11:48
|
| racor
|
rdieter: do we care about other people's ponys?
|
11:48
|
| Rathann
|
having said that, I'm still in favour of this draft
|
11:48
|
| ubertibbs
|
Personally I have no problems with adding additional macros if it makes things simpler for the packagers and makes the packages simpler to comprehend.
|
11:48
|
| spot
|
Can we do a vote?
|
11:49
|
| racor
|
spot: i this applies, you can shut down this FPC
|
11:49
|
| rdieter
|
racor: as long is they don't interfere, and play nice with other ponys.
|
11:49
|
| racor
|
it's our job to review other group's proposal.
|
11:49
|
| ubertibbs
|
And I don't think the committee as a whole does, either, because we've approved Haskell and Java and R in the past, with their macros included.
|
11:49
|
| spot
|
racor: and... we are.
|
11:49
|
| racor
|
ubertibbs ... yes, mistakes to learn from.
|
11:50
|
| ubertibbs
|
Hardly.
|
11:50
|
| ubertibbs
|
I mean, this wasn't even raised as an objection then.
|
11:50
|
| ubertibbs
|
We _asked_ them to add macros to Java and Haskell.
|
11:50
|
| * f13 hasn't noticed the world ending because java packages have macros
|
11:51
|
| racor
|
ubertibbs: Did we?
|
11:51
|
| Rathann
|
spot: +1 on fonts packaging automation
|
11:51
|
| ubertibbs
|
It makes the packages reasonable instead of having 50 lines of identical shell code pasted into them.
|
11:51
|
| spot
|
+1 from me
|
11:51
|
| hansg
|
spot: +1 on fonts packaging automation
|
11:51
|
| ubertibbs
|
+1 from me.
|
11:51
|
| racor
|
-1 from me
|
11:51
|
| rdieter
|
+1 (there's good and bad uses of macros, this is an example of the good kind, imo)
|
11:51
|
| ubertibbs
|
racor: If you want the reference where we asked the Java folks to add the macros, I will dig it out for you.
|
11:52
|
| spot
|
abadger1999: would you like to vote?
|
11:52
|
| abadger1999
|
+1
|
11:52
|
| spot
|
okay, thats 6 for and 1 against, it passes
|
11:52
|
| spot
|
we have two other items on the "todo" list for today, but i'm not sure they are ready for review yet
|
11:52
|
| spot
|
JavaScript and Python Virtual Provides
|
11:53
|
| spot
|
abadger1999: both of these are yours, i believe
|
11:53
|
| abadger1999
|
spot: Too busy with upstream python issues.
|
11:53
|
| spot
|
abadger1999: okay, then, are there any other issues for today?
|
11:53
|
| abadger1999
|
I owe the committee a pros and cons table for the javascript guidelines.
|
11:53
|
| abadger1999
|
https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00074.html
|
11:53
|
| abadger1999
|
That's an additional issue.
|
11:54
|
| f13
|
there was the message I posted regarding review guidelines vs package guidelines
|
11:54
|
| ubertibbs
|
Yes, f13's request.
|
11:54
|
| spot
|
if no one is opposed, i can go over the review guidelines and make sure they're all expressed in the packaging guidelines
|
11:55
|
| abadger1999
|
spot: +1
|
11:55
|
| f13
|
i was kind of hoping some kind soul would do it so that spot or I wouldn't have to (:
|
11:55
|
| spot
|
f13: i know them well enough, it won't take me too long
|
11:55
|
| ubertibbs
|
+1 for someone else doing it.
|
11:55
|
| ubertibbs
|
I so hate working in the wiki.
|
11:55
|
| spot
|
okay, since i am not hearing opposition, i'll just tackle that
|
11:56
|
| f13
|
ubertibbs: you should really try lmacken's vim plugin for firefox/wiki
|
11:56
|
| spot
|
as to the FHS stuff, i'm not opposed with making it a MUST that packages follow the FHS
|
11:56
|
| ubertibbs
|
f13: I used to use mozex, but it doesn't work with ff3.
|
11:56
|
| spot
|
the only thing that gives me concern is cross compilers
|
11:57
|
| ubertibbs
|
Well, remember that /spu was a mistake that has been fixed.
|
11:57
|
| spot
|
i know they need a toplevel in /usr
|
11:57
|
| Rathann
|
is FHS sane now? if so, no objections
|
11:57
|
| racor
|
spot: why?
|
11:57
|
| ubertibbs
|
And I tried to do something about cross-compilers and was flamed so much for my trouble that I gave up.
|
11:57
|
| spot
|
racor: that was what i thought, keeping in mind that i'm not an expert here
|
11:57
|
| racor
|
the spu package is simply broken.
|
11:57
|
| spot
|
racor: do cross compilers need to violate the FHS?
|
11:57
|
| f13
|
racor: cross compilers need /usr/<target>/ don't they?
|
11:57
|
| hansg
|
f13, that is preferred way of doing things, yes
|
11:58
|
| racor
|
spot,f13: Right, the need $exec_prefix/<target>
|
11:58
|
| f13
|
is that allowed by the FHS ?
|
11:58
|
| QuitSonar_Gal has left this server (Read error: 110 (Connection timed out)).
|
11:58
|
| abadger1999
|
spot, racor: Is the crosscompiler location specified in the GNU coding standard?
|
11:58
|
| racor
|
f13, no, but it's common practice ever since GCC is around
|
11:58
|
| ubertibbs
|
racor: So when spot said the same thing as you just said, you replied "why?".
|
11:58
|
| * abadger1999 knows that libexecdir is.
|
11:58
|
| hansg
|
f13, AFAIK no, but it is how the whole world does it
|
11:58
|
| f13
|
so this is exactly what spot was asking about
|
11:59
|
| ubertibbs
|
It's no wonder why people are confused.
|
11:59
|
| spot
|
so, i don't think the FHS specifies where cross toolchains should go
|
11:59
|
| f13
|
cross compilers don't adhere to the FHS, so that's a concern if we were to make FHS mandatory.
|
11:59
|
| Rathann
|
f13: we could make it mandatory except for cross-compilers
|
11:59
|
| ubertibbs
|
"As exceptions..... libexec.... cross compilers..."
|
11:59
|
| f13
|
(or more correctly the FHS doesn't adhere to cross compilers)
|
11:59
|
| racor
|
spot, f13: the why was aiming at the spu toolchain. it is badly packaged
|
12:00
|
| f13
|
racor: spu was the recent example, regardless of /spu, it also had /usr/spu/
|
12:00
|
| spot
|
really, this boils down to a lack of guidelines for how to package cross toolchains
|
12:00
|
| racor
|
there is no need for /spu, GCC however needs /usr/spu
|
12:00
|
| f13
|
ubertibbs: clearly all our guidelines must have 2 listed exceptions to them. Lets make /that/ a guideline, with exceptions (:
|
12:01
|
| abadger1999
|
Looks like crosscompiler location is not specified in GNU standards.
|
12:01
|
| racor
|
that said, /usr/<target> is the only case where GCC-cross toolchains deviate from the FHS.
|
12:01
|
| f13
|
racor: please ignore the "/spu" part of the question. spot was mostly concentrating on /usr/spu which is common across all cross compilers we have (/usr/<target>)
|
12:01
|
| ubertibbs
|
Everyone knows and agrees that /spu was a mistake caused by a macro that somehow was undefined. It was fixed immediately after it was brought up.
|
12:01
|
| spot
|
okay, so we could make this a must and add the exception for the /usr/<target> for cross toolchains?
|
12:01
|
| racor
|
spot: OK with me.
|
12:02
|
| spot
|
are there any other places where enforcing the FHS strictly would cause us problems?
|
12:02
|
| abadger1999
|
"with exceptions for libexecdir (specified in the GNU Coding Standards [LINK]) and /usr/target for crosscompilers"
|
12:02
|
| abadger1999
|
http://www.gnu.org/prep/standards/standards.html#Directory-Variables
|
12:02
|
| hansg
|
spot, +1
|
12:02
|
| ubertibbs
|
I'm sure there are other problems, but we should simply address them when they come up.
|
12:03
|
| racor
|
this of course should not invalidate attempts to make GCC better compliant to the FHS.
|
12:03
|
| spot
|
abadger1999: looks good to me.
|
12:03
|
| abadger1999
|
+1 from me :-)
|
12:03
|
| racor
|
+1
|
12:03
|
| Rathann
|
+1
|
12:03
|
| spot
|
+1
|
12:03
|
| rdieter
|
+1
|
12:04
|
| spot
|
ubertibbs: would you like to chime in?
|
12:04
|
| ubertibbs
|
+1
|
12:04
|
| ubertibbs
|
sorry
|
12:04
|
| spot
|
okay, thats +5 easily
|
12:04
|
| spot
|
any other items?
|
12:04
|
| spot
|
none from me
|
12:04
|
| Rathann
|
so javascript and python are postponed?
|
12:05
|
| spot
|
Rathann: yes
|
12:05
|
| Rathann
|
js looks fine to me though
|
12:05
|
| Rathann
|
we've already discussed it too
|
12:05
|
| abadger1999
|
Rathann: Yeah... I've been running across problems with my own draft.
|
12:05
|
| Rathann
|
ah
|
12:06
|
| hansg
|
For those interested in cross compiler guidelines the embedded SIG (which is sort of dead atm) has a blurb here: http://fedoraproject.org/wiki/Extras/SIGs/Embedded/CrossCompiling
|
12:06
|
| abadger1999
|
Rathann: I want to change javascript to be more like static libraries.
|
12:06
|
| Rathann
|
ok then
|
12:06
|
| ubertibbs
|
It's more along the lines of it not really being reasonable to do it in some other way.
|
12:06
|
| abadger1999
|
But that has the usual static library issues so it needs evaluation.
|
12:06
|
| hansg
|
The <exex-prefix>/<target> is specified in gcc's INSTALL document
|
12:06
|
| Rathann
|
abadger1999: not more like java .jars?
|
12:06
|
| ubertibbs
|
BTW, I just approved a puthon package that includes some portion of jquery. Maybe I shouldn't have done that; I'm not really sure.
|
12:07
|
| abadger1999
|
Rathann: I'm only passingly familiar with .jars What do you see as a parallel?
|
12:07
|
| abadger1999
|
ubertibbs: <nod> Until we get JavaScript Guidelines, that's probably what we should do. We'll definitely want to clean those up after wards, though.
|
12:08
|
| * hansg has got to go now
|
12:09
|
| Rathann
|
when not used via http, both jars and js have be put into path or symlinked to be usable by an application
|
12:09
|
| hansg
|
Next meeting same time ? I still really would like to see a different time.
|
12:10
|
| hansg
|
Bye all/
|
12:10
|
| Rathann
|
but they're not "linked in" as is the case with static libs
|
12:10
|
| Rathann
|
bye hansg
|
12:10
|
| Rathann
|
abadger1999: ^
|
12:10
|
| abadger1999
|
So js is a bit more involved. Because it is almost always served over http, having tons of little files creates a huge latency.
|
12:10
|
| spot
|
feel free to keep chatting guys, but i'm calling the meeting
|
12:11
|
| Rathann
|
true
|
12:11
|
| abadger1999
|
But to organize your code you want to have lots of little files.
|
12:11
|
| Rathann
|
thanks spot :)
|
12:11
|
| abadger1999
|
Thanks spot!
|
12:11
|
| abadger1999
|
So with dojo, I discovered that they distribute a tarball with tons of individual files, a way to specify dependencies between them, and a script to "compile" them into a single file.
|
12:12
|
| Rathann
|
ah
|
12:12
|
| Rathann
|
neat, but do we really want to do that?
|
12:12
|
| abadger1999
|
heh. Not sure :-)
|
12:12
|
| abadger1999
|
If we did, then it would be like static libraries.
|
12:13
|
| Rathann
|
yes
|
12:13
|
| nim-nim
|
all: thanks for approving the fonts stuff
|
12:13
|
| abadger1999
|
If we don't, applications will be very slow by default.
|
12:13
|
| Rathann
|
abadger1999: what's the slowdown? 10%? 50%?
|
12:13
|
| abadger1999
|
Rathann: I found it depends on the http server. For a python app using CherryPy, it was seconds vs minutes.
|
12:14
|
| abadger1999
|
Rathann: When I switched it to apache, it was still seconds vs over a minute.
|
12:15
|
| Rathann
|
I'm thinking about some sort of caching/preprocessing, i.e. build one file out of all the dependent js files but rebuild it if any of them gets updated
|
12:16
|
| abadger1999
|
<nod> You mean dynamically?
|
12:16
|
| Rathann
|
I guess
|
12:16
|
| abadger1999
|
mod_javascript :-)
|
12:16
|
| Rathann
|
heh
|
12:16
|
| Rathann
|
just an idea
|
12:17
|
| Rathann
|
all right, I have to go shop for food
|
12:17
|
| Rathann
|
later folks
|
12:18
|
| abadger1999
|
yeah. I think it's a good idea but there's no upstream project to do it ATM... We'd have to devote manhours to make it happen.
|
12:18
|
| abadger1999
|
Rathann: Later!
|
12:18
|
| Rathann has left this channel ("Leaving.").
|
12:18
|
