bug#33848: Store references in SBCL-compiled code are "invisible"

[Mark H Weaver]

Ludovic Courtès  writes:
> LGTM!  Feel free to push this version or an improved one.  I think it’s
> good to have it in the upcoming release, and if it’s pushed sooner,
> we’ll have more time to react in case something’s wrong.

I pushed an improved version of the patch to 'master' as commit
1bab9b9f17256a9e4f45f5b0cceb8b52e0a1b1ed.

 Thanks,
   Mark

bug#47791: util-linux fails to build on the Hurd (some tests fail)

[Maxime Devos]

On my x86_64-linux-gnu with a childhurd, util-linux fails to compile.

$ guix build util-linux --system=i586-gnu
> [exporting path ...]
> offloading build of /gnu/store/nih[...]8fxg-util-linux-2.35.1.drv to 
> 'localhost'
> [log, attached in e-mail]

$ guix --version
> guix (GNU Guix) 3f3d66377c052d6121b46db53391614329fa4ffb

Some bits that seem relevant:

>fdisk: MBR - sort ... OK
>fdisk: invalid input tests... FAILED (fdisk/oddinput)
>fdisk: sunlabel tests ... OK
> [...]
>hwclock: system to hw... SKIPPED (no root permissions)
>ipcs: headers... FAILED (ipcs/headers)
>ipcs: limits overflow... SKIPPED (no root permissions)
> [...]
> : ends-with   ... OK
> : mountpoint  ... FAILED 
> (libmount/utils-mountpoint)
> : mountpoint-subdir   ... SKIPPED (no /proc)
> [...]
>  3 tests of 204 FAILED

To be investigated ...

Greeings,
Maxime.


signature.asc
Description: This is a digitally signed message part

bug#47791: Acknowledgement (util-linux fails to build on the Hurd (some tests fail))

[Maxime Devos]

Forgot to attach the log.


h1bb689vfickgnxd52q6rpnngy8fxg-util-linux-2.35.1.drv.bz2
Description: application/bzip


signature.asc
Description: This is a digitally signed message part

bug#47064: [racket-users] bytevector-uncompress: internal error uncompressing

[Mark H Weaver]

Hi Philip,

Philip McGrath  writes:

> On 4/14/21 1:54 AM, Mark H Weaver wrote:
>> In this case, I suspect that within a *.zo file, a Guix store item name
>> was split into pieces, with the hash and "-" together in one piece but
>> split somewhere between the "-" and the last byte of the store item.
>> This results in corruption of the bytes following that piece.

FYI, I've now verified this suspicion.  Here's precisely the corruption
that occurred:

--8<---cut here---start->8---
mhw@jojen ~$ diff -u <(hexdump -C $(guix build racket 
--no-grafts)/share/racket/pkgs/gui-lib/mred/private/wx/gtk/compiled/utils_rkt.zo)
 \
 <(hexdump -C $(guix build racket
)/share/racket/pkgs/gui-lib/mred/private/wx/gtk/compiled/utils_rkt.zo)
--- /dev/fd/63  2021-04-15 04:36:01.240427788 -0400
+++ /dev/fd/62  2021-04-15 04:36:01.240427788 -0400
@@ -2047,11 +2047,11 @@
 7fe0  49 8b 6f 0b 08 00 09 d0  02 2f d7 fe d0 02 07 f2  |I.o../..|
 7ff0  02 0b 00 62 12 04 00 12  12 05 00 3e 12 06 00 17  |...b...>|
 8000  12 07 3d 02 f0 28 32 02  04 75 6e 69 78 00 1e 26  |..=..(2..unix..&|
-8010  5a 2f 67 6e 75 2f 73 74  6f 72 65 2f 69 72 6a 61  |Z/gnu/store/irja|
-8020  6e 35 77 71 37 6a 32 35  66 61 32 6d 36 6e 32 78  |n5wq7j25fa2m6n2x|
-8030  68 6c 38 6d 67 6c 73 61  71 78 6e 34 2d 49 02 02  |hl8mglsaqxn4-I..|
-8040  a5 02 fd 01 2b 73 76 67  2d 32 2e 34 30 2e 30 2f  |+svg-2.40.0/|
-8050  6c 69 62 2f c2 02 39 2e  73 6f 9b 02 1d 43 9b 02  |lib/..9.so...C..|
+8010  5a 2f 67 6e 75 2f 73 74  6f 72 65 2f 36 66 32 30  |Z/gnu/store/6f20|
+8020  38 64 61 6b 32 77 64 62  30 61 72 31 68 6e 38 79  |8dak2wdb0ar1hn8y|
+8030  6b 31 39 30 79 77 67 67  69 77 33 63 2d 67 64 6b  |k190ywggiw3c-gdk|
+8040  2d 70 69 78 62 75 66 2b  73 76 67 2d 32 2e 34 30  |-pixbuf+svg-2.40|
+8050  2e 30 62 2f c2 02 39 2e  73 6f 9b 02 1d 43 9b 02  |.0b/..9.so...C..|
 8060  57 30 07 01 02 0e 35 00  05 a2 02 c3 12 08 0c 26  |W05&|
 8070  00 18 12 09 02 2c 84 00  55 02 0f 54 02 09 13 7f  |.,..U..T|
 8080  54 02 1b 49 54 02 15 32  54 02 15 1c 54 02 1f 01  |T..IT..2T...T...|
--8<---cut here---end--->8---

> Yes, I agree with this diagnosis.
>
> It seems the discussion has become a bit fragmented, since Jack first 
> reported one set of symptoms in  and 
> you then reported another in  (with 
> much better forensics than I'd found on my own—thanks!).
>
> Both issues should have been fixed (at least with respect to Racket) by 
> my patch in , which was applied on 
> Monday.

Sounds good, thank you!

  Mark

bug#47662: Replace/Remove UUID request in config.scm

[Ludovic Courtès]

Hi,

bo0od  skribis:

> When someone taking the manual-cli installation of GuixOS, And
> reaching where he will fill the config.scm, Parts of it really
> annoying to fill like UUID. If possible change it to the partition
> name only like sda1,xvda1..etc and let guix take the needed uuid from
> there (or any other method possible).

When installing Guix System manually, you are free to choose how to
refer to devices: by their /dev name (not recommended), by UUID, or by
file system label.

  
https://guix.gnu.org/manual/en/html_node/File-Systems.html#index-file_002dsystem

The graphical installer is meant to simplify the initial configuration:
you do the initial installation with it, and from there you can tweak
the generated config—easier than starting from a blank page.

I’m closing this bug because I don’t see anything more we could do.

Thanks,
Ludo’.

bug#47631: Add graphical installation and solve tons of headache

[Ludovic Courtès]

Hi,

bo0od  skribis:

> According to my communications on IRC i see that guix doesnt want to
> have an offline installation, Which mean it need internet connection 
> available at the installation process.

More specifically, we cannot guarantee that an off-line installation
would work because it depends on the software and services you’ll
choose.

> This is fine except when user having either static-ip or using VM
> which doesnt give readable network interface to the distro inside it
> (falling into same category of static-ip).
>
> solving/giving:
>
> - Adding static IP and so as manually installing is not well
>   documented and need knowledge and skills (very faraway to be handled
>  by new users)check #47630

Right, this one’s already filed.

> - Easiness of modifying things e.g instead of using tens of commands
>   it will be replaced with couple of clicks and for surely less typing 
> (compare gparted vs parted steps or network-manager vs ip commands and
> so on). You can checkout many distros whos giving this opportunity
> like nixos, trisquel/triskel, mint...etc

Did you try the graphical installation?

  https://guix.gnu.org/en/videos/system-graphical-installer/

It’s key strokes rather than clicks, but I think it addresses most of
the issues you describe.

> - Give trial usage of the distro for the user before installing it

Did you try the live VM image?

  https://guix.gnu.org/en/download/

I’m closing because I don’t see anything actionable.  Please file issues
focused on specific problems.

Thanks,
Ludo’.

bug#47748: Packages which cant be find/removed by guix remove

[Julien Lepiller]

Le 15 avril 2021 06:16:51 GMT-04:00, bo0od  a écrit :
> > guix operates on explicitely installed packages, dependencies are 
>implementation details. It just doesn't work like apt or other package 
>managers. New tool, new usages.
>
>So how user gonna delete preinstalled packages which are not installed 
>by guix install x?
>
>wpa-supplicant is none essential package when there is no wifi, how
>user 
>gonna delete it?
>
>no easy way to do it (i mean easy as similarly to apt/dnf..etc) thats 
>the whole issue
>
>Maybe something like synapse should exist to do this job in guixos?
>
>I dunno, But current idea of no clean,easy way to delete these packages
>
>(or similar) just bad usability experience.

Again, you have the wrong idea. wpa-supplicant is not installed, but its 
service is running, because it's part oh %desktop-services. No amount of guix 
remove will help you, because it can only wosk on user (or root) profiles, not 
the system services.

To remove it, you need to remove it from your os declaration (/etc/config.scm) 
with something like this:

(modify-services %desktop-services
  (delete wpa-supplicant-service-type))

(Or something similar, the manual suggests the above for removing gdm for 
instance, but there seems to be doubts about whether that's actually correct or 
not)

Then reconfigure your new system:

sudo guix system reconfigure /etc/config.scm

Now, your new generation is not running wpa-supplicant anymore (you can check 
sudo herd status for that). Older generations still have wpa-supplicant, so 
it's still hanging around in the store. To purge it, you can delete those 
generations (loosing all possibility ofqrolling back to them):

sudo guix system delete-generations
guix gc # to effectively remove unnecessary store items

After that, you should not have wpa-supplicant in the store anymore.

HTH!

>
>
>
>
>Julien Lepiller:
>> Le 14 avril 2021 12:31:31 GMT-04:00, bo0od  a écrit
>:
 In particular, there are multiple
 profiles, and each of them could contain avahi or a reference to
>>> avahi.
>>>
>>> That doesnt address the issue im talking about, why guix remove
>doesnt
>>> recognize the package that number 1 , number 2 if the package will
>>> break
>>> something important guix should say that after processing the
>command
>>> guix remove x package then show warning message this x package is
>>> dependency of xyz which might break your system would you like to
>>> proceed?  <- something like that.
>> 
>> guix removc only operates on your user profile, which doesn't contain
>avahi. That's what it's telling you.
>> 
>> You can check that you do not have avahi installed in your profile
>with
>> 
>> guix package -l
>> 
>> And that none of your installed packages depend on it:
>> 
>> guix size `readlink -f ~/.guix-profile`
>> 
>> Guix operates only on explicitely installed packages, which I think
>is much cleaner and allows it to be more predictable. Compare, if A
>depends on B and C, initially you have all three.
>> 
>> apt install B then apt remove A -> nothing
>> apt remove A then apt install B -> only B
>> 
>> guix install B then guix remove A -> B and C
>> guix remove A then guix install B -> B and C
>> 
>> guix operates on explicitely installed packages, dependencies are
>implementation details. It just doesn't work like apt or other package
>managers. New tool, new usages.
>> 
>>>
 Second, your operating-system declaration apparently is running
 the avahi server. Since you didn't share it, I don't know if it
>comes
 from a service dependency or if it's declared explicitely
>>>
>>> do you mean config.scm? if you need something type the command or
>where
>>>
>>> and i will bring it to you.
>> 
>> Yes, I meant /etc/config.scm (well, by convention, as you can always
>create the file elsewhere). But I don't need it anymore, since I
>learned it's actually part of the default %desktop-services.
>> 
>>>
 When you run "guix remove" as user, it only affects your user
>>> profile,
 in which there is no avahi or wpa-supplicant package. Also note
>that,
>>> if
 any of your user's profile had a dependency on avahi, "guix remove
 avahi" would not have any effect on it either, because it's not
 installed explicitely, it's only present in the store to satisfy a
 dependency.
>>>
>>> You dont consider that an issue when someone use guix remove x then
>ops
>>>
>>> guess what nothing indicate something can be done, and guess what no
>>> error message gonna tell you what the hell going on. Least can be
>said
>>> about this bad usability.
>> 
>> It's not "no message", is it? I lust tried "guix remove hello", and I
>don't have hello in my profile. It told me (in red): error: package
>'hello' not found in profile.
>> 
>> Not sure how it could be more explicit.
>> 
>>>
 I hope this is helpful :)
>>>
>>> Appreciated :)
>>>
>>> Julien Lepiller:
 Le Tue, 13 Apr 2021 12:46:19 +,
 bo0od  a écrit :

