<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*
<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>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: 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>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
<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)
<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?
<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>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>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
<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 :)
<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>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.
<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.
<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
<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