***Server sets mode: +cnt
<dustyweb>it's not easy for me to tell under what circumstances a user is vulnerable <apteryx>guix refresh: error: mkstemp!: Read-only file system --> Is this an old bug? <apteryx>oh, just I'm dumb; I must use ./pre-inst-env to be able to modify the guix sources ;) *civodul prepares to switch the OverDrive to GuixSD <laks>Hi All, I'm Lakshmi and I just finished the verification process for the communication channel for GUIX. So just trying to send a new message and see if its all good :) <sneek>laks, thomassgn says: I think wicd was changed for networkmanager, I'd check the sources. <civodul>efraim: did you try our current 4.18.4 kernel on aarch64? <efraim>civodul: to build it or to use it? <efraim>I'm not having a lot of luck with binutils' gold linker, keep on getting an error during the test suite about '-lugins', upstream thinks its a sed error and is supposed to be '--plugins' <efraim>I assume once we have that fixed we can have working go on armhf and aarch64 <efraim>i just saw x265 failed on armhf on master, no idea what's going on there <civodul>lemme know if you spot anything wrong <civodul>for the ttyAMA0 config, i mostly copied what openSuSE already had <efraim>if you're running on btrfs you'll want a balance cron job to keep the disk from filling up <efraim> (string-append #$btrfs-progs "/bin/btrfs balance start -dusage=50 -musage=70 /"))) <efraim>I think you also want a /boot (or /boot/efi) on vfat <nixo_>Hi, my 'guix gc' is failing with 'error: build failed: executing SQLite statement: FOREIGN KEY constraint failed'. I saw on the irc log that i'm not the only one but could'nt find a way to solve. guix gc --verify doesn't fix it <efraim>you also don't have any swap, and btrfs doesn't support swapfiles <civodul>nixo_: that's usually a bad sign, is it a recent install? is the hard disk OK? <civodul>efraim: the openSuSE install has /boot on /dev/sda2, but i guess we don't need that separate partition <efraim>I'm not sure if the separate /boot is needed, I have it on my laptop though <nixo_>civodul: yes it's installed from 2 weeks, but I have this problem from near the beginning (at my first gc after 3 days), I hope the hd is fine, but it's btrfs so who knows XD <nixo_>civodul: I'm checking the store manually, all paths in `sqlite3 /var/guix/db/db.sqlite 'select path from ValidPaths'` exists <roptat>is it possible to differentiate native-inputs from other kinds of inputs in a build phase? <roptat>for npm packages, there is a way to keep a dependency to inputs by creating a symlink to the store item of the dependency <roptat>which is nice because it allows us to run a node script directly from the store <roptat>but it'd be nice to do that automatically and we don't want to keep references to native-inputs (for instance a test framework) <roptat>currently that's done by looking at every input, but that includes native-inputs <civodul>roptat: it's possible to differentiate them but only when cross-compiling <civodul>we'd need to run the SQL statements at the prompt to see what happens... <roptat>civodul: ok, maybe I can try and look at the package.json file to know which dependency I really need at runtime <civodul>but note that the gc scans the result upon completion to determining the residual references <civodul>so i'm not sure you need to do something manually <nixo_>civodul: uhm.. So the way to go should be to boot from usb and re install with the same configuration? <nixo_>I had to do it a couple of time with nixos and worked, but I don't want to :D <civodul>nixo_: yeah that sounds really bad but it looks like the database is corrupt or something <nixo_>it contains the db.sqlite (guix_db.sqlite) and ls -lah /gnu/store (gnu_store) <roptat>civodul: what do you mean? right now I get references to the native-inputs included in the output <roptat>and I don't want that, because these native-inputs could be very big <nixo_>if firefox send won't work with libreJS I can put it on my nextcloud, let me know <civodul>i tried "pragma main.integritycheck;" which turns up nothing <civodul>efraim: what does the balance thing do? how frequently should it run? <civodul>nixo_: does "guix gc --list-dead" work? if it does, does "guix gc -d /gnu/store/SOMETHING-DEAD" work? <efraim>it takes partially used block groups and combines them together, allowing free space to actually be free <efraim>dusage is for data, musage is for metadata <efraim>I run mine daily, it takes under 5 minutes <nixo_>civodul: have a nice lunch (guix gc -d works, is just guix gc that does not.. ehm) <civodul>nixo_: what if you run: for i in `guix gc --list-dead`; do echo $i && guix gc -d $i ; done <civodul>that might allows us to identify the faulty entry <nixo_>first failing: `/gnu/store/8a213jvfzafcf6mfny2hs2jb1ya94i92-grub-image.png` <civodul>yeah actually that won't work, we'd need to sort them topologically first <nixo_>also fails: `/gnu/store/yl5wpd2gl5fj791iqhwg4a49k5n3abmv-grub-2.02` but that's all <civodul>do you have a Guix checkout where you could build guix-daemon? <civodul>if you do, then you could run this guix-daemon (which contains debugging symbols), and then attach gdb to it <nixo_>I cloned the guix repo, something like this? `guix package -L git/guix -i guix-daemon` <Kate18>I am an outreachy applicant, and I'd like to participate in "Create user video documentation for GNU Guix" project. Where can I find tasks for newcomers? <Kate18>I only see bugs for programmers now. <roptat>I think a good first step is to install guix on a foreign distro or guixsd on bare metal or a VM <roptat>you should also take note about the installation process, since that will be very useful for the project <roptat>then, a very good first contribution is to add a package to the distribution <roptat>I've read that R packages are especially simple to add because we have an importer, but I've never packaged a R package myself <roptat>if you need help on any of these tasks, don't hesitate to ask for help here or on the mailing list ;) <nixo_>rotpat: I tried with emacs packages from melpa (ther's an importer for it too) and it is really simple, the importer does 95% of the work <nixo_>but I found little documentation on how to actually install the code generated by the importer (that's the 5% i needed to do manually), so something that documents it would be useful IMHO <civodul>like roptat wrote, adding a new package or updating/modifying an existing one is a good first contribution <civodul>and of course you can ask for guidance on this channel <civodul>did you manage to get Guix up and running on your machine? <Kate18>civodul: Tanks. Could you also explain the purpose of the project? Should those videos be for beginners? <civodul>Kate18: yes, those videos should be about using Guix for specific tasks ("managing" software, setting up a development environment, etc.) <civodul>they should target people with some knowledge of GNU/Linux who do not know Guix and are not experts in the field <civodul>so yes mostly beginners, but with some experience of the command line <civodul>the "development environment" use case would obviously target developers, but again we expect them to know nothing about Guix itself <civodul>g_bor[m], rekado: feel free to complement or correct :-) <civodul>efraim: strace fails to build on aarch64: "configure: error: Cannot enable m32 personality support" <Kate18>civodul: I want to explain. Right now the possible contributions for the video/scripts/documentation making project are installin Guix and Making a package. But the project is about making stuff available for beginners. So, the question is - what is the goal of the project and how applicants will be assessed since there is no explicit requirement about making scripts available for users or about making videos with subtitles? <civodul>Kate18: we thought about using and making small contributions to Guix as good first contributions because making those introductory scripts and videos will require some knowledge of Guix and the "big picture" <civodul>i see this can be surprising that the first contributions are more "developer-oriented", so to speak <civodul>but for us it's more of a way to get started understanding what Guix is about <Kate18>civodul: I fully agree. I was just concerned about my efficiency. For example, right now I can't compete with other people because there is no criterion. For example, I can use ffmpeg and po4a for subtitle translation, make short and meaningful subtitles. But does it matter? Or should I build more packages? <efraim>civodul: I can take a look later, aarch64 doesn't support '-m32' or '-m64' <civodul>Kate18: it certainly matters of course, and that you can use these tools is very important to us <civodul>as for building packages, i think what we care about is that you can use Guix yourself and have a feel about what it does, what's special about it, etc. <Kate18>civodul: thanks, though I like guix I won't participate in the project - it is not clear how to make a better contribution. Maybe it would be better to make a prerequisite - knwoledge of guix and a contribution task to be reworking a peace of documentation into a script. *rekado is back after two long meetings <civodul>rekado: thoughts about what Kate18 wrote above? <civodul>oh and this reminds me i'll be at a stupid seminar all day long tomorrow :-/ <rekado>I agree with what you wrote, though: the point of the first contributions is to make sure that the intern gets exposed to the documentation as they try to get started. <rekado>Packaging something is the best way of getting to know many of the parts of the system and the community infrastructure (mailing lists, IRC, etc) <rekado>it also serves as a git exercise, which will be useful throughout the project. <civodul>though i wonder if we sould have added something that exercises the video/script skills <civodul>not sure exactly how that could work, though <rekado>we don’t really need any existing video processing skills, I think <rekado>a useful video could be little more than a narrated slideshow. <rekado>the first thing we need is the “story board”: what to show, when, and with what narration. <rekado>compiling this as a video is very simple: ffmpeg takes all the “slides” and a text file of durations, and it produces a video. <rekado>that video can be merged with an audio file: a reading of the narration text. <rekado>we don’t even need to have the intern produce the audio file – that could be left to other people <rekado>(e.g. those with a good microphone and/or those with clear pronunciation) <rekado>getting from nothing to a set of video ideas, and from there to clear story boards for each of the video ideas, and to narration texts — that’s the biggest part of the project. <rekado>“nothing to concrete ideas” requires knowledge of Guix features, so using it and reading the blog posts is a precondition to good work. ***siraben[m] is now known as siraben
<civodul>what we're asking for may be the right thing after all <jonsger>nice, I got guix working on openSUSE Tumbleweed build with guile2.2 :) <civodul>rekado: BTW, i tried to package the "lm" (Latin Modern fonts) texlive package <civodul>problem is that it contains only METAPOST source <civodul>and so i'd need METATYPE1 to create type1 fonts (which i need) <civodul>do you have experience with these things? <civodul>efraim: news from the front: grub-efi-2.02/sbin/grub-install: error: efibootmgr failed to register the boot entry: Unknown error 65535. <Digit>good god, what have i done. :.G the horror. i've upgraded firefox. not in guix. no rollback from this nightmare. <efraim>civodul: I have strace building on my aarch64, waiting for it to pass the tests to push it <apteryx>civodul: I have a local package of ttf2pt1 that I've yet to push; could that help? (it would if that METATYPE1 can be converted by TTF) <apteryx>hmm, reading about METATYPE1, I'm afraid not ;) <civodul>apteryx: i actually added ttf2pt1 not long ago! <civodul>it doesn't help here though, because all i have is METAPOST <civodul>efraim, vagrantc: the weird thing is that efibootmgr actually exits with 0 (when i strace it) <apteryx>civodul: oh, good to know :) I'll be curious to compare our ttf2pt1 package definitions <mbakke>civodul (IRC): I'm getting a merge conflict on guix/self.scm on core-updates between 8bece84022752b635b28dba0b051d215bcc19fab and 099bb0175f681e5f68dafb8ad973866f31fe515c. <mbakke>Am I correct in understanding that the first should "win", i.e. #:guile-version (effective-version)? <mbakke>Derp. Not effective-version, but "guile-version". <civodul>mbakke: around line 920, it should be #:guile-version (if (>= pull-version 1) "2.2" guile-version) <civodul>so basically what the second commit does, but without the "2.2.2" special case <Digit>the grass sure looks greener over in guixland. <roptat>for my ocaml update, after updating ocaml, adding ocaml-4.02 and a few things, I need to patch almost every package <roptat>some updates, some new inputs, ... <roptat>is it ok to send a big patch (> 4K lines), or should I send multiple small patches? <bavier>roptat: if the patch is atomic, I think it should be fine <bavier>roptat: e.g. corresponds to a single commit <roptat>well, I'll send a lot of small patches :p <roptat>it corresponds to multiple packages, but that's only fixing things after updating ocaml <roptat>they fail for different reasons: they lack ocamlbuild, or they aren't compatible so I need to update them, and other things <bavier>imo, fixes like that should be committed together with the update that prompted the fix <roptat>I don't know, some fixes are non trivial <roptat>and some packages use a completely different build system now <bavier>well, I suppose we can decide once we've seen that patches then <roptat>I've started splitting the big patch in multiple patches, so I'll send them to the mailing and see what people think then <jonsger>bavier: thanks for those guile2.0 patches. They brought guix on openSUSE back to work :) <civodul>efraim, vagrantc: alright, i got past that grub-install issue; any recommendations before i type "reboot"? :-) <civodul>so, kernel boots, but hard disk isn't detected <vagrantc>civodul: my guess would be some specific driver module <mange>Is anyone using channels to pull from git repositories that need authentication? I'm getting "guix pull: error: Git error: authentication required but no callback set", and can't see any obvious way to fix that.