<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>* gnu/packages/patches/gobject-introspection-absolute-shlib-path.patch, <iskarian>gnu/packages/patches/gobject-introspection-cc.patch: Modify files. <raghavgururajan>podiki[m]: Unlikely. It would require gobject-introspection+cairo package definition. <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 <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>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! <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>any way, did't work. Can't load python files <iskarian>excalamus, `guix install' or `guix package -f <file>' <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 <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? <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" <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>However that dependency also needs another dependency <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)? <xd1le>what language or platform is the package in? <xd1le>hmm sometimes there are tools to autogenerate (skeleton) definitions for a group of packages for a particular platform <xd1le>but I don't know anything about java :/ <DynastyMic>so the convention is to write such dependecy packages as java-x-dependency <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 <xd1le>reminds me of the nodejs ecosystem <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 <xd1le>yeah either the git log or the top of the file usually has some names <xd1le>in the web view, to the right of the file there is a "log" button too <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? <muradm>guerrilla: no, you put your channels.scm in ~/.config/guix/channels.scm <muradm>then you run "sudo -E guix system reconfigure ~/.config/guix/my-system.scm" <muradm>-E flag to sudu will make your user environment preserved <muradm>so guix commands will see ~/.config/guix/channels.scm <muradm>and i suggest keeping your system config under user directory or else where <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>definitely.. arch was may legacy also <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 :) <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>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>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, hugo says: My Shapefile library, announced on 30 december 2020 <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>/home/user/.guix-profile/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory <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)? <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 `Ã|` <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-
<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 <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. <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 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>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 <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 <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 <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 ;-) <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. <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 <abrenon>should a copyright line be included even in a patch that just corrects the URL of a home-page ? <apteryx>I think the rule of thumb is 10 modified or new lines (removed text is not copyrightable) <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) <raghavgururajan>apteryx: So the plan is to merge the gobject update when you also merge your changes? <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>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). <raghavgururajan>I reused the commit message in the patch files. I think it was originally formatted by git diff instead of format-patch. <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>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>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. <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>apparently the root cause is "I can't find file `tcbx1000'." <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? <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 libguile.so 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 <rndd>all i needed is to run guile-config compile ***soheil_ is now known as soheil
<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: l3backend-dvips.pro", even though i added texlive-latex-l3backend <civodul>perhaps an environment variable missing or some such? <civodul>(and it still solves problems "well enough") <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 ***ds815 is now known as dstolfa
<podiki[m]>i'm anxious to try too, maybe this week is the week.... <roptat>maybe don't try it today, it's rebuilding the world (including the rust bootstrap chain...) <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