<vagrantc>happy to finally see: da551107129d22dfb2a4278a55b702a7340e7f51 scripts: pull: Add options for generation management <civodul>vagrantc: i don't think you need --with-guile-site-dir <civodul>modules should end up in share/guile/site/2.2 by default <civodul>oh i see that Andreas said issues were not fixed <vagrantc>and they're not well documented either ... but basically some old test suite failures on guile 1.8 and/or 2.0 ... and the code that the failures were testing is no longer present <vagrantc>test suite failures and/or infinite stalls <civodul>oh and marked as "wontfix" without further ado <civodul>yeah i'm pretty sure the issues Andreas encountered back then are long gone <civodul>upstream has been building with Guile 2.0 (and now 2.2) on Gitlab-CI for a while <civodul>well i'm upstream for the Guile bits, but CI was set up by Nikos, ueno et al. <gnu_srs>Building the bootstrap tarballs fails here: guix/build/utils.scm:616:6: In procedure invoke: <gnu_srs>Throw to key `srfi-34' with args `(#<condition &invoke-error [program: "/gnu/store/a4rxl40jr7gmq8bp3dryq4yq67cwkwiw-patch-2.7.6/bin/patch" arguments: ("--force" "--no-backup-if-mismatch" "-p1" "--input" "/gnu/store/72pkmaq5bk70r42zdn8dzlcsg54akp72-guile-2.2-default-utf8.patch") exit-status: 1 term-signal: #f stop-signal: #f] 56dcc0>)'. <gnu_srs>I've changed gnu/packages/make-bootstrap.scm to build for guile-2.0, not guile-2.2? <gnu_srs>more info: builder for `/gnu/store/m1xyiqifwy43amqylkkicwppc7pvzrs0-guile-2.0.14.tar.xz.drv' failed with exit code 1 <gnu_srs>build of /gnu/store/m1xyiqifwy43amqylkkicwppc7pvzrs0-guile-2.0.14.tar.xz.drv failed <vagrantc>gnu_srs: did you have to change the gnutls patch at all? <vagrantc>oh, my old patch accidentally didn't update one of the lines to guile 2.2 <vagrantc>gnu_srs: oh, no, mine did 2.2 consistantly ... you re-introduced something in your patch <vagrantc>is there a way to use a git origin but treat one of the git subdirs as the top-level directory? <nckx>Hullo Minall. vagrantc: You mean something other than ‘add a chdir phase after 'unpack’? (Probably.) <nckx>For once, you can use statefulness to your advantage 🙂 <nckx>Yup. It's not uncommon. Thought maybe you meant ‘when applying patches that expect to be applied in a subdirectory’, since I'm not sure if snippets are run before patching and whether the CWD is also ‘carried over’ in that case. <vagrantc>basically have a project that ships a subdir with a javascript component and a python component, and i only want the python component, and it's simple enough to just treat that directory as upstream <vagrantc>then python-build-system works with a simple setup.py <nckx>Right. chdir's totally acceptable in such cases. <vagrantc>the other option was treating Debian's package as upstream, as they basically do that... <tune>I am trying to run offlineimap and I got this error " ERROR: No CA certificates and no server fingerprints configured. You must configure at least something, otherwise having SSL helps nothing." <tune>I have had ssl issuess with various things in the past that I could never really figure out, so I thought maybe this is a system-wide issue <vagrantc>there's a section about certs in the manual; you may need to explicitly export some environment variables <tune>I have tried that in the past and it makes everything worse <tune>I have certs installed in the system profile and I think that's for user stuff <vagrantc>you'd then need to export those variables with appropriate paths for the system configuration, would be my guess <vagrantc>unless offlineimap hard-codes some path to certs that doesn't exist... <tune>although now it appears to be hanging while connecting <tune>it hasn't asked for a password yet but it almost seems like it's trying to sync already <Parra>One question guys, if I need libpython3.5.so for compiling my application, how can I include this as a dependency in a package and later on passing it to CMake? <Parra>have I to include the whole python package? <nckx>CMake should find it automatically then. <Parra>thank you, can I remove python interpeter binaries later on? <nckx>Parra: No. Packages are atoms, your package either depends on another package or it doesn't. <Parra>and python as a standalone library isn't distributed, right? <nckx>I think that's a universal concept even across different operating systems. <nckx>One could split the python library into (say) a :lib output, but that hasn't been done and might or might not make much sense 🙂 <Parra>but by now I will use python package <Parra>i.e recompiling python and using only the lib folder <Parra>for me makes sense because I'm buidling a Polyglot <Parra>I'm not interested in the interpeter itself, only the libs <Parra>it's a library focused on embedding languages in other languages <nckx>Sure. I guess that could make sense if size is really important to you. It may or may not make sense to do upstream (in Guix itself), though. <nckx>Parra: Just out of curiousity, what's ‘building a Polyglot’? <Parra>can I share the link here? it's opensource <Parra>basically it allows you to do FFI between languages <Parra>you can call Python functions from NodeJS, or any other language <nckx>Ooh, FFI on steroids. Gotcha. <Parra>I'm using it to build a FaaS but the idea is to distribute it in npm, pip, gem.. and for this, I need to compile metacall with multiple runtimes at same time <Parra>metacall later on loads them as a plug-in <Parra>but the project seems too complex for people not used to code C/C++ and use CMake <Parra>so that's why I decided to use Guix to distribute it and reducing complexity <nckx>Interesting. I wonder how that will work out, you might exercise some interesting corners of Guix this way. Good luck! <Parra>thanks dude, I will keep you informed <nckx>(Feel free to ask for any help you may need here or on the mailing list.) <vagrantc>both inputs and native-inputs are available in during tests? ***Digitteknohippie is now known as Digit
***runejuhl1 is now known as runejuhl
<efraim>sneek: later tell vagrantc both inputs and native-inputs (and propagated-inputs) are available during tests <gnu_srs>In the build of bootstrap-tarballs /usr/var/log/guix/drvs/m1/...-guile-2.0.14.tar.xz.drv.gz tells me that one patch failed: applying '/gnu/store/...guile-2.2-default-utf8.patch'. <gnu_srs>Maybe I should adopt it for guile-2.0 or remove it. Is it really needed? <efraim>gnu_srs: I would suggest adapting it for guile-2.0. It's either still in the repo or it was changed from -2.0 to -2.2 <efraim>do we have a python-effective-version macro? <efraim>nothing super official, just lots of versions of (version-major+minor (package-version (assoc-ref inputs "python"))) <civodul>efraim: on core-updates, i did something, IIRC <civodul>yeah there's a 'python-version' procedure <civodul>see 9c2563a80b6f1d8fb8677f5314e6180ea9916aa5 <efraim>i wonder if it works on python2 inherited packages. I'm fixing python2-matplotlib atm <civodul>it's a build-side procedure, so yes, it should work <civodul>oh my system runs on core-updates today <efraim>home office is too hot, I've finally gotten my G4 out and I'm ssh-ed in to all the machines from my dining room table <efraim>still a shock every time I try to run 'guix package -A ' and I get 'command not found' <civodul`>uh laptop just crashed, maybe i spoke too fast <efraim>running gnome or something else? ***civodul` is now known as civodul
*rekado reconfigures on core-updates <efraim>i might disable the tests on python2-matplotlib, looking through ci.guix.gnu.org it looks like it started failing when python-matplotlib was updated to 3.1.1 and the test command was fixed to actually run <efraim>so it wasn't actually running the tests before <rekado>python2-matplotlib is also remaining on version 2.x. <rekado>because upstream dropped python 2 support. <rekado>I hope we can get rid of abandoned software like that soon. <refpga>Hello, I set up postgresql as per the setup in database services documentation: (postgresql-service #:extension-packages (list postgis)). Now when I reconfigure my system to the config.scm file, it shows me an error: initdb: directory "/var/lib/postgresql/data" exists but is not empty. <civodul>refpga: looking at the code, it seems harmless <civodul>namely, "initdb" is always invoked, even if /var/lib/postgresql/data already exists <civodul>but its exit code is not actually checked <civodul>that said, it would be better to not invoke initdb when DATA-DIRECTORY already exists <civodul>refpga: could you report it to bug-guix@gnu.org? <roptat>I think I managed to do what I wanted with fold-home :) <roptat>I was able to reconfigure with this <roptat>it's very close to the service architecture, so maybe we could simply change the way services work, and use services for home configuration too <roptat>sure, as soon as I update documentation :) <roptat>and actually, I think this is what we need for the TODO item in the roadmap "unprivileged user services, managed declaratively by the user" <roptat>by the way, we have two items in Infrastructure that are done but still marked as TODO: "web site officially available at https://guix.gnu.org" and "Guix Data Service deployed" <civodul>yeah, do you want to mark them as DONE? <civodul>roptat: indeed ssh-home-type looks very much like ssh-service-type :-) <refpga>civodul:Should I create a user postgres using config.scm? Because I cannot switch to that user to create a new database either. <civodul>roptat: i guess we should see what needs to be different between system services and user services, and what can be factorized <roptat>civodul, sure, I'll talk about it in my update <civodul>refpga: not sure, i'm not familiar with this <civodul>but maybe you can ask on help-guix@gnu.org? <truby>rekado: I'm having a look at the include paths for clang++. clang tries to look for libc++'s headers in ${path/to/clang}/../include/c++; it won't find them here in this case because the path it looks in is after it has resolved symlinks, and the clang store path doesn't match the libcxx store path. In the case of libstdc++ it looks for them in ${path/to/crt1.o}/../include/c++, so I'm not sure why it isn't finding them in that <roelj>What's the best way to add "guix" as a dependency to another package, for a version of guix that was installed with "guix pull"? <rekado>perl-glib failed on core-updates <truby>ah, I think it doesn't find the libstdc++ headers because LibDir is being changed to the path to glibc in its own store, which doesn't contain the C++ headers. (and clang looks in LibDir + "/include/c++"). So that makes sense too. Seems like these issues might both be fixed by having a clang-toolchain similar to gcc-toolchain? <rekado>android-libutils fails to build on core-updates, so fastboot cannot be built. <efraim>not guix related, but I managed to get syncthing to run on my G4 using qemu and binfmt and and arm binary <refpga>Damn, I did a guix pull and reconfigure and it's stuck on compiling linux kernel now... <efraim>what are some big endian systems besides ppc and ppc64? <civodul>refpga: which derivation? (the /gnu/store/....drv file name) <civodul>efraim: big endian CPUs are an endangered species <efraim>I thought 'el' was for little endian <g_bor>This might better belong to guile, but I will ask it here anyways. *civodul sees: sha256 hash mismatch for /gnu/store/y0r8djhx0vx1aii1g63hz6bmnx9nyvyd-fontforge-scripting-array-reference.patch <g_bor>I am working on a netlink wrapper. <refpga>civodul: It's /gnu/store/2a1rvqgnciajzsvl2x8rd8qn6skkwwkf-profile.drv I think. <g_bor>What would be the best way to get a select not block the whole program? Should I start a thread for that? <civodul>you should synchronize with roptat, who was considering submitting it as an Outreachy subject, i think <civodul>you can pass 'select' the timeout duration you want <g_bor>I already have some stuff, and made some research <efraim>qemu-mips on debian sid on powerpc gave a stack trace on syncthing, looks like I get to file a bug <roptat>g_bor, although I don't really have time to write a proposal, maybe this week-end, but I'm moving, writing my thesis... it's all happening at the same time ^^' <g_bor>the only thing is that a recvfrom! blocks all thread, so we need a select somewhere <roptat>g_bor, I can commit to be a mentor or co-mentor on this task though <g_bor>roptat: ok, I will try to come up with something, if you don't mind. I am willing to comentor this. <efraim>ppc64 also failed hard, but I wasn't sure 32-bit -> 64-bit was workable <g_bor>I have almost a fully fledged soultion to get by without systemcall wrappers <roptat>g_bor, netlink uses sockets, no? <g_bor>so only the messages should be written and tested. <g_bor>Yes, this works on netlink sockets. <rekado>refpga: linux-libre has *just* been upgraded <g_bor>What I was a bit unsure about is selecting a recieve buffer size, but I decided to extract the value form the iproute2 source code. <efraim>g_bor: my favorite method "find someone else who figured it out and use their answer" <civodul>rekado: looks like Rutger quietly stepped up to upgrade linux-libre 5.x :-) <g_bor>the problem was, that different people found out different ways to do this, and some had subtle race conditions. The only two things working here are: <rekado>civodul: yes, I was pleasantly surprised by that! <g_bor>stick to the maximum allowed by the protocol, which is 4GB, not very reasonable <efraim>point release bumps might not be so bad, I know I wouldn't have it in me to do larger bumps <g_bor>or use something that works for our usecase currently, and follow up with the implementation limits. Our usecase is replicating iproute2, so what works for the will work for us. <g_bor>They currently use 1MB buffers. <g_bor>yes, the linux-libre update is really nice. <g_bor>I was thinking about it for a while, but I am just not sure if we should have any additional test in place... <g_bor>are you testing these kernel updates locally before pushing, or you have some other method? <roptat>g_bor, can't you instantiate a bare-bones system on a VM to test a new kernel? <g_bor>roptat: I believe I could. I was wondering if we have a process... <g_bor>I tried to ask it on the announcement that new maintainer is needed. <g_bor>I also have a channel where I inherit linux-libre, do some adjustment, and I update it like it was done here. <g_bor>Then I pull on my test environment, and run my test to see if it is all right. <g_bor>If that is ok, I can also do this in upstream guix. <g_bor>It's just that our userbase is much more widespread, and the kernel seems to be a critical part. <roptat>I implemented the extension system I talked about a few days ago :) <roptat>now, I'd like to have some service transformation options, especially for manipulating extension-points <g_bor>I was about to implement a git configuration yesterday, as I felt the need. <roptat>and even better if you could follow the new format <roptat>btw, you could use make-ini-file from (home utils) <g_bor>I was thinking about some setting, core.editor, user.name, user.e-mail, core.hooksPath , maybe the signing settings came to my mind. <roptat>iirc the git configuration is in ini format <g_bor>ok, I will have a look at that <roptat>it's just a way to create a file-like object you can pass to the extension of root-home-type <g_bor>roptat: almost there. Nice. Only thing missing here is the possibility to add a subsection specifier. I will try to come up with a patch. <g_bor>Also, i don't want to implement all the options, but would like to leave an escape hatch to add text to a section. Wdyt? <civodul>the fontforge change i just pushed introduces lots of rebuilds, but i think it could hardly be avoided <g_bor>roptat: I will try to come up with a netlink proposal. As the deadline is quite near, I will focus on that. <roptat>I'll probably have some time to read what you will have written this week-end <g_bor>My question is, if the proposal should include the static-networking-service frontend? <civodul>i think it could, with the understanding that it'd be a 2nd phase of the project <civodul>and also probably less tricky that the actual netlink bindings <g_bor>Ok. We should then find out what we would like the static-networking service look like. I would suggest to split it up, like the netlink interface is, so we don't have routing information intermixed. <roptat>g_bor, I pushed my changes to master, so you can work on top of it <rekado>another project for Outreachy (we could submit more than one proposal) is to make the installer more accessible, e.g. to add support for screen readers etc. <g_bor>rekado: do you have a mentor for that project in mind? <roptat>g_bor, if we manage to get the netlink bindings working, then the next step is indeed to implement the static-networking service with it <roptat>maybe a first step would keep the current interface, and then expand it? <rekado>g_bor: I have, but I know that sadly it would unrealistic. *rekado thinks roptat made some great points about accessibility in the past <roptat>yes, but I can't commit to mentor two projects at the same time <roptat>although, I could for the next round ***Digitteknohippie is now known as Digit
<g_bor>roptat: that might also work. I believe that maybe we should do it in a way to make static networking depend on an static-ip and a static-route service, to gain some flexibility. But that is not so important right now. <roptat>also, isn't iptables managed with netlink too? <g_bor>One more question: I believe that the netlink binding could be useful outside guix. Should we do it in guix, or as an independent library? <roptat>I'm not sure, an independent library would be nice <roptat>but how would that integrate with guix properly? *rekado marvels at the difference a comma can make <g_bor>roptat: yes, that was my question. As far as I understand we already have dependencies of this kind, but I don't know how those are managed. <g_bor>For example I believe we use guile-json <g_bor>Currently doing this in tree would allow us to get things rolling faster, so I would go for that, with the goal to allow for easy extraction later. <roptat>g_bor, actually, if it's a service, all of the netlink code would be in the service, in the form of a gexp <roptat>so I think we can make it load the guile-netlink implementation from a package definition <g_bor>roptat: I believe something like that is done for other guile dependencies. I can't check that right now. <quiliro>I get: "shepherd: Evaluating user expression (let* ((services (map primitive-load (?))) # ?) ?)." at the end ef every system reconfigure. Is it normal? <g_bor>I will try to come up with a preliminary draft by tomorrow. <quiliro>Thank you, rekado. What does it mean? <rekado>geda-gaf has failing tests on core-updates <rekado>alsa-modular-synth fails to build on core-updates :( *g_bor creating working tree for core-updates to have a look <rekado>alsa-modular-synth can be built with GCC 5, so I’m going to push that workaround. <g_bor>rekado:ok, make check is still running here... <rekado>same problem with gcc-arm-none-eabi-4.9 (builds fine with gcc-5) and avr-gcc (trying with gcc-5 now) <civodul>rekado: it's weird that we have to use GCC 5 for these things <civodul>often it's been the other way around <rekado>I bet we can build alsa-modular-synth with GCC 7 if we pass some extra flags about the C++ standard or something like that. <rekado>after the core-updates merge it would be great if we could patch these packages properly <civodul>yeah, we don't have to block everything forever <rekado>hmm, avr-libc fails, but just adding gcc-5 doesn’t help here. <rekado>fatal error: gnu/stubs-32.h: No such file or directory ***Digitteknohippie is now known as Digit
<civodul>rekado: that's because it uses -m32 or similar, right? <rekado>avr-toolchain can be installed on the master branch <efraim>-m32 and -m64 were easy targets when I was banging away at aarch64 <rekado>a comment says: C_INCLUDE_PATH poses issues for cross-building, leading to failures when building avr-libc on 64-bit systems. Simply unsetting it allows the build to succeed because it doesn't try to use any of the native system's headers. <dongcarl>are we talking about gcc 5 to 7 transition problems? <civodul>rekado: maybe we need to unset more, like CPLUS_INCLUDE_PATH and CPATH <rekado>civodul: yes, that’s what I just did. Seems to work. <dongcarl>at some point I remember reading that GCC 5 doesn't work with CPATH, only with *_INCLUDE_PATH, and GCC 7 is the exact opposite, but might not be related. <rekado>still broken is geda-gaf. Don’t know what to do about that. <rekado>hmm, the build output of ncmpc breaks through the verbosity barrier of “guix package” *rekado will push five commits to core-updates later tonight *rekado build supertuxkart on core-updates <roelj>Did rekado find all easter eggs in supertuxkart yet? ;) <civodul>what, there are easter eggs in supertuxkart? <roelj>Quite literal ones, yes. But I did not want to derail the core updates merge! <Paprika>I was wondering why xfe and xwm are not in the Guix System repositories? <Paprika>they are both free software and are excellent to use on older hardware <lprndn>Paprika: I don't have any special information but I would just suppose because nobody did it? <Paprika>Yeah, I thought so, I was hoping I might encourage someone by posting this here :) <Paprika>(since I have no knowledge on how to do it myself) <lprndn>just by curiosity, what are they used for? <Paprika>and wdm is a lightweight login manager for X <Paprika>Oh thanks for that link, I didn't know it existed! <Paprika>A whole different issue: the "custom.conf" file exists 3 times in 3 different /gnu/store/lot of text/gdm/ folders <Paprika>how do I know which version of gdm my system is using? <Paprika>and editing either of the three is impossible since it's a read-only file system <roptat> Paprika to "edit" the file on the guix system means changing the os declaration and generating a new file <roptat>to see what files your system currently depends on, you can use for instance "guix gc -R /run/current-system" <roptat>that will give you everything in the store that is recursively referenced by anything in /run/current-system <roptat>if you | grep gdm, you should find the one that is currently used <Paprika>thank you roptat, but how do I change a configuration then? <Paprika>all I'm trying to do is enable autologin <roptat>Paprika, it's all in your config.scm <roptat>although I don't know the details of how to change that specific file <Paprika>convenient yet confusing (since I'm still very new to guix) <roptat>the whole point of guix is that it's stateless: to get to a good configuration, you usually start with an os, change a file, try something else, change another file,... mutating the state at every step <roptat>with guix, you build an os once from a declaration of what it should contain, and you always get the same thing <roptat>when you want to "change" something, you change the declaration, and build a completely new os (that happen to share a lot of components with the other os) <roptat>anyway, for what you want to achieve, you'll have to use modify-services, because the gdm-service-type is defined as part as %desktop-services (and that's probably what you are using, right?) <roptat>modify-services takes a list of services (like %desktop-services) and a list of transformations you want to apply and returns a new list of services ***Digitteknohippie is now known as Digit
<vagrantc>efraim: do you recall the arch-specific diffoscope dependencies i added other than ghc? <sneek>Welcome back vagrantc, you have 1 message. <sneek>vagrantc, efraim says: both inputs and native-inputs (and propagated-inputs) are available during tests <Paprika>yes I'm using &desktop-services roptat <roptat>I hope that makes sense to you :) <Paprika>oh thanks for that, I wouldn't have come up with that I think.. It does make sense though <gnu_srs1>(00:57:02) vagrantc: gnu_srs: oh, no, mine did 2.2 consistantly ... you re-introduced something in your patch: <gnu_srs1>I took the package description etc from the latest found version of guile-gnutls 3.4.11-3 <Paprika>roptat, when I try to reconfigure it tells me that ... is an unbound variable <Paprika>I'm sure I should put something there but I'm unsure what <Paprika>I can post my config.scm file if it helps <roptat>Paprika, yeah, I meant ... to be whatever services you already used <Paprika>ah so I should just put %desktop-services there again? <roptat>no, modify-services replaces that <vagrantc>gnu_srs1: + dh_makeshlibs $(BDIR) --remaining-packages -Xguile/2.0/guile-gnutls-v-2.so <vagrantc>gnu_srs1: unless i'm misunderstanding that? <roptat>if you didn't have any service, then that's (services (modify-services <things>)) <roptat>no need for cons* if you only need the modified services <vagrantc>gnu_srs1: a bit rude to remove wontfix without maintainer comment :P <vagrantc>gnu_srs1: also a bit rude for the maintainer not to comment... :) <vagrantc>gnu_srs1: thanks for prodding the bug :) <roptat>need to afk now, but of course others can help you if you need any more help :) <vagrantc>gnu_srs1: guile-git is sitting in NEW, and i seem to recall the guix package itself being mostly ready other than those two <vagrantc>gnu_srs1: though need to build a tarball from git for the bootstrap binaries workaround <civodul>vagrantc: do you think i need to chime in re guile-gnutls in Debian? <vagrantc>civodul: i could only see it helping? :) <vagrantc>with just one person, it's an echo chamber, with two people, it's a back and forth ... with three, a conversation! :) <civodul>vagrantc: heh, alright, let's have a conversation :-) <quiliro>Mi havas problemon ekbruligi gnome-terminal-on. <quiliro># Locale not supported by C library. <quiliro># Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: Error calling StartServiceByName for org.gnome.Terminal: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.gnome.Terminal exited with status 9 <quiliro>(locale "es_ES.utf8") estas en mia config.scm-o <quiliro>I am trying to start gnome-terminal from Xfce terminal <efraim>do you have glibc-locales and not glibc-utf8-locales installed? <vagrantc>packaging python-binwalk, and it optionally uses python-coverage to produce somewhat more verbose test summary ... is it worth adding? builds fine without. <vagrantc>bumps guix size from 190.0MB to 190.8MB ... <nckx>vagrantc: Sounds worth it. <quiliro>efraim: I have neither...Sholudn't that be done by reconfigure? <efraim>quiliro: i'd just run 'guix package -i glibc-locales'. i'm pretty sure esperanto isn't in glibc-utf8-locales <nckx>Indeed, eo needs special fiddling, but es_ES shouldn't… <nckx>I think I suggested switching from es_EC to es_ES (‘temporarily’) for exactly that reason. <rekado>gnumeric fails to build on core-updates <rekado> /gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/bash: line 3: 23026 Segmentation fault itstool -m "${mo}" ${d}/C/gnumeric.xml <rekado>I don’t think there’s an easy way around this. *nckx .oO …diffoscope is the new libreoffice… <vagrantc>well, it certainly handles more file formats. <vagrantc>i've got ~3 more package definitions to get the diffoscope test suite down to about only ~50 skipped tests <nckx>I certainly use it more often. <rekado>upgraded my packages on core-updates with this command: ./pre-inst-env guix package -u . --do-not-upgrade geda-gaf --do-not-upgrade diffoscope *rekado pushes fixes to core-updates <bluekeys>Hi guix. Do you know why I might be finding some packages from the command line with a guix package -s, but don't find when I'm using the emacs mode? <civodul>that reminds me of discussions regarding package maintainership and how it might give a sense of ownership :-) <ketchup>I'm looking forward to switch to GuixSD, but one issue that I can't find a solution for is using CCache when building the packages <rekado>ketchup: we don’t use CCache when building packages. They are always built in a fresh environment. <rekado>bluekeys: I bet that’s because Emacs Guix does not use the same Guix as you would on the command line. <ketchup>Oh damn, I forgot that it creates a new image lmao <rekado>bluekeys: going forward it should be using “guix repl”, but it currently doesn’t do that (due to missing features in “guix repl”) <rekado>civodul: I’m glad we don’t have package ownership in Guix. (And it looks like being a little inept at using debbugs tags has its advantages… :)) <bluekeys>rekado: What do you mean? Is it because I have a source checkout of guix from git? Geiser is pointed at that in my .emacs... Where is it looking if not at the repl? And is the repl not looking at my git source checkout? <sirmacik>how can I use xfce-desktop with network-manager? <sirmacik>I've changed gnome-desktop-service-type to xfce but as for network-manager config part it asks me to add gnome package <rekado>bluekeys: I’m not sure, actually. It’s been a while since I used Emacs Guix. <g_bor>I was wondeing how to search for tags in the issues.guix issue tracker. <g_bor>rekado: what is missing for that? <rekado>the problem here is that debbugs has two types of tags: status and user tags. <rekado>user tags are arbitrary tags that are tied to a user account <rekado>the status tags themselves are very limited. <rekado>I implemented search for user tags in guile-debbugs, but I don’t think I exposed that feature in mumi. <rekado>the search is the weakest part, because it still depends on the debbugs search <g_bor>The only tag I am currently looking for is easy, and I believe it is a status tag. <rekado>I don’t think there’s an official “easy” tag in debbugs. <vagrantc>civodul: yes, debian's definitely evolved from a "strong sense of maintainer ownership" to a "somewhat less strong sense of maintainer ownership" :) <vagrantc>civodul: happy to have gotten a response at all, though! <Parra>hey guys I'm having a problem, X.509 certificate of 'github.com' could not be verified, I have installed nss-certs but the issue is still happening <vagrantc>civodul: i don't know what the options are they don't want to re-enable it <rekado>Hey Parra, have you followed the instructions in the manual? <Parra>in the section troubleshooting <rekado>Parra: can you show us the environment variables that are set? <rekado>g_bor: let me see if I can find this with guile-debbugs <rekado>g_bor: would be nice if mumi had a list of easy issues right on the front page. <vagrantc>civodul: though the next blocker might be getting proper licensing and copyrights recorded for gnu/packages/patches/ ... <vagrantc>civodul: also a little wondering about /var/guix as opposed to /var/SOMETHING/guix <vagrantc>is it too late to propose updating python-six in core-updates? <rekado>g_bor: guile-debbugs says that these issues match the tag “easy”: (32709 36594 31302 36592 29365 26797 36868) <rekado>(soap-invoke %gnu get-bugs '((package . "guix") (tag . "easy"))) <vagrantc>guix refresh --list-dependent python-six <vagrantc>Building the following 1005 packages would ensure 2110 dependent packages are rebuilt: dstat@0.7.4 python-pygra <rekado>vagrantc: let’s do this in the next core-updates cycle <rekado>what happened to core-updates-next? Is that open for business? <g_bor>rekado:that list looks good to me. debbugs has the same. <rekado>I remember that Mark and janneke were working on it to fix the bootstrap binaries. <rekado>g_bor: neat. In that case we could probably just add a tag search after all. <rekado>jackhill: and “GuixSD” should be replaced with “Guix System” <rekado>jackhill: this is something the Savannah admins need to do for us. (We can’t do this ourselves, I think) <g_bor>rekado: could you do it, or should I have a look at that? <g_bor>I would rather point the issue tracker url in the outreachy proposal to mumi. *rekado reads mumi source code <civodul>it does seem "weird" to me as an outsider how much decision making power a single package maintainer has <janneke>rekado: that was on core-updates, civodul also helped *janneke hasn't had much luck with core-updates-next yet <vagrantc>civodul: obviously a bigger deal with packages that are pretty heavily relied on <rekado>janneke: so, pushing to core-updates-next as the next core-updates is fine? <janneke>rekado: yes, i think so -- but i'm not sure about its state... <janneke>i tried cross-builds (because of the many cross-build fixes) but building a cross-gcc fails for me <janneke>and i also cannot use core-updates-next (yet) for my new scheme-only bootstrap work <janneke>possibly due to a gcc-7 switch? i'm sure someone knows, although mark was also involved in core-updates-next <civodul>rekado, janneke: i think core-updates-next is actually an old version of the current core-updates <civodul>i think we just forgot to remove it when when Mark copied the new bootstrap to core-updates <janneke>civodul: oh? at the very least, core-updates-next has patches like <janneke>659a2d0f4f gnu: perl: Fix cross-compilation. <janneke>that do not seem to be on core-updates <janneke>but those patches there could be a mistake? ***Digitteknohippie is now known as Digit
<civodul>well we should double-check and recreate the branch if needed <civodul>i think it initially differed from core-updates by just a couple of commit from Mark <g_bor>roptat: I have a proposal for you to review :) <rekado>oh, octave built fine with texlive-union! Now I just need to reduce the diff…