<rlb>daviid: let's say that I end up with some time -- do you already know what the root of the dep tree is there, i.e. maybe I'd need to start with trying to migrate g-wrap unless it has other rdepends? <rlb>And more generally -- are any of these projects no longer active upstream such that they really probably should be dropped from buster (for now)? <daviid>rlb: guile-cairo does not depend on anything else but guile (any version, including the very latest stable) and cairo 1.10 <daviid>g-wrap does not depend on anything but guile as well, and works with the vey latest guile stable <mwette>just joined: What's the discussion? <rlb>mwette: just discussing what might be involved in removing guile-2.0 from debian buster. <daviid>guile-gnome depends on g-wrap, guile-cairo, and a few gnome libs all available in buster (I use guile-gnome here, mainly for GNU Foliot and guile-clutter (which depends on guile-gnome, only glib and gobject though (and clutter 1.15) <rlb>(I'm sometimes hesitant to just "throw over the wall" an NMU, i.e. just keeping something in buster if it still doesn't have an active maintainer, may not be doing anyone any favors.) <daviid>rlb: I have no idea who is using guile-gnome using the deb package, I always use every lib I need from the source, which is (partially) why I don't even use guix myself (yet ...) <daviid>I'm an 'upstreamer', what matters for me is that what I write (or co-maintain) is autotool chained and passes 'make distcheck' <daviid>rlb: and that is the case for all these three and guile-clutter (which is as important, if not more, for me, then guile-gnome, and it is not even in guix yet) <daviid>(no blaming to anyonw here, just saying that guile-clutter is not in guix yet, and gule-clutter is very difficult to install, impossible for a newbie almst, so it would be wonderfull if it was ... but I won't do it, at least not in the near future) <rlb>I wonder how g-wrap has handled transitions in debian, i.e. if I rebuild libgwrap-runtime2 against guile 2.2 instead of guile-2.0, I don't think the library name can stay the same, and maybe not the package name (unless we have a flag day transition). <rlb>(exactly the kind of thing that makes me hesitant to mess with (library producing) packages "casually" -- might well make a big mess that I'm then somewhat obligated to clean up) <rlb>yeah, that's not going to work -- it produces the exact same library, but of course completely incompatible. <daviid>rlb: g-wrap s compatible with both 2.0 and 2.2, it does not need to change ts nae, nor installation ... <rlb>the binary ABI's not likely the "same" for clients. <daviid>rlb: I don't think so, the source code is unchanged, and copiled file ar comiled on the fly and nstalled in use cache, depending on the guile version ... <rlb>i.e. if an app had g-wrap linked against libguile 2.0 and some other lib linked against libguile 2.0. I'm guessing that'd be trouble. <rlb>last time I looked in to this, my conclusion was that all guile libs need to have the guile X.Y version in the name. <daviid>that lib should be installed in a different dir, no? <rlb>e.g. /usr/lib/libgwrap-core-runtime-guile-2.0.so.2 etc. <daviid>that is ot where upsteam install things <rlb>but last time I looked at it I wandered off after understanding the complexity/mess. <rlb>Yeah, I'm going to leave this alone -- at most, I'll probably file for removal of these packages from debian, until/unless there's a maintainer. <daviid>rlb: yes, I understand, I see here that I decided for diff dir, but the name remain the same ... *rlb has too much else that's already pending. <daviid>rlb: my pont is, you withdraw guile 2.0 from buster, then these packages can remain <rlb>Not unless we do something about the libs -- and/or have a very clear transition policy that everything that matters implements, etc. <daviid>the problem is if you keep both, but you said in the beginning of the duiscusin you want to withdraw 2.0 from buster <rlb>You just can't have two libs with the same name (and SONAME) but incompatible ABIs -- leads to segfaults, or worse. <daviid>but you would not withdraw guile 2.0 and keep g-wrap lib build for guile 2.0 right? <rlb>In order for g-wrap to be upgraded to 2.2 I suspect it has to change its library names, or sonames, or both. <daviid>rlb: only if you keep guile 2.0 as well, iiuc <rlb>daviid: people already have that stuff installed. <rlb>It won't automatically disappear. <rlb>... i.e. it's non-trivial to get that right, including possibly all the relevant Breaks/Conflicts/Whatever to force out the incompatible ABI, and that's definitely frowned upon. <rlb>Not even sure the ftpmasters would allow it. ***geokon1 is now known as geokon
<rlb>i.e. hypothetically, I suspect the new g-wrap would have to list every package version in debian that's already linked against it going back through at least stretch as a Breaks/Conflicts/etc. And even then, people who'd linked their own stuff against the lib would just be out of luck -- and that's not allowed. <rlb>(at least not in debian) <rlb>if the lib name and/or soname doesn't change, then the abi can't change. <daviid>rlb: I have no 'hard feeling' here, feel free to drop all these packages from debian, there are not really maintained upstream either anyway, just kept 'alive' <rlb>Oh no worries, didn't think you did -- just explaining the restrictions. <daviid>rlb: yes, tx, I understand nonw of us s the time, and not even the wish ... so it's ok <daviid>the only one package that is complicated to manually istall is guile-clutter, all thee can be sintalled manually with no pain in few minutes ... ***Server sets mode: +nt
<mange>I assume (filter (negate unspecified?) your-list)? ***rekado_ is now known as rekado
***geokon1 is now known as geokon
<lloda>I think I'll try to release without the doc fixes <lloda>kick the can down the road :-/ <lloda>sorry, the git is git://git.savannah.gnu.org/guile-cairo.git <lloda>the one earlier is just the browser <lloda>I cannot make distcheck because one of the tests tries to do ../../env guile -s /bin/bash ../../../../build-aux/test-driver ... which doesn't make sense <lloda>all this make-fu is over my head sadly <daviid>make: *** No rule to make target 'distcheck'. Stop. <daviid>i did ./autogen.sh;./configure;make distcheck <daviid>lloda: i'm not in my best concentration mood but i've nver seen this error ever :) <daviid>make clean fails, make distclean fails as well ... must be something 'basic' somehow ... don't know <lloda>you have to pass --prefix=... to ./autogen.sh <daviid>ok, but then you sould specify that , will tyr <lloda>usually you only need to pass it to ./configure, but cairo does the same <lloda>I don't think it should work that way, but what do I know <daviid>you should print a message in tht case <lloda>autogen.sh does print a message <lloda>but you have to run it on its own to see it, ofc if you do autogen.sh && .. && .. you don't see it <daviid>ok, evenwith --prefix=/opt2, make distcheck fails here <daviid>lloda: I really thing it's a bad idea t 'have to' pass --prefix to autogen.sh <daviid>lloda: autogen should just do 'autoreconf -vif <lloda>re: paste, it's the same error I get <lloda>It happens because tests/unit-tests/Makefile.am runs ../env guile -s SHELL for some reason, and the arg of -s should be a Guile script <lloda>I don't understand how SHELL ends up there though <lloda>so I don't know how to fix that <lloda>re: autogen.sh fix, could you send a patch? <lloda>what's the build-aux/config.rpath thing? I don't have that in guile-cairo <daviid>you cn skip it, but its becaue of guile.m4 macro (that I add to all my prjects ... see the commebt in that sema file) <daviid>lloda: I don't remember, does gule-cairo uses guile-lib unit-test? <lloda>I've pushed the autogen.sh fix <daviid>lloda: I'm not 100% of my capacity here :), sorry <lloda>I don't think it uses guile-lib (it does use guile-lib for building the doc) but I'm not 100% sure <lloda>daviid: no worries, this is async anyway <daviid>error: Your local changes to the following files would be overwritten by merge: <daviid>you need to remove INSTALL from the tree <daviid>but then it leads to the same error 'make distcheck' <daviid>lloda: not sure, but I see I use <daviid>$(abs_top_builddir)/pre-inst-env\ <daviid>$(GUILE) -L $(abs_top_builddir)/test-suite\ <daviid>that is very different from what is there <daviid>API_FILE=$(srcdir)/cairo.api $(top_builddir)/env guile -s <daviid>hoestly, at tis moment, I fail to see the problem, but make distcheck still fils here <lloda>I'll write tonight to guile-user to get more eyes on this <lloda>but if you think of something, please let me know <daviid>yes, I'll look into this after I get some rest ... <daviid>did you change anything in the test-suite Makefile(s)? <daviid>it's the first time I see this error (rnning make distcheck) <rekado>daviid: do you know who upstream is for <rekado>for the Guile packages that would be dropped from Debian? <daviid>guile won't be droped from debian, but maybe g-wrap, guile-cairo and guile-gnome <rekado>I meant “Guile* packages”, not Guile itself. <daviid>"The current maintainer of guile-gnome-platform, Andreas Rottmann <rotty@debian.org>, has orphaned this package." <rekado>you wrote earlier that they “are not really maintained upstream either anyway, just kept 'alive'” <daviid>rekado: yes, that is my understanding <rekado>I assumed you are the upstream of these packages. <daviid>yes, but I keep them alive, I didn't really maintained these <daviid>rekado: guile-gnome, for example, binds gtk 2.10 <daviid>but I amke sure it compiles and works with the latest stable ... <rekado>do you think it would make sense for someone to try to upgrade the bindings to GTK3 or would it make more sense to start basically from scratch? <daviid>gnome withdraw a couple of old bindings, I ust emove them <daviid>but I have had no time (and no money to be honest) <daviid>rekado: guile-cairo is receiving some love though, lloda is working on it <daviid>guile-cairo doesn no depend on g-wrap <daviid>rekado: guile-clutter depends on guile-gnome (only glib and gobject) and guile-cairo (but not the version in guix, it depends on the source tree version), and guile-clutter, together with grip clutter examples, is pretty cool, but for some reason, never 'grapped' guix attention <daviid>grip clutter examples are among the things most advanced and fun I ever wrote <daviid>it has objects that 'fall' and 'resist' gravity, fr exaple ... <daviid>anyway, guile-clutter binds clutter 1.15, and needs 'git cherry pick' (I found a bug in clutter, that has been fixed in 1.25 or so ...) <daviid>rekado: 'all in all' guile-gnome and what depends on it is about 10y behind <daviid>everybody is working on the snake ... <daviid>for one guiler, ther are 1 million pythonist,and theyhave money <daviid>we neve eve get funding from nowhere ... <daviid>thinking that lisp and its dialects have 'the best numerical tower' on this planet, it' kind of pretty ironic ... <daviid>and now, all libs are in C++, which we can't even bind ... <civodul>Julia is much younger than Guile and quite successful <daviid>one would have to pay me quite a lot to give up guile for julia <daviid>when I see young s/w engineer saying that java is 'a must' (and beter then clos ?!?), then julia has a future ... too <jlicht>daviid: at the end of the day, programming languages are tools to get things done. And isn't being able to use your tool of choice for a job a good thing for everyone? <daviid>jlicht: there is no doubt, to me, that lisp and any dialects, id a couple of order of magnitude superior to any other, any, (sub)programminglanguage(s), the rest is marketing and 'young s/w engineer' to go in the trap becaue they need to pay the bill (which i true for almost any other job) s/w enginneer is the only job on this (stupid) planet for which who shooses the tools i not the s/w engineer, but fashion, and (stupid) compamies <cmaloney>TO be fair, it's usually the software folks that pick the tools initially, then it just becomes oral tradition handed down from generation to generation at a company <daviid>cmaloney: that is not my experience, but I respect yours of course <daviid>up to reasearch lab got 'afraid' because if 'they' let me do things using lisp (or guile), then they would be f....p if I 'disapear' ... <cmaloney>I'm thinking in areas where there aren't many technical folks making the decisions <daviid>cmaloney: I've had that enormous luck till now too, but that is an extraordinary exceptin <cmaloney>where someone initially decides based on their personal preference, and then it becomes law <daviid>I don't know, not even one company tat uses guile <jlicht>daviid: I did not mean to contradict you, I just mean that understanding many tools is never a bad thing. <cmaloney>Honestly I'm still surprised when I hear about places that use scheme <daviid>jlicht: I hve still to see any tother language to provide me with ore power the lisp nd/or guile <cmaloney>but that's partly because I didn't pay attention until recently <daviid>cmaloney: I don't know, apart from the guix project, any company using scheme <cmaloney>I'm just happy that folks are learning Racket. I think it's lovely <daviid>cmaloney: yes, racket is 'more or less' a lisp dialect <daviid>withut gops/clos, there bigest mistake <daviid>cmaloney: oop, used appriopriately, is good (see gnome if you have any doubt, but there are may other example out there ...) <daviid>as I said recently on #scheme to someone 'against' oop ingeneral, and goops in particular: coll, then offer me a good gnome binding using srfi-9 <daviid>anyway, I have to go for now, see U all later <rekado>Does anyone know of Scheme libraries for parsing emails (e.g. multipart messages)? <rekado>I’m at the beginning of writing what I need myself, but I’d much rather just use something existing. <rekado>(I already ported a parser for rfc822 messages from a Chicken port of a module for Gauche) <rekado>(but it only parses message headers) <mwette>scheme@(guile-user)> ,use (nyacc lang nx-lib) <mwette>scheme@(guile-user)> (install-inline-language-evaluator) <mwette>scheme@(guile-user)> #<nx-matlab: a=[1, 2, 3]; ># <mwette>scheme@(guile-user)> (define b (vector-ref a 2)) <mwette>scheme@(guile-user)> #<nx-javascript: var c = b + 2; ># <mwette>scheme@(guile-user)> (define d 1) <mwette>scheme@(guile-user)> (set! d #<nx-matlab: d + 1; >#) <mwette>scheme@(guile-user)> (set! d #<nx-javascript: d + 1; >#) <mwette>maybe I should change the name "matlab" to "octave" <rekado>+1 for changing the name to “nx-octave” <sneek>Welcome back dustyweb, you have 1 message. <sneek>dustyweb, civodul says: the browser example might not be a good one: if there's a "good enough" firefox or chromium in a channel elsewhere, why would people bother getting it into Guix proper? <dustyweb>in fact I was just looking at your slides about libchop <civodul>mwette: i think Octave people call it "the M language" <dustyweb>but also because there's a general need for a uri scheme for content-addressed encrypted data <dustyweb>tahoe-lafs also has an applicable design but a lot of layers to it <civodul>yeah, Tahoe-LAFS is very nice, but maybe more sophisticated than what you describe <mwette>civodul: ha ha. OK, so I've changed the name to nx-octave. <civodul>dustyweb: i looked at casync, which seems quite nice, but unfortunately it doesn't do "convergent encryption" <rekado>issues.guix.info is now also available via HTTPS. <amz3>I hope we will have a devroom at FOSDEM <jcowan>Simple and brilliant but totally insecure: it's not nice to fool Father Kerckhoff! <amz3>ah it's about the previous convo *janneke reads the tragic discussions ... dustyweb: don't be discouraged! <rain1>I want to read the discussion too <rekado>rain1: be careful what you wish for. It’s really not pleasant. <rain1>nobody invite me to this ML yet <dustyweb>and sent a pretty strong statement about it too <janneke>rain1: i probably really shouldn't have mentioned it here; the only reason i did it was because i care for dustyweb <dustyweb>janneke: it was 800+ emails without real progress IMO <rain1>well i PM'd dustyweb about it ealrier <rain1>a lot of people are talking about it <dustyweb>rain1: oh, I got a PM saying "hey" from you but nothing else btw :) <janneke>dustyweb: i'm glad that you take care of yourself...but i feel we "need" you -- maybe in friendlier times <rekado>janneke: sadly I don’t see anything good coming out of the main thread. <rekado>a glimmer of hope is the work on howto-volunteer.html <janneke>in fact, you all here, and at #guix and #bootstrappable have given me so much hope! <dustyweb>#guix and #guile continue to be great projects within GNU <dustyweb>I like to think #mediagoblin has been too even though I have been inactive lately :) <dustyweb>I'm going to contribute to GNU projects that I think are doing good, but I won't be starting any new GNU projects until I see some changes for GNU as a whole. <rain1>maybe becausei don't have a GNU project <janneke>maybe i hoped too much that we could spread our openness and friendliness into gnu -- fast; i start to realise that you cannot force tolerance onto people <rekado>there’s a lot of resistance against this; I didn’t expect this to be *this* fierce, though. <janneke>dustyweb: i just started one, i may be writing a code of conduct :-D <janneke>rekado: i really wondered about this -- but with hindsight it was to be expected <rain1>is there no way to read this discussion? I guess there is no archive <dustyweb>rain1: sadly gnu-prog-discuss is a private list... sometimes I understand the need to take conversations into private, but tbh this is something I've never liked about g-p-d <rain1>it seems a bit dissonant that GNU is so open and about free software but this sounds like some important decisions are being made in private <dustyweb>yes... imo it's not the only governance problem in GNU either <janneke>the only thing we can do is, practice patience, hold our ground, be inspirational <janneke>some changes take one or two generations <rain1>i want to know what changes you all wish for in GNU