IRC channel logs

2018-07-27.log

back to list of logs

<civodul>mbakke: i'm done with the master -> core-updates merge and a few more things
<mbakke>civodul: Nice work. And thanks for catching that tar bug... :/
<AndroUser>hello,how install guixbd
<mange>Hey AndroUser! You can find some instructions on how to install GuixSD in our manual: https://www.gnu.org/software/guix/manual/en/html_node/System-Installation.html
<mange>If you have any issues with it, ask here and we can help you.
<AndroUser>thankyou
<g_bor[m]>hello!
<g_bor[m]>git.sv.gnu.org does not resolve for me.
<g_bor[m]>Anyone else seeing this?
<janneke>g_bor[m]: works for me
<g_bor[m]>ok, thanks. now it's also fine for me. ISTM there was some local thing.
<AndroUser>@mange ^.^
***AndroUser is now known as gogogo
<civodul>Hello Guix!
<brendyn>hi
<efraim>Hi!
<g_bor[m]>hello!
<g_bor[m]>I'm having a look at a possibility of a maven build system.
<g_bor[m]>ISTM it would be useful to have the pom.xml-s included in our jar files, if it exists in the source, as we could avoid specifiying maven coordinates in our package definitions, if those really match to the coordinates of the source we use. As far as I can see we still need a way to add the maven coordinates, as we sometime use different version than the dependency listed, to avoid version bloat. WDYT?
<civodul>hey g_bor[m]!
<civodul>ACTION doesn't know anything about Maven
<g_bor>civodul: It goes like this: there's a file to list the dependencies, each dep has a name and version. These names and versions are specified in the build tree. If we have a package that needs a dependency, then if we have exactly that version, and have this information embedded into the artifact, then we don't need to specify these. However, currently it seems that we have to fake version information to avoid
<g_bor>version bloat.
<g_bor>so, if we embed the information in the artifacts we can avoid specifying it in our packages.
<demotri>Hi
<demotri>g_bor: I saw your maven comments in the IRC logs. What do you mean by "maven coordinates"?
<g_bor[m]>maven coordinates are groupId, artifactId and version.
<g_bor[m]>demotri: hi!
<demotri>g_bor[m]: OK. I see. First, I think: Yes, we should add the pom.xml into jar:META-INF/pom.xml folder. Further, we should place the pom.xml along with the jar (like it is the case in ~/.m2/repository).
<demotri>g_bor[m]: Maybe it would be even good to place the jar+xml in the store like we have in mvn repo: /gnu/store/...-package/org/my-company/my-project/1.2.3/my-project-1.2.3.jar
<demotri>g_bor[m]: Adding the pom.xml into the jar is something that mvn already does (when we finally build with maven).
<demotri>g_bor[m]: Why do you think we need the mvn coordinates (groupid:artifactid:version) in the package definition?
<demotri>g_bor[m]: Would it be an idea to name the packages like the coordinates? maven-org.my-company:my-cool-project
<rekado_>I’d prefer to specify this as a property in the package definition.
<rekado_>jars can be built with ther build systems, so I wouldn’t like to name them after the conventions of just one build system.
<g_bor>I intend to use the maven-install plugin to create a local repository. It can infer the maven coordinates, if the pom.xml is in the jar file. In that case we don't need to add these to the package definitions.
<g_bor>I think this will work most of the time.
<rekado_>okay. We would need to change the ant-build-system to make it embed the pom.xml if it exists.
<g_bor>rekado_: ok, agreed
<rekado_>and we may need to change a bunch of packages, so that the jars they produce match the names used in the pom.xml files.
<g_bor>This will trigger a full rebuild, so I think this should go to staging.
<rekado_>this may be necessary in the case of packages that use the generated build.xml, so we may need to do this in the build.xml generator.
<g_bor>Ok, I will have a look at that later.
<demotri>Sorry, AFK.
<demotri>rekado_: You might be right. We shouldn't make the package-name dependent on the build-system.
<demotri>It would be cool if we can reuse most of our ant-generated packages, but I have the slight feeling that we get into troubles with that.
<rekado_>we have a lot of ant-build-system packages that would have been built with maven had it been available.
<g_bor[m]>rekado_: I have a question, what do use java-ecj for? It seems to be seriously outdated, and seem to have no dependents.
<rekado_>I’d like those to be usable by packages that use the new maven-build-system
<rekado_>java-ecj is part of the bootstrap
<demotri>What about multi-module projects (i.e. parent-pom + sub-directories): Is that "one" big package? Or n+1?
<demotri>What about pom.xml-only? I.e. you define only the parent and reference it later in different projects?
<g_bor[m]>ok, the it is safe to stick with jdk7 there.
<rekado_>g_bor[m]: yes.
<rekado_>maybe we should break out the bootstrap into a separate module.
<g_bor[m]>rekado_:Yes, it would be nice to have bootstrap in a separate module. Can you have a look at that later?
<rekado_>much later, yes :)
<g_bor[m]>:) ok, I will try to do that then.
<g_bor>rekado_: Do you have any idea regarding this pigx-ranseq test suite failure?
<demotri>guix environment /gnu/store/... does not work. Right? guix environment package --with-source=package.1.2.3.tar.gz does also not work. Any way to get into a "with-source" environment?
<rekado_>g_bor: how can I reproduce the error?
<pkill9>how do you add a module to the kernel source so it gets built?
<pkill9>is the simplest way to just put the source of the module into one of the existing directories?
<pkill9>subdirectories* (with the modules in them
<pkill9>)
<efraim>rekado_, civodul: I think the overdrive overheated and shut off, just turned it back on
<ecbrown>wondering if anyone else is seeing: Service user-homes could not be started, also for term-auto and avahi-daemon
<efraim>python-qscintilla failed on hydra on x86_64, i'm assuming a race condition with the substitution
<rekado_>efraim: oh :(
<rekado_>sneek: later tell pkill9 You don’t need to add a module to the kernel source. It can be a separate package. You just need to add it to the list of kernel modules in the operating-system configuration.
<sneek>Got it.
<rekado_>sneek: botsnack
<sneek>:)
<civodul>efraim: ok, thanks!
<civodul>kind of a bummer that it doesn't keep up
<efraim>unfortunately I think it's the heat
<civodul>yeah and imagine it's rather warm in your town :-)
<civodul>*i imagine
<jlicht>my SoC's are overheating about once a day atm. We even had the warmest night _ever_ recorded last night!
<civodul>woow
<civodul>here we had 35°C yesterday
<jlicht>with expectations of breaking that record the upcoming night again already
<civodul>my a20-olinuxino is super stable, heat or not
<civodul>it's also mostly idle, which certainly helps ;-)
<efraim>I have an old laptop that was decent for a year and then would overheat repeatedly, summer or winter
<civodul>bah
<civodul>sometimes it's accumulated dust inside the case
<rekado_>civodul: can we abandoned the ("label" ,actual-package) syntax for most packages? What do you think about making the label optional?
<rekado_>even if we switched to gexps we’d still need to declare a list of packages, so I thought that maybe we could get rid of the labels even without switching everything to gexps.
***snape` is now known as snape
<civodul>rekado_: yes, mostly
<civodul>i am kind of willing to do the grand switch to gexps in core-updates, BTW
<civodul>there's a difficulty though, which is dependency graph rewriting
<civodul>if we start using #$foo instead of (assoc-ref inputs "foo"), then graph rewriting becomes trickier
<civodul>we don't have to abandon (assoc-ref inputs "foo") though, but then we'd introduce labels "unhygienically", which is not great either
<civodul>so it needs a bit of thought
<civodul>not sure if i'm being clear :-)
<rekado_>yes, I understand.
<civodul>janneke: what's a good way to test wip-bootstrap?
<civodul>everything takes place in mes.scm, but not (yet) in commencement.scm, right?
<jlicht>Are there folks with an IMAP-IDLE based solution for mail synchronisation? All I can find are old broken packages and node-js scripts
<cehteh>sync to what?
<cehteh>dovecot does imap idle just fine
<cehteh>android k9mail as well. problem are desktop/pc clients :/
<jlicht>cehteh: in my case, a google suite account (basically gmail), a university account, a posteo account
<jlicht>I am currently using mbsync/isync, which works like a dream, but it does not support the IDLE thing, so I have to poll every N minutes to sync my mailbox
<cehteh>mhm cant you configure forwards on 2 of those to your favorite mail server
<cehteh>dunno about imap-idle bases sync things
<jlicht>I could configure all the mail servers, but was hoping for a client-side solution for now :-)
<cehteh>sorry i dont know .. maybe check the imapfilter (this lua thingy), i know that it exists and wanted to take a closer look, but not done so
<cehteh>short look at the docs: it supports idle
<cehteh>may already do the trick :)
<jlicht>thanks cehteh! I do not really know lua, but this seems like it would help me
<cehteh>lua is somewhat simple, when you have problems you can ask me or join #lua
<rekado_>g_bor: the pigx-rnaseq test failure is likely because STAR eats too much memory. I’ll disable that test.
<janneke>civodul: yes, best way to test is: edit gnu/packages/mes.scm and set ==> (define %fake-bootstrap? #t)
<janneke>civodul: then: ./pre-inst-env guix build mes-boot
<janneke>when that works, try: ./pre-inst-env guix build gcc-mesboot (that builds everything)
<janneke>then, try again with out fake-bootstrap? #t cheating -- that takes ~2h to build tcc-boot0
<pkill9>is anyone else getting certificate problem at https://gnunet.org/bot/log/guix/ ?
<sneek>Welcome back pkill9, you have 1 message.
<sneek>pkill9, rekado_ says: You don’t need to add a module to the kernel source. It can be a separate package. You just need to add it to the list of kernel modules in the operating-system configuration.
<civodul>janneke: i see, thanks
<civodul>janneke: though even with %fake-bootstrap? #f, we're sitting on top of (standard-packages), aren't we?
<pkill9>rekado_: where do you add it? I see there's 'initrd-modules and 'firmware', is it one of those?
<janneke>civodul: yes, that's right
<janneke>civodul: the fake currently means: run MesCC on Guile
<janneke>we will sharpen that definition as we go
<civodul>ok, so currently we cannot try the full bootstrap
<civodul>AIUI the next step could be to move bits from mes.scm to commencement.scm, does that make sense?
<janneke>civodul: right, the best that we now have is building gcc-4.7.4 without prior gcc-toolchain (but with bootstrap-guile, and corutils and some other bootstrap-binary cheats)
<janneke>so the next step would be trying to try reemove gcc-4.7.4, binutils and glibc from the bootstrap binaries and replace them with the "bootstrap" from mes.scm
<civodul>ok
<janneke>...but here i'm intentionall speaking vaguely...i lack familiarity with the real commencement bootstrap
<jlicht>cehteh: imapfilter is simply perfect!
<jlicht>thank you so much
<jlicht>and lua seems really fun to get into.
<jlicht>Can a description for a package be taken from the package itself, or should care be taken to come up with a original formulation?
<jlicht>*an
<brendyn>jlicht: I don't think there is any reason to be ashamed about copying sentences, as long as they're actually good.
<kballou>Is there somewhere to get more information on the `manifest` object? Specification or Reference documentation? https://www.gnu.org/software/guix/manual/en/html_node/Invoking-guix-package.html#profile_002dmanifest <- this manual page seems to be lacking more than package list examples... I'm also looking at `guix/profiles.scm`...
<pkill9>hi
<pkill9>how do i add grub command line options?
<pkill9>if there is a way
<roptat>pkill9: there's a "linux-arguments" entry in the menu-entry type
<pkill9>ok
<roptat>see http://guix.info/manual/en/Bootloader-Configuration.html#Bootloader-Configuration
<pkill9>nice, i was wanting to add grub menu-entries a while back, didn't think you could
<roptat>the only issue I have is that it doesn't allow chainloading (yet)
<pkill9>rekado_: is there an example of how i can add a kernel module ?
<pkill9>ACTION is desperate to load a kernel module
<pkill9>roptat: are the grub boot paramters the same as linux-arguments?
<pkill9>it seems it is
<roptat>we don't have a source bootstrap for haskell, do weQ
<OriansJ>roptat: no but I believe that there was work on getting a Haskell Compiler in Lisp working, There hasn't been an update on that in a while so I am not sure where that stands right now.
<OriansJ>But the good news is the Source bootstrap for C is making good progress thanks to janneke's wonderful work.
<jlicht>rust is also still an issue I think
<rain1>there is mrustc written in C++
<thomassgn>wigust: for some reason, the printing works today. I have rebooted once between. Now I just have to figure out why the printer with ink prints blank pages. Was watching the logs but they don't give me anything on the color issue... :P Thanks for the help
<g_bor[m]>Hello guix!
<g_bor[m]>clojure fails on master, on phase 'create-jar-indices with "is a directory". Is it safe to delete this phase, or should I adjust it?
<g_bor[m]>roptat: unfortunately not yet. rekado tried it several way, no success yet. I asked if it would be acceptable to finish the bootstrap path like build a 32 bit ghc and cross-compile a 64 bit one from that, but he said he would like to get rid of nhc, and compile a patched a patched ghc instead.
<OriansJ>jlicht: our issue with Rust is when they introduce new features, they have a bad habit of requiring them to build the new version with them. But as a developing community, we hope they will mature out of that soon.
<sneek>So noted.
<nixd>How would one go about creating a new package? I keep reading that the package definition has to be "in place"/in the guix source tree. Say, you have a package definition in a thepackage.scm file somewhere in ~/, and I want to try if it works. How would one proceed?
<pkill9>nixd: you can specify additional directories of package definitions by adding them on the ocmmand-line with -L, or adding them to the GUIX_PACKAGE_PATH environment variable
<nixd>pkill9 Is it normal that there is no GUIX_PACKAGE_PATH env variable by default?
<nixd>I don't see one when running printenv anyways.
<nixd>When I try guix build -L /the/path -K --verbosity=5 I merely get "building (newline) | entered goal loop". Without the verbosity flag I don't get any return value. What am I doing wrong?
<pkill9>nixd: yes it's normal
<pkill9>it adds the directories in that environment ariable to the default directory
<pkill9>variable*
<pkill9>i have it set in my ~/.profile so everytime i run the guix command, it will include my personal 'repository'
<nixd>pkill9 Thanks. I've now also tried guix build with -L and the directory, but I don't get any output from guix build at all. With verbosity=5 I just get "building" and "entered goal loop". Not sure whats wrong
<pkill9>nixd: can you post your package definition into a pastebin?
<nixd>pkill9 I will do that tomorrow. Ill see if I can find time to post it when you're here aswell. Thanks for now!
<aminb>hi all, anyone know why guixsd still doesn't support lvm?
<aminb>(asking for a lvm on luks setup)
<g_bor[m]>aminb: it seems there was actually nobody really interested in implementing it. Last time I investigated this I noticed that lvm very badly maps to the current mapped device concept. Furthermore there seems to be a problem regarding including stuff in initrd, if I am correct now we generate an initrd with 'everything needed'. luks in itself can be used however.
<kballou>aminb: static compilation for lvm seems to have been problematic so far... I wanted to look into this because I'm also interested in getting LVM support, but I'm still trying to get my feet wet :/
<kballou>g_bor[m]: would `uuid` mapping work for lvm partitions if static compilation was working?
<g_bor[m]>I am also interested, and I have seen some work regarding the static compilation on the mailing list.
<g_bor[m]>Actually I would like to use the classic vgchange -a y as a mapped device activation, but a volume group is a bad mapped deviceish thing, as it not really a source, nor a target.
<g_bor[m]>Yes, uuid mapping would work.
<pkill9>i like the new `guix pull` message that says which packages have been updated
<ng0>last time we had something close to working lvm was in 2016 by jookia
<ng0>but that predated mapped-devices iirc
<ng0>or at least file systems changed a lot since 2016 here
<ng0>I think if you really want to do this, there's a whole community here for help, lvm is even on our 1.0 roadmap iirc
<ng0>best kitchen view. I can see the moon and the mars today :)
<g_bor[m]>ng0: Good for you, here it is 8/8.
<ng0>8 8?
<ng0>what does that mean?
<ng0>cloudy?
<jlicht>ng0: any chance you can see the lunar eclipse tonight?
<ng0>I've seen it here, still going on.. total eclipse is over though
<ng0>I miss being able to see a large part of the milky way in summer... where I grew up this was possible, but here's too much lights of the cities.
<pkill9>rekado_: where do you specify where to add compiled kernel modules?
<pkill9>i worded that weirdly
<pkill9>where in the system configuration do you specify which compiled kernel modules to add to the kernel*