IRC channel logs


back to list of logs

<iskarian>also (unrelated) based on what I've seen I think the changelog should always have a file before the colon, so it should look like:
<iskarian>* gnu/packages/patches/gobject-introspection-absolute-shlib-path.patch: Modify file.
<iskarian>* gnu/packages/patches/gobject-introspection-cc.patch: Likewise.
<iskarian>or perhaps:
<iskarian>* gnu/packages/patches/gobject-introspection-absolute-shlib-path.patch,
<iskarian>gnu/packages/patches/gobject-introspection-cc.patch: Modify files.
<podiki[m]>does that gobject also address this?
<podiki[m]>which is for this bug
<raghavgururajan>iskarian: Thanks!
<raghavgururajan>podiki[m]: Unlikely. It would require gobject-introspection+cairo package definition.
<raghavgururajan>Let me see what I can do.
<podiki[m]>raghavgururajan: it has been a while, but I think cairo was the odd library out for some reason (and as noted, nix had to do something similar)
<podiki[m]>raghavgururajan thanks I'll take a look! I wonder if it'll still need that path patch, as the stuff I was trying to build uses the introspection files. Anyway, been a while since I tried, will dig it up
<podiki[m]>(also know a bit more about guix now)
<raghavgururajan>Oops, messasge came twice.
<raghavgururajan>podiki[m]: May be like this,
<excalamus> good evening
<iskarian>hello :)
<excalamus>iskarian: hi, my work continues on the Plover plugin. Got it to build, but need to figure out how to test it.
<excalamus> is it preferred to package from git rather than pypi?
<iskarian>if pypi works that's fine
<iskarian>sometimes the pypi dist doesn't contain everything you need to build and test, in which case you'd want to switch to upstream
<iskarian>If you install plover and the plugin in your profile, and you're able to load a .py dictionary, I'd say that's a success!
<xd1le>hi guix
<excalamus>iskarian: how do I add it to my profile? Append the bin/ to guix_profile?
<excalamus>did a bunch of exports to various path(can never)
<excalamus>remember if export is recursive
<excalamus>any way, did't work. Can't load python files
<iskarian>excalamus, `guix install' or `guix package -f <file>'
<excalamus>the plugin needs to be in site-packages
<iskarian>also did you add native-search-paths to plover?
<excalamus>no, thanks. Meant to, made a note, stepped away for 12 hours and lost the note...
<calnombl>so, I guix system init'd a system with rootfs encryption running on arm, and it's currently failing to boot after leaving the initrd
<calnombl>specifically it switches root and runs the --boot= command, but then fails to start file-systems and a bunch more services
<calnombl>any chance anyone has any ideas?
<excalamus>iskarian: sweet, it works!
<excalamus>gotta clean up the imports
<excalamus>okay, so by doing the guix package -f my-package.scm, it got installed to my profile, even out side my environment. But all I need to do is roll back and it will be garbage collected
***sneek_ is now known as sneek
<excalamus>is that expected? That calling guix package inside an environment would install it to the environment outside the guix environment?
<excalamus>outside being my main system
<iskarian>ah, sorry, I didn't realize you were using environments
<iskarian>Yes, that's correct, the guix commands are always "global" (really, user-global)
<iskarian>All that "guix environment" does is change what's available in the environment
<iskarian>In order to test plover with an environment, you would do something like "guix environment --ad-hoc plover python-plover-python-dictionary"
<iskarian>But I'm not sure how you would specify a package within a file to supply to "guix environment"
<xd1le>`guix environment -l <file>` ?
<excalamus>no worries! I'm out of time for this evening, unfortunately. I want to write up what I've done so far. Then I'd love to see about getting this "in guix"
<iskarian>excalamus, great! IMO the easiest way to contribute is following the steps in the manual:
<excalamus>I'm thankful for the help you've (all) shared
<excalamus>cool, started that a while back. Had some errors, but we'll see how it goes on revisit
<DynastyMic>So I'm trying to write a package in guix. However in order to build such package I need a few dependencies.
<DynastyMic>Some of which aren't already in any guix channel
<DynastyMic>So I try to write a package for that dependency
<DynastyMic>However that dependency also needs another dependency
<DynastyMic>and so on
<DynastyMic>so, should I just keep on adding packages
<raghavgururajan>sneek, later tell civodul: Since we have glib 2.68 in core-updates-frozed, what do you think of including gobject-introspection 1.68 as well from core-updates (426038df3b4a00fc3c4a3997c4014ac6da5192cf)?
<DynastyMic>or am I doing something wrong
<xd1le>what language or platform is the package in?
<DynastyMic>When I try to guix package --install-from-file
<DynastyMic>It throws me an error log
<xd1le>hmm sometimes there are tools to autogenerate (skeleton) definitions for a group of packages for a particular platform
<DynastyMic>saying that x dependency wasn't found
<xd1le>but I don't know anything about java :/
<DynastyMic>yep, that's exactly how I am now
<DynastyMic>I didn't know a thing about Java
<DynastyMic>Yesterday I learned about Ant and Maven
<DynastyMic>so the convention is to write such dependecy packages as java-x-dependency
<DynastyMic>and also I can apply inheritance
<DynastyMic>since all those packages are built more or less the same way
***lastebil_ is now known as lastebil
<xd1le>maybe try to figure out the dependency tree beforehand to see how much manual work would be involved?
<xd1le>until you get to dependencies that are packaged
<DynastyMic>Yeah, the thing is that the main package im building has about 8 dependencies that aren't already in guix
<DynastyMic>each of those has at least 5
<DynastyMic>and of those another 5
<DynastyMic>and so on
<DynastyMic>so I don't know how to tackle such problem
<xd1le>yeah that's rough
<xd1le>reminds me of the nodejs ecosystem
<xd1le>not sure either
<DynastyMic>should I ask on the mailing list?
<DynastyMic>or is there someone I could mail that specializes in java
<xd1le>what I would do is look at the existing java package definitions in guix and try to get ahold of some those maintainers
<DynastyMic>oh, good advice
<DynastyMic>how can I know the author of the packages?
<DynastyMic>just searching for the user on java.scm at git?
<xd1le>yeah either the git log or the top of the file usually has some names
<xd1le>in comment
<xd1le>in the web view, to the right of the file there is a "log" button too
<xd1le>o/ char
<DynastyMic>xd1le got it, I'm doing that =)
<xd1le>good luck!
<raghavgururajan>char: o/
<raghavgururajan>char: Were you able to build gtk4? It has been merged.
<guerrilla>Quick question: What happens if I run `guix system reconfigure /etc/config.scm` as a non-root user?
<muradm>guerrilla: i suppose it won't work
<muradm>sudo -E guix system reconfigure ..
<guerrilla>So does that mean I need to maintain two copies of my channel.scm for both root and my non-root user?
<guerrilla>channels.scm I mean
<muradm>guerrilla: no, you put your channels.scm in ~/.config/guix/channels.scm
<muradm>then you do "guix pull ..."
<muradm>then you run "sudo -E guix system reconfigure ~/.config/guix/my-system.scm"
<qzdlns[m]>morning guix
<muradm>-E flag to sudu will make your user environment preserved
<muradm>so guix commands will see ~/.config/guix/channels.scm
<guerrilla>muradm: Okay thank you
<muradm>and i suggest keeping your system config under user directory or else where
<muradm>but not under /etc
<muradm>in case you need to rebuild your /etc you may loose/forget that it is there
<guerrilla>muradm: That worked. Okay, definitely. I'll keep it with my channels. Thanks for your advice.
<guerrilla>Still pretty disoriented by how different this is
<muradm>guerrilla: from ubuntu?.. :)
<guerrilla>muradm: Arch
<the_tubular> Welcome refugee guerrilla
<muradm>definitely.. arch was may legacy also
<the_tubular>It's better here :)
<moshy>I have an update on the bootsrap build errors. Have not been able to reproduce them on a clean install, so it's just my own machine that's having issues.
<guerrilla>the_tubular: Thanks. I like it so far. It's nice to see how far GNU has come.
<fsg>Hello, I've created a pack to use on a system without guix and the package uses ssl and openssl is in the profile but cetificate verfications aren't working
<guerrilla>fsg: I think you may need the nss-certs package. That was done for me by the installer for the guix distro
<fsg>guerrilla: Right, just did a search in the profile and there is really no certificate, I'm going to include nss-certs, thanks for the answer and the package :)
<guerrilla>Good luck :)
<abrenon>hi guix
<attila_lendvai>so, python-build-system uses wrap-program deep down. would it be pointless to try to change that to wrap-script and see what happens?
<attila_lendvai>the root issue is python packages using sys.argv[0], that is changed by wrap-program
<abcdw>Hi guix!
<abcdw>Do anyone packaged browserpass extension?
<muradm>guix environment --ad-hoc artanis -- guile --no-auto-compile -c '(use-modules (artanis artanis))'
<muradm>fails with no code for module (artanis artanis)
<muradm>is it problem with packaging, or what i do wrong?
<abrenon>many package have a home-page pointing to the main page, often a README, of a code repository, is that to be prefered over a distinct website that gives more general information about the project, including tutorials, etc. ?
<attila_lendvai>abrenon, that's probably just a fallback for projects that don't have a fullfledged website
<abrenon>ok, thanks !
<abrenon>still unsure about dependencies
<abrenon>looking at pandoc, it seems like the package dependencies that are really part of the project have their home-page pointing to the page of the main project (like ghc-pandoc-types)
<abrenon>but I couldn't think of other examples
<abrenon>is that the way it's usually done or is pandoc an exception ?
<maximed>muradm: guix environment --ad-hoc guile artanis -- guile --no-auto-compile ...
<sneek>maximed, you have 2 messages!
<sneek>maximed, dhruvin says: 1. pre-inst-env current-guix build logs -> and 2. guix --with-commit build logs ->
<sneek>maximed, hugo says: My Shapefile library, announced on 30 december 2020
<muradm>maximed: ah thanks..
<attila_lendvai>maximed, thanks for the hints on the list! i'm around here also for a more interactive loop.
<guerrilla>Ok, so I've had bluetoothctl working fine but I couldn't get bluetooth to work in gnome-control-center. Based on some mailing list posts, I found that this can happen because of lack of access to /dev/rfkill, so I set that to o+w as suggested but how can I fix this in my GUIX configuration instead?
<guerrilla>(making rfkill other-writable fixed the problem.)
<runejuhl>Hi all! Anyone else seeing issues with LibreOffice and non-ASCII characters in file names? For some reason I'm unable to open any files that contain e.g. æøå. Running Guix on top of Ubuntu, have been seeing the issue for at least a month.
<attila_lendvai>guerrilla, i never could connect my Apple Magic Trackpad with gnome-control-center prior to gnome 4 (regardless of distro). i use blueman.
<stfnbms>I get the error
<stfnbms>/home/user/.guix-profile/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
<stfnbms>trying to compile QMK firmware.
<stfnbms>Does anybody know which package I need to install for stubs-32.h?
<roptat>stfnbms, I think you get this error because you try to build for 32 bits on a 64bits system. Our compilers are not multilib
<roptat>instead, you probably want to use a 32 bits compiler, which you can get with, eg. guix environment --ad-hoc gcc-toolchain --system=i686-linux
<stfnbms>Thank you. I will have to look into guix environment.
<stfnbms>This is Guix on Ubuntu as a foreign distro, by the way.
<mbakke>runejuhl: opening files with æøå in the name works for me. What $LANG are you using (check with the 'locale' command)?
<mbakke>(on Guix System)
<runejuhl>mbakke: everything is en_US.UTF-8, only difference is LC_TIME=en_DK.UTF-8
<mbakke>guerrilla: you could write a udev rule that sets the desired permissions on the device. I don't have an example at hand though.
<mbakke>runejuhl: do the files not show up in the file manager, or do you get some error?
<roptat>stfnbms, it doesn't really matter, guix works the same on foreign distro :)
<ennoausberlin>Hello. I am interested in accessing a guix vm via virt-viewer using guix spice-vdagent-service. Is this possible and is there a sample configuration?
<runejuhl>mbakke: it shows up, but gives the error "The operation on <path> was started with an invalid parameter"
<maximed>ennoausberlin: The manual has a subsection ‘Using ‘virt-viewer’ with Spice’ that seems relevant
<runejuhl>mbakke: the path shown is messed up too, `æ` becomes `Ã|`
<maximed>I haven't used it myself though
<mbakke>runejuhl: I get the same error if I start libreoffice with an invalid locale. Perhaps you need to install glibc-locales and configure GUIX_LOCPATH?
<ennoausberlin>maximed:Ah. Nice. I did not see this, I saw only the Spice Service point at the Miscellaneous-Services part in the manual
<guerrilla>mbakke: Ok, I see the part of the manual for that. That sounds good. Thanks
<runejuhl>mbakke: aah, I think I know. I think Guix behaves badly due to my LC_TIME. GUIX_LOCPATH is set, glibc-locales is installed, but I used to have similar issues in Guix a long time ago. I'm sure unsetting LC_TIME will make it work right, let me confirm
<runejuhl>mbakke: yes, that's the one. Guix does not like LC_TIME=en_DK.UTF-8 :)
<mbakke>runejuhl: weird, 'LC_TIME=en_DK.UTF-8 libreoffice' works for me
<runejuhl>mbakke: can you also open files with æøå in them?
***duds-_ is now known as duds-
<mbakke>runejuhl: yes
<runejuhl>for some reason I can't reproduce it anymore. I ran `guix environment bash` and tried from there and that worked. After exiting environment it still works...
<runejuhl>At least now I know how I might be able to debug it a bit further
<runejuhl>Thanks mbakke :)
<mbakke>you are welcome :-)
<mbakke>runejuhl: if it works in a terminal, but not from say GNOME, it could be that the desktop environment/launcher does not have GUIX_LOCPATH configured
<vats>Hello. I need to set the variable JAVA_HOME to point to the openjdk installation path, which I can locate in /gnu/store/ but nowhere in ~/.guix-profile/. What do you guys set that JAVA_HOME to?
<sneek>Welcome back vats, you have 1 message!
<sneek>vats, ArneBab says: I use ./gradlew in guix which works.
<runejuhl>mbakke: bingo, that's the one!
<apteryx>civodul: hi! I've improved the Cling package; it now builds against shared LLVM & Clang libraries (much smaller builds). Only the test will need attention: The Cling Jupyter kernel builds fine, if that was of interest (whatever that is :-))
<raghavgururajan>Hello Guix!
<apteryx>We should also migrate our LLVM packages on core-updates to use the *DYLIB way of building LLVM as a shared library, as what we're using is not a supported configuration
<pinoaffe>hi raghavgururajan!
<pinoaffe>Hi guix! I'm trying to package "nominatim", a geocoding server (address->coordinates) and it appears that the build process requires an additional file that's not in the source tar ball (a sql database dump) - what would be the required way to deal with this?
<abrenon> mentions the need to set --localstatedir=/var when running ./configure but does not
<abrenon>why is that ?
<pinoaffe>another issue is that the file in question (available at ) is not versioned or anything, it may randomly change in the future, thus making the build difficult to reproduce
<abrenon>pinoaffe: is generated by tools from the repos itself maybe ?
<civodul>apteryx: nice! so Cling is almost ready for upstreaming?
<sneek>civodul, you have 1 message!
<sneek>civodul, raghavgururajan says: Since we have glib 2.68 in core-updates-frozed, what do you think of including gobject-introspection 1.68 as well from core-updates (426038df3b4a00fc3c4a3997c4014ac6da5192cf)?
<civodul>raghavgururajan: i don't have particular decision power, but what i can say is that, given that gobject-introspection has 7K dependents, it's prolly too late to change it in core-updates-frozen
<civodul>that branch is supposed to contain only "bug fixes"
<civodul>but it's probably good for core-updates, tho!
<roptat>didn't a binutils update just go through in core-updates-frozen?
<maximed>roptat: Wasn't that ‘gnu: binutils: Fix file descriptor leak’?
<civodul>well, that's a bug fix, strictly speaking
<civodul>but yeah, that's unfortunate
<roptat>sure, I'm not complaining, but we'll be rebuilding the world
<civodul>right, but a gobject-introspection upgrade may be more disruptive than this binutils patch
<civodul>potentially, but who knows
<roptat>fair enough
<roptat>we really need shorter c-u cycles
<civodul>this time we got faster feedback from ci... but maybe fewer dedicated volunteers initially :-)
<civodul>but i feel we're on the right track now
<roptat>maybe doing it before the holidays was not a good idea :)
<civodul>though actually the branch has been around for a year or so i think
<apteryx>civodul: nealy ready for upstreaming, yes!
<apteryx>raghavgururajan civodul: I have a world rebuilding change to merge soon to core-updates-frozen; so if there are other world rebuilding changes worthy of making it for the next release, we should batch them
<apteryx>this one:
<civodul>oh, lemme take a look
<civodul>apteryx: so patches 1 & 2 have nothing to do with Rust, right?
<apteryx>correct; it's already a batch of unrelated changes for core-updates-frozen :-). The first two are the most critical to fix; the other are nice to have that we may as well commit if we're rebuilding the world.
<apteryx>as it'll make rebuilding it faster ;-)
<raghavgururajan>civodul: I see.
<raghavgururajan>apteryx: Ah, okay. I was thinking of this
<apteryx>I'd be in favor of batching such changes if they provide benefits; if they're just a regular version bump with no gain other than a more recent version, perhaps it's not worth the added risk at this point
<raghavgururajan>I don't think gobject update will be disruptive, as the the ABI version remains the same. Also, I rebuilt with the world with that update on wip-gnome. And now in core-updates, so far good.
<raghavgururajan>Ah okay.
<apteryx>raghavgururajan: OK! If you're confident it doesn't break anything, I'd say let's do it!
<ennoausberlin>Hi. I created a vm with guix system vm config.scm and it was build perfectly fine and store and the run-script was printed out.
<apteryx>two more things I'd like to look into if I get the time: test if moving to inkscape 1.0 is doable (which gets rid of the Python 2) -- last time I thought it didn't work on non-x86 platforms, but I was testing with QEMU
<ennoausberlin>If I create multiple vms how can I remove them from store if I don't need a certain one anymore
<maximed>ennoausberlin: "guix gc"
<raghavgururajan>apteryx: Okay. :)
<apteryx>the last thing would have been fixing Mesa to resolve, but that's probably too involved and will have to wait for the next core-updates merge cycle
*apteryx returns to work
<abrenon>should a copyright line be included even in a patch that just corrects the URL of a home-page ?
<ennoausberlin>maximed: That was easy.
<apteryx>abrenon: no
<apteryx>I think the rule of thumb is 10 modified or new lines (removed text is not copyrightable)
<abrenon>that makes sense : )
<mbakke>civodul: thanks for the feedback in :) I'm not sure what to write in the documentation, WDYT about something like this?
<mbakke>I removed the "short commit strings are discouraged" as the API reference may not be the best place (perhaps more suitable under packaging guidelines)
*mbakke brb
<raghavgururajan>apteryx: So the plan is to merge the gobject update when you also merge your changes?
<civodul>mbakke: what you propose here LGTM!
<civodul>it's just to make it clear that such strings are accepted, otherwise people are unlikely to try
<civodul>raghavgururajan, apteryx: i'm reluctant to applying the gobject-introspection upgrade; it's potentially disruptive and i'd rather avoid that at this stage
<apteryx>raghavgururajan: yes! I just sent an email to guix-devel suggesting that world-rebuilding changes be batched by marking them as blocking
<civodul>raghavgururajan: BTW, contains changes to patch headers that would be best avoided
<apteryx>civodul: ah, our replies crossed
<civodul>yup :-)
<raghavgururajan>civodul: Cool1 No worries.
<raghavgururajan>Ah okay. I guess I should use diff instead of format-patch.
<apteryx>civodul: what is the issue with patch headers? if raghav is the original other of said patches, that's OK to have it identified as such, no? (if they're not the original author, I agree, that'd be misleading).
<apteryx>original author*
<raghavgururajan>I reused the commit message in the patch files. I think it was originally formatted by git diff instead of format-patch.
<raghavgururajan>I'll fix it in few minutes.
<ennoausberlin>Any idea why one of the last steps the build of info-dir.drv fails if I try to build a guix vm?
*muradm still compiling core-updates-frozen...
<dhruvin>I think (current-guix) package is broken. As maximed mentioned earlier, source doesn't seem to have the tests directory. Hence the 'disable-failing-tests' phase, which tries to modify 'tests/syscalls.scm.XXXXXX', fails. Should I create an issue?
<maximed>dhruvin: Seems reasonable.
<maximed>FWIW, I think 'current-guix' is only ‘meant‘ for the system tests and gnu/ci.scm
<maximed>Though it would be nice to make it work in more environments
<dhruvin>maximed: Oh, I didn't know about it. In your opinion what would be the best way to package latest guix in a system image?
<maximed>dhruvin: Maybe use the 'channels' code?
<maximed>Not sure about the details
<maximed>See (guix scripts time-machine), in particular 'cached-channel-instance'
<dhruvin>maximed: I could boot that VM and run guix pull and save the disk image. But that'd be my last resort.
<dhruvin>maximed: Will look into it, thanks.
<civodul>apteryx: i think the patch headers didn't need to be changed because the patches were essentially adjusted to the new line offsets
<civodul>i also find the Git header (with From: etc.) rather useless
<civodul>(and misleading regarding authorship in this case)
<civodul>does anyone have ideas on how to address this TeX error: ?
<civodul>apparently the root cause is "I can't find file `tcbx1000'."
<civodul>but hey, i can't find it either!
<raghavgururajan>civodul: I pushed the fix regarding the headers. :)
<civodul>raghavgururajan: coolio :-)
<civodul>apteryx: i commented on a few things in
<civodul>i can't really comment on the Python and Rust bits, but it looks promising :-)
<raghavgururajan>Btw, will there be a staging --> master merge, before core-updates-frozen --> master merge?
<rndd>hi everyone!
<sneek>Welcome back rndd, you have 1 message!
<sneek>rndd, dstolfa says: as someone who's modified anaconda and has complex setups based on anaconda, i think that is a terrible idea. simple way to crash anaconda: have 2 disks with MDRAID metadata and watch anaconda drop you into the python debugger.
<iskarian>morning guix :) looks like more world rebuilds, heh
<rndd> dstolfa: ohhhh, okay. but i mostly think about laptops.
<rndd>btw, can i ask here about embedding guile in C?
<roptat>rndd, maybe that's better suited for #guile ?
<roptat>but you can always ask (not that I would be able to answer...) don't ask to ask :)
<rndd>i'm trying to find on ubuntu
<rndd>tried pkg-config --libs guile-3.0
<rndd>but it returns No package 'guile-3.0' found
<rndd>package guile-3.0-dev is installed
<iskarian><apteryx> I think the rule of thumb is 10 modified or new lines
<iskarian>Huh, I hadn't heard of this before
<rndd>i found solution
<rndd>all i needed is to run guile-config compile
<rndd>guile-config link
***soheil_ is now known as soheil
<apteryx>civodul: thank you!
<apteryx>civodul: what I do in those cases (missing TeX file), is use the tlmgr utility (which is fixed on core-updates)
<apteryx>you can do tlmgr info or search IIRC, for any resource file
<apteryx>it's a bit like 'apt-file search', if you know that tool
<rekado>civodul: that’s a font file that should be provided by the “ec” package.
<rekado>what I do is primitive: I open texlive.tlpdb and search the file name, then search upward for “^name” to see the package name.
<mbakke>I think many TeX Live packages fail to declare their propagated-inputs.
<iskarian>Does anyone know off the top of their head if our GCC still looks in /lib and so on in addition to LIBRARY_PATH?
<rekado>mbakke: do you have examples? All the new ones should be fine.
<rekado>(according to texlive.tlpdb, which doesn’t necessarily mean it’s correct)
<civodul>rekado: it seems to be texlive-jknappen on core-updates-frozen (works for me)
<civodul>however! i'm now stuck with "dvips: ! Couldn't find header file:", even though i added texlive-latex-l3backend
<civodul>and said file is in there
<civodul>perhaps an environment variable missing or some such?
<civodul>(and it still solves problems "well enough")
<civodul>ah sorry, ECHAN
<civodul>muradm: i've just pushed fixes for the older glibc versions (on core-updates-frozen)
<jonsger>how good is the shape of core-updates-frozen already?
<civodul>jonsger: hey! it was quite good (80% substitutes on x86_64), but it's currently rebuilding the world :-)
<civodul>still, it's great if you can give it a try, see which of your favorite packages fail to build, etc.
*jonsger gives it a try, needs sway 1.6
<jonsger>1.038 objects where downloaded :)
***ds815 is now known as dstolfa
<podiki[m]>i'm anxious to try too, maybe this week is the week....
<drakonis>when's guix 1.4.0?
<roptat>maybe don't try it today, it's rebuilding the world (including the rust bootstrap chain...)
<ArneBab>vats: to calculate java home for an arbitrary java, see
<ArneBab>vats: that article has all the ugliness I have to do to get stuff working that I need for work.
<vats>ArneBab: Thank you. I was struggling with compiling it. I wonder if it's too much work to package it.
<voroskoi[m]>is it possible to have multiple source or origin for a package?
<lilyp>voroskoi[m]: you have to trick around a bit with either computed origins or adding origins as inputs
<voroskoi[m]>can you point me some docs or an example somewhere?