> Hi There,
>
> I saw some packages insta

bug#47786: Several build --keep-failed result in wrong env variables

[Dmitry Matveyev]

Hello,

I use guix on Arch Linux, version
050be36cbf3a42199f64f2e44c59f1cb1b3afab5.

Several invocations of guix build --keep-failed creates directories in
/tmp like this one guix-build-hello-2.10.drv-0 for 1st build and then
guix-build-hello-2.10.drv-1 for 2nd and so on (with last digit
increasing). But environment variables for all of them are set to point
to the very 1st directory.

Reproduce:

$ guix build --check --keep-failed hello
^C
$ guix build --check --keep-failed hello
^C
$ cd /tmp/guix-build-hello-2.10.drv-1/
$ grep PWD environment-variables
export OLDPWD
export PWD="/tmp/guix-build-hello-2.10.drv-0/hello-2.10"

Here although we are in directory /tmp/guix-build-hello-2.10.drv-1/, PWD
is set to .drv-0 directory.

Regards,
Dmitry.

bug#42414: Packages Installed With GNU Guix not finding Correct Glibc

[Bonface Munyoki K .]

"Frederick M. Muriithi"
 writes:

> After wrestling with this issue some more and
> trying to figure out the cause, I finally fingered
> Ubuntu as the culprit.
>
> Something in my upgrade from Ubuntu 18.04 LTS to
> Ubuntu 20.04 LTS subtly broke my system. Also I
> think a recent change in guix preventing me from
> doing a 'guix pull' unless logged in as root might
> have had something to do with it.
>
> I'm not quite sure what the final cause was, but I
> fixed the issue, and did a [quick
> write-up](https://fredmanglis.me.ke/blog/guix-apps-not-finding-glibc.html
> ) to help anyone else experiencing the issue.
>

This seems to have been fixed, so going ahead to
close this :)

tl;dr fix: Updating the package seemed to fix
things.


-- 
Bonface M. K. D4F09EB110177E03C28E2FE1F5BBAE1E0392253F
Humble GNU Emacs User / Bearer of scheme-y parens
Curator:  / Twitter: @BonfaceKilz


signature.asc
Description: PGP signature

bug#47660: Add link to the ticket when someone reply

[Bonface Munyoki K .]

bo0od  writes:

> what are you talking about? who uses PGP/GPG for
> a public ticket tracking system?...
>

I do. I sign my e-mails as a guarantee to my
recipients that what you get is truly from
me. That plus my mail client makes that-- signing
emails-- way easy to do. I also sign all my
commits, even on the major platforms. FWIW, even
on GH, and GL, you could sign your emails when
replying to an email, thereby having the
recipients on the Cc see your pgp/ gpg signature,
while GL/ GH scrapes it off when displaying it's
contents. However, there are people who sign email
inline. Here's one such example:
https://github.com/alezost/guix.el/issues/39

PS: If you use gnus from Emacs, you should read:
https://www.gnu.org/software/emacs/manual/html_node/message/Signing-and-encryption.html#Signing-and-encryption
In my Emacs, I have:

