<ngz>Hello. I'm encountering an odd problem while packaging stuff. A package source code is wrapped within 2 zip files. I can extract it by setting a new `unpack' phase, but how can I use a `snippet' to get rid of pesky bundled libraries? <adfeno>ngz: something along the lines of the (delete ...) procedures? <adfeno>I have seen this somewhere, although it's been a while since I last tried to code in Scheme. <ngz>I mean: I cannot easily access to the files to delete, because I suppose they are still wrapped within a zip file when `snippet' code is evaluated, or so I think. <ngz>Actually, I don't have a clear picture about when `snippet' happens. <adfeno>I don't know if Guix allows for this complex definition, but it would go like this: <adfeno>A Scheme procedure that iterates over each file in the current directory only (not its parent directories), and for each non-directory which is also a zip file, append a new `unpack' phase) <ngz>This is roughly what I'm doing in the unpack phase. Except I don't append a new `unpack' phase, but I simply call "unzip". <adfeno>I think that the `(use-modules (ice-9 ftw))' might be of some help here, particularly the 'scandir procedure. <adfeno>Yes, that way of doing it also works <ngz>My question is more oriented towards "source.zip". Let's assume my source directory contains "source.zip", with all the source code in it. If I unzip it in `snippet', do I still need to unzip it in `unpack'? <ngz>err towards `snippet'. <ngz>And if I unzip it in `snippet', am I expected to zip it again? <ngz>It seems they use a zipped zip because the outer zip is 7x smaller than the inner one. <adfeno>As far as I have tested, before `snippet' there is an attempt to unpack it, the snippet makes the changes, and a hook after that packs it again (or puts it into a directory, I can't remember which of these two options now). Then, when the build phases begin, `unpack' comes and does it's job in the modified source, and so does all the other build phases. <adfeno>Inevitably the hidden hook after `snippet' will do its thing <ngz>So I still have to take care of the inner zip in `snippet'. <ngz>and pack it again after removing stuff. <adfeno>It would be a good idea to take care of the zips during `snippet' , but you don't need to pack it again <adfeno>(the hook after `snippet' will pack it for you) <ngz>I don't think so. As I explained, this particular package constists of a zip file of a zip file of source code. <ngz>If I understand you correctly, the hook will pack the outer zip for me. <ngz>But not the inner one. <ngz>Yes, but it depends on what I leave in the directory at the end of my snippet. <ngz>If I leave source code, it will pack it, but the zip after `snippet' will be 7x larger than the initial zip. <ngz>I'm not sure this is desirable. <adfeno>When making packages I often tend to use `snippet' for general changes that are of the benefit of other distributions (reproducibility changes, bug fixes caused by upstream, GNU FSDG compliance), and leave build phases for Guix specific tweaks (making references to the store or to inputs/outputs, replacing "usr" with nothing) <adfeno>But in this case of the zip files inside another one, I think you can just *not* have a `snippet' and instead operate by replacing appending a phase after the "unpack" one in order to deal with the zip files within. <ngz>You may well be right. <adfeno>Otherwise, if dealing with the zip files already in `snippet', you would have the 7x larger zip you mentioned. <adfeno>For other maintainers, leave a comment on top of the added phase explaining why you made it into such a way instead of as a snippet. <adfeno>This size rationale is importation to mention, I think <ngz>I think I have more comments than actual code in this package. <ngz>adfeno: Thank you for the advice, btw. <ngz>Gah. Now I have "unbound variable: gnu-build" in %resolve-variable. <mbakke>ngz: You could add two "origins", each with their own snippets, and use them as "native-inputs". Then just have (source #f) in the package derivation. <mbakke>s/derivation/definition/ (it's late :P) <RockAndSka>Concerning the new pack option, aka '--relocatable' (oh yeahhhh!!), is the .profile exported only works in relocatable mode, or work normally too if it detected than the package is inside /gnu/store ? <ngz>mbakke: You mean one has the regular source, and the second one has (source #f)? <mbakke>Wait, I mean you could use one of them the "normal" way (source %foo), and the other as a native-input. <mbakke>Or both as native-input, if it's not clear which zipball is "authoritative". <ngz>I think I understand what you mean. <ngz>mbakke: Actually, no. The native-input origin would be a fake one, whose only purpose is to have a snippet attached to it? But how can I specify its source should be the inner zip (so the snippet hook can zip it again)? <mbakke>ngz: Oh, you want to "merge" the two tarballs? I don't see a way short of creating a custom derivation. <ngz>Thinking about it, is there any point in removing bundled library during build phase (as opposed to snippet), since they are not used anyway? <mbakke>You'll have the assurance that the bundled library is not used in the future, for one. <ngz>the library isn't moved to output, is it? <mbakke>I mean, time pass by, updates are made, upstream changes build system.... Suddenly the "unused" bundle is actually used, but no one notices. <mbakke>But by providing one or both of the origins as a native-input, you could "merge" them in a custom "unpack" phase. <ngz>Would that make a difference with current state? <mbakke>I'm not sure what the current state is, I just jumped into a discussion without reading the beginning nor the end :P <ngz>The only thing, AFAIK, I am missing actually is a way to remove bundled libraries in `snippet'. I remove them prior to `build' phase at the moment. If this is good enough, so be it. <ngz>I have to go. Thank you for the help mbakke. <travankor>is there a beginners guide for guixsd? Or will I be better served learning NixOS and migrating to GuixSD later? <vagrantc>if you aren't familiar with scheme, it's a bit of a steep learning curve <samplet>travankor: FWIW, I started with GuixSD, and found it not too hard learn. It’s very different, sure, but you learn by solving one problem at a time. <samplet>Also, the Guix community is usually pretty helpful. <travankor>I'm new to functional programming/configuration so I guess I will be learning a lot either way. I'm leaning towards GuixSD since it seems more cohesively designed (Scheme/Guile). <vagrantc>ACTION was drawn to the commitment to free software <marusich>The commitment to freedom is an important aspect of the project that I really like. <samplet>I think the best parts of Guix are the commitment to freedom, the efforts going in to bootstrapping, and multi-stage programming (Scheme). ***Gamayun_ is now known as Gamayun
<churndre>THIS IS AN EMERGENCY NOTICE THIS IS NOT SPAM: THIS NOTICE IS CURRENTLY GOING OUT TO ALL CHANNELS THROUGH THE FREENODE EMERGENCY NOTIFICATION SYSTEM: GRUMBLE HAS INADVERTENTLY NOT RESET THE FREENODE SECURITY PASSWORD CAUSING A BREAK IN FREENODE SECURITY WHERE ALL PASSWORDS HAVE BEEN RELEASED. PLEASE SEE GRUMLE IN #FREENODE FOR INFORMATION ON HOW TO SECURE YOUR ACCOUNT!! <churndre>THIS IS AN EMERGENCY NOTICE THIS IS NOT SPAM: THIS NOTICE IS CURRENTLY GOING OUT TO ALL CHANNELS THROUGH THE FREENODE EMERGENCY NOTIFICATION SYSTEM: GRUMBLE HAS INADVERTENTLY NOT RESET THE FREENODE SECURITY PASSWORD CAUSING A BREAK IN FREENODE SECURITY WHERE ALL PASSWORDS HAVE BEEN RELEASED. PLEASE SEE GRUMLE IN #FREENODE FOR INFORMATION ON HOW TO SECURE YOUR ACCOUNT!! <churndre>THIS IS AN EMERGENCY NOTICE THIS IS NOT SPAM: THIS NOTICE IS CURRENTLY GOING OUT TO ALL CHANNELS THROUGH THE FREENODE EMERGENCY NOTIFICATION SYSTEM: GRUMBLE HAS INADVERTENTLY NOT RESET THE FREENODE SECURITY PASSWORD CAUSING A BREAK IN FREENODE SECURITY WHERE ALL PASSWORDS HAVE BEEN RELEASED. PLEASE SEE GRUMLE IN #FREENODE FOR INFORMATION ON HOW TO SECURE YOUR ACCOUNT!! <churndre>THIS IS AN EMERGENCY NOTICE THIS IS NOT SPAM: THIS NOTICE IS CURRENTLY GOING OUT TO ALL CHANNELS THROUGH THE FREENODE EMERGENCY NOTIFICATION SYSTEM: GRUMBLE HAS INADVERTENTLY NOT RESET THE FREENODE SECURITY PASSWORD CAUSING A BREAK IN FREENODE SECURITY WHERE ALL PASSWORDS HAVE BEEN RELEASED. PLEASE SEE GRUMLE IN #FREENODE FOR INFORMATION ON HOW TO SECURE YOUR ACCOUNT!! <churndre>wigust lain0n bavier dddddd sahithi-ihtihas Barista slyfox catonano2 einarelen travankor[m] jonsger iyzsong lxo pagurus reepca-laptop sentriz shpx shiranaihito rekado_ terpri joelpet xkapastel neuromorphic yrk divansantana daviid detrout dustyweb Gamayun m-o oleo Haaninjo janneke efraim bill-auger quigonjinn phant0mas csprng specing madage richi235 tilpner nordstrom ym nckx emacsomancer Apteryx_ Sleep_Walker jackhill nu gnunet_bot happy_gnu[m] Digit jchmrt nic ***jonsger1 is now known as jonsger
***jonsger1 is now known as jonsger
***Piece_Maker is now known as Acou_Bass
***jonsger1 is now known as jonsger
<jlicht>o/ janneke. Great work on the latest release of Mes :-) <janneke>jlicht: i have real good hopes we can now get bring the wip-bootstrap branch very close to a really useful state <jlicht>yeah, that was the feeling I got as well regarding your release notes. Very exciting indeed ***Piece_Maker is now known as Acou_Bass
<Digit>heh, funny spam there proclaiming to not be spam, n other falsehoods. <Rukako>gpg-agent is quite nice for ssh keys too <Rukako>I have not tried it in guix yet however <civodul>but i like the neat hack outlined in the article <pkill9>Rukako: aren't you thinking of ssh-agent? <pkill9>or can gpg-agent handle ssh keys as well? <ng0>it can handle authentication keys which can output a format usable by openssh <ng0>a format -> the "public key" <ng0>it's annyoing to setup and because you rely on gpg I would not recommend it. use ssh for ssh, use gpg for gpg. it works, but watch out for your gpg keys. <jlicht>what is wrong with relying on gpg, ng0? <ng0>so muhc can go wrong if people are not careful. if you have no backup key to log in, a series of mistakes could lock you out of your servers. <jlicht>I understand the pitfalls of key-based logins, but how does this compare to using e.g. openssh for ssh logins <ng0>jlicht: it's more about usability. I could write about how to set it up, etc.. it's just too warm to discuss anything today^^ <ng0>formbi: startx on its own is difficult, hacky at best. I would suggest a login manager like SLIM and other supported ones <roptat>formbi: using %desktop-services instead of %base-services will work, but it adds more than just a login manager <massma>I ran into a small problem and I was curious if anyone came across it and had a quick fix before I dig deeper. <massma>I'm on GuixSD, and I've installed aspell and emacs with Guix <massma>spell checking with apell suing M-x ispell works great on every buffer I've tried <massma>however, when I'm editing .tex files with LaTeX mode on, M-x ispell fails <massma>with "Process ispell not running" <massma>"Starting new Ispell process /home/adam/.guix-profile/bin/aspell with default dictionary... <massma>Spell-checking body.tex using aspell with default dictionary...done <massma>ispell-send-string: Process ispell not running" <massma>Has anyone else come across this issue? I know it might be an emacs problem, but I figured it couldn't hurt to ask here because my same spell checking .tex files in my same emacs config works on other disdros <OriansJ>massma: have you tried M-x ispell-buffer <massma>yes, with unfortunately the same result. also, this seems not to be specific to my .emacs configuration, because starting emacs with --no-init-file returns the same behavior: M-x ispell* works in all buffers except when LaTeX mode is on, when it fails with "Process ispell not running" <OriansJ>massma: and you have setf ispell-program-name to ~/.guix-profile/bin/aspell right? ***kimin is now known as kp9ioij
***kp9ioij is now known as kimin
***oleo is now known as Guest9731
***Guest9731 is now known as oleo
<jorgesumle>guix pull: error: Git error: failed to create temporary file '/home/jorge/.cache/guix/pull/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/.git/objects/pack/pack_git2_3BpJYT': Permission denied ***oleo is now known as Guest12164
<formbi>jorgesumle: maybe run guix pull as root ***Guest12164 is now known as oleo
<rekado_>formbi: this would not help as it would run “guix pull” as the root user.