<zimoun>erkin: are you currently running Guix on your machine? <clone>Does anyone know how to make a package that builds a git repo with recursive submodules? <clone>i tried (git-reference (url "url") (commit "commit") (recursive? #t)) but it didn't change anything <mihi>terpri, thanks. Now trying to find an editor I can install on hurd (that preferrably has substitutes) so that I can "monkey-patch" that scm file :) <mihi>if I don't find any, I'll have to resort to ed or sed. <terpri>maybe nano? iirc that's the only "visual" text editor on the install disk <mihi>nano tries to build python (no substitute and I think the blog mentions it does not buidl). e3 tries to build python. Even ed tries to build python. <mihi>so sed is the way to go. :-> <mihi>emacs-minimal 27.1 also tries to build python <rekado>this must then be coming from glibc <mihi>but no glibc on the screen <rekado>see the output of ‘guix graph --type=bag anything’ <terpri>mihi, i'm pretty sure you can't monkey-patch files under /gnu/store if that's what you mean; you'll need a git checkout of guix, to modify it outside of /gnu/store (and you can override the default guix channel in ~/.config/guix/channels.scm to use your modified copy) <mihi>(at least I cannot connect to it via SSH, unlike the one I downloaded last a few weeks ago) <rekado>the childhurd service takes care of wiring up the network, so SSH will work fine <rekado>is there a reason why you aren’t using the service? <terpri>e.g. my channels.scm is: (list (channel (name 'guix) (url (string-append "file://" (getenv "HOME") "/src/guix")) (branch "current") (introduction (@@ (guix channels) %guix-channel-introduction)))) <mihi>up until 3 days ago I was not even running Guix Linux. And now I'm running Guix Linux as a VM and without nested hw virtualization running a vm inside a vm is slow... <terpri>(i don't remember what the 'introduction' bit is for, probably authentication-related) <rekado> “Channel introductions answer these questions by describing the first <rekado>commit of a channel that should be authenticated. The first time a <rekado>channel is fetched with ‘guix pull’ or ‘guix time-machine’, the command <rekado>looks up the introductory commit and verifies that it is signed by the <rekado>specified OpenPGP key. From then on, it authenticates commits according <mihi>herd status sshd says it is started, but without having even netstat available I cannot find out which port it is listening on? <terpri>although just the "pre-inst-env" script in the repo might suffice if you don't want to mess with channels <mihi>by the way, I managed monkey patching the store and no "checksum validation error" or whatever prevented me from that :-D <mihi>now it reads my monkey-patched /fake_proc_partitions table but fails as there is no device node for /dev/hd0s1 <DrimysWinteri>hello, How can I set the default font in my system? I'm running Swaywm <mihi>Enough for today... "filesystem with label my-root not found" <DrimysWinteri>Icecat is displaying awesomefont glyphs in the menus and pages and I hate it <mihi>ah ok I can just replace the (file-system-label ...) by "/dev/hd0s1". And now it tries to build python again. So really enough for today. <nckx>DrimysWinteri: Don't know the answer to your first question, but take a look at IceCat's ‘gfx.downloadable_fonts.enabled’ about:config setting for the second. <nckx>(I don't think there is an answer to the first, there is no system-global default font.) <nckx>DrimysWinteri: Don't you want to disable downloading ‘Web fonts’ like ‘Font Awesome’? <DrimysWinteri>mmm nope, the problem is that for example in the Preferences menu I see glyphs of awesome font, like where should read 'windows' it shows me the windows logo <blackbeard>$ guix environment --expose=$HOME/.mozilla --expose=$HOME/.guix-profile -E '^DISPLAY$' --container --network --no-cwd --ad-hoc icecat --expose=$HOME/.Xauthority -E '$XDG_DATA_DIRS' <nckx>DrimysWinteri: What's wrong with that? Sounds closer to ‘patching IceCat to suit your taste’ than ‘changing a font’. You could try messing with fontconfig either through putting your own custom replacement in ~/.local/share/fonts or force some kind of [range?] substitution through fonts.conf. It may or may not work depending on how IceCat renders things. <blackbeard>when I run that command ^ i can't see fonts on icecat just some rectangles <nckx>Otherwise, patch IceCat. <blackbeard>nckx: that is the rectangle I see yes, hhaha unless that is an emoji or something <blackbeard>i kinda saw that coming because i know nckx uses emojis <pineapples>blackbeard: I could not find an emoji font pack in the Guix repository, sadly :( <joshuaBPMan>hey guix, I'm trying to get a shepherd user service that does a haunt build && haunt serve -w -p 23403. So far no luck. <blackbeard>pineapples: emacs has an emoji pack that works without the font :) <ZombieChicken>Hello. Is there a working port of GuixSD for the Pinebook Pro? I seem to recall one was either done, or in the works, but I don't recall which <sys2>hi #guix! I'm trying to build a (slightly modified) pacakge from the repo using `guix package --install-from-file=$PWD/xdisorg.scm`, but I'm getting: `guix package: error: cannot install non-package object: #<unspecified>`. Does anyone know why? Is --install-from-file wrong? <apteryx>blackbeard[m]: why are you exposing XDG_DATA_DIRS? <apteryx>it's referring to things not exposed in your container <roptat>sys2, the file probably only has define-public stuff, so the return value is #<unspecified>, which guix cannot build :) <roptat>you need to add a line at the end where you put the name of the package you want to build <roptat>actually, the latest version of guix should tell you that <sys2>roptat: do you know where I can find that line? sorry this is my first time doing this <sys2>ohh nvm I see... it's just the name. lol thanks ***iyzsong-- is now known as iyzsong-w
<bavier[m]1>I just finished reading the latest Hurd blog post. Really nice. Thank you to all the authors! <Zambonifofex>Regarding Hurd: I wish there were an option to download an ISO installer for Guix with Hurd. Perhaps it’d be interesting to have it as an option in the standard installer, even. I don’t know, just thinking out loud, I guess. <xelxebar>Holy crud. This blog post is intensely exciting. Massive congrats to the devs for pulling so many threads together into this superadditive feature. ***iyzsong-- is now known as iyzsong-w
<janneke>Zambonifofex: that would be nice; for now a good option is to install gnu/linux based guix and use "guix system install" from there ***iyzsong-- is now known as iyzsong-w
<bdju>can I use a normal ~/.themes dir on guix system or do I need to do something unusual? ***rekado_ is now known as rekado
<sneek>Welcome back mothacehe, you have 1 message! <sneek>mothacehe, efraim says: building the arm image natively worked and the board boots up! Now I just need to find growfs <efraim>yeah, in the end I figured it would be faster to just use ext4 rather than rush write btrfs support <zimoun>Hi mothacehe! I think Copyright is missing in cuirass watchdog.scm and metrics files. <rekado>oof, I just upgraded icecat and all I get now is “Segmentation fault” <efraim>instructions I found online say use fdisk do delete partitions and recreate at full size, partprobe from parted to pick them up and resize2fs to grow it <mothacehe>efraim: you can also specify the partition size at build time <efraim>I realized that after I finished <mothacehe>I need to write a cookbook/blog article about all that\ <efraim>also I didn't really have space for a much larger image on that machine <efraim>it might be worth creating the image with parted and fdisk already included as "bonus packages" ***apteryx_ is now known as apteryx
<mothacehe>efraim: we could maybe add them to %base-packages, I guess it won't add much to the closure <efraim>I'll see about putting together a %base-packages-disk-utils that would be useful for inclusion in raw images and installation images <efraim>we need to sync the packages a bit, %base-packages-interactive has zile and nano, installation image has zile nano and nvi <mothacehe>yes there are some extra packages in (gnu system install) <ani>hi, I have been directed to this channel from outreachy. <ani>I am interested in project called "Add a subcommand showing GNU Guix history of all packages" <ani>may I know which languages are required to work on this project afaik guile scheme is like lisp and derivative of scheme. And GNU is trying to use Guile scheme as extension language <ani>my question is how shall I proceed towards contributing to the project? <Brendan[m]4>Guix is 99% Guile Scheme so that's what you want to learn. <rekado>ani: Scheme is a small dialect in the Lisp family of languages. <ani>So shall I directly learn guile or <rekado>ani: to get started with Guix I recommend installing it first (on your GNU/Linux distro of choice) and playing with its features. <ani>go from lisp to guile <rekado>there are hundreds of different Lisp languages, all with minor differences <rekado>it won’t be useful to learn *some* Lisp variant and only *then* learn Guile <rekado>I’d also suggest not to learn Guile first :) <ani>Guix is also an operating system. I wanted to install it on libreboot, but I believe because its 100% free I won't be able to run due to my wifi card? So I will first install it as a package manager. Which one shall I go for full OS or as a package manager? <rekado>install it as a package manager first <rekado>you will have most of the features available <ani>so which would you suggest me to learn? <rekado>(Guix is quite a bit more than just a package manager; you have access to features that really don’t match that term) <rekado>one of the first tasks we ask of potential Outreachy interns is to write a package definition. <rekado>“write” is too big a word, really: to generate a package definition <rekado>we have so-called “importers” that generate code for you; you only need to adapt them. <rekado>but before you do any of that: install Guix on your distro with the installer script and install the “hello” package to see it in action. <ani>sure I will do that> <rekado>to avoid problems I also suggest looking at the Contributing section of the manual. <rekado>at some point we will ask you to make a contribution by sending some code; that section explains how to set up everything to be ready for that. <rekado>there are a few conventions and tools to use, and it makes everything easier in the long run if you know the very basics of how to use them. <rekado>the good thing is that you can use Guix to install these tools, so first things first: install Guix ;) <ani>Okay, I am excited as this is my first time actually someone has helped me in Free Software Contribution. Thank you very much. :) <rekado>if at any point you get stuck don’t think too much about it: just ask here, even if you think it might be a silly question. <rekado>getting started is the hardest yet most important step <rekado>everything else after that is rather easy. <rekado>you’re welcome! I’m looking forward to working with you towards your first contribution! <rekado>I need to go now; see you around! <Brendan[m]4>Is there more information that clarifies what "add a command showing GNU Guix history of all packages" entails? I clicked the Outreachy link and it just said you may need to login to find more information. <g_bor[m]>zimoun: Wow, your proposal is getting quite a traction. Congrats! <Kimapr[m]>> Guix is also an operating system. I wanted to install it on libreboot, but I believe because its 100% free I won't be able to run due to my wifi card? So I will first install it as a package manager. Which one shall I go for full OS or as a package manager? <Kimapr[m]>ani: If you really need non-free software, there are various channels providing package definitions for them. It isn't recommended and it isn't allowed here to direct people to them but you can find them yourself <g_bor[m]>ani: for this project either the os or the package manager only version is ok. <mothacehe>efraim: i'm changing arm64-disk-image format to 'compressed-disk-image so that it produces a .xz raw disk-image. <zimoun>civodul: what do we do about the v1.2 release? Soon or postpone because some fixes are required? Danny’s bug about i686 &co and time for translation, to name some “blocking” points. WDYT? <civodul>zimoun: what was the target date again? :-) <civodul>i'm sorry for not being more rigorous <civodul>i don't think the 32-bit issue is a blocker ***cyrozap is now known as Guest30462
<zimoun>civodul: intially my plan was October 29th, but you said earlier should be possible <zimoun>because now there are *a lot* new stuff that deserve release all by themselves. :-) Authentication, Hurd, Images, packages updates, etc. <civodul>i believe roptat sent new POT files for translation, so that's good <zimoun>well, at FOSDEM you said that we need people that track and try to keep the schedule for releasing. Well, I am trying ;-) <civodul>i'm currently working on --with-c-toolchain v2, but hopefully then i'll focus on more release things <zimoun>cool! Another feature which deserves new release. ;-) ***iyzsong-- is now known as iyzsong-w
<mothacehe>What about starting a 1.2 branch, so that we can have the CI build installer images people can test? <zimoun>civodul, roptat: I will send an email to translators and see Oct. 20th is a good canditate to have all the translations updated. Since there is new material and move of others. Does it make sense? <civodul>zimoun: i think you can inform them that we're targeting end of Oct. rather than suggest that they do the work by then :-) <civodul>mothacehe: yes, i wonder, should we branch yet? <civodul>at any rate, i agree we need to call for installer tests <civodul>the GRUB menu shows the commit i think, right? <mothacehe>we can make a first pass on master, by sending a link to the latest installer to guix-devel <zimoun>civodul: yeah for sure. That’s what I meant. :-) <mothacehe>Brendan[m]4: There's no "latest" link to the 32 bits installer <mothacehe>but you can still find it at ci.guix.gnu.org <civodul>mothacehe: would you like to send a call for testing the x86_64 installer? :-) *Brendan[m]4 discovered the sleep* procedure O.o <civodul>BTW, i've seen the SQL wizardry for Cuirass, thumbs up! <mothacehe>you were right about the importance of having write transactions <mothacehe>I suspect the final issues are happen when a lot of builds start/stop and we issue many update queries <civodul>yeah i run "tail -f cuirass.log" and you can see that the "build succeeded" lines scroll by slowly <mothacehe>I'm diving into sqlite internals, but it seems that if a read query (select) is ran concurrently with a write query (update), on the same table, then the read query is promoted to a write query <mothacehe>and have to wait for the unique write query lock <mothacehe>so having a worker that could accumulate those write queries and send them in 500 queries batch for instance <mothacehe>the 228450 lines of sqlite3.c are a bit intimidating :p <civodul>BTW, now that the coordinator service is committed, cbaines should unleash their creativity and have it run on the build farm :-) <civodul>also i got another demand for dynamic offloading at work <zimoun>civodul: cool! the v2 “–with-c-toolchain“. Eager to test it. :-) <civodul>zimoun: thanks, lemme know how it goes! <civodul>mothacehe: i mean that instead of a static list in machines.scm, you could have build "agents" that come and go <civodul>the head node would just broadcast build requests that available agents pick up <civodul>it'd be useful on big clusters managed by OpenStackShift and all that <civodul>or HPC clusters where you access machines through a batch scheduler <mothacehe>civodul: that could indeed by really nice and we have some nice bricks with the GBC. However, given the time I'm spending debugging tricky fibers + sqlite issues, I think that we should have this dynamic offloading mechanism directly as a part of Guix or Cuirass at term. <mothacehe>so that we maintain only one fiberized webserver implementation <civodul>ah sure, we don't want to duplicate tough work like this :-) <civodul>but i think offloading is mostly orthogonal to Cuirass <mothacehe>then Cuirass would only evaluate + offload builds <cbaines>I spent the weekend fixing I hope most of the issues with PostgreSQL/Squee and fibers, now the Guix Data Service should have less issues with fibers blocking <mothacehe>and we could have dynamic offloading as a part of Guix <civodul>well, "dynamic offloading" is a misnomer because offloading is synchronous (you run "guix build" and wait for the result) whereas what i have in mind is more like async distributed builds (what GBC does) <cbaines>My thinking with the Guix Build Coordinator has been that it's sort of a hack until the Guile daemon becomes more realistic <mothacehe>cbaines: the cuirass fiber watchdog can maybe help you <leoprikler>Is there a way to list the grafts that are applied to a package? <civodul>looks like everyone has blocking fibers :-) <PotentialUser-49>does anyone use emacs-treemacs? i was trying to install emacs-lsp-java but the emacs-treemacs-2.8 build fails <civodul>but you can also open the .drv and its corresponding "guile-builder" file to get a good idea <cbaines>mothacehe, yeah, that looks really neat. I've only been looking at metrics requests timing out so far. <leoprikler>okay, follow-up, is there a way to use an already grafted package as input? <leoprikler>I believe that the grafting process breaks some QResources in mumble. <numerobis>Hi #guix! Beginner question: after guix pull, how can I force all packages to be updated, using the latest package definitions in the freshly downloaded guix? <zimoun>civodul, mothacehe: does it make sense to implement something à la StarPU? i.e., HEFT and work stealing. <zimoun>well, it is INRIA’s same family ;-) <zimoun>I am probably out-of-scope and drifting as usual. ;-) <OriansJ>guix fallback to software heritage doesn't seem to be happening for cxqgwmlw0wshq6h4214wb0gjx4b346i4-libsndfile-1.0.30.tar.bz2 with guix on commit 29a2eb36ff85eb75eeb907aa687fbb655b5f1097 <zacts>does the hurd version of guix run on any real hw? <zimoun>OriansJ: it is complicated about tarball since SWH does not store tarballs <zimoun>the map our checksum to SWH content is not always straightforward <Brendan[m]4>i feel like we should fully embrace git repos, avoiding tarballs when we can <civodul>zimoun: yeah the problem is not so much the scheduling algorithm at this point <OriansJ>zimoun: ok, is there a way to download the git from SWH and then generate the tarball locally and have guix use that? <Brendan[m]4>ill look at it, but my reason is that i hope people can use guix for hacking on projects. for that purpose there is no use for a tarball anyway <Brendan[m]4>if the repo is git, then abstractions like "build the latest git version" can be built <OriansJ>Look, I honestly don't care. I just need guix build to consistently be able to grab the known good source and build known good binaries <zimoun>civodul: I have not closely followed the topic, just random chats with mothacehe and see the recent patch by apteryx. My understanding is that offload.scm picks one machines and then the dameon on this machine schedule the build. I do not know what is the scheduling strategy of the daemon but from my little experience it does not use all the ressource of the machine has. <OriansJ>Look this issue isn't old; it has been with us since the beginning (hence guix refresh) <zacts>Brendan[m]4: what about projects that don't use git? <zimoun>OriansJ: yes and no. Yes, there is a wip bridge https://git.ngyro.com/disarchive/ and discussions on the SWH side. No because if you do not have the tarball to generate, you cannot have the SWH-ID to lookup. <zimoun>Brendan[m]4: I am working on hit. Help welcome :-) <zacts>well, I know of projects using fossil-scm, subversion and cvs <zimoun>SWH support SVN and hg, and git. <zacts>I wonder if you could allow for tarballs as a fallback <zacts>so the default would be to use git over tarballs, and then if it can't find that, it would revert to using a tarball for it <zacts>and re: my question on the hurd, I have a beaglebone and I'm trying to decide what to do with it <zacts>I have two beaglebones, and rpi2, and an rpi4 <Brendan[m]4>the problem is they are simply not the samething. they dont have the same hash, or even the same method of computing the hash, and the files are most likely different in a few ways <Brendan[m]4>so they would be essentially two different package definitions <civodul>zimoun: "guix offload" i kinda dumb, it doesn't see the big picture, but it's good enough, at least it's not the main issue here <botsnack>Hello, don't forget that you can convert a git repo to a tarball with dist-package. <botsnack>The only problem being of course that a tarball has modification dates in it (otherwise make is lost) so it is not reproducible. <zimoun>civodul: yes. The bottlneck is the daemon scheduler. (Which is opaque to me. :-)) <zimoun>OriansJ: your issue is because you do not use substitutes, right? <zacts>hm... it's also possible to convert svn, cvs, and fossil to git <mothacehe>zacts: those boards are armv7 and armv8 architecture which are not supported by the Hurd <mothacehe>if you can find some i386 hw, then maybe it will work :) <botsnack>Also some packages will need to pull things from the internet, like gnulib, so dist-package will not work in that case. <OriansJ>zimoun: my issue is because guix can't build half the packages they have substitutes for <zacts>hm... mothacehe how active is the guix+hurd project? <zacts>as far as the guix side of it is concerned? <zacts>mothacehe: I saw something on the guix homepage, but just skimmed it <zacts>also, I'm on a console-only browser at the moment <OriansJ>hell here is an even simpler solution to the guix missing tars problem; just host them on a Gnu Server <botsnack>There were plans to use IPFS and Gnunet at one time <OriansJ>hell, I'd even throw a terabyte of storage to help with that <OriansJ>but I need the ability to get the tars in the first place to even help with that <zimoun>OriansJ: the file you want is on libsndfile-1.0.28.tar.xz is on the ci.guix.gnu.org <OriansJ>I am willing to git clone a shitload of repos and waste disk space to generate the tars if required <botsnack>The problem is, you won't be able to get the exact same tars, because most were generated with ancient or patched autotools <civodul>OriansJ: thanks very much but we're already working on it as zimoun wrote :-) <OriansJ>zimoun: and how is a new user expected to know that or the method to get that file <civodul>"guix time-machine --commit=29a2eb36ff85eb75eeb907aa687fbb655b5f1097 -- build -S libsndfile" works for me <zimoun>OriansJ: well the command: guix build $(guix gc --references $(guix build libsndfile -d) | grep libsndfile-1.0.28.tar) should do the job to populate your store <civodul>which file exactly is missing for you? <civodul>zimoun: there's no libsndfile-1.0.28 at that commit, only 1.0.30 AFAICS, no? <zimoun>I did guix time-machine –commit=… – edit libsndfile <civodul>but then "guix build /gnu/store/h9f64ndkw3bn5agbyr55kvlk0pa3099v-libsndfile-1.0.30.tar.bz2.drv --check" fails with a hash mismatch <civodul>not the same as a disappearing tarball <OriansJ>so can we please for the love of god have default working downloads for source tarballs <zimoun>civodul, OriansJ: I works for because it is not .tar.bz2 by .tar.xz <civodul>OriansJ: even asking politely won't fix this issue, but you can help! :-) <OriansJ>I don't care what crazy song or dance needs to be done, a new user needs to be able to do guix package -i mpv and without substitutes it should just work <zimoun>OriansJ: Please open a bug report because it is difficult for me to handle all the parameters. Because it works for me! The very same command you pasted <OriansJ>and I have reproduced the behavior with 1.1.0-29.4e3ed9b and 29a2eb36ff85eb75eeb907aa687fbb655b5f1097 <botsnack>What kind of page do you get when you browse the github URL? not found? forbidden? <zimoun>OriansJ: on my machine with nothing fancy, ‘guix packge -i mpv’ perfectly works. <OriansJ>and if you look at https://github.com/erikd/libsndfile/releases/ note it says: libsndfile-1.0.30.tar.bz2 and libsndfile-1.0.30.tar.bz2.asc files were re-uploaded due to problems with incorrect line endings. Update the hashes if necessary. Sorry for the inconvenience. <terpri>random question: is there an easy way to "copy and paste" between a guix system and an android phone running lineageos + f-droid? particularly for typing signal messages as we don't have signal desktop (and i've heard signal desktop isn't great either) <botsnack>I hope next time they will make a patch release ^^ <nckx>OriansJ: So what you want is to enable substitution only for fixed-output derivations? <botsnack>The obvious first thing to do would be to change the hash of libsndfile-1.0.30 to 06k1wj3lwm7vf21s8yqy51k6nrkn9z610bj1gxb618ag5hq77wlx <OriansJ>nckx: no substitutes for bootstrappers <terpri>kdeconnect seems overly complicated, qr codes and text-file transfers are obvious options but would probably be annoying to use on a regular basis <zimoun>OriansJ, nckx: something like guix build $(guix gc --references $(guix <nckx>OriansJ: They changed a *lot* more than line endings. <nckx>And you answer isn't one. <OriansJ>nckx: looks more like generated source than something humans would write <Brendan[m]4>the source output should just be a mirror, its odd to think of it as a substitute because its content addressed anyway. <nckx>OriansJ: Please tell us what you actually want, instead of a slogan. The substitute servers serve the tarball you need. If you get it elsewhere, IPFS, GNU, whatever, it's still substitution. So choose. <terpri>(although i might be underestimating qr code usability, also maybe there's some bluetooth-based utility to push text into android's copy-and-paste buffer or "sharing" system) <OriansJ>nckx: I would like "guix package -i mpv" to work <zimoun>OriansJ: no. It is just to fetch the tarball you want. Only! Because upstream did wrongly, we cannot fix the world. <OriansJ>zimoun: I don't care about the tarball <OriansJ>I care that guix is not able to build mpv <nckx>OriansJ: More slogans :-/ It does. Through substitution. Of the binary *or* the source. <zimoun>OriansJ: …and you need the libsndfile tarball. Right? It changed upstream, that’s not our responsability. To get the same tarball, since it is not possible to get it from upstream, because hash mismatch, you have to fetch from elsewhere. It is what I am proposing. <OriansJ>zimoun: guix is a software distribution <Brendan[m]1>guix should automatically fetch it from elsewhere. if we have a substitute of it, that that should be used as a fallback even if substitutes are disabled, because this is just an alternate source for a sha256 checked file <OriansJ>if it is not able to distribute the pieces needed to build the programs it provides, it isn't doing job #1 <nckx>Brendan[m]1: That's exactly what I propose above, but OriansJ rejected it flat out. <botsnack>I think you should save some words for the failing libsndfile release at github.com/erikd/libsndfile :) <zimoun>OriansJ, Brendan[m]: it is about UI and whislist: adding Guix build farm as fixed-output substitutes. So please fill a bug report (or check if none is already open :-)) <OriansJ>zimoun: demanding the source code used for the binaries isn't fucking UI or whislist; it is the basic expectation of a GNU PROJECT APPLICATION! <Brendan[m]1>OriansJ I support what you want, just please be polite about it. its just work that needs to be done, <nckx>OriansJ: You're being so uncharacteristically inarticulate and entitled that I'm not motivated to solve your use-case. I think what you point out is a known bug: that Guix tries upstream first, and doesn't fall back if it serves garbage. Whether it should do so is a reasonable discussion. This is not. <nckx>Please adjust your attitude. <zimoun>OriansJ: I do like the tone of this conversation and I have to go. *zimoun says: no to boring meetings <botsnack>Could someone not just fix the hash in the libsndfile definition? <OriansJ>nckx: ok. let me reframe it in the following fashion: Guix is distributing binaries to our users and I as a user am not able to obtain the source code used to build that binary and I find this personally concerning and feel that issue should be addressed as a matter of user freedom. <Brendan[m]1>it can, but then time-machine doesnt work. the past cant be changed <nckx>botsnack: Totally, but that's beside the point since guix time-machine is expected to work. <botsnack>Sorry, I did not follow that part of the conversation. But I still think that would be useful for us living in the future :) <nckx>OriansJ: I think that's a deliberately dramatic reframing as something it mos def is not in order to get it the attention you think it deserves. It deserves attention even without that hyperbole. <nckx>‘guix build --source’ (etc.) should always work, it's a severe UI/UX/uatever bug when it doesn't, but it's not quite a freedom issue. <terpri>Brendan[m]1, hmm...looks kdeconnect might have improved significantly since i last looked at it, looks like it uses TLS+TOFU for security now (vs. a...questionably-secured protocol a few years ago). i'll try it out again (and maybe its gnome equivalent gsconnect), thanks for the recommendation! <OriansJ>nckx: "The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this." <nckx>botsnack: I'm updating it by the way. <OriansJ>It isn't being dramatic to point out that source code corresponding to a binary distributed is a concern <OriansJ>thank you for updating the checksum nckx <OriansJ>but I still have the concern about guix ensuring users have access to the source code corresponding to the binaries (substitutes) that they provide to the users <nckx>It is with absolute certainty not a freedom issue, nor is it almost one, like it is not a cat or a jumbo jet. <nckx>divoplade: Thought it was you 😉 <OriansJ>nckx: it isn't even a UI issue. How do users get the source code used to build the binary substitutes is an issue of user freedom. <OriansJ>even if the solution is provide do X in the manual; <OriansJ>users should be able to always get the source code for any binaries we distribute *kmicu enters and immediately leaves to preserve freedom from the unnecessary drama. <nckx>Sage and wise kmicu. I wish there was a hexchat time-machine. /me exits stage right to pore over diffoscope output before pushing the hash change. <terpri>that had me confused for a moment. "has sneek become sentient?" :D <divoplade>The key thing is botsnack is the only preserved user from sneek abuse <sneek>divoplade, vits-test says: huh? <botsnack>So you see, sneek could not send me a message <sneek>divoplade, you have 1 message! <sneek>divoplade, vits-test says: some pron, sir ***vits-test is now known as botsnack-vits
<sneek>botcnack-vits, botsnack-vits says: i own Ur kitties! ***botsnack-vits is now known as vits-test
<nckx>divoplade: Ooh, 1337. Maybe you should report that CVE to dsmith in #guile before registering the snotbackvuln.com domain name. <leoprikler>vits-test: (equal? (package #1) (package #1)) seems to always be #f <terpri>sneek, do we feed you enough? you getting enough calories and batteries? have a botsnack courtesy of botfood not bombs <leoprikler>I think we should refine the botsnack thing though <vits-test>leoprikler: IDK, tried with %base-services but those are list with services.. Was thought, didn't actually tested. *nckx made a mistake in the commit message, s/libsndfile/libsndfile-1.0.30/, please don't tell mother. <leoprikler>Maybe services have an easier time implementing equal? <divoplade>The libsndfile hash is correct on my side, and mpv builds successfully <leoprikler>Seems like it: (eval '(equal? (dbus-service) (dbus-service)) (resolve-module '(gnu services dbus))) <nckx>OriansJ: I'm positive that the ‘guix should try the next URL on hash mismatch’ bug has been reported before, along with the obvious solution (turning the current && behaviour into || until we end up trying the content-address mirror ci.guix), but I can't find it. This is close: http://issues.guix.gnu.org/40906 <nckx>Could be worth re-pinging that. <nckx>divoplade: After pulling you mean yas? <divoplade>Yes, pulling and guix build mpv right after that (I have substitutes for the other packages) <nckx>Partner likes to quip ‘the Internet is forever!’. Should really show them the Guix commit log. <nckx>‘Why'm I being punished like this’, they would ask. <divoplade>I think it's good to have parts of the internet read-write, especially where you put sensible stuff and personal data, but this is a case where we want immutability. ***vits-test is now known as nlly
<davexunit>(%exception #<inferior-object #<&action-exception-error service: file-system-/sys/kernel/debug action: start key: match-error args: ("match" "no matching pattern" ("none" "/sys/kernel/debug" "debugfs" () #f #f #f))>>) <davexunit>my guix is fairly recent but not the newest so I'm running 'guix pull' now to see if I can replicate with the latest. <nckx>davexunit: Your guix would have to be several months old by this point for that to be an issue. Is ‘nodev debugfs’ missing from (probably the target's) /proc/filesystems? <nckx>Ah. That could well be the reason. <nckx>It's only ever been a non-fatal error for me, so the answer here was simply ‘ignore it’. Unfortunate. <nckx>davexunit: Not ideal but: one-time ‘ssh guix system reconfigure’ an option? <davexunit>this is my proc mount: none on /proc type proc (rw,relatime) <nckx>A.k.a. ‘does the running kernel support foofs’. <nckx>Hm, then I guess it is due to the target Guix not having a notion of it yet. <lemes>hi, everyone! my name is Magali and I'm an Outreachy applicant and this project caught my eyes since it uses Scheme, which I'm currently learning in college. I just installed guix on my foreign distro and am trying to learn a bit about it. <nckx>davexunit: ‘Update some other way & it should work from then on’, is my best advice. Sorry. <davexunit>maybe the service that is doing this should be fixed so that this isn't fatal <davexunit>well... a guix pull and a second deploy worked. <nckx>It wasn't locally (w/o deploy) IIRC. <davexunit>not sure if a second deploy would have worked without the pull or what <davexunit>I have a suspicion that maybe enough system activation scripts ran that a second deploy would have worked. <nckx>davexunit: Yeah, same. Maybe I had to reconfigure twice & don't remember that part. <Zambonifofex>Well, I was able to generate a `qcow2` image of Guix Hurd from Guix Linux within a QEMU machine and transmit it to my host machine. Now I wanted to be able to run it on my host using QEMU, and although I am able to get to Grub, I am unable to get past it. Does anyone by chance know what the problem might be? <Zambonifofex>I’m running QEMU like this: `qemu-system-i386 -nic user,model=virtio-net-pci -enable-kvm -m 1024 -device virtio-blk,drive=hd -drive if=none,file=hd7.img,id=hd guix2.qcow2` <Zambonifofex>I generated `hd7.img` with `qemu-img create -f qcow2 hd7.img 128G` <Zambonifofex>`guix2.qcow2` is the Guix Hurd image I mentioned I generated. <janneke>Zambonifofex: have you retried? can you try running qemu with --cpu base? <janneke>Zambonifofex: note that virtio is not supported <ani>I am trying to install(through script) GUIX only my newly installed trisquel getting this error <ani>[FAIL] missing openpgp public key. Fetch it with this command <ani>after running the command or fetching it still unable to install <civodul>ani: what does that "wget ... | gpg ..." command print? <Zambonifofex>janneke: I get the same exact problem with just `qemu-system-i386 -enable-kvm -m 1024 --cpu base guix2.qcow2` <xelxebar>Having trouble setting up guix offload. It's complaining that guile fails to start on the remote machine; however issuing ssh foo@remote.host guile --version runs just fine. <xelxebar>In this case I have (user "foo") set in the build-machine configuration for remote.host. <xelxebar>Is there a way to get more verbose output with `guix offload'? <roptat>ani, you probably need "wget ... | sudo gpg ..." instead <roptat>if you're running the script as user with sudo, it will try to use root's gpg, but the wget command only adds the key to the user's gpg keyring, hence "sudo" in front of gpg <clone11>I just switched to guix, and on other distros I usually put a ton of custom scripts in /usr/local/bin. How do I handle this on guix? I want them to be accesible to all users to I don't want to make ~/bin folders. Do I need to define my scripts as packages? <roptat>then you can add them to your system declaratively <roptat>so next time you install the guix system on another machine, you can copy your declaration and get these scripts directly :) <janneke>and thanks for trying...sadly i'm out of inspiration atm of what you could try <Zambonifofex>janneke: I see. That’s fine, don’t worry too much about it! Thank you for bothering to try to help anyway! <civodul>do CMake and Meson build with "-g" by default? <civodul>apteryx: looks like "retrieving 1 store item from '141.80.167.163'..." never completes because the GC lock is taken, and so it eventually times out <civodul>it's the problem that mothacehe, cbaines & i have been discussing: gc takes way too long now <apteryx>does the gc has everything it needs in the db itself? Or it relies on scanning the store manually? <ani>civodul: Now I managed to install it <ani>roptat: I installed it. <ani>though getting some error figuring out, if need help will come here again. <apteryx>is it possible to run guix-daemon as a simple user? <roptat>I think it checks that it's running as root initially <apteryx>it doesn't seem to, but it wants to use /var/guix/daemon-socket/socket, for which it doesn't have permission <apteryx>ah, seems to work with --listen /tmp/user-guix-daemon.sock <apteryx>ah yes, and then: GUIX_DAEMON_SOCKET=$PWD/user-guix-daemon.sock guix build hello -> guix build: error: store database directory `/var/guix/db' is not writable: Permission denied <roptat>and then I suppose the store will not be writable either <roptat>maybe you could reconfigure to change the localstatedir and the store directory? <roptat>(if you only change the localstatedir you might break things) <ani>after installing guix When I run guix install hello, I get following error <ani>guile: warning: failed to install locale <ani>hint: consider installing the 'glibc-utf8-locales' or 'glibc-locales' package and <ani>defining 'GUIX_LOCPATH', along these lines: <roptat>that's only a warning, not an error. You might want to run "guix pull", I think it's fixed in a recent commit <ani>I did made a entry in my .bashrc with GUIX_Localpath <roptat>I don't think that's part of glibc-utf8-locales, let me check <roptat>it's much more limited than i thought <roptat>anyway, let us know if a simple guix pull did the trick <ani>so I should use en_US then <roptat>you can also insatll glibc-locales <civodul>apteryx: you also need GUIX_STATE_DIRECTORY IIRC <roptat>it has all of them, yours will be in there :) <nckx>roptat: Hm, the script already suggests just that (wget | sudo -i gpg). I wonder what happened. 🤔 <roptat>maybe a network issue the first time they tried then? <civodul>another kernel crash: "X: page allocation failure: order:4, mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null),cpuset=/,mems_allowed=0" :-/ <mfg>how do i specify a package with it's module path? i need the gettext package and guile thinks i want to call the gettext function... <mfg>or do i have to use #:prefix ? <leoprikler>mfg the gettext package is called gnu-gettext (alternatively gettext-minimal) to avoid overriding the gettext function <mfg>Ah okay, i always search for package name swith guix search, so this only shows what's in the name filed i guess? <leoprikler>you can inspect the package by following the location: link or by invoking `guix edit $PACKAGE' <civodul>we'll need Guix and Guile facemasks, it's 2020 <ani>I guess installing guix as a os is easier than installing it as a package manager <roptat>ani, as an os, we can controll more stuff, so the experience is smoother, but we want to support other distros too! <roptat>the installer script is supposed to make things easier, but if anything seems to be missing, we can always improve it <roptat>like, the locales thing should be fixed with the next version for instance <civodul>(if anyone's watching the FSF live stream, what's the name of the speaker? i missed it) <ani>roptat: I changed my locale still getting warning <ani>thats failed to install localr <pineapples>Hello! I'm in the process of documenting my configuration files, and I've been wondering what does #guix think about adding a standard GPL3+ license notice to system configuration files <sneek>Welcome back pineapples, you have 1 message! <sneek>pineapples, nckx says: guix install font-google-noto (warning: it's a big boy) <janneke>civodul: everyone is really keeping quiet about guile, amazing discipline! <civodul>still, it's amazing that the FSF president is a Schemer <roptat>pineapples, i think it makes sense, your config is a program after all <civodul>janneke: or were you also referring to the recent Guile bugs? <roptat>ani, did you run "guix pull" as user? <roptat>and can you check what "type guix" says? It should be hashed to ~/.config/guix/current/bin/guix <janneke>civodul: no, joking 'bout gknauth and their love of racket -- real cool <roptat>(also make sure that path is first in your $PATH) <janneke>someone could tell them there's a whole operating system written in racket (gnu guix) <ani>roptat I run guix pull it is still running <ani>waiting it to get finished <pineapples>roptat: My definition of a program is stricter, but if you say so. Thanks! <roptat>well, maybe your config is really small, but it's really a program that uses guix as a library, and returns an operating-system record <roptat>it can become quite complex, and I don't think you can really distinguish it from a software <pineapples>roptat: When you put it into this perspective. Also, thanks for that link. I found a shorter version of the GPL3+ legal notice, which I like more, in one of the system configs :) <apteryx>mmh, how can I attach to a sudo run guix-daemon with a user ran gdb? I get ptrace: Operation not permitted <apteryx>even after setting kernel.yama.ptrace_scope = 0 <pkill9>is there an important for go packages? *janneke tries to asks nckx in a friendly way to remove python from sudo again, by email <pinoaffe>only semi-related to guix, but do any of y'all have a nice workflow to send a series of patches to the mailing list? <leoprikler>send the cover letter using your normal mailer, then git send-email --to=NNNNN@debbugs.gnu.org <ani>guix pull: error: Git error: failed to resolve address for git.savannah.gnu.org: Temporary failure in name resolution <ani>Installed guix and did run "$ guix pull" <roptat>ani, that's a network issue, maybe try again? <apteryx>can anyone share how to debug the daemon with gdb? The best I've found so far is 'sudo -E ./pre-inst-env gdb --args guix-daemon --build-users-group=guixbuild --max-silent-time 0 --timeout 0 --log-compression bzip2 --max-jobs=1', but it keeps exiting <janneke>we were having a --to me-- kind of difficult clash on sudo and i didn't feel we had consensus yet; so i posted here about it, so that maybe civodul could chime in -- removing python right away feels a bit rude to me <janneke>my message here could have been read as publicly pressurising nckx, which really wasn't my intention, and i apologise for it <divoplade>Dear guix hackers, suppose that I have a web service that receives a username and a password. How do I check that it authentifies a local account on the system? <apteryx>janneke, nckx: I just answered to the sudo without python patch thread <apteryx>if we don't have anyone actively using this, I think it may be better to drop it <nckx>janneke: All good! I *do* think Hurd support is a good reason to remove it in the default sudo. I think the ‘security’ argument is lazy & bogus, but that's not relevant then. apteryx: I do. It's trivial for those who do to define their own sudo-with-python, or even do so in Guix. <apteryx>well, sudo is supposed to be small and secure, IIUC. The more stuff you add to it, the more attack surface you provide. I'm not security expert, but that's my basic understanding of the argument. <apteryx>to be clear, I don't really care -- I was just trying to tip the balance one way or the other so that janneke can proceed. Given it is useful and don't think the security arguments makes sense, then it seems the natural outcome is to keep it as python-minimal. <nckx>No, I don't think they do, but I do think it does make sense to remove it to simplify the dependency graph of sudo. <nckx>Someone said it was ‘brittle’; I don't know what they mean by that but assume they weren't just saying it to spread FUD. <nlly>i heard about opendoas. Why not use it instead of sudo? ***nlly is now known as vits-test
<apteryx>I think it was the full python package pulling x11 that was causing a problem on the hurd. Since python-minimal doesn't pull x11 in, then it would solve the problem just as well, while allowing people to write their sudo configs in Python. <nckx>vits-test: Well, indeed, why not? It's already in Guix. Go nuts 😉 <nckx>If you mean make it the default: because everyone knows and expects sudo. <nckx>apteryx: Ohkay, thanks for correcting my misrememberance. But I haven't tested it with -minimal & I probably won't. <apteryx>well if you use it often you would ;-) <nckx>*Does* anyone use opendoas as their primary sudo replacement on Guix System? <apteryx>I'd expect it wouldn't change a thing <nckx>Does include all the same standard liberries? <nckx>apteryx: To say that I hardly ever use Python is an understatement. I'm sure my Python looks like Scheme with just enough brackets removed to make it work. <janneke>civodul: package transformations for the win \o/ <apteryx>nckx: to answer your question about what standard library differs, I think this says 'not much': diff -rq "$(guix build python)" "$(guix build python-minimal)" | grep -i only <apteryx>err, my command with the guix build expansion doesn't actually work, but it does if you replace with the "out" outputs and append "/lib/python3.8/" to it. <apteryx>or try again with: diff -rq "$(guix build python | head -n1)/lib/python3.8/" "$(guix build python-minimal)/lib/python3.8/" | grep -i only <apteryx>this shows which files one has that the other doesn't <nckx>Yeah, TBH I did that with diffoscope after posing the question and came to much the same (if uninformed) conclusion. <nckx>Weird bug of the week: my IceCat tabs (just the tabs) crash when I connect my Bluetooth Magic Mouse. Even while on a different workspace: connect mouse, switch back, crashed. <mihi>Zambonifofex, I think Guix Hurd still has a long way until a self-hosted installer. Debian has one, but they have to heavily patch the Mach microkernel to make it work (e.g. to add ramdisk support) <mihi>and about your qemu command line: Make qemu emulate a "real" IDE drive (primary master) and you will get past GRUB. <mihi>rekado, had a look at the graph you posted (SSH works again yay!), and it seems really only glibc needs python-minimal. But I thought I saw guix pull some glibc substitute earlier, so unsure why it tries to build it (I'll let it run now and see if it succeeds) <apteryx>in build.cc: if (buildMode == bmCheck) return; -> perhaps the reason we can't have --check with --rounds ? <apteryx>that's in void DerivationGoal::registerOutputs() <mjw>civodul, do you need to graft? <mjw>civodul, I mean at least with gcc the code generated with/without -g is (should) be exactly the same. <mjw>civodul, so a rebuild with debuginfo which is then stripped out (should) produce the same binary package, plus an additional .debug package <mjw>also, why are packages without-debug-info even allowed? :) <apteryx>Qt's debug symbols uses close to a GiB, for example, IIRC. <civodul>mjw: the alternative is grafting or rebuilding the whole stack <civodul>and it's a case where we know we can safely graft because the thing has the same ABI <mjw>apteryx, ok, for the builder, yes. And yeah Qt is humongous... <mjw>civodul, I mean, you don't really have to graft the bin output, it should be bit-identical, so you can throw it away, you just get an extra debug output <civodul>so --with-debug-info is a good stopgap <civodul>mjw: adding an output means you get a different store file name, so you need to graft <civodul>(for this patch i didn't even use a separate output, simply left binaries unstripped) <mjw>yeah, I see because nobody build the debug output so you have nothing to compare it against... bleah <civodul>more importantly, the store is not content-addressed by "input-addressed" so to speak <civodul>if you add disable stripping, you change the "inputs" (an input parameter), so you get a different output file name <mjw>yeah, but, but, but... <civodul>that's how it works, it's essentially memoization/caching <mjw>My point is really that gcc really goes out of its way to make sure the debuginfo does not influence the (binary) output <mjw>See gcc -fcompare-debug <civodul>i know, but the daemon just sees a build process that takes inputs and produces outputs <civodul>it doesn't know what that "gcc" thing is ;-) <mjw>But can't it learn that some inputs can be ignored? <civodul>it's tempting, but it's also a slippery slope <mjw>aka, if you see this input "argument" then it simply means an extra output is produced (or not) <civodul>Eelco Dolstra (of Nix) had a notion of "equivalence classes" in his thesis <mjw>Then you can require packages to have a .debug output, but also allow a user to not produce it <civodul>yeah, but that'd actually be a fundamental change <mjw>ah, yes, I should remember when arguing about package inputs/outputs always come equipped with some Greek symbols and a proof :) <civodul>anyway, i found it fun to have this option of just rebuilding stuff to get debug info <civodul>it's yet another option, in addition to debug info servers and all <mjw>sorry for firs starting a debate on how to do it differently instead of saying "this is awesome and infinitely better than before when we didn't have anything!" <civodul>heh np, it's a natural reaction i guess! <civodul>this whole thing is pretty weird :-) <mjw>also I still don't have a good intuition for guix to be honest. Which is weird because it should be so simple f(input) = output <mjw>maybe it is too simple and I keep grasping for there being more to it :) <civodul>well, i think that makes it easy to reason about what's going on <civodul>but OTOH, it's also very different from what most people are used to <civodul>we're just very much used to thinking in terms of state-changing operations *apteryx pushes a fix for honoring --rounds when also using --check <apteryx>it was two returns to remove :-) (commit 0fa0e8df60) <Zambonifofex>mihi: Well, I did get past Grub, but it still stops soon after. <Zambonifofex>There are more messages above that image that have scrolled offscreen. <Zambonifofex>This is the command I used: `qemu-system-i386 -enable-kvm -m 1024 -device ahci,id=ahci -device ide-hd,drive=hd,bus=ahci.0 -drive if=none,file=guix2.qcow2,id=hd` <mihi>Zambonifofex, i would use piix3-ide or similar instead of ahci <mihi>not sure if that works on kvm, though (my host OS does not support KVM) <mihi>and yes, the error is most likely caused by your disk controller not being supported by the Mach microkernel <morgansmith>I'm trying to package a thing that uses the gid 65534 in it's tests for a group that doesn't exist. However, our environment.scm creates a group called overflow with that gid. I can't seem to invoke groupdel or modify /etc/group to remove the overflow group. Any other ideas? <morgansmith>I'm kinda upset I even have to deal with this. I'd think the ruby code their using for getting an empty gid would work. They do this: Etc.getpwnam('nobody').gid <cbaines>morgansmith, assuming your package is failing to build, I doubt that has anything to do with code in environment.scm <cbaines>have you got a link to the code, and can you share the error you see? <morgansmith>well it builds, but the test suite fails. Does the build environment not use environment.scm for the build environment? <morgansmith>ugh, I've never shared a snippet before, what pastebin should I use? <cbaines>but yeah, environment.scm is used for the `guix environment ...` script <apteryx>is someone using the mpd service? is it working? <cbaines>I think the relevant code for the build "environment" is in nix/libstore/build.cc <morgansmith>I use the mpd service but it disconnect from pulse/alsa every time I go to use it <cbaines>morgansmith, so, it looks like this bit Etc.getpwnam('nobody').gid evaluates to 65534 <cbaines>which makes sense, as that matches up with what the build daemon puts in /etc/passwd <cbaines>morgansmith, I think the problem comes when it runs effectively Etc.getgrgid(65534).name <morgansmith>cbaines: I don't quite follow. There isn't a group at 65534, but there is supposed to be one there? <cbaines>morgansmith, yeah, I think that's correct <jonsger>apteryx: hash mismatch, see my paste <pineapples>Am I the only person to not being able to 'guix pull'? Guix is telling me there's an error in a guix-daemon-1.1.0-30.5918cb5 derivation <apteryx>ah, and I must have that in my store, so it works for me, since I made that change *morgansmith is furiously copy pasting that comment <apteryx>jonsger, pineapples sorry, seems I goofed an update to the 'guix' package. I used 'make update-guix-package'. <dannym>pineapples: Nope, me too. It happens because the sha256 hash for the package "guix" is wrong. Not sure what happened, but Maxim Cournoyer updated it today. <dannym>apteryx: Yeah, I had problem with make update-guix-package for my own build today, too. It does some weird unintuitive stuff... <apteryx>hmm... guess I'll compute the hash via 'guix hash -rx' rather than trust 'make update-guix-package' for now <dannym>apteryx: Please file a bug to bug-guix@gnu.org about it. <apteryx>jonsger, pineapples try again, it should work <helaoban>hello guix: (...puts on dunce hat...): why is the /run/user/$my-uid directory missing on my system? I have elongid running... <morgansmith>cbaines: I went to go disable that test, but it's the only test. Also it checks against the nobody group a lot so it'd be a ton of work to patch. I guess I'm just disabling all the tests :P <helaoban>I ran into this problem try to run 'shepherd', which gives me: 'In procedure stat: No such file or directory: "/run/user/1000/shepherd"' <pineapples>apteryx: It's building guix-system.drv now, thanks *pineapples heads off since there's nothing else to complain about <cbaines>morgansmith, yeah, it's not ideal, but packaging it with the tests disabled is still better than not packaging it at all 