--8<---cut here---start->8---
(use-package mm-encode
  :config (setq mm-encrypt-option 'guided) (setq
  mm-sign-option 'guided))

(use-package mml-sec
  :config (setq mml-secure-openpgp-encrypt-to-self
  t) (setq mml-secure-openpgp-sign-with-sender t)
  (setq mml-secure-smime-encrypt-to-self t) (setq
  mml-secure-smime-sign-with-sender t))

(use-package epa-file
  :config (setq
  epa-file-cache-passphrase-for-symmetric-encryption
  nil))
--8<---cut here---end--->8---


> gitlab,github,trac...etc all giving the ticket
> URL on the bottom of the message nothing with
> magic im suggesting here.
>
> Maxime Devos:
>> On Fri, 2021-04-09 at 20:44 +, bo0od wrote:
>>> This work or i search for it also work, But we
>>> are talking making things much easier and its
>>> possible through providing the link directly
>>> to the ticket in bottom, I believe this
>>> practice followed by all major ticketing
>>> systems,platforms,projects.. So i dont
>>> understand whats the big deal having it here
>>> as well.
>> Mangling e-mails can cause all kinds of
>> trouble.  It would mess up git patches, break
>> messages signed with PGP or S/MIME (does anyone
>> here actually use S/MIME?), makes some headers
>> used for spam detection (and more generally,
>> detecting forged mails) invalid, which will
>> lead to messages from the mailing list and
>> @debbugs.gnu.org be marked as spam ...
>> Greetings, Maxime.
>> 
>
>
>
>

-- 
Bonface
M. K. D4F09EB110177E03C28E2FE1F5BBAE1E0392253F
Humble GNU Emacs User / Bearer of scheme-y parens
Curator:  / Twitter:
@BonfaceKilz


signature.asc
Description: PGP signature

bug#36508: GDM files have incorrect owner after temporarily removing service

[Ludovic Courtès]

Hi,

Brendan Tildesley  skribis:

>> On 04/14/2021 12:32 PM Ludovic Courtès  wrote:

[...]

>> The patch Brendan posted LGTM (though I’m surprised the directory itself
>> can have the right UID/GID while files inside it don’t; perhaps this was
>> made possible by 2161820ebbbab62a5ce76c9101ebaec54dc61586, which chowns
>> the home directory unconditionally.)
>> 
>> Note that there are other places, in addition to GDM, where we
>> forcefully reset the UID/GID of the home directory (e.g., for the
>> ‘knot-resolver’ service.)
>> 
>> My preferred solution to this would be to unconditionally chown -R home
>> directories upon activation (for efficiency, it would be best if we
>> could do that if and only if the home directory itself has wrong
>> ownership).  Thoughts?
>> 
> I'm confused. It sounds like you're suggesting to add the very IF condition 
> that my
> patch removes from %gdm-activation in order to fix the problem.

I’d like to understand why the ‘if’ the patch removes was problematic.
I think it relates to the commit above, but that needs more
investigation.

Ludo’.

bug#47631: Add graphical installation and solve tons of headache

[Ludovic Courtès]

Hi,

bo0od  skribis:

>> Did you try the graphical installation?
>>
>>https://guix.gnu.org/en/videos/system-graphical-installer/
>>
>> It’s key strokes rather than clicks, but I think it addresses most of
>> the issues you describe.
>
> Yes i do know this, But whats different between what guix is doing and
> others are doing (examples i gave above), They give you access to GUI
> of their distro without internet and from within this live GUI access
> to the distro you can configure the internet/partition..etc (easily 
> specially for first time users) using GUI tools without internet (you
> can even test the distro without the need to install it)

Letting users use GUI (or non-GUI) tools by themselves doesn’t look
appealing to me.  We made the choice to provide a guided installer,
similar to that of Debian and other distros, such that users don’t have
to figure out by themselves that they need to run gparted, follow steps,
etc.

> Thats what im requesting not what is currently happening.
>
>> Did you try the live VM image?
>>
>>https://guix.gnu.org/en/download/
>
> What? where?

Search for “QEMU”.

>> I’m closing because I don’t see anything actionable.  Please file issues
>> focused on specific problems.
>
> Guix need to improve itself when first time initiated, Please check
> other projects like NixOS,Triskel,Mint,Ubuntu...etc

I contributed to NixOS long ago, and unless things have changed, it
doesn’t have a guided installer.

> If you dont like that live graphical gui access, then do it as debian
> is doing it which give you proper gui screen specifically intended to 
> configure your internet then you can proceed with the installation.

So I guess your primary request is about giving access to the GUIs.
That comes at a cost (the ISO is already quite big) but that’s something
we could consider.

For now, our focus is on improving the guided installer itself.

Thanks,
Ludo’.

bug#47748: Packages which cant be find/removed by guix remove

[bo0od]

> You seem to want it to do something different than it was intended to
> do, although I'm not precisely sure what that is.  Do you want it to try
> to purge all copies of the given package from /gnu/store?  If so, that
> might require deleting (or modifying) older system generations and older
> user profiles, which would interfere with rollback functionality.

Isnt this the standard understanding of deleting a package whether in 
GNU/Linux or Windows or Mac? If user has the root rights he should be 
able to delete software x, otherwise software x just hanging there 
forever and to delete it someone needs a hell of steps to do that and if 
so then this is can have usability issues , and so as security issues. 
usability issues are clear like the example above which i want to delete 
x using package manager (Thats gnu/linux way of deleting packages if 
mistaken correct me) then it wont be deleted. For security issues if x 
package is outdated and/or got widely exploited security vulnerability 
it just wont be gone from the distro (least we can say easily) leading 
to permanent vulnerability in the OS.


> Or perhaps you want it to automatically update all user profiles, as well
> as the system, to avoid depending on that package, directly or
> indirectly?  If so, there are a couple of problems with that: (1) on
> multi-user systems (which is admittedly becoming an edge case) it would
> violate the principle that each user should have control over their own
> profiles, and (2) it would apparently involve automagically editing your
> OS configuration file to remove any packages or services that depend
> (directly or indirectly) on the specified packages.

So you see for example wpa-supplicant is not essential package for an OS 
which doesnt use wifi, Yet in guix i cant just delete it using guix 
remove it or sudo guix remove it, I find this annoying to have something 
like this happening within my OS.


Check main distros like Debian or Fedora and i want to know where is 
that avahi or wpa-supplicant (god know how many more) cant be removed?


Btw even packages which might break the distro you can delete them if 
you have root rights using just the package manager with the same simple 
command.


> Nonetheless, I very much appreciate your feedback.  I suspect that many
> other people experimenting with Guix feel as you do, but that some of
> them are simply walking away in silence.

Sure anytime, Thanks to you 2 

Mark H Weaver:

Hi,

bo0od  writes:


  > In particular, there are multiple
  > profiles, and each of them could contain avahi or a reference to avahi.

That doesnt address the issue im talking about, why guix remove doesnt
recognize the package that number 1 , number 2 if the package will break
something important guix should say that after processing the command
guix remove x package then show warning message this x package is
dependency of xyz which might break your system would you like to
proceed?  <- something like that.


This seems to be based on a misunderstanding about what "guix remove" is
intended to do.  As Julien indicated, it is _only_ meant to remove the
given packages from the set of *explicitly-requested* packages installed
in your user profile.  More precisely, it creates a _new_ user profile
that's the same as the previous one, but with some packages removed from
the set of explicitly-requested packages.  It _never_ deletes anything.

You seem to want it to do something different than it was intended to
do, although I'm not precisely sure what that is.  Do you want it to try
to purge all copies of the given package from /gnu/store?  If so, that
might require deleting (or modifying) older system generations and older
user profiles, which would interfere with rollback functionality.  Or
perhaps you want it to automatically update all user profiles, as well
as the system, to avoid depending on that package, directly or
indirectly?  If so, there are a couple of problems with that: (1) on
multi-user systems (which is admittedly becoming an edge case) it would
violate the principle that each user should have control over their own
profiles, and (2) it would apparently involve automagically editing your
OS configuration file to remove any packages or services that depend
(directly or indirectly) on the specified packages.


From my perspective, it seems that you have expectations about how

package managers should work based on your experience with traditional
GNU/Linux distributions.  Guix is based on a radically different
approach which takes some time to become acquainted with.  Perhaps our
documentation needs to be improved to better manage user expectations.

It reminds me of how many developers responded when asked to switch to
Git from CVS or Subversion.  Many developers found that transition
difficult, and considered it a flaw in Git that it failed to conform to
their expectations.

Nonetheless, I very much appreciate your feedback.  I suspect that many
other people experimenti

bug#47797: Segmentation fault when calling 'git-predicate' in a package file

[Ingo Ruhnke]

Calling git-predicate from a simple package file causes guix to segfault.
Bisect traced it down to this commit:


commit c1940fde43c7aca37d67589cc5cb248086d17d56
Author: Ludovic Courtès 
Date:   Fri Mar 19 11:51:20 2021 +0100

git-download: Autoload Guile-Git.

* guix/git-download.scm: Autoload (git ...) modules.


Steps to reproduce the issue:

$ cat mypkg.scm
(use-modules (guix git-download))
(git-predicate "/tmp")

$ guix package -f mypkg.scm
Segmentation fault (core dumped)

$ guix --version
guix (GNU Guix) 1bab9b9f17256a9e4f45f5b0cceb8b52e0a1b1ed

(gdb) where
#0  0x in ?? ()
#1  0x7fffeb0f44c4 in git_buf_try_grow () from
/gnu/store/jil14glx1j7mrj4cvzmw876rzyv7i960-libgit2-1.1.0/lib/libgit2.so
#2  0x7fffeb0f47a5 in git_buf_set () from
/gnu/store/jil14glx1j7mrj4cvzmw876rzyv7i960-libgit2-1.1.0/lib/libgit2.so
#3  0x7fffeb146fe7 in git_path_prettify () from
/gnu/store/jil14glx1j7mrj4cvzmw876rzyv7i960-libgit2-1.1.0/lib/libgit2.so
#4  0x7fffeb15b3ad in find_repo () from
/gnu/store/jil14glx1j7mrj4cvzmw876rzyv7i960-libgit2-1.1.0/lib/libgit2.so
#5  0x7fffeb15c28b in git_repository_discover () from
/gnu/store/jil14glx1j7mrj4cvzmw876rzyv7i960-libgit2-1.1.0/lib/libgit2.so
#6  0x77c1266d in ffi_call_unix64 () from
/gnu/store/bw15z9kh9c65ycc2vbhl2izwfwfva7p1-libffi-3.3/lib/libffi.so.7
#7  0x77c10ac0 in ffi_call_int () from
/gnu/store/bw15z9kh9c65ycc2vbhl2izwfwfva7p1-libffi-3.3/lib/libffi.so.7
#8  0x77edefbe in scm_i_foreign_call () from
/gnu/store/q8brh7j5mwy0hbrly6hjb1m3wwndxqc8-guile-3.0.5/lib/libguile-3.0.so.1
#9  0x77f4d904 in foreign_call () from
/gnu/store/q8brh7j5mwy0hbrly6hjb1m3wwndxqc8-guile-3.0.5/lib/libguile-3.0.so.1
#10 0x77f54118 in vm_regular_engine () from
/gnu/store/q8brh7j5mwy0hbrly6hjb1m3wwndxqc8-guile-3.0.5/lib/libguile-3.0.so.1
#11 0x77f555b5 in scm_call_n () from
/gnu/store/q8brh7j5mwy0hbrly6hjb1m3wwndxqc8-guile-3.0.5/lib/libguile-3.0.so.1
#12 0x77ed2d27 in scm_primitive_eval () from
/gnu/store/q8brh7j5mwy0hbrly6hjb1m3wwndxqc8-guile-3.0.5/lib/libguile-3.0.so.1
#13 0x77ed2d83 in scm_eval () from
/gnu/store/q8brh7j5mwy0hbrly6hjb1m3wwndxqc8-guile-3.0.5/lib/libguile-3.0.so.1
#14 0x77f2b830 in scm_shell () from
/gnu/store/q8brh7j5mwy0hbrly6hjb1m3wwndxqc8-guile-3.0.5/lib/libguile-3.0.so.1
#15 0x77eea73d in invoke_main_func () from
/gnu/store/q8brh7j5mwy0hbrly6hjb1m3wwndxqc8-guile-3.0.5/lib/libguile-3.0.so.1
#16 0x77eccb0a in c_body () from
/gnu/store/q8brh7j5mwy0hbrly6hjb1m3wwndxqc8-guile-3.0.5/lib/libguile-3.0.so.1
#17 0x77f54149 in vm_regular_engine () from
/gnu/store/q8brh7j5mwy0hbrly6hjb1m3wwndxqc8-guile-3.0.5/lib/libguile-3.0.so.1
#18 0x77f555b5 in scm_call_n () from
/gnu/store/q8brh7j5mwy0hbrly6hjb1m3wwndxqc8-guile-3.0.5/lib/libguile-3.0.so.1
#19 0x77ed1bba in scm_call_2 () from
/gnu/store/q8brh7j5mwy0hbrly6hjb1m3wwndxqc8-guile-3.0.5/lib/libguile-3.0.so.1
#20 0x77ed33ba in scm_c_with_exception_handler () from
/gnu/store/q8brh7j5mwy0hbrly6hjb1m3wwndxqc8-guile-3.0.5/lib/libguile-3.0.so.1
#21 0x77f4ac3d in scm_c_catch () from
/gnu/store/q8brh7j5mwy0hbrly6hjb1m3wwndxqc8-guile-3.0.5/lib/libguile-3.0.so.1
#22 0x77ecd0b3 in scm_i_with_continuation_barrier () from
/gnu/store/q8brh7j5mwy0hbrly6hjb1m3wwndxqc8-guile-3.0.5/lib/libguile-3.0.so.1
#23 0x77ecd145 in scm_c_with_continuation_barrier () from
/gnu/store/q8brh7j5mwy0hbrly6hjb1m3wwndxqc8-guile-3.0.5/lib/libguile-3.0.so.1
#24 0x77f496df in with_guile () from
/gnu/store/q8brh7j5mwy0hbrly6hjb1m3wwndxqc8-guile-3.0.5/lib/libguile-3.0.so.1
#25 0x77c56a68 in GC_call_with_stack_base () from
/gnu/store/iycnpxxrg8m9wf9w58d6zvp9sdby6m9d-libgc-7.6.12/lib/libgc.so.1
#26 0x77f499f8 in scm_with_guile () from
/gnu/store/q8brh7j5mwy0hbrly6hjb1m3wwndxqc8-guile-3.0.5/lib/libguile-3.0.so.1
#27 0x77eea8b2 in scm_boot_guile () from
/gnu/store/q8brh7j5mwy0hbrly6hjb1m3wwndxqc8-guile-3.0.5/lib/libguile-3.0.so.1
#28 0x0040119a in main ()

bug#47631: Add graphical installation and solve tons of headache

[bo0od]

> Did you try the graphical installation?
>
>https://guix.gnu.org/en/videos/system-graphical-installer/
>
> It’s key strokes rather than clicks, but I think it addresses most of
> the issues you describe.

Yes i do know this, But whats different between what guix is doing and 
others are doing (examples i gave above), They give you access to GUI of 
their distro without internet and from within this live GUI access to 
the distro you can configure the internet/partition..etc (easily 
specially for first time users) using GUI tools without internet (you 
can even test the distro without the need to install it)


Thats what im requesting not what is currently happening.

> Did you try the live VM image?
>
>https://guix.gnu.org/en/download/

What? where?

> I’m closing because I don’t see anything actionable.  Please file issues
> focused on specific problems.

Guix need to improve itself when first time initiated, Please check 
other projects like NixOS,Triskel,Mint,Ubuntu...etc



If you dont like that live graphical gui access, then do it as debian is 
doing it which give you proper gui screen specifically intended to 
configure your internet then you can proceed with the installation.


Otherwise guix is useless case specially for new users in places where 
internet need to be configured manually (adding IP,Gateway,Netmask... 
manually).


Ludovic Courtès:

Hi,

bo0od  skribis:


According to my communications on IRC i see that guix doesnt want to
have an offline installation, Which mean it need internet connection
available at the installation process.


More specifically, we cannot guarantee that an off-line installation
would work because it depends on the software and services you’ll
choose.


This is fine except when user having either static-ip or using VM
which doesnt give readable network interface to the distro inside it
(falling into same category of static-ip).

solving/giving:

- Adding static IP and so as manually installing is not well
   documented and need knowledge and skills (very faraway to be handled
  by new users)check #47630


Right, this one’s already filed.


- Easiness of modifying things e.g instead of using tens of commands
   it will be replaced with couple of clicks and for surely less typing
(compare gparted vs parted steps or network-manager vs ip commands and
so on). You can checkout many distros whos giving this opportunity
like nixos, trisquel/triskel, mint...etc


Did you try the graphical installation?

   https://guix.gnu.org/en/videos/system-graphical-installer/

It’s key strokes rather than clicks, but I think it addresses most of
the issues you describe.


- Give trial usage of the distro for the user before installing it


Did you try the live VM image?

   https://guix.gnu.org/en/download/

I’m closing because I don’t see anything actionable.  Please file issues
focused on specific problems.

Thanks,
Ludo’.

bug#47748: Packages which cant be find/removed by guix remove

[bo0od]

> guix remove: error: package 'm17n-lib' not found in profile
> Hint: All users have their own profiles.  To remove packages from the 
profile

> of the root user, run "sudo guix remove PACKAGES" or equivalent.

yeah very nice one, except that "sudo guix remove package" doesnt work :(

This is how its done in debian/fedora, for e.g this is what debian error 
give if apt needs root rights to delete a package:


"user@host:~$ apt remove hexchat
E: Could not open lock file /var/lib/dpkg/lock-frontend - open (13: 
Permission denied)
E: Unable to acquire the dpkg frontend lock 
(/var/lib/dpkg/lock-frontend), are you root?"


This is what it shows in Fedora:

"[user@host ~]$ dnf remove wpa-supplicant
Error: This command has to be run with superuser privileges (under the 
root user on most systems)."


But like i said current situation in guix is not about using sudo guix 
or guix alone.


Maxime Devos:

On Wed, 2021-04-14 at 16:31 +, bo0od wrote:

  > Second, your operating-system declaration apparently is running
  > the avahi server. Since you didn't share it, I don't know if it comes
  > from a service dependency or if it's declared explicitely

do you mean config.scm?


I'm not Julien Lepiller, but I believe that's wat asked for
-- the file with the (operating-system ...) declaration.


if you need something type the command or where
and i will bring it to you.

It's the *file* ‘we’ need.  (Well, the file JL needs.)
It's not a command you need to type, it's a file you need
to attach to the e-mail.


  > When you run "guix remove" as user, it only affects your user profile,
  > in which there is no avahi or wpa-supplicant package. Also note that, if
  > any of your user's profile had a dependency on avahi, "guix remove
  > avahi" would not have any effect on it either, because it's not
  > installed explicitely, it's only present in the store to satisfy a
  > dependency.

You dont consider that an issue when someone use guix remove x then ops
guess what nothing indicate something can be done, and guess what no
error message gonna tell you what the hell going on. Least can be said
about this bad usability.


Currently the error message when removing a package not existing in the profile
is:

$ guix remove m17n-lib
guix remove: error: package 'm17n-lib' not found in profile

What do you think of adding a few hints?  Some ideas:

guix remove: error: package 'm17n-lib' not found in profile
Hint: All users have their own profiles.  To remove packages from the profile
of the root user, run "sudo guix remove PACKAGES" or equivalent.
Hint: On Guix System, packages can defined in the operating system declaration.
These are not affected by "guix remove PACKAGES".

and, when applicable:

Hint: 'm17n-lib' is propagated from 'MANUALLY-INSTALLED-PACKAGE', via N 
intermediate
packages.  Consider running "guix remove MANUALLY-INSTALLED-PACKAGE" instead.

Would that have been helpful to you?

Greetings,
Maxime.

bug#47748: Packages which cant be find/removed by guix remove

[bo0od]

> guix operates on explicitely installed packages, dependencies are 
implementation details. It just doesn't work like apt or other package 
managers. New tool, new usages.


So how user gonna delete preinstalled packages which are not installed 
by guix install x?


wpa-supplicant is none essential package when there is no wifi, how user 
gonna delete it?


no easy way to do it (i mean easy as similarly to apt/dnf..etc) thats 
the whole issue


Maybe something like synapse should exist to do this job in guixos?

I dunno, But current idea of no clean,easy way to delete these packages 
(or similar) just bad usability experience.





Julien Lepiller:

Le 14 avril 2021 12:31:31 GMT-04:00, bo0od  a écrit :

In particular, there are multiple
profiles, and each of them could contain avahi or a reference to

avahi.

That doesnt address the issue im talking about, why guix remove doesnt
recognize the package that number 1 , number 2 if the package will
break
something important guix should say that after processing the command
guix remove x package then show warning message this x package is
dependency of xyz which might break your system would you like to
proceed?  <- something like that.


guix removc only operates on your user profile, which doesn't contain avahi. 
That's what it's telling you.

You can check that you do not have avahi installed in your profile with

guix package -l

And that none of your installed packages depend on it:

guix size `readlink -f ~/.guix-profile`

Guix operates only on explicitely installed packages, which I think is much 
cleaner and allows it to be more predictable. Compare, if A depends on B and C, 
initially you have all three.

apt install B then apt remove A -> nothing
apt remove A then apt install B -> only B

guix install B then guix remove A -> B and C
guix remove A then guix install B -> B and C

guix operates on explicitely installed packages, dependencies are 
implementation details. It just doesn't work like apt or other package 
managers. New tool, new usages.




Second, your operating-system declaration apparently is running
the avahi server. Since you didn't share it, I don't know if it comes
from a service dependency or if it's declared explicitely


do you mean config.scm? if you need something type the command or where

and i will bring it to you.


Yes, I meant /etc/config.scm (well, by convention, as you can always create the 
file elsewhere). But I don't need it anymore, since I learned it's actually 
part of the default %desktop-services.




When you run "guix remove" as user, it only affects your user

profile,

in which there is no avahi or wpa-supplicant package. Also note that,

if

any of your user's profile had a dependency on avahi, "guix remove
avahi" would not have any effect on it either, because it's not
installed explicitely, it's only present in the store to satisfy a
dependency.


You dont consider that an issue when someone use guix remove x then ops

guess what nothing indicate something can be done, and guess what no
error message gonna tell you what the hell going on. Least can be said
about this bad usability.


It's not "no message", is it? I lust tried "guix remove hello", and I don't 
have hello in my profile. It told me (in red): error: package 'hello' not found in profile.

Not sure how it could be more explicit.




I hope this is helpful :)


Appreciated :)

Julien Lepiller:

Le Tue, 13 Apr 2021 12:46:19 +,
bo0od  a écrit :


Hi There,

I saw some packages installed by default with guix like
wpa-supplicant and avahi..., But if i type 'guix remove av' and i
press tab nothing will complete the word and if i type 'guix remove
avahi' or 'guix remove wpa-supplicant' ... just give error message.
(check the uploaded txt file)


Guix has a different notion of "installed" and "not installed" from
other distros because of its model (and because it lets us use (but

not

"install") incompatible packages). In particular, there are multiple
profiles, and each of them could contain avahi or a reference to

avahi.

In your case, I think avahi comes from two places:

First, guix itself depends on guile-avahi, which brings in avahi.
That's because substitution can use avahi to get substitutes from

your

local network.

Second, your operating-system declaration apparently is running
the avahi server. Since you didn't share it, I don't know if it comes
from a service dependency or if it's declared explicitely, but if you
don't want it to be running, that's where you'd remove it (either
remove the explicit service, or the dependent service (guix

publish?))


