Re: Staging branch [substitute availability armhf-linux]
Sorry, I forgot to attach that config.(use-modules (gnu bootloader)
(gnu bootloader u-boot)
(gnu services base)
(gnu system)
(gnu system image)
(gnu system file-systems)
(guix channels)
(guix inferior)
(srfi srfi-1))
(define wip-pinebook
(list (channel (name 'guix)
(url "https://git.savannah.gnu.org/git/guix.git;)
(branch "wip-pinebook-pro")
(introduction
(make-channel-introduction
"47a5442aa7dad8b1904483954e91640c3cac5e90"
(openpgp-fingerprint
"658073613BFCC5C7E2E45D45DC518FC87F9716AA"))
(define inferior-pinebook (inferior-for-channels wip-pinebook))
(operating-system
(host-name "test")
(timezone "US/Eastern")
(locale "en_US.utf8")
(bootloader (bootloader-configuration
(bootloader u-boot-pinebook-pro-rk3399-bootloader)
(target "/dev/vda")))
(kernel (first (lookup-inferior-packages inferior-pinebook
"linux-libre-pinebook-pro")))
(kernel-arguments (cons* "video=HDMI-A-1:1920x1080@60"
"video=eDP-1:1920x1080@60"
"vga=current"
%default-kernel-arguments))
(initrd-modules '())
(file-systems (cons (file-system
(device (file-system-label root-label))
(mount-point "/")
(type "ext4"))
%base-file-systems))
(users (cons (user-account
(name "test")
(group "users")
(supplementary-groups '("wheel"))
(password (crypt "test" "$5$ca")))
%base-user-accounts))
(services (cons* (service agetty-service-type
(agetty-configuration
(extra-options '("-L"))
(baud-rate "150")
(term "vt100")
(tty "ttyS2")))
%base-services)))
Re: Staging branch [substitute availability armhf-linux]
Hi, > > LCD output, nothing answering on serial console (@1.5Mbps > > (uboot speed) or 115.2Kbps (kernel speed, I think)). Both kernel and u-boot use 150 baud. > Strange, seems that Caliph did manage to get a serial console. Caliph, > any insight here? A configuration close to the pinebook-pro-barebones-os configuration worked for me software-wise (albiet, without LCD output), but there's a few hardware tweaks that need to be done to get it working. On the mainboard there's two switches: an eMMC disable switch and a serial output switch. The serial output switch needs to be set properly to get serial out through the headphone jack. Nominally you should also disable the internal eMMC if there's anything on it in order to use Guix's u-boot, but I wasn't able to get the switch to work so I just removed the eMMC flash. From the log posted earlier, it does look like that's the case, so it's booting from the factory-default 2017 u-boot with blobs. I just realized that the configuration I used had one (significant) change: agetty needs to be started on /dev/ttyS2, not /dev/ttyS0. I have just submitted a patch to fix this (https://issues.guix.gnu.org/45997). To get the LCD up, I used an inferior with linux-libre-pinebook-pro from the wip-pinebook-pro branch, and included some kernel arguments from janneke that Mathieu told me about, though I'm unsure how necessary they are with the kernel patches. I have also heard that disabling CONFIG_ROCKCHIP_CDN_DP on mainline would work too, but I haven't tested it. I'll attach a config that should work to bring up serial and the LCD. Hope this helps.
Re: Staging branch [substitute availability armhf-linux]
On Sun, Jan 17, 2021 at 12:01 PM Mathieu Othacehe wrote: > you should be able to download this image. Yep, I DL'ed and got the same result as with my own images, so my building is not be the problem. > Yes looks like the search pagination and ordering is broken, those are > definitely bugs that you can report. Done : https://issues.guix.gnu.org/45936 -- Vincent Legoll
Re: Staging branch [substitute availability armhf-linux]
> That's slightly different than what I have been doing, but > the resulting image has the same problem than mine, no > LCD output, nothing answering on serial console (@1.5Mbps > (uboot speed) or 115.2Kbps (kernel speed, I think)). Strange, seems that Caliph did manage to get a serial console. Caliph, any insight here? > Does cuirass only remove the link after a while after the image has > been gc'ed ? Yes turns out it was a regression due to PostgreSQL switch, this is now solved and you should be able to download this image. Mathieu
Re: Staging branch [substitute availability armhf-linux]
On Sun, Jan 17, 2021 at 11:17 AM Mathieu Othacehe wrote: > --8<---cut here---start->8--- > guix build -f pinebook.scm > --8<---cut here---end--->8--- > > should achieve the same result locally. That's slightly different than what I have been doing, but the resulting image has the same problem than mine, no LCD output, nothing answering on serial console (@1.5Mbps (uboot speed) or 115.2Kbps (kernel speed, I think)). > > That's where I searched, but did not find one with > > the "Build outputs" link like the one you cited. > > > > Why is 190783 different from the 6 other ones returned > > by this search query ? > > Because I just enabled build outputs production for Pinebook Pro images. Does cuirass only remove the link after a while after the image has been gc'ed ? > > BTW, I think there is a problem in the way Cuirass web UI sorts > > its results (apparently by oldest to newest, on the completion > > time column) it looks like it is doing a string comparison, where > > "32 minutes ago" is older than "37 hours ago". The "<< < > >>" > > buttons also act strangely. Do you see such things ? > > Should I report them as bugs ? > > Yes looks like the search pagination and ordering is broken, those are > definitely bugs that you can report. I'll do it later today Thanks -- Vincent Legoll
Re: Staging branch [substitute availability armhf-linux]
Hello, > trying to DL (in browser or with wget) the build output, by using > the "https://ci.guix.gnu.org/download/190783; link, I get: > error "Could not find the request build product." Oh, it's already been garbage collected on Berlin, sorry about that :(. I'll see what I can do. In the meantime, running the attached file this way: --8<---cut here---start->8--- guix build -f pinebook.scm --8<---cut here---end--->8--- should achieve the same result locally. > That's where I searched, but did not find one with > the "Build outputs" link like the one you cited. > > Why is 190783 different from the 6 other ones returned > by this search query ? Because I just enabled build outputs production for Pinebook Pro images. > BTW, I think there is a problem in the way Cuirass web UI sorts > its results (apparently by oldest to newest, on the completion > time column) it looks like it is doing a string comparison, where > "32 minutes ago" is older than "37 hours ago". The "<< < > >>" > buttons also act strangely. Do you see such things ? > Should I report them as bugs ? Yes looks like the search pagination and ordering is broken, those are definitely bugs that you can report. Mathieu pinebook.scm Description: Binary data
Re: Staging branch [substitute availability armhf-linux]
Hello, Thanks On Sun, Jan 17, 2021 at 10:35 AM Mathieu Othacehe wrote: > You can download the latest Pinebook Pro image here: > > https://ci.guix.gnu.org/build/190783/details trying to DL (in browser or with wget) the build output, by using the "https://ci.guix.gnu.org/download/190783; link, I get: error "Could not find the request build product." > to search for the latest images: > > https://ci.guix.gnu.org/search?query=spec%3Aguix-master+system%3Ax86_64-linux+status%3Asuccess+pinebook-pro That's where I searched, but did not find one with the "Build outputs" link like the one you cited. Why is 190783 different from the 6 other ones returned by this search query ? BTW, I think there is a problem in the way Cuirass web UI sorts its results (apparently by oldest to newest, on the completion time column) it looks like it is doing a string comparison, where "32 minutes ago" is older than "37 hours ago". The "<< < > >>" buttons also act strangely. Do you see such things ? Should I report them as bugs ? Tchuss -- Vincent Legoll
Re: Staging branch [substitute availability armhf-linux]
Hello Vincent, You can download the latest Pinebook Pro image here: https://ci.guix.gnu.org/build/190783/details to search for the latest images: https://ci.guix.gnu.org/search?query=spec%3Aguix-master+system%3Ax86_64-linux+status%3Asuccess+pinebook-pro Thanks, Mathieu
Re: Staging branch [substitute availability armhf-linux]
Hello, > > I even attempted building the pinebook pro image without success. > > Hm... it's a shame we are building this and it doesn't work. I only tried my locally built one, is there a substitute that I can try ? That would tell if the problem is on my side or not. > Do you also use some armhf (32-bit) hardware? I would like. I tried and failed (I tried to build an image for an orangepi+2e) I have other non-x86 HW that I would like to have guixsd on. I don't ask for susbstitutes, I can build them locally if needed and doable. -- Vincent Legoll
Re: Staging branch [substitute availability armhf-linux]
On Fri, Jan 15, 2021 at 09:27:36AM +0100, Vincent Legoll wrote: > On Fri, Jan 15, 2021 at 12:07 AM Leo Famulari wrote: > > Specifically about armhf, if anybody wants to use it with Guix, I hope > > they will speak up. > > I am interested, I have tried, and failed to get anything (apart from guix > on foreign armbian). But I am more interested in guixsd though. Okay, thanks for letting us know. > I even attempted building the pinebook pro image without success. Hm... it's a shame we are building this and it doesn't work. Do you also use some armhf (32-bit) hardware?
Re: Staging branch [substitute availability armhf-linux]
Hello, On Fri, Jan 15, 2021 at 10:54 AM Mathieu Othacehe wrote: > It seems that Caliph Nomble succeeded to build a Pinebook Pro image and > booted it, without graphics, after a few fixes: > https://issues.guix.gnu.org/45584. > > You may want to try again :). DONE, it's a bit better, this time initrd, kernel & dtb loaded properly. But serial output stopped after "Starting kernel ..." which is probably because of mismatched serial port speed, but I tried to relaunch screen with 57600, 115200 and still go no output. [complete uboot log attached] LCD screen stays black which is probably normal. The image was built like the following: # ./pre-inst-env guix describe Git checkout: repository: /home/vince/dev/repo/guix branch: master commit: c03875b0361f114634caeb54935fe37a9b7b05af # echo "(use-modules (gnu system images pinebook-pro)) pinebook-pro-barebones-os" > /tmp/os.scm # ./pre-inst-env guix system disk-image -t pinebook-pro-raw /tmp/os.scm [...] /gnu/store/5fj3aha8jsyji9mpqzf2krakl08r9zlw-disk-image Next I'll try the hints from: https://issues.guix.gnu.org/45584 > >> There is almost no armhf hardware that is suitable > >> for a build-from-source distro in terms of performance, thermal design > >> and suitable storage (SD cards will not last for unless you pay a huge > >> amount for the absolute highest quality). Binary distros like Trisquel > >> are a much better option for armhf. > > > > The cross buildability *should* be kind of a solution for this. > > Yes we could always decide to stop supporting native ARMv7 substitutes > and only focus on the cross-building to provide ready to use image for > this architecture. Isn't there a way to reconcile the 2 ? At least theoretically cross- or native- compilation should give identical output, though I dunno how far that is from reality (probably not good, or we would be doing just that) > >> All that is not a reason to not support armhf, but if nobody is using > >> it, then we should officially deprecate it, and not leave it in this > >> in-between state. > > > > I'm not using it because I can't make it work. > > Don't hesitate to report the issues you encountered! I've done it a few times already, for armhf, arm64, powerpc64, mipsel. And I'll (re-)try anything if I'm hinted as what to try next. The main problem from my PoV is the scatteredness of the infos. Tchuss -- Vincent Legoll DDR Version 1.20 20190314 In channel 0 CS = 0 MR0=0x98 MR4=0x1 MR5=0xFF MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 CS = 1 MR0=0x18 MR4=0x1 MR5=0xFF MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0x98 MR4=0x1 MR5=0xFF MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 CS = 1 MR0=0x18 MR4=0x1 MR5=0xFF MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel 1 training pass! change freq to 400MHz 0,1 channel 0 CS = 0 MR0=0x98 MR4=0x1 MR5=0xFF MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 CS = 1 MR0=0x18 MR4=0x1 MR5=0xFF MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0x98 MR4=0x1 MR5=0xFF MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 CS = 1 MR0=0x18 MR4=0x1 MR5=0xFF MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel 1 training pass! change freq to 800MHz 1,0 Channel 0: LPDDR4,800MHz Bus Width=32 Col=10 Bank=8 Row=15/15 CS=2 Die Bus-Width=16 Size=2048MB Channel 1: LPDDR4,800MHz Bus Width=32 Col=10 Bank=8 Row=15/15 CS=2 Die Bus-Width=16 Size=2048MB 256B stride ch 0 ddrconfig = 0x101, ddrsize = 0x2020 ch 1 ddrconfig = 0x101, ddrsize = 0x2020 pmugrf_os_reg[2] = 0x3AA1FAA1, stride = 0xD OUT Boot1: 2019-03-14, version: 1.19 CPUId = 0x0 ChipType = 0x10, 251 SdmmcInit=2 0 BootCapSize=10 UserCapSize=119276MB FwPartOffset=2000 , 10 mmc0:cmd5,20 SdmmcInit=0 0 BootCapSize=0 UserCapSize=30528MB FwPartOffset=2000 , 0 StorageInit ok = 191888 SecureMode = 0 SecureInit read PBA: 0x4 SecureInit read PBA: 0x404 SecureInit read PBA: 0x804 SecureInit read PBA: 0xc04 SecureInit read PBA: 0x1004 SecureInit read PBA: 0x1404 SecureInit read PBA: 0x1804 SecureInit read PBA: 0x1c04 SecureInit ret = 0, SecureMode = 0 atags_set_bootdev: ret:(0) GPT 0x3380ec0 signature is wrong recovery gpt... GPT 0x3380ec0 signature is wrong recovery gpt fail! LoadTrust Addr:0x4000 LoadTrust Addr:0x4400 LoadTrust Addr:0x4800 LoadTrust Addr:0x4c00 LoadTrust Addr:0x5000 LoadTrust Addr:0x5400 LoadTrust Addr:0x5800 LoadTrust Addr:0x5c00 Addr:0x4000 No find trust.img! LoadTrustBL error:-3 SecureMode = 0 SecureInit read PBA: 0x4 SecureInit read PBA: 0x404 SecureInit read PBA: 0x804 SecureInit read PBA: 0xc04 SecureInit read PBA: 0x1004 SecureInit read PBA: 0x1404 SecureInit read PBA: 0x1804 SecureInit read PBA: 0x1c04 SecureInit ret = 0, SecureMode = 0 atags_set_bootdev: ret:(0) GPT 0x3380ec0 signature is wrong recovery gpt... GPT 0x3380ec0 signature is wrong recovery gpt fail!
Re: Staging branch [substitute availability armhf-linux]
Hello Vincent, > I even attempted building the pinebook pro image without success. It seems that Caliph Nomble succeeded to build a Pinebook Pro image and booted it, without graphics, after a few fixes: https://issues.guix.gnu.org/45584. You may want to try again :). >> There is almost no armhf hardware that is suitable >> for a build-from-source distro in terms of performance, thermal design >> and suitable storage (SD cards will not last for unless you pay a huge >> amount for the absolute highest quality). Binary distros like Trisquel >> are a much better option for armhf. > > The cross buildability *should* be kind of a solution for this. Yes we could always decide to stop supporting native ARMv7 substitutes and only focus on the cross-building to provide ready to use image for this architecture. >> All that is not a reason to not support armhf, but if nobody is using >> it, then we should officially deprecate it, and not leave it in this >> in-between state. > > I'm not using it because I can't make it work. Don't hesitate to report the issues you encountered! Thanks, Mathieu
Re: Staging branch [substitute availability armhf-linux]
Hey Ludo, > You seem to imply that the issue is the number of architectures, rather > than the small number of ARMv7 build machines (now that we disabled > 32-bit builds on AArch64). Do I get it right? Yes my point is that building three specifications on three architectures, including an emulated one, is already hard for the build farm, so adding more specifications/architectures seems complex. Even if we fix the problem raised by Danny, enabling again ARMv7 transparent emulation, without any additional hardware wouldn't fit. > That was a problem with Cuirass doing ‘build-derivations’ RPCs for > derivations spanning multiple architectures (the RPC would complete once > the slowest architecture is done), but maybe that’s no longer the case > with the new remote builds feature you’ve been working on? Yes, that's solved by the remote building feature. The workers are declaring the architectures they support. When they request work, the remote server picks randomly an architecture and select the most priority build available. This way the queuing happens at the database level and not in the guix-daemon itself. Thanks, Mathieu
Re: Staging branch [substitute availability armhf-linux]
Hello, On Fri, Jan 15, 2021 at 12:07 AM Leo Famulari wrote: > Specifically about armhf, if anybody wants to use it with Guix, I hope > they will speak up. I am interested, I have tried, and failed to get anything (apart from guix on foreign armbian). But I am more interested in guixsd though. I even attempted building the pinebook pro image without success. > I think we should monitor the volume of substitute requests per platform > and see how big the demand for armhf Guix really is. With the current situation, I'm not sure this would really be representative of the armhf or arm64 demand. > Although there is a huge amount of armhf hardware deployed, Guix seems a > very poor fit for it. In its current state. > There is almost no armhf hardware that is suitable > for a build-from-source distro in terms of performance, thermal design > and suitable storage (SD cards will not last for unless you pay a huge > amount for the absolute highest quality). Binary distros like Trisquel > are a much better option for armhf. The cross buildability *should* be kind of a solution for this. > All that is not a reason to not support armhf, but if nobody is using > it, then we should officially deprecate it, and not leave it in this > in-between state. I'm not using it because I can't make it work. -- Vincent Legoll
Re: Staging branch [substitute availability armhf-linux]
On Thu, Jan 14, 2021 at 09:44:17AM +0100, Mathieu Othacehe wrote: > Your weather summary is a great idea, thanks! As I said in my previous > email, the armhf substitutes are not built right now on the CI. It's > really sad but we have to make an impossible choice between: Specifically about armhf, if anybody wants to use it with Guix, I hope they will speak up. I would have expected to hear from users that they were not getting any substitutes. I think we should monitor the volume of substitute requests per platform and see how big the demand for armhf Guix really is. Although there is a huge amount of armhf hardware deployed, Guix seems a very poor fit for it. There is almost no armhf hardware that is suitable for a build-from-source distro in terms of performance, thermal design and suitable storage (SD cards will not last for unless you pay a huge amount for the absolute highest quality). Binary distros like Trisquel are a much better option for armhf. All that is not a reason to not support armhf, but if nobody is using it, then we should officially deprecate it, and not leave it in this in-between state.
Re: Staging branch [substitute availability armhf-linux]
Hi, Mathieu Othacehe skribis: > Your weather summary is a great idea, thanks! As I said in my previous > email, the armhf substitutes are not built right now on the CI. It's > really sad but we have to make an impossible choice between: > > * Trying to build everything on all architecture and have the CI that is > awfully lagging behind. > > * Restrict the number of architecture we want to provide substitutes > for. You seem to imply that the issue is the number of architectures, rather than the small number of ARMv7 build machines (now that we disabled 32-bit builds on AArch64). Do I get it right? That was a problem with Cuirass doing ‘build-derivations’ RPCs for derivations spanning multiple architectures (the RPC would complete once the slowest architecture is done), but maybe that’s no longer the case with the new remote builds feature you’ve been working on? Ludo’.
Re: Staging branch [substitute availability armhf-linux]
Hi Mathieu, I have not read carefully all the emails on the topic, so I am probably out-of-scope. On Thu, 14 Jan 2021 at 09:44, Mathieu Othacehe wrote: > * Trying to build everything on all architecture and have the CI that is > awfully lagging behind. > > * Restrict the number of architecture we want to provide substitutes > for. Maybe we could use Bayfront and the recent Fosshost donation differently and so use them to cross-compile, removing the x86 builds on them. Cheers, simon
Re: Staging branch [substitute availability armhf-linux]
> The armhf-linux platform is in the worst shape, both on the master and > staging branches. It's a shame because it's also the least powerful, > with almost no hardware thermally capable of sustained CPU usage, so > users will have the worst experience building packages for it. > > Does anyone want to work on it? Should we just "fix it on the master > branch?" Your weather summary is a great idea, thanks! As I said in my previous email, the armhf substitutes are not built right now on the CI. It's really sad but we have to make an impossible choice between: * Trying to build everything on all architecture and have the CI that is awfully lagging behind. * Restrict the number of architecture we want to provide substitutes for. Thanks, Mathieu
Re: Staging branch [substitute availability armhf-linux]
The armhf-linux platform is in the worst shape, both on the master and staging branches. It's a shame because it's also the least powerful, with almost no hardware thermally capable of sustained CPU usage, so users will have the worst experience building packages for it. Does anyone want to work on it? Should we just "fix it on the master branch?" -- 3301 packages are missing from 'https://ci.guix.gnu.org' for 'armhf-linux', among which: 2695 gdk-pixbuf@2.40.0 /gnu/store/xjdgypav5vcl4pyc388cs6gr5hv73fvp-gdk-pixbuf-2.40.0 2277 imagemagick@6.9.11-48 /gnu/store/gjb5j8yf7aynicmfsxwqnwzhjp2sp6i8-imagemagick-6.9.11-48-doc /gnu/store/vnpms2y3g9wrkl550zk0gh5vx9rb5hym-imagemagick-6.9.11-48 2239 elfutils@0.182 /gnu/store/kbdmbs8h83kqya6wqjisjm6snbnjxpff-elfutils-0.182-bin /gnu/store/iy8q5i7fa9c347r34lllrvbqzh6lwrfr-elfutils-0.182 2194 libdrm@2.4.103 /gnu/store/i6ydsdg2ha6k40s5vrqh5c5wqkkhx0i8-libdrm-2.4.103 2188 glslang@10-11.0.0 /gnu/store/xvw9jbfqrjv5pc8d1ckni72y6mwll2ay-glslang-10-11.0.0 1990 rust@1.19.0 /gnu/store/jgbkdpxrf18q3yms4a1apzkawsqhzqkr-rust-1.19.0-cargo /gnu/store/2zmswj21202j7xfli9aizz6a9k6pkfvd-rust-1.19.0 1861 xkbcomp-intermediate@1.4.4 /gnu/store/c61lfs091rv4pa405rxcqzxn9hzvdlyn-xkbcomp-intermediate-1.4.4 1665 tzdata@2020f /gnu/store/ix7dkzsc2g2028xxqirwmjlprdiarhsa-tzdata-2020f 1331 libcap@2.45 /gnu/store/rcx340qk9dcs7lck86xba8fmbwn132vm-libcap-2.45 1093 postgresql@13.1 /gnu/store/bcgry8jrhs9d5z532yhacf2zzzviyzqi-postgresql-13.1 964 mariadb@10.5.8 /gnu/store/3fa29zjsb48279g3qifa5fjlihx6wzvy-mariadb-10.5.8-dev /gnu/store/hxg1mynghbs1frnnwx2vb84ywj912a8j-mariadb-10.5.8-lib /gnu/store/67zkwlflvmj2mia67ifx07rzb3m2vyfn-mariadb-10.5.8 872 xprop@1.2.5 /gnu/store/2yj1m9xpil630qcry3psw6pg5nc7j8gh-xprop-1.2.5 855 libinput-minimal@1.16.4 /gnu/store/zyr2hl2bsqxw63kr67p6nycdpmyng1f9-libinput-minimal-1.16.4 830 vulkan-headers@1.2.164 /gnu/store/41gwjqma4whf6dvfif9d02fmmfa80bdr-vulkan-headers-1.2.164 788 sbcl@2.1.0 /gnu/store/3dvfa85ycrpxbj208yfwikl0n33lavwi-sbcl-2.1.0-doc /gnu/store/1b7qwyv732n28gahwpjagv3xjjlpm2ik-sbcl-2.1.0 784 patchelf@0.11 /gnu/store/ww555zg4njj4acr12qhbl8xjq9dzdg7f-patchelf-0.11 749 python-pytz@2020.4 /gnu/store/lx2iqg2cpyi2ds1qqszav3vrf68hli5i-python-pytz-2020.4 739 python-cffi@1.14.4 /gnu/store/x27rkkrp2dw3j0v0n3izd513kzxha6qp-python-cffi-1.14.4 714 python-iso8601@0.1.13 /gnu/store/68b8mqbgsvdaqnrp3414sxqwymlpn29y-python-iso8601-0.1.13 682 python-cryptography-vectors@3.3.1 /gnu/store/v3jjq6dmsf9l62pbfmz3502wc0fdixbh-python-cryptography-vectors-3.3.1 667 python-certifi@2020.12.5 /gnu/store/rbw7ni2f13s2fgxw825ygd5lpa1j2nw4-python-certifi-2020.12.5 619 gstreamer@1.18.2 /gnu/store/355qdcpy3dnv4yjpgrdxbgwk1hi03fw3-gstreamer-1.18.2 582 classpath@0.93 /gnu/store/5hy2cdkjscq5546ym6jkf048dyick7cd-classpath-0.93 576 nss-certs@3.59 /gnu/store/p131lkj2mhiq5dbl4snlkaachvlivbjy-nss-certs-3.59 511 python-pygments@2.7.3 /gnu/store/4mzgxp6bsx4zk7xylr7hm5l8d7bby1x6-python-pygments-2.7.3 401 shadow@4.8.1 /gnu/store/lxnfvrkijw9awbrw47vx4nmra2dmpa16-shadow-4.8.1 245 git@2.30.0 /gnu/store/xvpmhk29ykscfdpfyjhpyrhahi6rck19-git-2.30.0-credential-netrc /gnu/store/fnyrbmzxhcgbpl300irpycr8fy85dqrs-git-2.30.0-gui /gnu/store/klswflk1cqn723i0hyzxg3vv2wicrb5k-git-2.30.0 /gnu/store/06f3b2igianyqwic7jp2c216lb98w6jb-git-2.30.0-send-email /gnu/store/7i9clx90q28b966aypr8g3yhrvqd1b3z-git-2.30.0-subtree /gnu/store/zlc18bbhbgc7lzjk5xqw5p54a0jrr8l3-git-2.30.0-svn 234 gsasl@1.10.0 /gnu/store/gs1mgdfxd7il90ij78zl9jdfrg2j7dcq-gsasl-1.10.0 227 gdk-pixbuf@2.40.0 /gnu/store/xjdgypav5vcl4pyc388cs6gr5hv73fvp-gdk-pixbuf-2.40.0 222 libdrm@2.4.103 /gnu/store/i6ydsdg2ha6k40s5vrqh5c5wqkkhx0i8-libdrm-2.4.103 221 elfutils@0.182 /gnu/store/kbdmbs8h83kqya6wqjisjm6snbnjxpff-elfutils-0.182-bin /gnu/store/iy8q5i7fa9c347r34lllrvbqzh6lwrfr-elfutils-0.182 218 imagemagick@6.9.11-48 /gnu/store/gjb5j8yf7aynicmfsxwqnwzhjp2sp6i8-imagemagick-6.9.11-48-doc /gnu/store/vnpms2y3g9wrkl550zk0gh5vx9rb5hym-imagemagick-6.9.11-48 217 xkbcomp-intermediate@1.4.4 /gnu/store/c61lfs091rv4pa405rxcqzxn9hzvdlyn-xkbcomp-intermediate-1.4.4 216 libcap@2.45 /gnu/store/rcx340qk9dcs7lck86xba8fmbwn132vm-libcap-2.45 216 tzdata@2020f /gnu/store/ix7dkzsc2g2028xxqirwmjlprdiarhsa-tzdata-2020f 214 xprop@1.2.5 /gnu/store/2yj1m9xpil630qcry3psw6pg5nc7j8gh-xprop-1.2.5 213 postgresql@13.1 /gnu/store/bcgry8jrhs9d5z532yhacf2zzzviyzqi-postgresql-13.1 213 mariadb@10.5.8 /gnu/store/3fa29zjsb48279g3qifa5fjlihx6wzvy-mariadb-10.5.8-dev /gnu/store/hxg1mynghbs1frnnwx2vb84ywj912a8j-mariadb-10.5.8-lib /gnu/store/67zkwlflvmj2mia67ifx07rzb3m2vyfn-mariadb-10.5.8 213 libinput-minimal@1.16.4
