Fernando-Basso has quit [Remote host closed the connection]
Diagon has joined #racket
Arcaelyx has quit [Quit: Arcaelyx]
Arcaelyx has joined #racket
FreeFull has quit []
vraid has quit [Ping timeout: 276 seconds]
efm has joined #racket
orivej has quit [Ping timeout: 246 seconds]
q9929t has joined #racket
q9929t has quit [Remote host closed the connection]
q9929t has joined #racket
orivej has joined #racket
q9929t has quit [Read error: Connection reset by peer]
dddddd has quit [Remote host closed the connection]
q9929t has joined #racket
q9929t has quit [Client Quit]
orivej has quit [Ping timeout: 268 seconds]
Diagon has quit [Quit: Leaving]
ZombieChicken has joined #racket
efm has quit [Ping timeout: 245 seconds]
orivej has joined #racket
Arcaelyx has quit [Ping timeout: 272 seconds]
orivej has quit [Ping timeout: 258 seconds]
lavaflow_ has joined #racket
lavaflow has quit [Read error: Connection reset by peer]
cantstanya has quit [Remote host closed the connection]
cantstanya has joined #racket
endformationage has quit [Quit: WeeChat 2.5]
sauvin has joined #racket
sauvin has quit [Max SendQ exceeded]
sauvin has joined #racket
orivej has joined #racket
manualcrank has quit [Quit: WeeChat 1.9.1]
DGASAU has quit [Ping timeout: 245 seconds]
mSSM has joined #racket
efm has joined #racket
euhmeuh has joined #racket
Sgeo_ has joined #racket
Sgeo__ has quit [Ping timeout: 258 seconds]
mSSM has quit [Ping timeout: 248 seconds]
DGASAU has joined #racket
zipper has joined #racket
libertyprime has joined #racket
afidegnum has quit [Quit: leaving]
vraid has joined #racket
orivej has quit [Ping timeout: 248 seconds]
orivej has joined #racket
libertyprime has quit [Quit: leaving]
soegaard has joined #racket
tilpner has quit [Quit: WeeChat 2.4]
zipper has quit [Ping timeout: 245 seconds]
dddddd has joined #racket
zipper has joined #racket
zipper has quit [Ping timeout: 258 seconds]
zipper has joined #racket
zipper has quit [Ping timeout: 272 seconds]
zipper has joined #racket
<ermo>
when building racket, are the files in ${exec_prefix}/racket/collects/ considered arch-independent or not?
<ermo>
as far as I can tell, the ubuntu package collects both /usr/share/racket/collects and /usr/share/racket/pkgs in racket-common, which to me suggests that they're supposed to be arch-independent?
<soegaard>
ermo: A cautious yes. Most collects and packages are architecture independent. But where is the gui library stored?
<ermo>
I'm packaging racket for exherbo, which uses a different multi-arch setup to most distros and tend to expose issues like these
<ermo>
*tends
<ermo>
so I'm trying to figure out where I stand =)
<soegaard>
ermo: send asumu an email
<soegaard>
the rkt files are architecture independent
<bremner>
as are the .zo afaik
<soegaard>
yes
zipper has quit [Ping timeout: 246 seconds]
<ermo>
IIRC, bin and lib use ${prefix} when they should be using ${exec_prefix}. I'm going to complete my investigation and try to cook up a patch for the Makefiles.
<ermo>
bremner: would you be open to test such a patch on debian/ubuntu to see if it generates the same package list (i.e. essentially a no-op change from a "traditional, non-obscure distro" packaging perspective)
<ermo>
once I know more, I'll see if asumu is interested =)
ephemera_ has quit [Ping timeout: 248 seconds]
zipper has joined #racket
<ermo>
soegaard: second question: with racket-on-chez, are the .rkt files then compiled to arch-specific machine code?
<soegaard>
Yes, I believe the "zo" files will contain machine code.
<ermo>
because in that case, I'm not sure /usr/share is really the right place to put them
<ermo>
e.g. python uses /usr/lib for its packages
<ermo>
and I can see why 3m and cs would benefit from using the same directory structure
<bremner>
the debian packages mainly use /usr/share because not all architectures are capable of building the docs. If .zo's stop being arch independent that will have to change
<bremner>
s/docs/docs and byte compiled stuff/
<ermo>
yeah
<ermo>
well the docs should probably stay under /usr/share
<ermo>
(i.e. ${datadir}/racket}
<ermo>
but .rkt files (and bytecode stuff) probably ought to live under ${exec_prefix}/lib/
<bremner>
otoh, that will probably mean dropping support for racket on mips and maybe some arm variants (in Debian)
<ermo>
and executables should probably live under {exec_prefix}/bin and not just {prefix}/bin
<ermo>
(this might seems slightly anal and OT to #racket as such)
<bremner>
right, I can imagine that might be the correct thing to do, but it will break the debian packages (probably), so I can't really test it.
<ermo>
sheet
zipper has quit [Ping timeout: 246 seconds]
<bremner>
ermo: isn't collectsdir meant to be configurable? I don't understand why patching is needed
<ermo>
look at the .desktop files setup in 312
<ermo>
/usr/<arch-specific>/share/applications is flat out wrong
<bremner>
sure.
<ermo>
so that needs a patch
zipper has joined #racket
<bremner>
ok, but hows that related to collects?
<bremner>
I mean, desktop files are optional.
<bremner>
just some shim so people can click icons?
<ermo>
with the default config, collects and common libraries can end up in different dirs. If they're both supposed to be arch-independent, then surely they should end up in the same dir by default?
<ermo>
e.g. /usr/share
<ermo>
(or /usr/lib)
<ermo>
at least, that's my current understanding (and I could well be *wrong*)
<ermo>
no matter what {prefix} I specify I mean
orivej has quit [Ping timeout: 268 seconds]
<bremner>
ok, but do you need to change the default configuration as a packager?
<ermo>
in the ideal case, I should specify the GNU dir options that I need to specify
<ermo>
e.g. ${prefix} and ${datarootdir}
<ermo>
(in the case of exherbo)
<ermo>
and then things should just work
<ermo>
assuming a build system that is compliant with the spec
<ermo>
in this case, it appears racket's build system is not.
<ermo>
for e.g. Debian, the change should be a no-op in the default case.
<ermo>
from a packaging perspective (unless Debian does its own custom thing, but judging from the file list in racket-common, that looks unlikely?)
<ermo>
and since I'm the odd man out (representing exherbo) I guess it falls on me to make sure the system follows the spec and doesn't break shit for other diligent packagers spending their valuable free time maintaing FLOSS
<ermo>
(pardon my french)
<bremner>
ermo: moving things around in the filesystem isn't a no-op though
<ermo>
from the perspective of rebuilding the package, it should be, shouldn't it?
<ermo>
it's a problem for packages with reverse deps obviously
iyzsong has joined #racket
<ermo>
(is this the right channel to discuss this? We're veering into maintainer territory, even if the discussion is interesting)
<bremner>
I don't know where else would be appropriate.
<ermo>
keep in mind that I'm coming at this from a "from-source distro" perspective. Rebuilding and fixing broken linking is a single command away and then the whole system is updated after x amount of time. But I suppose it isn't that simple in a pre-packaged distro
<bremner>
right, for us the binary packages are the artifacts of interest, and those change in a non-trivial way
<ermo>
Hm. I suppose it can't hurt to try to cook up a "correct" Makefile patch first.
<ermo>
I mean, I can obviously subvert the the package by simply specifying --exec_prefix=/usr/share , but it looks a bit, well, "odd"
<bremner>
agreed.
<ermo>
so there are two issues
<ermo>
one is to get the prefixes minimally correct
<ermo>
the other is a potentially invasive change to move libs and .rkt files (+ compilation artifacts) to (..)/lib/racket
<ermo>
(e.g. the python-like way)
<bremner>
well, .rkt is arch indep as already mentioned
<ermo>
yeah, but the .zo might not be in the future
<ermo>
and .py are also arch independent, yet they are still libraries and thus live under /usr/lib
<ermo>
just like the .rkt files are libraries
<bremner>
I don't follow that
<bremner>
I don't think "is a library" in the informal sense is related to being in /usr/lib. At least not in debian.
<ermo>
"the .rkt files are libraries" <- is that contentious? I can import them in the racket interpreter. I thought that was the definition of a library?
<ermo>
what am I not getting? ^^'
<ermo>
or, rather, am I expressing myself in a way that is ambiguous?
<ermo>
(not trying to be difficult, just trying to understand)
<bremner>
well my /usr/lib is almost all arch dependent stuff
<ermo>
for reference see: ls /usr/lib/python* , ls /usr/lib/perl, ls /usr/lib/lua <- they all have arch-independent libraries (i.e. script code meant to be run by an interpreter)?
<bremner>
but you're right that python puts stuff in /usr/lib
<bremner>
*shrug*
<ermo>
what makes racket different in that aspect?
<ermo>
sorry "ls /usr/lib/perl*"
<bremner>
sure.
<ermo>
I would argue that, in this case, racket is on the wrong path compared to, well, everything else
<bremner>
but /usr/share/perl/ is also there
* ermo
doesn't have a Debian/Ubuntu box handy
<bremner>
ermo: I'm not saying you're wrong, I'm just thinking about cost/benefit
<bremner>
I have 50M of perl libraries in /usr/share/perl
<ermo>
how many lua and/or python libraries do have in /usr/share ?
* ermo
checks guile
<ermo>
grr, not installed here
<ermo>
perl-base installs to /usr/lib in Ubuntu.
<ermo>
while -modules install to /usr/share
<bremner>
anyway, my only point is that things are not as clear cut as you might hope for.
<ermo>
... unfortunately :/
<ermo>
but you're absolutely right that it needs serious consideration.
<ermo>
for many reasons, some of which I might not even be aware of.
<ermo>
so you definitely have my attention =)
q9929t has joined #racket
<ermo>
bremner: cheers for taking the time to engage with me over this! =)
<bremner>
welcome
q9929t has quit [Quit: q9929t]
zipper has quit [Ping timeout: 244 seconds]
zipper has joined #racket
acarrico has joined #racket
manualcrank has joined #racket
mSSM has joined #racket
dustyweb has quit [Remote host closed the connection]
dustyweb has joined #racket
tilpner has joined #racket
<tonyg>
I could have sworn I saw somewhere a link to Matthew's thinking re racket2 syntax proposal, but I've since lost it. Does anyone know where he's written things down?
<tonyg>
I'm remembering a document that had "decisions" and "considerations" perhaps, like, things that he thinks are pretty well mandatory, plus things for the community to discuss that he's flexible on