Avahi is added by the installer if you enable "Substitute server
discovery" in the installer.

Similarly, wpa-supplicant is probably part of another profile, or

maybe

declared in your config.scm. Once you change it, you should

reconfigure

(guix system reconfigure /etc/config.scm). This will not remove files
from the store, until you run guix gc.

When you run "guix remove" as user, it

bug#47786: Several build --keep-failed result in wrong env variables

[Leo Famulari]

On Thu, Apr 15, 2021 at 08:31:54AM +0600, Dmitry Matveyev wrote:
> Hello,
> 
> I use guix on Arch Linux, version
> 050be36cbf3a42199f64f2e44c59f1cb1b3afab5.
> 
> Several invocations of guix build --keep-failed creates directories in
> /tmp like this one guix-build-hello-2.10.drv-0 for 1st build and then
> guix-build-hello-2.10.drv-1 for 2nd and so on (with last digit
> increasing). But environment variables for all of them are set to point
> to the very 1st directory.
> 
> Reproduce:
> 
> $ guix build --check --keep-failed hello
> ^C
> $ guix build --check --keep-failed hello
> ^C
> $ cd /tmp/guix-build-hello-2.10.drv-1/
> $ grep PWD environment-variables
> export OLDPWD
> export PWD="/tmp/guix-build-hello-2.10.drv-0/hello-2.10"
> 
> Here although we are in directory /tmp/guix-build-hello-2.10.drv-1/, PWD
> is set to .drv-0 directory.

I see, thanks for the report.

This is probably because, within the build environment, the directory is
always named '/tmp/guix-build-$name-$version.drv-0/', for
reproducibility.

We should see about changing the PWD variable after the build fails.

bug#47660: Add link to the ticket when someone reply

[Maxime Devos]

On Thu, 2021-04-15 at 17:00 +, bo0od wrote:
> To be honest i find this bad thing to use emails to do anything rather 
> than online registration and not necessary stuff (means being 
> encrypted,manipulated.. just not something important)

To be honest, I find it a bad thing that many projects (I'm looking at
GitHub here (*)) only have a web interface, that require registration
(and often have terms of service I would consider criminal).  Then there
are multiple web sites requiring registration that I need to keep track
of.

