<gnutec>terpri: I install retro because is the only one small. Editor has 130KB. <terpri>gnutec, now that you mention it, there is a bit of a strange correlation...counterexamples include: andOTP, AnySoftKeyboard, ConnectBot, K-9 Mail, Hourglass (and i don't really like AnySoftKeyboard that much, just the "least bad" free kbd i've found) <terpri>other than those all of the notably good apps i've installed do seem to be gpl or mpl <terpri>counterexamples of nongpl apps being terrible* <terpri>no emacs in f-droid yet, alas :) <gnutec>terpri: HAHAHAHAHA I think emacs need keyboard to be good. But GPLv3 apps are particularly great apps in f-droid. <bdju>you can run emacs in termux at least <bdju>but then you miss out on the benefits of the graphical version, like opening images <terpri>oh right, you can just install a terminal <terpri>but on my sony xz2 compact (<6" screen) hitting those control-meta-hyper-foo bindings might be tricky ;) *terpri pokes around the icecat package definition <hendursaga>So, I'm running guix pull and I only have one package in the manifest file, glibc-utf8-locales, but it's pulling say libssh and all kinds of other packages. What's going on? <hendursaga>Are those needed for Guix itself and that's why? <vagrantc_>building and/or substituting all the things guix needs for itself <vagrantc_>guix pull essentially does a git pull and then compiles guix ... so everything needed to compile guix needs to be available <NieDzejkob>libssh is used because of functionality like guix deploy and guix offload <hendursaga>Any Guix devs here have a PinePhone? There was a little bit of discussion, but so far there's only a NixOS build. <hendursaga>I have one, a Brave Heart edition, but I'm too new to this. ***vagrantc_ is now known as vagrantc
<jonsger>for the pinephone itself I guess you need a little different stack, because (AFAIK) the upstream linux kernel hasn't all the requiered functions. So you would need to add linux-pinephone and create a `u-boot-pinephone` package. Then you could create an image and flash it to a SD card... <hendursaga>I'm installing GuixSD. I figure going hardcore-mode might motivate me to learn Guix more :) <nojr>so, how can I fix a GIMP issue that it wont pick up plug-ins dropped into GIMP's .config folder? <terpri>repl/shell all the way, how else are you supposed to live-hack new features into guix at install time? ;) <terpri>nojr, this is guix's gimp package on a foreign distro? <terpri>nojr, and you've checked it's the right config folder for guix's gimp package (from preferences or lsof or something)? <terpri>nojr, also is this plugins in general or one particular plugin? (for example guix's version has python2 extensions enabled, but not python3 which i'd hope upstream is working on) <hendursaga>So, I installed GuixSD and it appeared the installation went well, it said it was complete and to remove the installation medium and press enter to reboot but it just sat there with a blue screen (not of death) and finally I just hard rebooted it and it went into GRUB, I inputted my encryption password, it boots, but then it asks for a password again, for /dev/sda, but it doesn't recognize my <hendursaga>keyboard and/or doesn't accept my password when I hit input. This is in early Guile boot. <hendursaga>What do I do next? I'm not sure how to debug this. <hendursaga>I'm assuming going into the GRUB command-line and/or setting some flags but I'm not sure what. <terpri>gnutec, if you mean the official android app, it's dangerously insecure and you shouldn't use it (regardless of the licensing). i can send you a link if that's what you mean, disregard if you're talking about a free client or something <terpri>a link with more info on the security problems* <gnutec>terpri: No. Is the official app. I have many of them. My smartphone has microsoft app that I can remove. So... <gnutec>hendursaga: Encrypt the /dev/sda? I don't do that. Is not necessary and I did have some problems when I used with Ubuntu. <hendursaga>gnutec: I used the guided installation and encrypted as one huge partition. <hendursaga>gnutec: Was I supposed to split it into two partitions, one for / one for /home?? <terpri>(that's about the android app for tiktok) <gnutec>hendursaga: No! I always do this configuration (/ and /home). In Ubuntu I did login and all. But some app could not access files because of that. I don't remember right now, but I don't encrypt my disk again. <hendursaga>You don't encrypt at all? I'm afraid that'd be a deal-breaker. <hendursaga>Anyone here got an encrypted installation to work? <apteryx>hendursaga: full disk encryption (including /boot) is supported <hendursaga>apteryx: So where did I go wrong? How do I debug and fix this? <apteryx>hendursaga: the first password (for GRUB) will use the US QWERTY keyboard layout, but after that (2nd password for booting the kernel Linux) it will use whatever keyboard layout you have defined in your OS config. <hendursaga>Thing is, even pressing return doesn't do anything. <apteryx>hendursaga: that's strange. Have you tried another keyboard? Mine acts weird at boot time, because it includes some USB hub that messes things. <hendursaga>I've tried two USB keyboards, stilll nothing. And no, this isn't a laptop. <hendursaga>And I've connected them to both the back and front USB ports. <apteryx>Well I don't have much of an idea, but I guess you could try from a live USB (it can be your Guix System installation image on a USB key) and see if you can successfully cryptsetup unlock the drive. <hendursaga>OK..? I'm not entirely sure what the cryptsetup commands would be though :/ <apteryx>but we already know it is because GRUB is able to unlock it <apteryx>hendursaga: it would be 'cryptsetup unlock /dev/sdX some-label' <apteryx>then you can try 'mount /dev/mapper/some-label /mnt' <hendursaga>Also, what IS the difference between the first and second passwords? Like, what do they unlock? <apteryx>if you have a single drive, yeah, that's probably how it shows up. <gnutec>terpri: I think all apps collect data, because you have to create a account. When I install tiktok, it ask me if I'm male, what I like to see. I don't created an account. <apteryx>the first one is GRUB unlocking the drive to know what it contains (e.g, looking for /boot). The second password is triggered when Linux from the initrd tries mount the root file system (someone correct me if I got this wrong). <gnutec>terpri: The app cannot access my device without my permission since android 6 I think. So, I see not problems. <terpri>gnutec, read the links. it vacuums up all the data it can get from your system, reports your location every 30s under some circumstances, tries to foil attempts at reverse engineering, can download and execute arbitrary code, etc. etc. etc. <hendursaga>apteryx: I booted into the installation medium and am at the root shell. It says cryptsetup unlock is not an action? <terpri>"everything network-related" (wifi network info, for example) is probably enough to personally identify you if you're just using it in your apartment/house, account or no <apteryx>yeah, I confused the action with udisksctl unlock ;-). It's 'open', sorry. <apteryx>yeah, luksOpen is the old (still supported) syntax <hendursaga>OK, I got it mounted. It looks like a Guix installation. Now what? <apteryx>at least we know the LUKS part is alright. <apteryx>Perhaps your keyboard layout is different at boot than what you expect <hendursaga>Why exactly would that make a difference in whether return works or not? <hendursaga>Is there any other key combination that might do something? ctrl-alt-f<whatever> or something? Anything to tell me the keyboard works? <apteryx>hendursaga: IIRC you won't get any visual feedback of whether return works or not from the LUKS prompt at this point <apteryx>right, this would be shown at least, and prompt you again for like 3 times before giving up. <terpri>gnutec, even if you don't care about privacy in the least, the fact that they can apparently download and run arbitrary binaries on your phone should give you pause from a security perspective <terpri>(what if they get their hands on an android 0day?) <apteryx>hendursaga: hm. And those 2 keyboards you tried are basic USB keyboards, right? <hendursaga>Yeah. They've worked for anything and everything else I've used them for. <terpri>anyway, i'm just forwarding links, it's your decision whether to trust them or not <hendursaga>There's no hope for using say SSH at this point, no? <apteryx>hendursaga: would you mind sharing your os config? Perhaps something in the way you defined your keyboard layout <terpri>my friends don't use tiktok, so unlike the popular american proprietary social networks, it's a non-issue for me personally <hendursaga>I think I recall something like /etc/config.scm or something.. <apteryx>hendursaga: if you've used the graphical installer, yes, I think it's supposed to produce a file at /etc/config.scm <hendursaga>apteryx: I'll get to it tomorrow. I'm a bit too tired to think straight. <terpri>apteryx, that's correct (re: double-entering passwords) iiuc <terpri>there are workarounds, but they're complicated enough that it's always been easier to just type the passphrase twice :) <gnutec>terpri: "run arbitrary binaries on your phone". Android, since 6.0, has a SELinux, a Mandatory Access Control. So no app can run any other app or read file without permission. <apteryx>hendursaga: sure! good luck with your install, have a good rest! <gnutec>terpri: I think all this worry is a fake news. What business do with our data depends of law in each country. <terpri>gnutec, selinux isn't a magic bullet. anyway, this is increasingly off-topic. enjoy running whatever software you'd like on your computers <terpri>too much trouble for me, maybe worth trying for slow typists ;) <gnutec>I just create a account with my cell phone number and a see something missing. I can't use [space] in my password. <terpri>gnutec, if you read the links, a secondary concern is that the overall implementation appears to be complete garbage. so weird limitations on passwords aren't terribly surprising <terpri>gnutec, imo you should find a different channel for tiktok tech support, since it's nonfree and has no relationship to guix (and is unlikely to, unless someone writes a free client or something) ***sneek_ is now known as sneek
<Kimapr>do we have torbrowser yet? i can't find it with guix search <Kimapr>hmm, also chromium throws a ERR_SSL_PROTOCOL_ERROR at me when i try to access torproject.org through https and "Object not found" with http <Kimapr>> curl: (1) Received HTTP/0.9 when not allowed <mroh>yay, finally, I have a lvmcache on / => happy ;) <janneke>Kimapr: we do have a tor service that can be used with icecat... <mothacehe>janneke: the CI successfully built the first Hurd image, I'm updating the website. <PurpleSym>Is it somehow possible to `guix download` a local repository at a specific commit into the guix store. <janneke>civodul: some of it may be trivial, but the "sqlite/hurd" and guile-sqlite patches are too "scary" for me to just push <janneke>civodul: also...rekado is still having troubles with "herd start chilhurd", only manually starting qemu works in berlin; really weird <rekado_>the childhurd does start but I can’t connect to it via SSH <rekado_>it’s the same on the other build nodes <nckx>raghavgururajan: Ouch. What happened? <efraim>Idea on the childhurd issue, does qemu have propagated inputs? PATH issues are normally my problem with custom services <civodul>PurpleSym: "guix download" only downloads files; it cannot do 'git clone' for you (yet) <PurpleSym>Hm, ok. Can I do this via `guix repl` civodul? I’m trying to manually call git-fetch. <janneke>efraim: interesting...but no, qemu doesn't have propagated inputs <civodul>i'll take a look but it's a busy week for me <civodul>PurpleSym: 'git-fetch' simply returns a derivation, and it's that derivation's build process that actually clones <PurpleSym>Building packages that have a non-public repository URL. So I thought I could simply import a local checkout into the store. <civodul>perhaps (git-checkout ...) would work well for you <civodul>it clones the repo on the client side instead of doing it in a derivation <PurpleSym>Ah, you mean using that instead of (origin …)? <PotentialUser-25>Hi, where is the best place to get help installing guix? On arch, I've hit an error with installing either "guix" or "guix-git" from AUR: <rekado_>PotentialUser-25: we are not maintaining the package on AUR. We recommend installing with the provided installer script. <PotentialUser-25>re: running out of memory, not sure (how can I tell?) but this is a laptop with 16GB RAM, and the machine is fairly quiet. <rekado_>with 16GB RAM it’s indeed unlikely that you ran out of memory <ArneBab>janneke: should the hurd service already be available in the regular guix? <raghavgururajan>nckx: I deleted a branch that had commits which I did not format-patch yet. But `git reflog` and `git checkout -b <branch> <hash>` helped me. <nckx>git reflog is a life saver. <nckx>It's reasonably hard to lose data in git once it's been committed, assuming you haven't gc'd in the meantime. Glad it worked out. <PurpleSym>civodul: Oh, there seems to be an easier way: `guix build --with-git-url=package=/path/to/local/repo …`. Strangely `-S` fails with a pattern matching error. <civodul>PurpleSym: yeah --with-git-url uses git-checkout under the hood ***lukedashjr is now known as luke-jr
<rekado_>re childhurd: today I want to take some time to investigate why this is failing <ArneBab>3953 qemu-system-x86_64 -machine pc,accel=kvm -cpu max -smp 6 -m 4096 -hda debian_wheezy_amd64_standard.qcow2 -nographic -net nic,model=virtio -net user,hostfwd=tcp::10022-:22 <mothacehe>janneke: the doc also mentions the "--hda" option, while it's shouldn't right? <ArneBab>explicitly adding (net-options '("--device" … "…2222…")) is not honored — could that be connected? <ArneBab>… I’m not sure whether my qemu is actually the hurd, because herd stop childhurd does not stop it <janneke>ArneBab: from where do you get the "::10022-:22" bits? <janneke>ah, well ... yeah, you're looking at another qemu: qemu-system-x86_64 <ArneBab>how can I detect whether the hurd is really running? How do you login with ssh? <janneke>that's not hurd; also "(net-options ...) in gnu/services/virtualization.scm uses ::10022-:2222 <janneke>ArneBab: mine looks like this: /gnu/store/hw6gysdjdv97nda59r2s8i3xlly4750v-qemu-minimal-5.0.0/bin/qemu-system-i386 --enable-kvm -m 4096 --device rtl8139,netdev=net0 --netdev user,id=net0,hostfwd=tcp:0.0.0.0:10022-:2222,hostfwd=tcp:0.0.0.0:15900-:5900 --snapshot --hda /gnu/store/n9gzbgy7d3dx40y9kf7s65pb5lvzcaf2-disk-image <ArneBab>but herd knows about the childhurd service <janneke>ArneBab: what does "herd status childhurd" say? <janneke>if it shows you a PID, try: cat /proc/PID/cmdline <ArneBab>"it is started. Running value is 9973. … <janneke>chances are it won't start because you already have port 10022 occupied... <ArneBab>ssh localhost -p 10022 asks me for a login <janneke>ArneBab: root@localhost? -- it should also say something about the ssh host key, no? <mothacehe>that's just a bunch of HTML, credit goes to janneke :) <janneke>mothacehe: yeah, *cough* wip-disk-image *cough* explosive branch mixture *cough* right :) <alextee[m]>is this more improved than the april 1st version now? <civodul>alextee[m]: it's the July 6 version, no cheating this time, the real thing! <civodul>it's a Guix System image cross-compiled from GNU/Linux <rekado_>hmm: guix/ui.scm:1953:12: In procedure run-guix-command:\nWrong type to apply: #f *janneke boots iavbgap image <rekado_>janneke: I think I found the reason why I can’t log in. <rekado_>well, perhaps just *one* of the reasons… <janneke>rekado_: ...okay, is that good or bad ;) <rekado_>it’s always good to find something fishy <rekado_>even if it fixing it doesn’t solve the problem *janneke just heard some ominous message echoing... ***cjpb0 is now known as cjpbirkbeck
<zimoun>civodul: well, the logs of #swh-devel does not seem available. )-: Do you think you will have time to review #42019. Otherwise I could provide them another URL for testing their listener. ***cjpb0 is now known as cjpbirkbeck
<civodul>zimoun: guix.gnu.org/sources.json should be updated within a few minutes <zimoun>civodul: cool! thank you! I am going to keep them in touch. ***cjpb0 is now known as cjpbirkbeck
<rekado_>hmm, looks like the Hurd VM doesn’t reliably boot. <rekado_>I added -curses to the qemu command to see what it’s doing and it gets stuck <rekado_>last thing it prints is ‘start ext2fs: Hurd server bootstrap: ext2fs[device:hd0s1] exec’ <janneke>rekado_: ah, something to inspect at last! <janneke>rekado_: have you tried several times, ext2fs startup is known to hang at times <rekado_>I think it may be just that. No weird interaction when running with shepherd. Just random hanging. <janneke>rekado_: ugh, but /much/ more frequent than i experienced it..."interesting" <janneke>something to take-up with the people in #hurd i guess ***rekado_ is now known as rekado
***cjpb0 is now known as cjpbirkbeck
***cjpb0 is now known as cjpbirkbeck
<hendursaga>Good news! I tried a third keyboard and it finally recognized it. <janneke>that must be handy, a working keyboard :-P <rekado>when I add ‘(service hurd-vm-service-type)’ to my list of services and reconfigure, all I get is an unhelpful error: ‘Wrong type to apply: #f’ <rekado>it reconfigures fine without that line <civodul>has anyone tried obs with ratpoison or similar? <civodul>warning: xcompcap: Unable to query window list because window manager does not support extended window manager Hints <civodul>mothacehe: too bad, it bothers me to switch WMs just for that <civodul>otherwise i can do simplescreenrecorder + something for audio <civodul>any recommendations for audio recording? <civodul>slightly higher-level than "cat /dev/dsp", but lower-level than Audacious? :-) <janneke>mothacehe: could that be a "let-system" issue? *janneke wants to cry... all hurd code breaks <mothacehe>operating-system-default-essential-services now calls operating-system-directory-base-entries which calls operating-system-boot-parameters-file which calls operating-system-boot-parameters. So %current-target-system was evaluated before being set. <rekado>mothacehe: your commit seems to have fixed it. It’s reconfiguring now. <mothacehe>Relying on operating-system-hurd being set, like in other places of (gnu system) does the trick. <rekado>I want to see if I can reproduce the boot freezes of the Hurd VM on my laptop; maybe it’s only bad on systems with new / big CPUs? <zimoun>civodul: what would be your suggestion to generate this sources.json for all the Guix history? Follow the commit parent, rebuild the guix-packages.drv? Other? <rekado>apteryx: I had the same problem. Run ‘guix pull’ and try again. <rekado>interesting news: I disabled KVM acceleration on berlin and for the third time in a row the Hurd VM booted without freezing. <rekado>perhaps this is a race condition that is especially bad on fast CPUs ***familia_ is now known as familia
<rekado>also no freezes with KVM enabled and ‘-cpu base’ <efraim>to me that sounds better than no KVM <rekado>I’ve restarted the VM four times and it worked reliably so far <rekado>before that it froze maybe 3 out of 4 times <rekado>so… next step is to find a way to keep the host key <janneke>mothacehe: oh great, thanks for the fix -- much better, also! <janneke>rekado: what if we generate it once and copy it in from the outside -- we also need to do something like that for the guix signing key? <efraim>would it be a terrible idea to copy the hosts' key into the container? <efraim>I guess it should be s/hosts'/host's/ , it's the host's key even though its on multiple hosts <lispmacs[work]>nckx: hi, I was doing another install where I needed to run guix pull because a Guix package on the ISO is broken. What again exactly was the commmand in needed to reconfigure system onto the mounted directory? <zzappie>lispmacs[work]: I maybe missing the context but it looks like youre looking for `guix system init /path/to/config.scm /mount/point` <zzappie>I've coded myself into a strange situation today. What I did is I tried to spawn a virtual machine with `guix system vm -f guix.scm` but in that file I've replaced the operating-system-packages record field with pckage definition build from local source tree <zzappie>but when I try to import the guile module provided with this pckage in one of the services gexps it can not load it <lfam>zzappie: Can you give more detail about what you tried and how it failed? From what I can tell, `guix system vm` doesn't take an '-f' option <zzappie>lfam: oops yep I ran it without '-f' option <lfam>It sounds like Guix isn't finding your custom package definition when you run the command <lfam>Does that sound right? Did you do anything to address that? <lfam>The `guix system vm` command requires the name of a file that contains an operating system declaration <lfam>Your guix.scm file doesn't define an operating system <zzappie>bigchaindb-node is that os declaration <lfam>Alright, it's a bit beyond my skills then <lfam>I don't really understand it but it looks like you imperatively change the package for operating-system-packages, but no in the services <lfam>I'm not much of a Schemer so I can't really say but that's my hunch <zzappie>lfam: Yes I basically swap one package with another which is build from local sourse tree. This id definetly results in store item that gets shared with virtual machine. Then I import this moudule in service-activation gexp so my guess was that it should be staged for execution inside the vm *zzappie This id -> This is <lfam>My point is that you didn't swap the package in the context of the operating system services <lfam>If I understand correctly... <lfam>Most services accept a 'foo-package' argument where you can swap out foo <zzappie>lfam: sorry I didn't get what are you refering to by foo-package... <lfam>For example, the openssh-service-type is configured with the openssh-configuration record. This record has the parameter 'openssh', which accepts a package variable, and you can use this parameter to change which openssh package is used by the service <lfam>Check the file 'gnu/services/ssh.scm' in our source tree <lfam>If you were to change swap out the openssh package in operating-system-packages, would it also affect the the package used by the openssh-service-type? I'm getting out of my depth but I think the answer is "no" <zzappie>lfam: aahh yeah now I get it. Thank for the hint. I have for some reason assumed that if I'll include the package containing guile module in os packages it will be available for importing is service activation gexp. That was stupid :) <NieDzejkob>What's the workflow for hacking on package definitions in a channel? i.e. what do I do instead of pre-inst-env? <efraim>NieDzejkob: I do ./pre-inst-env guix build --no-grafts -L /path/to/channel my-custom-package <efraim>if the channel has other channels as dependencies then you need to add them also with -L /path/to/other/channel <roptat>I'm having an issue with an mcron job I'm trying to run <roptat>I want to run "make" in a directory to update some stuff and put them on a website <roptat>I've looked at the generated mcron task and it basically is /gnu/store/...-make-4.3/bin/make -C /the/directory update <roptat>which I can run in any directory, and it runs the "update" target of the makefile <roptat>In the log however, this is what I get: -C: *** No rule to make target 'update'. Stop. <roptat>I tried with --directory=/the/directory too, and this time the message is: directory: *** No rule to make target 'update'. Stop. <roptat>how does mcron run the command, and how can its environment be so different that the exact same command works outside of mcron, but not from mcron? <efraim>I guess try running it in a pure environment to best test what happens inside a service <roptat>inside a pure environment with no package, I get an error as make tries to execute the update target <roptat>because it can't find some of the programs I need <roptat>but that made me realize the environment from the cron task is probably not the best to run the makefile, because it'll be missing stuff <efraim>made it past the build phase for librsvg@2.48.8 <lfam>roptat: I don't know about mcron but the environment of Debian's cron is totally different from a normal environment <lfam>You basically have to wrap your command in a script that creates the environment, and let cron run that script <civodul>sneek: later tell zimoun thanks for the update re SWH! i'm not sure how to deal with history <NieDzejkob>roptat: that looks like an off-by-one in the argv being passed to make <NieDzejkob>like, normally you'd have argv[0] = "make", argv[1] = "-C", and here it's argv[0] = "-C" <roptat>alright, that was it! thanks so much <lfam>dissoc: In most cases you won't have to do anything except use the python-build-system and add the required dependencies <lfam>You should take the sources from PyPi if they exist there <dissoc>I dont understand what you mean by taking sources from PyPi <lfam>pypi.org is the canonical location for Python source code distribution <lfam>Check existing Guix packages for the string 'pypi-uri' <lfam>So, you'll make a package definition for this program, using the python-build-system. It will probably fail to build due to missing dependencies. Keep adding them until it builds successfully and then test the program <lfam>This is the basic workflow <dissoc>gotcha. there's a setup.py file with intall_requires from setuptools. im guessing I just pull those in from guix packages <dissoc>okay. seems fairly straightforward. i was just unsure where to start. thanks for the help <lfam>Let us know if you get stuck <lfam>Python packaging is usually straightforward but sometimes there are some wrinkles <efraim>I didn't find it with a couple 'guix import pypi nanovga-saver' searches. also hopefully the pyqt5 doesn't give you too many problems <dissoc>i guess the other thing im not sure about is that you run this program by a command 'python myapp.py'. so if you were going to install this app would it be best to create a script named 'myapp' that executes the full command? <efraim>8 minutes for the build phase for librsvg-2.48.8 on bayfront vs 27 on my machine :/ <lfam>dissoc: I would deal with that after you get it building. It's possible (and desired) it will build a compiled program, not a script that must be interpreted every time you need it <lfam>In any case, the python-build-system should handle it <dissoc>okay will do. i'll also take a look at the python-build-system code. it will probably help me understand it a bit more <zimoun>Hi, I am running a tiny script to test the SWH coverage, using an ugly (slepp 31) to avoid to reach the rate limit fixed at 120 request per hour. So it takes ages. :-) I am a bit surprise because lookup-content returns often for url-fetch which means the tarball is reachable. However, I am surprised because almost all the git-fetch already tested are not reachable. Using the Data Service, I am only able to get no lint warnings. <sneek>zimoun, civodul says: thanks for the update re SWH! i'm not sure how to deal with history <zimoun>Where and how can I see the lint logs? On Cuirass? <civodul>zimoun: you should collect examples of git commits not archived so we can investigate them <civodul>as for tarballs: tarballs are archived as-is only by accident, for instance if a git repo contains the tarball <civodul>sometimes archival eventually fails, but we don't see any details <civodul>so if that happens in the next 10mn or so, you could ask on swh-devel for details :-) <zimoun>I think I did for sway, because I linted it to see what happens. :-) <civodul>i wonder if there's a thing like if you add ".git" to the URL archival fails <civodul>last i looked at it it seemed plausible <zimoun>Yes, but sway should be queued when it was updated. It is weird... <zimoun>Based on your small script for gforge.inria.fr, I added (sleep 31) to avoid the rate limit and so the script is running. So I can provide you a lot of non reachable git-fetch examples. :-) <civodul>yeah so just monitor the URL above and if one goes into "failed" state, report it to the SWH folks <civodul>i also noticed that things not on git{hub,lab} are more likely to be rejected (which is kinda ironic) <civodul>well, no figures, but that was my impression <vagrantc>could use pristine-tar and inject all the tarballs into a git repository and then have SWH mirror that ... <civodul>or just inject all the tarballs directly :-) <zimoun>I think they validate by hand the request. Maybe that's why. <vagrantc>or rather, inject one lineage of tarballs (e.g. project-a-v0.tar.gz, project-a-v1.tar.gz, etc) <civodul>i think we'll rather try to work with them <civodul>we could start the Reproducible Tarballs project <civodul>pristine-tar is nice, but it's all binary <zimoun>My goal is to provide some stats: how many url-fetch packages are currently reachable? And in the same time, guix lint is in-place since a couple of months so it seems (at least to me) to evaluate how many packages are archived this way. For example sway is not, so there is an issue from our side or their. <zimoun>pristine-tar is full of bugs :-) <civodul>zimoun: the archival checker was added in Aug 2019 <zimoun>vagrantc: yeah for sure. :-) But I am not sure it could do the job before fixing some bugs <dissoc>lfam: I was able to get the package to work. although the tests failed to run but everything installed after i disabled tests in the build <lfam>Great dissoc! If you want to add the package to Guix, we'll ask you to try to get the tests to work. If the test suite is not suitable for Guix for some reason, please add a code comment explaining why they are disabled <dissoc>i dont think a test actually failed. just that the tests failed to even test. i will have to dig a little into it <zimoun>civodul: back to my initial qestion. The lint logs are they available on Cuirass? If yes, how can I read them? <civodul>zimoun: cuirass doesn't run 'guix lint'; the Data Service does, but it does not run network-dependent checkers like this one <zimoun>civodul: thanks for the explanations. So I understand why some are not in. Today, it is up to the packager/commiter. <zimoun>do you know if there is a rate limit with their API for queuing? <zimoun>civodul: well the discussion you had on #swh-devel about tarball is pretty clear. https://forge.softwareheritage.org/P716 I am interested to know what you think could be the next step on Guix side: Tarball cache, archive and fallback to something like "guix build -S" instead of upstream, etc. <nckx>NieDzejkob: Oh, I disabled that since it wasted CPU cycles for questionable benefit. That ‘API’ in general is barely maintained, kept alive to support some of my scripts, but I should remove those public links. Thanks. <civodul>zimoun: in the short term, we should archive tarballs at home, like we're doing, but with an infinite TTL or something <civodul>longer term, we can find a way to reproduce tarballs from tar headers + files <vagrantc>you could also unpack the tarball and then hash it's contents like done with git checkouts <civodul>yes, but it's not the same hash method that SWH uses <vagrantc>then the intermediary hash of the actual tarball doesn't matter... <civodul>SWH uses git-tree hashes, whereas we use nar hashes <civodul>so another option is to switch the daemon to use git-tree hashes, or both <civodul>there are a few options, but none is really simple <vagrantc>the difference in hash is just how to look it up on SWH? <zimoun>except hold all the tarballs at home :-) <vagrantc>just do individual files and forget the tarballs ... :) <vagrantc>the (source) entries for packages would get a bit tediuous... <zimoun>civodul: thanks. Well, this story seems far from ended yet. :-( <civodul>likewise i think we can't use IPFS, even for plain files, because of different hashing <civodul>we couldn't just do lookups by sha256 it seems