* bug#37931: Cannot guix refresh -ru util-linux to get updated lsblk
@ 2019-10-26 1:22 Bengt Richter
2019-10-28 22:29 ` Marius Bakke
0 siblings, 1 reply; 7+ messages in thread
From: Bengt Richter @ 2019-10-26 1:22 UTC (permalink / raw)
To: 37931
Hi Guix,
IpPulled and updated to guix describe:
---------------------
Generation 19 Oct 24 2019 22:37:20 (current)
guix 6caa739
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 6caa7392d8e51f5ef26e9efaa867ca5f9e1cac91
---------------------
but lsblk -f still looks like this:
---------------------
NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
sda
├─sda1
├─sda2
├─sda3
├─sda4
├─sda5
├─sda6
└─sda7
sdb
└─sdb1
nvme0n1
├─nvme0n1p1 510M 50% /boot
├─nvme0n1p2
├─nvme0n1p3 [SWAP]
└─nvme0n1p4 12.6G 71% /
---------------------
where it should look like: (got this using foreign /usr/bin/lsblk -f)
---------------------
NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
sda
├─sda1 vfat Phanto1EFI 98AB-229C
├─sda2 ext4 d8ce4206-fc92-4248-8164-3fe5397c28fb
├─sda3 swap 59e8ffd8-a2df-4021-ba59-c8dda6215f83
├─sda4 ext4 Phanto4ArchGx 617f2280-d34a-4dea-ac50-a1222dd18c26
├─sda5 ext4 Phanto5ArchGxOn 71e61e41-81d0-48ac-b50f-a00668723c32
├─sda6 ext4 Phanto6Arch e5760f87-71bc-4318-92f1-d108e5c9e332
└─sda7 ext4 Phanto7GuixSD a60eac5f-2306-49c5-8c87-7cab28ff6d37
sdb
└─sdb1 ext4 Cruz1GxArchivA 18fb1d34-47b0-4d62-baea-43681ec2e5a4
nvme0n1
├─nvme0n1p1 vfat PhantoV1EFI 6E3C-D410 510M 50% /boot
├─nvme0n1p2 ext4 PhantoNv2Empty 76bc8f68-126c-4a6c-8b77-afc89bd2726a
├─nvme0n1p3 swap 24151091-f47a-46e2-a6cb-e5219eddae7c [SWAP]
└─nvme0n1p4 ext4 PhantoNv4ArchGx 12eec2bf-bc81-48a8-b444-26913c078302 12.6G 71% /
---------------------
So I tried:
[17:59 ~/bs]$ guix refresh -r util-linux
guix/build-system/gnu.scm:143:8: findutils would be upgraded from 4.6.0 to 4.7.0
gnu/packages/commencement.scm:2183:2: binutils would be upgraded from 2.32 to 2.33.1
gnu/packages/commencement.scm:2244:2: gcc would be upgraded from 7.4.0 to 9.2.0
gnu/packages/commencement.scm:2142:2: glibc would be upgraded from 2.29 to 2.30
[18:01 ~/bs]$ guix refresh -ru util-linux
guix/build-system/gnu.scm:143:8: error: cannot download for this method: #<procedure 7f277de49100 at gnu/packages/bootstrap.scm:155:4 (url hash-algo hash #:opti
onal name #:key system)>
[18:02 ~/bs]$ lsblk --version
lsblk from util-linux 2.34
[18:04 ~/bs]$ guix package -I util-linux
util-linux 2.34 out /gnu/store/xymkwf57x988q8cny2is1dgzrbr9xdfi-util-linux-2.34
[18:04 ~/bs]$ # was -ru combination a problem?
[18:05 ~/bs]$ guix refresh -u util-linux
[18:06 ~/bs]$ guix refresh -r util-linux
guix/build-system/gnu.scm:143:8: findutils would be upgraded from 4.6.0 to 4.7.0
gnu/packages/commencement.scm:2183:2: binutils would be upgraded from 2.32 to 2.33.1
gnu/packages/commencement.scm:2244:2: gcc would be upgraded from 7.4.0 to 9.2.0
gnu/packages/commencement.scm:2142:2: glibc would be upgraded from 2.29 to 2.30
[18:06 ~/bs]$ guix refresh -ur util-linux
guix/build-system/gnu.scm:143:8: error: cannot download for this method: #<procedure 7fb30f394e80 at gnu/packages/bootstrap.scm:155:4 (url hash-algo hash #:opti
onal name #:key system)>
[18:06 ~/bs]$ su -c 'setterm -file refresh-errors.txt -dump 1'
TIA for any help :)
--
Regards,
Bengt Richter
^ permalink raw reply [flat|nested] 7+ messages in thread* bug#37931: Cannot guix refresh -ru util-linux to get updated lsblk 2019-10-26 1:22 bug#37931: Cannot guix refresh -ru util-linux to get updated lsblk Bengt Richter @ 2019-10-28 22:29 ` Marius Bakke 2019-11-02 14:42 ` Bengt Richter 0 siblings, 1 reply; 7+ messages in thread From: Marius Bakke @ 2019-10-28 22:29 UTC (permalink / raw) To: Bengt Richter, 37931 [-- Attachment #1: Type: text/plain, Size: 4254 bytes --] Hi Bengt, Bengt Richter <bokr@bokr.com> writes: > Hi Guix, > > IpPulled and updated to guix describe: > --------------------- > Generation 19 Oct 24 2019 22:37:20 (current) > guix 6caa739 > repository URL: https://git.savannah.gnu.org/git/guix.git > branch: master > commit: 6caa7392d8e51f5ef26e9efaa867ca5f9e1cac91 > --------------------- > > but lsblk -f still looks like this: > --------------------- > NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT > sda > ├─sda1 > ├─sda2 > ├─sda3 > ├─sda4 > ├─sda5 > ├─sda6 > └─sda7 > sdb > └─sdb1 > nvme0n1 > ├─nvme0n1p1 510M 50% /boot > ├─nvme0n1p2 > ├─nvme0n1p3 [SWAP] > └─nvme0n1p4 12.6G 71% / > --------------------- > where it should look like: (got this using foreign /usr/bin/lsblk -f) > --------------------- > NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT > sda > ├─sda1 vfat Phanto1EFI 98AB-229C > ├─sda2 ext4 d8ce4206-fc92-4248-8164-3fe5397c28fb > ├─sda3 swap 59e8ffd8-a2df-4021-ba59-c8dda6215f83 > ├─sda4 ext4 Phanto4ArchGx 617f2280-d34a-4dea-ac50-a1222dd18c26 > ├─sda5 ext4 Phanto5ArchGxOn 71e61e41-81d0-48ac-b50f-a00668723c32 > ├─sda6 ext4 Phanto6Arch e5760f87-71bc-4318-92f1-d108e5c9e332 > └─sda7 ext4 Phanto7GuixSD a60eac5f-2306-49c5-8c87-7cab28ff6d37 > sdb > └─sdb1 ext4 Cruz1GxArchivA 18fb1d34-47b0-4d62-baea-43681ec2e5a4 > nvme0n1 > ├─nvme0n1p1 vfat PhantoV1EFI 6E3C-D410 510M 50% /boot > ├─nvme0n1p2 ext4 PhantoNv2Empty 76bc8f68-126c-4a6c-8b77-afc89bd2726a > ├─nvme0n1p3 swap 24151091-f47a-46e2-a6cb-e5219eddae7c [SWAP] > └─nvme0n1p4 ext4 PhantoNv4ArchGx 12eec2bf-bc81-48a8-b444-26913c078302 12.6G 71% / > --------------------- The `lsblk` program requires root privileges in order to detect file systems and UUIDs. I'm guessing your distribution makes it setuid root? To do the same on Guix System, see the "Setuid programs" section of the manual. You would need something along these lines in your config: (operating-system [...] (setuid-programs (cons #~(string-append #$util-linux "/bin/lsblk")) %setuid-programs)) Does that work for you? > So I tried: > > [17:59 ~/bs]$ guix refresh -r util-linux > guix/build-system/gnu.scm:143:8: findutils would be upgraded from 4.6.0 to 4.7.0 > gnu/packages/commencement.scm:2183:2: binutils would be upgraded from 2.32 to 2.33.1 > gnu/packages/commencement.scm:2244:2: gcc would be upgraded from 7.4.0 to 9.2.0 > gnu/packages/commencement.scm:2142:2: glibc would be upgraded from 2.29 to 2.30 > [18:01 ~/bs]$ guix refresh -ru util-linux > guix/build-system/gnu.scm:143:8: error: cannot download for this method: #<procedure 7f277de49100 at gnu/packages/bootstrap.scm:155:4 (url hash-algo hash #:opti > onal name #:key system)> 'guix refresh -u' only works in combination with the './pre-inst-env' script, because it tries to modify your Guix directly. In any case util-linux is already the latest version. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#37931: Cannot guix refresh -ru util-linux to get updated lsblk 2019-10-28 22:29 ` Marius Bakke @ 2019-11-02 14:42 ` Bengt Richter 2019-11-03 17:28 ` Marius Bakke 0 siblings, 1 reply; 7+ messages in thread From: Bengt Richter @ 2019-11-02 14:42 UTC (permalink / raw) To: Marius Bakke; +Cc: 37931 Hi Marius, On +2019-10-28 23:29:16 +0100, Marius Bakke wrote: > Hi Bengt, > > Bengt Richter <bokr@bokr.com> writes: > > > Hi Guix, > > > > IpPulled and updated to guix describe: > > --------------------- > > Generation 19 Oct 24 2019 22:37:20 (current) > > guix 6caa739 > > repository URL: https://git.savannah.gnu.org/git/guix.git > > branch: master > > commit: 6caa7392d8e51f5ef26e9efaa867ca5f9e1cac91 > > --------------------- > > > > but lsblk -f still looks like this: > > --------------------- > > NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT > > sda > > ├─sda1 > > ├─sda2 > > ├─sda3 > > ├─sda4 > > ├─sda5 > > ├─sda6 > > └─sda7 > > sdb > > └─sdb1 > > nvme0n1 > > ├─nvme0n1p1 510M 50% /boot > > ├─nvme0n1p2 > > ├─nvme0n1p3 [SWAP] > > └─nvme0n1p4 12.6G 71% / > > --------------------- > > where it should look like: (got this using foreign /usr/bin/lsblk -f) > > --------------------- > > NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT > > sda > > ├─sda1 vfat Phanto1EFI 98AB-229C > > ├─sda2 ext4 d8ce4206-fc92-4248-8164-3fe5397c28fb > > ├─sda3 swap 59e8ffd8-a2df-4021-ba59-c8dda6215f83 > > ├─sda4 ext4 Phanto4ArchGx 617f2280-d34a-4dea-ac50-a1222dd18c26 > > ├─sda5 ext4 Phanto5ArchGxOn 71e61e41-81d0-48ac-b50f-a00668723c32 > > ├─sda6 ext4 Phanto6Arch e5760f87-71bc-4318-92f1-d108e5c9e332 > > └─sda7 ext4 Phanto7GuixSD a60eac5f-2306-49c5-8c87-7cab28ff6d37 > > sdb > > └─sdb1 ext4 Cruz1GxArchivA 18fb1d34-47b0-4d62-baea-43681ec2e5a4 > > nvme0n1 > > ├─nvme0n1p1 vfat PhantoV1EFI 6E3C-D410 510M 50% /boot > > ├─nvme0n1p2 ext4 PhantoNv2Empty 76bc8f68-126c-4a6c-8b77-afc89bd2726a > > ├─nvme0n1p3 swap 24151091-f47a-46e2-a6cb-e5219eddae7c [SWAP] > > └─nvme0n1p4 ext4 PhantoNv4ArchGx 12eec2bf-bc81-48a8-b444-26913c078302 12.6G 71% / > > --------------------- > > The `lsblk` program requires root privileges in order to detect file > systems and UUIDs. I'm guessing your distribution makes it setuid root? > It doesn't look like it to me (the following snip is from TTY4, where I enabled guix paths and environment, so I can see ~/.guix-profile and /usr stuff at the same time): Ok, I'm back from TTY4 with some stuff (enclosed by the tagged snip lines): --8<----(from emacs shell mode, guix enabled)-----------cut here---------------start------------->8--- $ gx-mode Current gx-mode: MY_GUIX_MODE-enabled Next login gx-mode: MY_GUIX_MODE-enabled Choose by number (or q for no change) from the following guix modes for next login: 1) MY_GUIX_MODE-enabled 2) MY_GUIX_MODE-disabled 3) MY_GUIX_MODE-shepherd #? q No change made to current nor next guix mode. $ which -a lsblk /home/bokr/.guix-profile/bin/lsblk /usr/bin/lsblk $ which -a lsblk|xargs readlink -f /gnu/store/xymkwf57x988q8cny2is1dgzrbr9xdfi-util-linux-2.34/bin/lsblk /usr/bin/lsblk $ which -a lsblk|xargs readlink -f|xargs file /gnu/store/xymkwf57x988q8cny2is1dgzrbr9xdfi-util-linux-2.34/bin/lsblk: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/lib/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, not stripped /usr/bin/lsblk: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=4028ee9653d75f37372a56e4f53215d75c75f564, for GNU/Linux 3.2.0, stripped ┌───────────────────────────────────────────────────────┐ │ Notice "LSB pie executable" vs "LSB executable" above │ └───────────────────────────────────────────────────────┘ $ which -a lsblk|xargs readlink -f|xargs stat File: /gnu/store/xymkwf57x988q8cny2is1dgzrbr9xdfi-util-linux-2.34/bin/lsblk Size: 135560 Blocks: 272 IO Block: 4096 regular file Device: 10304h/66308d Inode: 1186253 Links: 2 Access: (0555/-r-xr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2019-11-01 02:38:11.782574923 -0700 Modify: 1969-12-31 16:00:01.000000000 -0800 Change: 2019-10-08 18:18:48.226579757 -0700 Birth: - File: /usr/bin/lsblk Size: 124992 Blocks: 248 IO Block: 4096 regular file Device: 10304h/66308d Inode: 264652 Links: 1 Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2019-11-01 02:38:55.354524750 -0700 Modify: 2019-06-27 03:04:01.000000000 -0700 Change: 2019-07-06 00:59:13.620416635 -0700 Birth: - $ ┌───────────────────────────────────────────────────────────────────┐ │ I see Access: is 0555 vs 0755, so doubt if that should be changed │ └───────────────────────────────────────────────────────────────────┘ $ which -a lsblk|xargs readlink -f|xargs readelf -h File: /gnu/store/xymkwf57x988q8cny2is1dgzrbr9xdfi-util-linux-2.34/bin/lsblk ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 ┌─────────────────────────────────────────────────────────────┐ │ Type: EXEC (Executable file) │ └─────────────────────────────────────────────────────────────┘ Machine: Advanced Micro Devices X86-64 Version: 0x1 Entry point address: 0x406440 Start of program headers: 64 (bytes into file) Start of section headers: 133640 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 56 (bytes) Number of program headers: 11 Size of section headers: 64 (bytes) Number of section headers: 30 Section header string table index: 29 File: /usr/bin/lsblk ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 ┌───────────────────────────────────────────────────────────────┐ │ Type: DYN (Shared object file) │ └───────────────────────────────────────────────────────────────┘ Machine: Advanced Micro Devices X86-64 Version: 0x1 Entry point address: 0x6c50 Start of program headers: 64 (bytes into file) Start of section headers: 123200 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 56 (bytes) Number of program headers: 11 Size of section headers: 64 (bytes) Number of section headers: 28 Section header string table index: 27 $ --8<----(from emacs shell mode, guix enabled)-----------cut here---------------end--------------->8--- I did: /usr/bin/strace -ittyko lsblkusr.strace lsblk -f in "foreign" mode and /usr/bin/strace -ittyko lsblk.strace lsblk -f in "guix mode" I used /usr/bin/strace in both cases because it has the -k option and the guix version doesn't. IDK if that could be an iffy combination, but it seemed to work. I looked at both outputs, and saw something strange in the guix mode trace which was not in the foreign version: oom references: ┌─────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ $ grep oom lsblk.strace |uniq -c │ │ 122 > /gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/lib/ld-2.29.so(oom+0x37) [0x1218] │ │ $ grep oom lsblkusr.strace │ └─────────────────────────────────────────────────────────────────────────────────────────────────────┘ Would whoever is familiar with the code have a look please? I would rather be debugging my own code ;-) --8<----(from emacs shell mode, guix enabled)-----------cut here---------------start------------->8--- $ # Both foreign and guix versions execute lsblk -h which shows the $ # -o options available -- identically: $ diff -u --report <(/usr/bin/lsblk -h) <(lsblk -h) Files /dev/fd/63 and /dev/fd/62 are identical $ # likewise the default output $ diff -u --report <(/usr/bin/lsblk) <(lsblk) Files /dev/fd/63 and /dev/fd/62 are identical $ $ # it is the -f option that calls for -o columns FSTYPE, LABEL, and UUID $ # that hits the problem (interestingly, FSAVAIL FSUSE% both work, and they were unavailable before 2.34): $ diff -u --report <(/usr/bin/lsblk -f) <(lsblk -f) --- /dev/fd/63 2019-11-01 21:11:53.517902795 -0700 +++ /dev/fd/62 2019-11-01 21:11:53.521236034 -0700 @@ -1,16 +1,16 @@ -NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT -sda -├─sda1 vfat Phanto1EFI 98AB-229C -├─sda2 ext4 d8ce4206-fc92-4248-8164-3fe5397c28fb -├─sda3 swap 59e8ffd8-a2df-4021-ba59-c8dda6215f83 -├─sda4 ext4 Phanto4ArchGx 617f2280-d34a-4dea-ac50-a1222dd18c26 -├─sda5 ext4 Phanto5ArchGxOn 71e61e41-81d0-48ac-b50f-a00668723c32 -├─sda6 ext4 Phanto6Arch e5760f87-71bc-4318-92f1-d108e5c9e332 -└─sda7 ext4 Phanto7GuixSD a60eac5f-2306-49c5-8c87-7cab28ff6d37 -sdb -└─sdb1 ext4 35c979a8-e19a-4447-bc84-47b66c0ade49 -nvme0n1 -├─nvme0n1p1 vfat PhantoV1EFI 6E3C-D410 510M 50% /boot -├─nvme0n1p2 ext4 PhantoNv2Empty 76bc8f68-126c-4a6c-8b77-afc89bd2726a -├─nvme0n1p3 swap 24151091-f47a-46e2-a6cb-e5219eddae7c [SWAP] -└─nvme0n1p4 ext4 PhantoNv4ArchGx 12eec2bf-bc81-48a8-b444-26913c078302 12.1G 72% / +NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT +sda +├─sda1 +├─sda2 +├─sda3 +├─sda4 +├─sda5 +├─sda6 +└─sda7 +sdb +└─sdb1 +nvme0n1 +├─nvme0n1p1 510M 50% /boot +├─nvme0n1p2 +├─nvme0n1p3 [SWAP] +└─nvme0n1p4 12.1G 72% / $ --8<----(from emacs shell mode, guix enabled)-----------cut here---------------end--------------->8--- I assume the column widths are computed by internally buffering the outputs called for for each heading, and values under those headings and determining the widest, and then formatting to that width plus padding. That is consistent with the above if you assume that guix's lsblk got a null string where it unsuccessfully tried to get FSTYPE, LABEL, and UUID values, e.g. showing headings and the lines ending in /boot: from above: /usr/bin/lsblk successfully retrieved -NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT -├─nvme0n1p1 vfat PhantoV1EFI 6E3C-D410 510M 50% /boot /gnu/store/xymkwf57x988q8cny2is1dgzrbr9xdfi-util-linux-2.34/bin/lsblk didn't get FSTYPE, LABEL, nor UUID +NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT +├─nvme0n1p1 510M 50% /boot > To do the same on Guix System, see the "Setuid programs" section of the > manual. You would need something along these lines in your config: > > (operating-system > [...] > (setuid-programs (cons #~(string-append #$util-linux "/bin/lsblk")) > %setuid-programs)) > > Does that work for you? I think it might "work" (produce the desired output) -- but so would intercepting lsblk in /usr/local/bin and brute forcing /usr/bin/lsblk or su -c 'lsblk -f' (didn't try, but think so, don't want to :). BTW, su -c 'lsblk -f' does "work," but I don't like that "solution" ;-) I have a hunch there's something that needs to be fixed for real, but I could well have done something stupid :) -- Regards, Bengt Richter ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#37931: Cannot guix refresh -ru util-linux to get updated lsblk 2019-11-02 14:42 ` Bengt Richter @ 2019-11-03 17:28 ` Marius Bakke 2019-11-06 15:40 ` bug#37931: util-linux dependency on udev Ludovic Courtès 2019-11-06 22:39 ` bug#37931: Cannot guix refresh -ru util-linux to get updated lsblk Bengt Richter 0 siblings, 2 replies; 7+ messages in thread From: Marius Bakke @ 2019-11-03 17:28 UTC (permalink / raw) To: Bengt Richter; +Cc: 37931 [-- Attachment #1: Type: text/plain, Size: 2695 bytes --] Bengt Richter <bokr@bokr.com> writes: > On +2019-10-28 23:29:16 +0100, Marius Bakke wrote: >> The `lsblk` program requires root privileges in order to detect file >> systems and UUIDs. I'm guessing your distribution makes it setuid root? >> > > It doesn't look like it to me (the following snip is from TTY4, where I enabled guix paths and environment, > so I can see ~/.guix-profile and /usr stuff at the same time): [...] > $ which -a lsblk|xargs readlink -f|xargs stat > File: /gnu/store/xymkwf57x988q8cny2is1dgzrbr9xdfi-util-linux-2.34/bin/lsblk > Size: 135560 Blocks: 272 IO Block: 4096 regular file > Device: 10304h/66308d Inode: 1186253 Links: 2 > Access: (0555/-r-xr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) > Access: 2019-11-01 02:38:11.782574923 -0700 > Modify: 1969-12-31 16:00:01.000000000 -0800 > Change: 2019-10-08 18:18:48.226579757 -0700 > Birth: - > File: /usr/bin/lsblk > Size: 124992 Blocks: 248 IO Block: 4096 regular file > Device: 10304h/66308d Inode: 264652 Links: 1 > Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) > Access: 2019-11-01 02:38:55.354524750 -0700 > Modify: 2019-06-27 03:04:01.000000000 -0700 > Change: 2019-07-06 00:59:13.620416635 -0700 > Birth: - > $ > ┌───────────────────────────────────────────────────────────────────┐ > │ I see Access: is 0555 vs 0755, so doubt if that should be changed │ > └───────────────────────────────────────────────────────────────────┘ Indeed, there are no setuid bits there. I had a look at the lsblkd source code, and found that it has an optional dependency on udev: https://github.com/karelzak/util-linux/blob/ccafadb7c58865f73d209fcfc74483be96cdf64d/misc-utils/lsblk-properties.c I tried building util-linux with udev support, and got the same output you expected without needing root privileges: (define-public util-linux/udev (package/inherit util-linux (name "util-linux-with-udev") (inputs `(("udev" ,eudev) ,@(package-inputs util-linux))))) Now, eudev already depends on util-linux, so adding udev support to the regular 'util-linux' package would introduce a circular dependency. I'm not sure what the best approach here is. We could add a 'util-linux-minimal' for use in package inputs, and/or add a udev-enabled variant to %base-packages. Thoughts? [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#37931: util-linux dependency on udev 2019-11-03 17:28 ` Marius Bakke @ 2019-11-06 15:40 ` Ludovic Courtès 2019-11-06 22:39 ` bug#37931: Cannot guix refresh -ru util-linux to get updated lsblk Bengt Richter 1 sibling, 0 replies; 7+ messages in thread From: Ludovic Courtès @ 2019-11-06 15:40 UTC (permalink / raw) To: Marius Bakke; +Cc: 37931 Hi, Marius Bakke <mbakke@fastmail.com> skribis: > I had a look at the lsblkd source code, and found that it has an > optional dependency on udev: > > https://github.com/karelzak/util-linux/blob/ccafadb7c58865f73d209fcfc74483be96cdf64d/misc-utils/lsblk-properties.c > > I tried building util-linux with udev support, and got the same output > you expected without needing root privileges: > > (define-public util-linux/udev > (package/inherit > util-linux > (name "util-linux-with-udev") > (inputs > `(("udev" ,eudev) > ,@(package-inputs util-linux))))) > > Now, eudev already depends on util-linux, so adding udev support to the > regular 'util-linux' package would introduce a circular dependency. > > I'm not sure what the best approach here is. We could add a > 'util-linux-minimal' for use in package inputs, and/or add a > udev-enabled variant to %base-packages. I think the latter is fine and can be done right away on ‘master’. WDYT? Ludo’. ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#37931: Cannot guix refresh -ru util-linux to get updated lsblk 2019-11-03 17:28 ` Marius Bakke 2019-11-06 15:40 ` bug#37931: util-linux dependency on udev Ludovic Courtès @ 2019-11-06 22:39 ` Bengt Richter 2020-01-08 19:14 ` Marius Bakke 1 sibling, 1 reply; 7+ messages in thread From: Bengt Richter @ 2019-11-06 22:39 UTC (permalink / raw) To: Marius Bakke; +Cc: 37931 Hi Marius, On +2019-11-03 18:28:40 +0100, Marius Bakke wrote: > Bengt Richter <bokr@bokr.com> writes: > > > On +2019-10-28 23:29:16 +0100, Marius Bakke wrote: > >> The `lsblk` program requires root privileges in order to detect file > >> systems and UUIDs. I'm guessing your distribution makes it setuid root? > >> > > > > It doesn't look like it to me (the following snip is from TTY4, where I enabled guix paths and environment, > > so I can see ~/.guix-profile and /usr stuff at the same time): > > [...] > > > > $ which -a lsblk|xargs readlink -f|xargs stat > > File: /gnu/store/xymkwf57x988q8cny2is1dgzrbr9xdfi-util-linux-2.34/bin/lsblk > > Size: 135560 Blocks: 272 IO Block: 4096 regular file > > Device: 10304h/66308d Inode: 1186253 Links: 2 > > Access: (0555/-r-xr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) > > Access: 2019-11-01 02:38:11.782574923 -0700 > > Modify: 1969-12-31 16:00:01.000000000 -0800 > > Change: 2019-10-08 18:18:48.226579757 -0700 > > Birth: - > > File: /usr/bin/lsblk > > Size: 124992 Blocks: 248 IO Block: 4096 regular file > > Device: 10304h/66308d Inode: 264652 Links: 1 > > Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) > > Access: 2019-11-01 02:38:55.354524750 -0700 > > Modify: 2019-06-27 03:04:01.000000000 -0700 > > Change: 2019-07-06 00:59:13.620416635 -0700 > > Birth: - > > $ > > ┌───────────────────────────────────────────────────────────────────┐ > > │ I see Access: is 0555 vs 0755, so doubt if that should be changed │ > > └───────────────────────────────────────────────────────────────────┘ > > Indeed, there are no setuid bits there. > > I had a look at the lsblkd source code, and found that it has an > optional dependency on udev: > > https://github.com/karelzak/util-linux/blob/ccafadb7c58865f73d209fcfc74483be96cdf64d/misc-utils/lsblk-properties.c > > I tried building util-linux with udev support, and got the same output > you expected without needing root privileges: > Sounds great ;-) > (define-public util-linux/udev > (package/inherit > util-linux > (name "util-linux-with-udev") > (inputs > `(("udev" ,eudev) > ,@(package-inputs util-linux))))) > > Now, eudev already depends on util-linux, so adding udev support to the > regular 'util-linux' package would introduce a circular dependency. > > I'm not sure what the best approach here is. We could add a > 'util-linux-minimal' for use in package inputs, and/or add a > udev-enabled variant to %base-packages. > > Thoughts? I'm a guix newbie :) I don't yet understand the internal dependency machinery of guix, so I'm wondering about the exact nature of the circularity. Is it really a kind of (let((... that needs to be a let*((... at some level? And which level of dependency are we talking about? I mean, everything is ultimately dependent on sources and translators in succession, but we identify intermediate collections and call them libraries or packages or scripts or executables etc. E.g., if part of the build sequence produces an obj library, is an interdependency between two library elements a circular dependency if that requires two passes for the linker to resolve? (i.e., the second is dependent on the library, but only as container of the other element). What is the chain of dependency that yields a user cmdline lsblk executable on my $PATH ? As a user, I don't much care beyond hoping guix pull will keep the functionality at my finger tips (thanks maintainers :), but... But once I start wanting a handy customization of something, I want it to be trivial to compose trivial things, which for me starts at a shell command line, composing a one-liner, and then writing two-line scripts when I find myself re-typing a lot, and so on, to things like examples in info guile, including C extensions. So, my thought is that whatever the solution is that puts lsblk on my $PATH, I want the system for it to be cherry-picker-friendly. By that I mean I want to be able to make tiny things from cherry-picked ("stolen" ;-) snippets/elements of something big and having the net result be minimal -- unless I really do e.g. want a busybox monolith for other reasons than puts "Hello World". Also, being a command line user, I want to be able to access any functionality from there ;-) That BTW includes graphics: I would like to be able to run any GUI program in headless mode and get graphic buffer output, or streams. Likewise, I would like guix build tools to be able e.g. to cherry-pick the sources of a browser to get the functionality that renders an html <table ...> ...</table> to sRGB buffer (assuming sources are modularized cherry-picker-friendly :) without incorporating more than necessary, (and automatically doing the license/attribution stuff ;-) IOW, sort of treating any large application's (or a kernel's! :) sources as a kind of library. Of course, I know cherry-picker-friendly is a dream, but I think it's a nice dream :) So I think it should be a design goal for FOSS to be easily snarfed. Life could be a bowl of cherries if enough people descide to be friendly ;-) -- Regards, Bengt Richter ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#37931: Cannot guix refresh -ru util-linux to get updated lsblk 2019-11-06 22:39 ` bug#37931: Cannot guix refresh -ru util-linux to get updated lsblk Bengt Richter @ 2020-01-08 19:14 ` Marius Bakke 0 siblings, 0 replies; 7+ messages in thread From: Marius Bakke @ 2020-01-08 19:14 UTC (permalink / raw) To: Bengt Richter; +Cc: 37931-done [-- Attachment #1: Type: text/plain, Size: 3853 bytes --] Bengt Richter <bokr@bokr.com> writes: > Hi Marius, > > On +2019-11-03 18:28:40 +0100, Marius Bakke wrote: >> Bengt Richter <bokr@bokr.com> writes: >> >> > On +2019-10-28 23:29:16 +0100, Marius Bakke wrote: >> >> The `lsblk` program requires root privileges in order to detect file >> >> systems and UUIDs. I'm guessing your distribution makes it setuid root? >> >> >> > >> > It doesn't look like it to me (the following snip is from TTY4, where I enabled guix paths and environment, >> > so I can see ~/.guix-profile and /usr stuff at the same time): >> >> [...] >> >> >> > $ which -a lsblk|xargs readlink -f|xargs stat >> > File: /gnu/store/xymkwf57x988q8cny2is1dgzrbr9xdfi-util-linux-2.34/bin/lsblk >> > Size: 135560 Blocks: 272 IO Block: 4096 regular file >> > Device: 10304h/66308d Inode: 1186253 Links: 2 >> > Access: (0555/-r-xr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) >> > Access: 2019-11-01 02:38:11.782574923 -0700 >> > Modify: 1969-12-31 16:00:01.000000000 -0800 >> > Change: 2019-10-08 18:18:48.226579757 -0700 >> > Birth: - >> > File: /usr/bin/lsblk >> > Size: 124992 Blocks: 248 IO Block: 4096 regular file >> > Device: 10304h/66308d Inode: 264652 Links: 1 >> > Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) >> > Access: 2019-11-01 02:38:55.354524750 -0700 >> > Modify: 2019-06-27 03:04:01.000000000 -0700 >> > Change: 2019-07-06 00:59:13.620416635 -0700 >> > Birth: - >> > $ >> > ┌───────────────────────────────────────────────────────────────────┐ >> > │ I see Access: is 0555 vs 0755, so doubt if that should be changed │ >> > └───────────────────────────────────────────────────────────────────┘ >> >> Indeed, there are no setuid bits there. >> >> I had a look at the lsblkd source code, and found that it has an >> optional dependency on udev: >> >> https://github.com/karelzak/util-linux/blob/ccafadb7c58865f73d209fcfc74483be96cdf64d/misc-utils/lsblk-properties.c >> >> I tried building util-linux with udev support, and got the same output >> you expected without needing root privileges: >> > > Sounds great ;-) > >> (define-public util-linux/udev >> (package/inherit >> util-linux >> (name "util-linux-with-udev") >> (inputs >> `(("udev" ,eudev) >> ,@(package-inputs util-linux))))) >> >> Now, eudev already depends on util-linux, so adding udev support to the >> regular 'util-linux' package would introduce a circular dependency. >> >> I'm not sure what the best approach here is. We could add a >> 'util-linux-minimal' for use in package inputs, and/or add a >> udev-enabled variant to %base-packages. >> >> Thoughts? This was finally committed in 71e0f1e9adbce4a6476a70bddabf13f6d7af2d40 and 01bb039e7b408893009d15f56cfcbdc8af70a4af. > > I'm a guix newbie :) > > I don't yet understand the internal dependency machinery of guix, > so I'm wondering about the exact nature of the circularity. > > Is it really a kind of (let((... that needs to be a let*((... > at some level? And which level of dependency are we talking about? The circular dependency is straightforward: eudev *requires* util-linux as part of its build process. Thus, eudev has util-linux as an input. That version of util-linux can not depend on eudev, because we can not build eudev without a working util-linux package. Wrt the rest of the message, I share your sentiment, and think we will get there. 'guix build --with-git-url' is pretty close already. :-) [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-01-08 19:15 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-10-26 1:22 bug#37931: Cannot guix refresh -ru util-linux to get updated lsblk Bengt Richter 2019-10-28 22:29 ` Marius Bakke 2019-11-02 14:42 ` Bengt Richter 2019-11-03 17:28 ` Marius Bakke 2019-11-06 15:40 ` bug#37931: util-linux dependency on udev Ludovic Courtès 2019-11-06 22:39 ` bug#37931: Cannot guix refresh -ru util-linux to get updated lsblk Bengt Richter 2020-01-08 19:14 ` Marius Bakke
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/guix.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).