(*) Ok, GitHub has e-mail notifications.  But I can't directly reply to them,
I need to go to the web interface.  At least, that was the case N years ago.

I like being able to perform all asynchronuous communication via e-mail,
instead of via a dozen platforms.  With e-mail, you get signing ‘for free’,
while with $PLATFORMS, you need to rely on each $PLATFORM infrastructure
or resort to ...

(my intepretation of your words, out of context, with encryption replaced with
 signing)
> extra tools, where you have to copy the message into the tool, let the
> tool verify the signature.  Or write a message into the tool, let the
> tool create the signature, and copy the message+signature into the web
> interface.

> Email sucks due to:
> * Messages are not encrypted by default which mean it need an extra tool 
> to do it and commonly used is GPG/PGP + it needs tool to implement this 
> encryption on the messages which mean mail reader/client most commonly 
> one used is thunderbird/icedove <- This method having tremendous 
> security issues check for example: [...]

Not relevant for our purposes.  Issues are public.  Only PGP for signing is
relevant here.  Also, PGP + Evolution works just fine for me, and evolution
doesn't download external attachements by default.

> * Most of the time (not always) heavily rely on clearnet which mean 
> issues of TLS/DNS which needs to be hardened otherwise they are exist by 
> names but does nothing.

I couldn't parse this.  What does ‘they are exist by names but does nothing’
mean?

> ..This is out of scope to discuss this in details, I just want to see 
> the bug URL linked to the bottom of the email i receive thats it.

Guix' bug tracking software is ‘GNU Bug Tracker’.  You could ask it on
that project's mailing lists.  Now I see you did that already:
.

I don't have anything else to say on this topic; I'm not sending further 
replies.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

bug#47748: Packages which cant be find/removed by guix remove

[Maxime Devos]

On Thu, 2021-04-15 at 09:37 +, bo0od wrote:
>  > guix remove: error: package 'm17n-lib' not found in profile
>  > Hint: All users have their own profiles.  To remove packages from the 
> profile
>  > of the root user, run "sudo guix remove PACKAGES" or equivalent.
> 
> yeah very nice one, except that "sudo guix remove package" doesnt work :(

I suggested two hints.  What do you think of the second hint:

Hint: On Guix System, packages can defined in the operating system declaration.
These are not affected by "guix remove PACKAGES".

I don't know if it applies to your exact situation though (not following
the discussion very closely).
 
> This is how its done in debian/fedora, for e.g this is what debian error 
> give if apt needs root rights to delete a package:
> 
> "user@host:~$ apt remove hexchat
> E: Could not open lock file /var/lib/dpkg/lock-frontend - open (13: 
> Permission denied)
> E: Unable to acquire the dpkg frontend lock 
> (/var/lib/dpkg/lock-frontend), are you root?"
> 
> This is what it shows in Fedora: [...]

In that case, my first hint would have been informative, no?
I don't see what you are trying to show here.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

bug#36508: GDM files have incorrect owner after temporarily removing service

[Mark H Weaver]

Hi Brendan,

Brendan Tildesley  writes:

> Guix system rollbacks should be a supported feature of Guix, not just a 
> gimmick
> that falls out of its design. It should be that a Guix user could leave their
> system for 5 years, and then do a guix pull; guix system reconfigure in the 
> year
> 2026. Perhaps at that time the new system will break, and then its desirable
> that they can rollback to the previous generation.

This sounds like a good set of goals to strive for.  I'm not sure that
Guix, on its own, will be able to achieve reliable 5-year rollback.  I
think that would require _all_ software in Guix that maintains mutable
state on disk to gracefully support downgrading to a version from 5
years earlier.

Nonetheless, Guix can certainly do its part to try to ensure that
multi-year rollbacks can work, and I agree that it's a good thing to
keep in mind.

> So what fixes we put in to 
> Guix services today need to consider not just how files could have changed in
> the past, but how they might change in breaking ways in the future, within 
> reason.

It's a good thing to keep in mind, yes.

> I don't know off the top of my head of any way that can be done other than to
> have chmod -R gdm:gdm /var/lib/gdm always executed.

I'm not necessarily opposed to doing that, at least as a temporary
workaround for GDM, but I don't think this is a satisfactory solution to
the larger problem.  A few points:

(1) I don't think we can assume that all files owned by a given user
will be in that user's home directory, especially for "system"
users.

(2) I also don't think we can assume that all files in a user's home
directory *should* be owned by that user.  Even if it's true today,
it might not be true tomorrow.

(3) Groups don't even have home directories.

> On 04/13/2021 10:51 PM Mark H Weaver  wrote:
>> 
>> There's some discussion of this issue at ,
>> although I'm not sure that Danny's suggested solution is practical.
>> 
>> Here's one idea: when activating a system, *never* delete users or
>> groups if files still exist that are owned by those users/groups.
>> Checking all filesystems would likely be too expensive, but perhaps it
>> would be sufficient to check certain directories such as /var, /etc, and
>> possibly the top directory of /home.
>> 
>> What do you think
>
> Wouldn't that imply that uids could be randomly different on different systems
> with the same configuration, and then remain statically different permanently?

Yes, and I agree that it's suboptimal.

> We want as little randomness and moving parts as possible. It's yet another
> way the system is not actually Functional, but has state.

Agreed.  Danny's suggested solution (UID = hash username) is clearly the
optimal approach in many respects.  It has the nice properties above.

The practical problem I see with Danny's approach is that in order to
make hash collisions sufficiently improbable, our UIDs and GIDs would
need to be much larger than the 16 bits that is widely supported by
POSIX software.  With 16-bit UIDs, the probability of a collision would
be 1.85% with 50 users, and 7.28% with 100 users.

To adopt this approach, I think that our UIDs and GIDs would need to be
at least 31 bits.  These are the problems I see:

(1) It's unlikely that all software in Guix robustly handles such large
UIDs/GIDs.  Desktop systems with UIDs/GIDs larger than 65533 have
not been widely tested, as far as I know.

(2) Even with 31 bit IDs, the probability of collisions would still be
uncomfortably high when large numbers of users are present: with 10k
users, the probability of hash collisions would be about 2.3%.

(3) We'd need a transition plan for users' existing file systems.

(4) It would be aesthetically unpleasant for our UIDs and GIDs to be
random-looking numbers with 10 decimal digits.

> Seems this bug spans 3 or so different bug reports. In 
> http://issues.guix.gnu.org/45571
> I commented that Nix uses hard coded id's, sorta like how ports are allocated
> for a purpose:
>
> https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/misc/ids.nix
>
> Perhaps you are thinking of other kinds of security issues that could be 
> caused that
> I'm not thinking of.

I'm not sure what you're getting at here.  The only security issue I've
raised so far is that ownership of files can _effectively_ be changed
when removing services and later adding them back.  For example, in my
case, 'colord' ended up being the owner of files in /var/lib/gdm.

> In that case maybe Nix devs have already made the best choice by
> making them static?

That might well be true.  At the present time, this is the option that
seems most appealing to me.

One possible approach would be to add a field to our 'operating-system'
record that explicitly specifies a total mapping from user/group names
to UIDs/GIDs.  It could either be a procedure (to support Danny's
hashing approach with its nice properties) or possibly also 

bug#36508: GDM files have incorrect owner after temporarily removing service

[Mark H Weaver]

Ludovic Courtès  writes:

> Note that there are other places, in addition to GDM, where we
> forcefully reset the UID/GID of the home directory (e.g., for the
> ‘knot-resolver’ service.)
>
> My preferred solution to this would be to unconditionally chown -R home
> directories upon activation (for efficiency, it would be best if we
> could do that if and only if the home directory itself has wrong
> ownership).  Thoughts?

It might be okay to do this in specific cases like /var/lib/gdm, but I'm
very uncomfortable doing it for *all* users, because:

(1) We shouldn't assume that all files within a home directory are
supposed to be owned by that user.

(2) We shouldn't assume that all files owned by a user will be within
their home directory.

(3) We shouldn't assume that all files within a home directory are
supposed to have the same 'group'.  I, for one, have sometimes had
subdirectories of my home directory with a different 'group', to
either restrict or grant other users access to selected files or
directories.

(4) Groups do not, in general, have home directories.

(5) I consider it unsatifactory for there to be *any* window of time
during system activation when the ownership of files is incorrect.

>> Here's one idea: when activating a system, *never* delete users or
>> groups if files still exist that are owned by those users/groups.
>> Checking all filesystems would likely be too expensive, but perhaps it
>> would be sufficient to check certain directories such as /var, /etc, and
>> possibly the top directory of /home.
>
> How would you determine which directories to look at though?  What if we
> miss an important one?

Yes, that's a good point.  I suppose that my idea above is not
satifactory either.

> Note that the ID allocation strategy in (gnu build accounts) ensures
> UIDs/GIDs aren’t reused right away (same strategy as implemented by
> Shadow, etc.).  So if you remove “bob”, then add “alice”, “alice” won’t
> be able to access the left-behind /home/bob because it has a different
> UID.

This mechanism is insufficient, because it only avoids the problem if
you add "alice" at the same time that "bob" is removed.  If you remove
"bob" during one system activation, and then later add "alice", then
"alice" might well be able to access bob's left-behind files.

In the case that I personally witnessed on my Guix system, files within
/var/lib/gdm ended up with 'colord' as their group.  That's not good.

Increasingly, I'm leaning toward the idea that the complete mapping from
names to IDs should somehow be explicitly given as part of the OS
configuration, as I advocated in .

What do you think?

 Thanks,
   Mark

bug#46496: Bug closed

[Morgan Smith]

Hello!

Thank you for reporting this bug. This bug was fixed in commit
8799369983315d799501b4f45a3954195b630ebb made on April 8th.

You are correct that libc_nano.a should be for newlib-nano and libc.a
should be for newlib. However, in the nano toolchain, both libc.a and
libc_nano.a (which was recently added) are used for newlib-nano.

In the future, we should combine the nano and non-nano toolchain
together so that it matches up with your (correct) intuition of what
should be where. But that is a job for another day.

Thanks,

Morgan

bug#36508: GDM files have incorrect owner after temporarily removing service

[Mark H Weaver]

Ludovic Courtès  writes:
> My preferred solution to this would be to unconditionally chown -R home
> directories upon activation

I also wonder if this could lead to security flaws similar to
CVE-2021-27851 , but perhaps 'chown' has
been written carefully to avoid such problems.

   Mark

bug#36508: GDM files have incorrect owner after temporarily removing service

[Mark H Weaver]

Ludovic Courtès  writes:

> Mark H Weaver  skribis:
>
>> Here's one idea: when activating a system, *never* delete users or
>> groups if files still exist that are owned by those users/groups.
>> Checking all filesystems would likely be too expensive, but perhaps it
>> would be sufficient to check certain directories such as /var, /etc, and
>> possibly the top directory of /home.
>
> How would you determine which directories to look at though?  What if we
> miss an important one?

I have another idea:

Maintain historical mappings from user/group names to UIDs/GIDs, perhaps
in some file in /etc, where entries are added but *never* automatically
removed.  When allocating UIDs/GIDs, we would avoid any UIDs/GIDs in the
range of those mappings.

Then, provide a UID/GID garbage collector, to be explicitly run by users
if desired, which would scan all filesystems to find the set of UID/GIDs
currently referenced, and remove entries from the historical mappings
that are no longer needed.

What do you think?

  Mark

bug#47660: Add link to the ticket when someone reply

[bo0od]

To be honest i find this bad thing to use emails to do anything rather 
than online registration and not necessary stuff (means being 
encrypted,manipulated.. just not something important)


Email sucks due to:
* Messages are not encrypted by default which mean it need an extra tool 
to do it and commonly used is GPG/PGP + it needs tool to implement this 
encryption on the messages which mean mail reader/client most commonly 
one used is thunderbird/icedove <- This method having tremendous 
security issues check for example:


- https://efail.de/
- https://www.whonix.org/wiki/OpenPGP#Issues_with_PGP

* Most of the time (not always) heavily rely on clearnet which mean 
issues of TLS/DNS which needs to be hardened otherwise they are exist by 
names but does nothing.



..This is out of scope to discuss this in details, I just want to see 
the bug URL linked to the bottom of the email i receive thats it.


Bonface Munyoki K.:

bo0od  writes:


what are you talking about? who uses PGP/GPG for
a public ticket tracking system?...



I do. I sign my e-mails as a guarantee to my
recipients that what you get is truly from
me. That plus my mail client makes that-- signing
emails-- way easy to do. I also sign all my
commits, even on the major platforms. FWIW, even
on GH, and GL, you could sign your emails when
replying to an email, thereby having the
recipients on the Cc see your pgp/ gpg signature,
while GL/ GH scrapes it off when displaying it's
contents. However, there are people who sign email
inline. Here's one such example:
https://github.com/alezost/guix.el/issues/39

PS: If you use gnus from Emacs, you should read:
https://www.gnu.org/software/emacs/manual/html_node/message/Signing-and-encryption.html#Signing-and-encryption
In my Emacs, I have:

--8<---cut here---start->8---
(use-package mm-encode
   :config (setq mm-encrypt-option 'guided) (setq
   mm-sign-option 'guided))

(use-package mml-sec
   :config (setq mml-secure-openpgp-encrypt-to-self
   t) (setq mml-secure-openpgp-sign-with-sender t)
   (setq mml-secure-smime-encrypt-to-self t) (setq
   mml-secure-smime-sign-with-sender t))

(use-package epa-file
   :config (setq
   epa-file-cache-passphrase-for-symmetric-encryption
   nil))
--8<---cut here---end--->8---



gitlab,github,trac...etc all giving the ticket
URL on the bottom of the message nothing with
magic im suggesting here.

Maxime Devos:

On Fri, 2021-04-09 at 20:44 +, bo0od wrote:

This work or i search for it also work, But we
are talking making things much easier and its
possible through providing the link directly
to the ticket in bottom, I believe this
practice followed by all major ticketing
systems,platforms,projects.. So i dont
understand whats the big deal having it here
as well.

Mangling e-mails can cause all kinds of
trouble.  It would mess up git patches, break
messages signed with PGP or S/MIME (does anyone
here actually use S/MIME?), makes some headers
used for spam detection (and more generally,
detecting forged mails) invalid, which will
lead to messages from the mailing list and
@debbugs.gnu.org be marked as spam ...
Greetings, Maxime.

bug#47808: guile-git-0.5.0.drv build failed

[Bone Baboon via Bug reports for GNU Guix]

On an i686 computer when I run `guix pull --no-substitutes` I get this
error: 

```
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Building from this channel:
  guix  https://git.savannah.gnu.org/git/guix.git   a5bbd38
building /gnu/store/2cllkgj32qqxvrlxkas27v6hd34g0b88-guile-git-0.5.0.drv...
/ 'check' phaseBacktrace:
  13 (primitive-load 
"/gnu/store/60dv1xf6dyzxiqg2kyd4rb3kpxrbk8as-compute-guix-derivation")
In ice-9/eval.scm:
155:9 12 (_ _)
159:9 11 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# ?) ?) ?) 
?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
In ice-9/boot-9.scm:
152:2 10 (with-fluid* _ _ _)
152:2  9 (with-fluid* _ _ _)
In ./guix/store.scm:
  2066:24  8 (run-with-store # _ 
#:guile-for-build _ #:system _ #:target _)
   1900:8  7 (_ _)
In ./guix/gexp.scm:
   256:18  6 (_ _)
   1137:2  5 (_ _)
   1003:2  4 (_ _)
849:4  3 (_ _)
In ./guix/store.scm:
  1948:12  2 (_ #)
   1362:5  1 (map/accumulate-builds # _ _)
  1373:15  0 (_ # _ _)

./guix/store.scm:1373:15: ERROR:
  1. &store-protocol-error:
  message: "build of 
`/gnu/store/2cllkgj32qqxvrlxkas27v6hd34g0b88-guile-git-0.5.0.drv' failed"
  status: 100
guix pull: error: You found a bug: the program 
'/gnu/store/60dv1xf6dyzxiqg2kyd4rb3kpxrbk8as-compute-guix-derivation'
failed to compute the derivation for Guix (version: 
"a5bbd38fd131282e928144e869dcdf1e09259085"; system: "i686-linux";
host version: "c311147bd16aa0e5746d9cbf31502f5fd61e470c"; pull-version: 1).
Please report it by email to .
```

`guix describe` outputs:

```
Generation 2Apr 12 2021 20:12:42(current)
  guix c311147
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: c311147bd16aa0e5746d9cbf31502f5fd61e470c
```

bug#47748: Packages which cant be find/removed by guix remove

[Mark H Weaver]

bo0od  writes:

>  > You seem to want it to do something different than it was intended to
>  > do, although I'm not precisely sure what that is.  Do you want it to try
>  > to purge all copies of the given package from /gnu/store?  If so, that
>  > might require deleting (or modifying) older system generations and older
>  > user profiles, which would interfere with rollback functionality.
>
> Isnt this the standard understanding of deleting a package whether in 
> GNU/Linux or Windows or Mac? If user has the root rights he should be 
> able to delete software x,

The command in Guix that most closely matches what you seem to be asking
for is "guix gc --delete", which will try to delete a given set of store
items.  In your original bug report, it looks like 'avahi' was one of
the things you were trying to remove, so I'll use that as an example:

--8<---cut here---start->8---
mhw@jojen ~$ guix gc --delete /gnu/store/…-avahi-0.8
finding garbage collector roots...
guix gc: error: cannot delete path `/gnu/store/…-avahi-0.8' since it is still 
alive
--8<---cut here---end--->8---

If you get this error, you can use "guix gc --referrers" to find out
what's keeping it alive:

--8<---cut here---start->8---
mhw@jojen ~$ guix gc --referrers /gnu/store/…-avahi-0.8
/gnu/store/…-geoclue-2.5.7
/gnu/store/…-gvfs-1.40.2
/gnu/store/…-pulseaudio-14.0
/gnu/store/…-cups-filters-1.27.4
/gnu/store/…-guile-avahi-0.4.0-1.6d43caf
/gnu/store/…-avahi-0.8
/gnu/store/…-cups-2.3.3
/gnu/store/…-grilo-plugins-0.3.11
--8<---cut here---end--->8---

So, it looks like I won't be able to remove avahi from my store, at
least not if I want to keep GNOME, CUPS, or Pulseaudio.

For similar reasons, I can't remove Avahi from my Debian server either:

--8<---cut here---start->8---
root@world:~# dpkg -r libavahi-client3
dpkg: dependency problems prevent removal of libavahi-client3:amd64:
 libvirt0:amd64 depends on libavahi-client3 (>= 0.6.16).
 libcups2:amd64 depends on libavahi-client3 (>= 0.6.16).

dpkg: error processing package libavahi-client3:amd64 (--remove):
 dependency problems - not removing
Errors were encountered while processing:
 libavahi-client3:amd64
--8<---cut here---end--->8---

Anyway, I agree that it would be good to have a user-friendly way to ask
Guix why a given piece of software is in their store, and to help them
find ways to remove it, if possible.  We have some tools to help with
this, e.g. "guix gc --referrers", "guix graph --type=reverse-package",
"guix graph --type=reverse-bag", and "guix graph --path", etc, but
there's plenty of room for improvement.

  Mark

bug#47717: guix outrageously exhaust itself (freeze) when there is package build failure

[Mark H Weaver]

bo0od  writes:

>  > I mean the ‘outrageously’ part.  When Linux runs out of memory, it
>  > freezes up.  Moral judgment is futile.  Better to adopt raingloom's
>  > earlyoom suggestion or similar.
>
> Im using default guix system nothing special, If this package usable to 
> solve these stuff i suggest then to include it by default.

'earlyoom' behavior is not necessarily desirable.  I, for one, have a
fairly old computer by today's standards, and sometimes I ask it to do
intensive things that are at the edge of its capabilities, such as
compiling GNU IceCat.  An aggressive 'earlyoom' might prematurely abort
jobs that could have completed, and thereby make it impossible for me to
continue using this old computer for development.

With that in mind, it's far from clear that 'earlyoom' should be our
default behavior.  It's good to have it as an option, though.

>  > 4 GiB is absolutely not enough to build an outrageous amount of ‘modern’
>  > software, especially in parallel (so not using --cores=1 --max-jobs=1)
>  > to make use of those expensive cores.
>  >
>  > I'm disgusted too.
>
> Yes it is, But you know this cant be a way of life with guix for end 
> user no? Something by default should solve this matter otherwise this is 
> not usable distro.

Many people are happily using it, and are quite enthusiastic about it,
so evidently it's "usable".  That doesn't imply that it's good for
everyone.  Perhaps you would prefer a more traditional distro, or one
that has had more time to mature.  If so, that's okay.

  Regards,
Mark

bug#36508: GDM files have incorrect owner after temporarily removing service

[Ludovic Courtès]

Hi Mark,

Mark H Weaver  skribis:

> Ludovic Courtès  writes:
>
>> Note that there are other places, in addition to GDM, where we
>> forcefully reset the UID/GID of the home directory (e.g., for the
>> ‘knot-resolver’ service.)
>>
>> My preferred solution to this would be to unconditionally chown -R home
>> directories upon activation (for efficiency, it would be best if we
>> could do that if and only if the home directory itself has wrong
>> ownership).  Thoughts?
>
> It might be okay to do this in specific cases like /var/lib/gdm, but I'm
> very uncomfortable doing it for *all* users, because:
>
> (1) We shouldn't assume that all files within a home directory are
> supposed to be owned by that user.
>
> (2) We shouldn't assume that all files owned by a user will be within
> their home directory.
>
> (3) We shouldn't assume that all files within a home directory are
> supposed to have the same 'group'.  I, for one, have sometimes had
> subdirectories of my home directory with a different 'group', to
> either restrict or grant other users access to selected files or
> directories.
>
> (4) Groups do not, in general, have home directories.
>
> (5) I consider it unsatifactory for there to be *any* window of time
> during system activation when the ownership of files is incorrect.

I agree this raises questions and we should take time to think through
it.  For system accounts though, I think 1–4 do not apply.

Perhaps a first step would be to do that for system accounts?

>> Note that the ID allocation strategy in (gnu build accounts) ensures
>> UIDs/GIDs aren’t reused right away (same strategy as implemented by
>> Shadow, etc.).  So if you remove “bob”, then add “alice”, “alice” won’t
>> be able to access the left-behind /home/bob because it has a different
>> UID.

To be clear, it’s doing the same as any other GNU/Linux distro.

> This mechanism is insufficient, because it only avoids the problem if
> you add "alice" at the same time that "bob" is removed.  If you remove
> "bob" during one system activation, and then later add "alice", then
> "alice" might well be able to access bob's left-behind files.
>
> In the case that I personally witnessed on my Guix system, files within
> /var/lib/gdm ended up with 'colord' as their group.  That's not good.
>
> Increasingly, I'm leaning toward the idea that the complete mapping from
> names to IDs should somehow be explicitly given as part of the OS
> configuration, as I advocated in .
>
> What do you think?

IDs as hash of the user names are interesting because that’d be
stateless (conversely, the current ID allocation strategy is stateful:
it arranges to not reuse recently-freed IDs.)

But like you write, we’d need 32-bit UIDs.  In libc, ‘uid_t’
(specifically ‘__UID_T_TYPE’ in typesizes.h) is 32-bit, so it might work
rather well in user space.

It still sounds like a change with significant implications though, and
it’s hard to predict exactly how it would go or what would break.  For
example, that does away with the system/non-system ranges, and wouldn’t
play well with “special” IDs like 0 and 65535.

To me, it’s a potential way out, but not a solution for the bug Brendan
reported today, nor a change we could implement in the coming
weeks/months; the time scale is probably longer.

WDYT?

Thanks,
Ludo’.

bug#47786: Several build --keep-failed result in wrong env variables

[Mark H Weaver]

tags 47786 + notabug
close 47786
thanks

Hi Dmitry,

Dmitry Matveyev  writes:

> I use guix on Arch Linux, version
> 050be36cbf3a42199f64f2e44c59f1cb1b3afab5.
>
> Several invocations of guix build --keep-failed creates directories in
> /tmp like this one guix-build-hello-2.10.drv-0 for 1st build and then
> guix-build-hello-2.10.drv-1 for 2nd and so on (with last digit
> increasing). But environment variables for all of them are set to point
> to the very 1st directory.

This is the intended behavior, although I agree that it can be
surprising.

The environment variables refer to "/tmp/guix-build-….drv-0" because
within the build container, the directory is _always_ named
"/tmp/guix-build-….drv-0", regardless of what name was given to the
directory outside of the build container.

In general, where practical, we try to isolate the build container from
irrelevant details about the host system (such as the contents of /tmp),
because those details might leak into the build outputs, compromising
reproducibility.

For example, some packages retain the absolute file name of the build
directory, as an aid to developers when users report bugs.
Reproducibility of such package builds would be lost if the build
directory name varied depending on the contents on /tmp on the host
system.

Does that make sense?

Thanks for the report,

  Mark

bug#36508: GDM files have incorrect owner after temporarily removing service

[Mark H Weaver]

Hi Ludovic,

Ludovic Courtès  wrote:
>>> Note that the ID allocation strategy in (gnu build accounts) ensures
>>> UIDs/GIDs aren’t reused right away (same strategy as implemented by
>>> Shadow, etc.).  So if you remove “bob”, then add “alice”, “alice” won’t
>>> be able to access the left-behind /home/bob because it has a different
>>> UID.

I replied:
>> This mechanism is insufficient, because it only avoids the problem if
>> you add "alice" at the same time that "bob" is removed.  If you remove
>> "bob" during one system activation, and then later add "alice", then
>> "alice" might well be able to access bob's left-behind files.

Ludovic Courtès  responded:
> To be clear, it’s doing the same as any other GNU/Linux distro.

I don't think that's quite right.

It's true that if you delete a user or group on another distro and then
re-add it, it might not be assigned the same UID/GID.  That much is the
same as any other distro.

The key difference is this: On Debian, at least in my experience, users
and groups are *never* deleted automatically.  They are only added
automatically, but never removed unless you explicitly ask to remove
them.  So, this problem does not arise in practice.

  Thanks,
Mark

bug#47631: Add graphical installation and solve tons of headache

[Léo Le Bouter via Bug reports for GNU Guix]

On Thu, 2021-04-15 at 10:00 +, bo0od wrote:
> Guix need to improve itself when first time initiated, Please check 
> other projects like NixOS,Triskel,Mint,Ubuntu...etc
> 
> 
> If you dont like that live graphical gui access, then do it as debian
> is 
> doing it which give you proper gui screen specifically intended to 
> configure your internet then you can proceed with the installation.
> 
> Otherwise guix is useless case specially for new users in places
> where 
> internet need to be configured manually (adding
> IP,Gateway,Netmask... 
> manually).

GNU Guix right now is not for novice users, things progress at their
own pace, based on available contributor time. Everyone realizes the
steep learning curve of GNU Guix. There is many issues to solve before
trying to make GNU Guix more accessible IMO. Be patient and things are
only going to improve. The best way to accelerate this as you ask is to
dive in and contribute, if you can, please do!


signature.asc
Description: This is a digitally signed message part

bug#36508: GDM files have incorrect owner after temporarily removing service

[Mark H Weaver]

Hi Ludovic,

Ludovic Courtès  writes:

> IDs as hash of the user names are interesting because that’d be
> stateless (conversely, the current ID allocation strategy is stateful:
> it arranges to not reuse recently-freed IDs.)
>
> But like you write, we’d need 32-bit UIDs.  In libc, ‘uid_t’
> (specifically ‘__UID_T_TYPE’ in typesizes.h) is 32-bit, so it might work
> rather well in user space.

The kernel and core system components certainly support 32-bit UIDs, and
have for around 20 years.

> It still sounds like a change with significant implications though, and
> it’s hard to predict exactly how it would go or what would break.

Right, my concern is with the vast majority of programs and libraries in
Guix, most of which probably haven't seen much (if any) testing with
large UIDs.

> For example, that does away with the system/non-system ranges, and
> wouldn’t play well with “special” IDs like 0 and 65535.

This particular issue is easily addressed.  It's easy enough to find a
function from 31-hash values to 32-bit IDs that's injective and avoids
any chosen subset of special IDs, as long as there are fewer than 2^31
special IDs.

Simply adding 65536 (or even 2^31) to the hash value would be one easy
option.

What do you think?

   Mark

bug#47812: Incorrect code in the Guix manual, but only on the website

[Mark H Weaver]

In the Guix manual, as it appears on our website,

  https://guix.gnu.org/manual/devel/en/html_node/X-Window.html

the manual entry for 'slim-service-type' suggests the following code to
remove the 'gdm' service from %desktop-services.

--8<---cut here---start->8---
   (modify-services %desktop-services
 (delete gdm-service-type))
--8<---cut here---end--->8---

This code is incorrect.  'modify-services' does not support deleting
services.

The puzzling thing is that I can't find where this suggested code exists
in our git repository.  The manual in our git repository is correct.
Instead of the code above, it suggests:

--8<---cut here---start->8---
   (remove (lambda (service)
 (eq? (service-kind service) gdm-service-type))
   %desktop-services)
--8<---cut here---end--->8---

This is the case on our 'master', 'core-updates', and 'version-1.2.0'
branches.  See:

  
https://git.sv.gnu.org/cgit/guix.git/tree/doc/guix.texi?id=ebd021f73292bf47b26a799665d6204574bae239#n17891
  
https://git.sv.gnu.org/cgit/guix.git/tree/doc/guix.texi?h=core-updates&id=76fc36d0a7215979bb74c05840f5a4de4ab5ea93#n17756
  
https://git.sv.gnu.org/cgit/guix.git/tree/doc/guix.texi?h=version-1.2.0&id=8603bcd5822a1a8364a7a74a698059d3d147568b#n17076

The correct text was added about 2 years ago, in the following commit:

  
https://git.sv.gnu.org/cgit/guix.git/commit/?id=dbef9015db107dd148133420b89af552ef08f8ee

I see no evidence of it being changed since then.

Any idea where the incorrect code on the website manual is coming from?

  Thanks,
Mark

bug#47812: Incorrect code in the Guix manual, but only on the website

[Mark H Weaver]

Mark H Weaver  writes:

> The correct text was added about 2 years ago, in the following commit:
>
>   
> https://git.sv.gnu.org/cgit/guix.git/commit/?id=dbef9015db107dd148133420b89af552ef08f8ee
>
> I see no evidence of it being changed since then.
>
> Any idea where the incorrect code on the website manual is coming from?

I see now that this new functionality was added to the 'staging' branch
3 days ago:

  
https://git.sv.gnu.org/cgit/guix.git/commit/?h=staging&id=a247f5c7537df7e0c09051ba22d5c95eb08f48b9

It seems inappropriate for our online website manual to be taken from
'staging'.  It has already led to an experienced Guix developer
repeatedly suggesting (to a new user) a code snippet that cannot
possibly work on the 'master' branch:

  https://bugs.gnu.org/47748#14
  https://bugs.gnu.org/47748#41

   Mark

bug#47812: Incorrect code in the Guix manual, but only on the website

[Leo Famulari]

On Thu, Apr 15, 2021 at 08:12:13PM -0400, Mark H Weaver wrote:
> Mark H Weaver  writes:
> 
> > The correct text was added about 2 years ago, in the following commit:
> >
> >   
> > https://git.sv.gnu.org/cgit/guix.git/commit/?id=dbef9015db107dd148133420b89af552ef08f8ee
> >
> > I see no evidence of it being changed since then.
> >
> > Any idea where the incorrect code on the website manual is coming from?
> 
> I see now that this new functionality was added to the 'staging' branch
> 3 days ago:
> 
>   
> https://git.sv.gnu.org/cgit/guix.git/commit/?h=staging&id=a247f5c7537df7e0c09051ba22d5c95eb08f48b9
> 
> It seems inappropriate for our online website manual to be taken from
> 'staging'.  It has already led to an experienced Guix developer
> repeatedly suggesting (to a new user) a code snippet that cannot
> possibly work on the 'master' branch:

Hm, that's not supposed to happen. It's supposed to be based on the
'master' branch.

bug#47812: Incorrect code in the Guix manual, but only on the website

[Leo Famulari]

On Thu, Apr 15, 2021 at 08:12:13PM -0400, Mark H Weaver wrote:
> I see now that this new functionality was added to the 'staging' branch
> 3 days ago:
> 
>   
> https://git.sv.gnu.org/cgit/guix.git/commit/?h=staging&id=a247f5c7537df7e0c09051ba22d5c95eb08f48b9

If I understand correctly, this commit is also on the master branch: 

https://git.savannah.gnu.org/cgit/guix.git/commit/?h=master&id=a247f5c7537df7e0c09051ba22d5c95eb08f48b9

And I do see it in my local copy of the repo.

Can you double-check on your end? Or have I misunderstood?

bug#47631: Add graphical installation and solve tons of headache

[bo0od]

> For now, our focus is on improving the guided installer itself.

Ok as you wish why not, But please dont give something less than what 
Debian installer providing.


Ludovic Courtès:

Hi,

bo0od  skribis:


Did you try the graphical installation?

https://guix.gnu.org/en/videos/system-graphical-installer/

It’s key strokes rather than clicks, but I think it addresses most of
the issues you describe.


Yes i do know this, But whats different between what guix is doing and
others are doing (examples i gave above), They give you access to GUI
of their distro without internet and from within this live GUI access
to the distro you can configure the internet/partition..etc (easily
specially for first time users) using GUI tools without internet (you
can even test the distro without the need to install it)


Letting users use GUI (or non-GUI) tools by themselves doesn’t look
appealing to me.  We made the choice to provide a guided installer,
similar to that of Debian and other distros, such that users don’t have
to figure out by themselves that they need to run gparted, follow steps,
etc.


Thats what im requesting not what is currently happening.


Did you try the live VM image?

https://guix.gnu.org/en/download/


What? where?


Search for “QEMU”.


I’m closing because I don’t see anything actionable.  Please file issues
focused on specific problems.


Guix need to improve itself when first time initiated, Please check
other projects like NixOS,Triskel,Mint,Ubuntu...etc


I contributed to NixOS long ago, and unless things have changed, it
doesn’t have a guided installer.


If you dont like that live graphical gui access, then do it as debian
is doing it which give you proper gui screen specifically intended to
configure your internet then you can proceed with the installation.


So I guess your primary request is about giving access to the GUIs.
That comes at a cost (the ISO is already quite big) but that’s something
we could consider.

For now, our focus is on improving the guided installer itself.

Thanks,
Ludo’.

bug#47748: Packages which cant be find/removed by guix remove

[bo0od]

> Again, you have the wrong idea. wpa-supplicant is not installed, but 
its service is running, because it's part oh %desktop-services. No 
amount of guix remove will help you, because it can only wosk on user 
(or root) profiles, not the system services.

>
> To remove it, you need to remove it from your os declaration 
(/etc/config.scm) with something like this:[...]


My friend isnt this what im saying not friendly,bad 
usability,disaster...etc


And i said to have maybe something like synapse which mean addressing 
everything installed and user can just remove the packages by clicking 
on them (or lets call it the GUI way of doing it) similar to the 
functionally you showed:


"(modify-services %desktop-services
   (delete wpa-supplicant-service-type))"

... or whatever suits the development and give friendly result, But if 
you tell me in 2021 user gonna go to /x/y/z then modify manually and add 
lines blah remove blah <- call me if guix will ever be a top usable 
distro in the coming 20 years from now or ever.



Julien Lepiller:

Le 15 avril 2021 06:16:51 GMT-04:00, bo0od  a écrit :

guix operates on explicitely installed packages, dependencies are

implementation details. It just doesn't work like apt or other package
managers. New tool, new usages.

So how user gonna delete preinstalled packages which are not installed
by guix install x?

wpa-supplicant is none essential package when there is no wifi, how
user
gonna delete it?

no easy way to do it (i mean easy as similarly to apt/dnf..etc) thats
the whole issue

Maybe something like synapse should exist to do this job in guixos?

I dunno, But current idea of no clean,easy way to delete these packages

(or similar) just bad usability experience.


Again, you have the wrong idea. wpa-supplicant is not installed, but its 
service is running, because it's part oh %desktop-services. No amount of guix 
remove will help you, because it can only wosk on user (or root) profiles, not 
the system services.

To remove it, you need to remove it from your os declaration (/etc/config.scm) 
with something like this:

(modify-services %desktop-services
   (delete wpa-supplicant-service-type))

(Or something similar, the manual suggests the above for removing gdm for 
instance, but there seems to be doubts about whether that's actually correct or 
not)

Then reconfigure your new system:

sudo guix system reconfigure /etc/config.scm

Now, your new generation is not running wpa-supplicant anymore (you can check 
sudo herd status for that). Older generations still have wpa-supplicant, so 
it's still hanging around in the store. To purge it, you can delete those 
generations (loosing all possibility ofqrolling back to them):

sudo guix system delete-generations
guix gc # to effectively remove unnecessary store items

After that, you should not have wpa-supplicant in the store anymore.

HTH!






Julien Lepiller:

Le 14 avril 2021 12:31:31 GMT-04:00, bo0od  a écrit

:

In particular, there are multiple
profiles, and each of them could contain avahi or a reference to

avahi.

That doesnt address the issue im talking about, why guix remove

doesnt

recognize the package that number 1 , number 2 if the package will
break
something important guix should say that after processing the

command

guix remove x package then show warning message this x package is
dependency of xyz which might break your system would you like to
proceed?  <- something like that.


guix removc only operates on your user profile, which doesn't contain

avahi. That's what it's telling you.


You can check that you do not have avahi installed in your profile

with


guix package -l

And that none of your installed packages depend on it:

guix size `readlink -f ~/.guix-profile`

Guix operates only on explicitely installed packages, which I think

is much cleaner and allows it to be more predictable. Compare, if A
depends on B and C, initially you have all three.


apt install B then apt remove A -> nothing
apt remove A then apt install B -> only B

guix install B then guix remove A -> B and C
guix remove A then guix install B -> B and C

guix operates on explicitely installed packages, dependencies are

implementation details. It just doesn't work like apt or other package
managers. New tool, new usages.





Second, your operating-system declaration apparently is running
the avahi server. Since you didn't share it, I don't know if it

comes

from a service dependency or if it's declared explicitely


do you mean config.scm? if you need something type the command or

where


and i will bring it to you.


Yes, I meant /etc/config.scm (well, by convention, as you can always

create the file elsewhere). But I don't need it anymore, since I
learned it's actually part of the default %desktop-services.





When you run "guix remove" as user, it only affects your user

profile,

in which there is no avahi or wpa-supplicant package. Also note

that,

if

any of your user's profile had a dependency on avahi,

bug#47812: Incorrect code in the Guix manual, but only on the website

[Mark H Weaver]

tags 47812 + notabug
close 47812
thanks

Hi Leo,

Leo Famulari  writes:

> On Thu, Apr 15, 2021 at 08:12:13PM -0400, Mark H Weaver wrote:
>> I see now that this new functionality was added to the 'staging' branch
>> 3 days ago:
>> 
>>   
>> https://git.sv.gnu.org/cgit/guix.git/commit/?h=staging&id=a247f5c7537df7e0c09051ba22d5c95eb08f48b9
>
> If I understand correctly, this commit is also on the master branch: 
>
> https://git.savannah.gnu.org/cgit/guix.git/commit/?h=master&id=a247f5c7537df7e0c09051ba22d5c95eb08f48b9
>
> And I do see it in my local copy of the repo.
>
> Can you double-check on your end? Or have I misunderstood?

No, you're right.  When I first checked, I hadn't updated my local git
repo recently enough to have the commit.  However, I'm not sure how I
managed to include (in my original report) a Savannah URL pointing to
the relevant code without noticing that it had the newly updated code.

I'm closing this bug now.  Sorry for the noise.

 Thanks,
   Mark

bug#47748: Packages which cant be find/removed by guix remove

[Leo Famulari]

On Fri, Apr 16, 2021 at 02:11:09AM +, bo0od wrote:
> My friend isnt this what im saying not friendly,bad usability,disaster...etc
> 
> And i said to have maybe something like synapse which mean addressing
> everything installed and user can just remove the packages by clicking on
> them (or lets call it the GUI way of doing it) similar to the functionally
> you showed:

The programs you are asking to remove are used internally by Guix.

You can't remove them with a simple command. You can't do that on other
Linux distros either.

For example, on Debian, I have /usr/bin/gpg:

--
$ ls -l /usr/bin/gpg
-rwxr-xr-x 1 root root 1046256 Aug 22  2019 /usr/bin/gpg
--

Then I uninstall it:

--
$ sudo apt-get remove gpg
[...]
$ ls -l /usr/bin/gpg
ls: cannot access '/usr/bin/gpg': No such file or directory
-

But, apt-get uses gpg too, to check package signatures. It still has its
own copy of gpg, so it still works. You can't remove it easily.

It's the same situation, and it's not a bug.