<everstone>I'm redefining a default variable in my scheme file. When I feed it into guix repl, it works exactly how I want it to. When add my (operating-system ...) bit at the bottom, it says "Not a list: #<unspecified>". I don't understand why
<roptat>BlackMug, sorry, I don't know what's wrong there
<BlackMug>roptat whos the author of that wiki part? maybe he know whats going on
<lle-bout>civodul: hey! about updaters I am thinking one category of packages that are uncovered would be those like 'umoci', it's hosted on github but downloads from releases, not sure why they arent covered
<BlackMug>because either something is done wrong or its a bug one of the two
<lle-bout>civodul: glad these last patches were merged!
<jackhill>cool, it definitely seems like a reasonble design
<apteryx>by the way did you end up getting btrfs subvolumes going?
<apteryx>(if my memory/nickname association serves me right, you had asked about it on the mailing list)
<jackhill>apteryx: uh, I don't remember asking about it on the mailing list, but I do use btrfs subvolumes. I just add them as additional filesystem in config.scm (or create them in the same place where I want them mounted).
<jackhill>I did find that I couldn't use a different subvolume thatn subvolid=5 for /gnu/store, because I didn't know how to tell grub to use it when finding the kernel.
<jackhill>Another rough edge I ran into was creating subvolumes for each user's home directory. If I pre-created them the skeleton files didn't get copied in. Would be cool to teach Guix about more btrfs operations, something else for the project queue.
<jackhill>Oh, and I would really like to be able to create btrfs filesystems with subvolumes and everything using the system image API.
<emacsen>ashishdev, do you understand why people use some people use, eg Python and others use C? Or why someone uses C and not Assembly?
<jgibbons[m]>One suggestion to clean up tty1, set the logfile of elogind, geoclue, and ntp to a log file that rottlog can take care of. These programs can give hints about location and other habits, so I think there should be an option to turn off loggin.
<emacsen>there are good reasons for language choices
<Frosku>If you think of programming languages as like vehicles
<emacsen>Frosku, yup yup. As for compatibility, there are and have been efforts to make software more compatible by abstracting out the runtime. That's what the JVM tried to do. With Webassembly we may even get it in our lifetime.
<DanklyTuned>If I want to use ``(use-modules (gnu packages))`` instead of specific modules, then I must use the ``(map specification->package ...)`` form?
***iyzsong-- is now known as iyzsong-w
<DanklyTuned>Or can I just have ``(use-modules (gnu packages))`` along with ``(use-package-modules ...)``?
<DanklyTuned>I should clarify, my desire is to name specific packages I want to install without worrying about what specific namespace they come from, example I want to install "mg" but it'd be nice if I didn't need to know it belonged to the "text-editors" namespace.
<DanklyTuned>Hm, I think this question came from a poor approach, doing something different now. Also need a better understanding of Guix, will come with use and more reading :)
<jgibbons[m]>I just use ``(map (lambda (pkg) (specification->package (symbol->string pkg))) '(...))``
<jgibbons[m]>It allows me to specify packages by name without worrying about namespace or specifying strings.
<jgibbons[m]>I can even ``(define %packages '(...))`` and use %packages in the above snippet.
<DanklyTuned>jgibbons[m]: Seems a lot of work to avoid using a list of strings, isn't it?
<jgibbons[m]>In an old system configuration, a lot of my system packages were xfce apps with the same prefix. I used ``(map (lambda (pkg) (specification->package (string-concatenate ("xfce4-" (symbol->string pkg) "-plugin"))) '(...))`` That config was organized in an interesting way.
<jgibbons[m]>On a desktop install, some processes dump their output to tty1. This makes that tty unusable because I don't know when it will be interrupted.
<jgibbons[m]>One suggestion to clean up tty1, set the logfile of elogind, geoclue, and ntp to a log file that rottlog can take care of. These programs can give hints about location and other habits, so I think there should be an option to turn off loggin.
<jgibbons[m]> * One suggestion to clean up tty1, set the logfile of elogind, geoclue, and ntp to a log file that rottlog can take care of. These programs can give hints about location and other habits, so I think there should be an option to turn off logging.
<jgibbons[m]>It looks like avahi-daemon, nscd, and NetworkManager make their home on tty12, which is means it's useless as tty1 except it's not even in the default config. Why/how do these daemons choose different ttys for their default output?
<jgibbons[m]>I saw a dbus message on tty12 and decided to stop the dbus service with herd. Then I couldn't log in with another vt. Hacking is so fun!
<sneek>allana, nckx says: Reddit links are fine; AFAIK we don't really have a link policy beyond ‘nothing obviously evil’. Almost every Web site apart from fsf.org will lead you to unfree things if you click often enough :) Just try to avoid non-free JS if there's an alternative without.
<brendyyn>allana: you make a new patch and send it in with [PATCH v2]
<tissevert>Arnik: I suppose console-font-tty1 must already be declared in some of the %desktop-services
<morgansmith>when I build something with the "with-branch" package transformation does it store the commit anywhere? I think it'd be nice to have the version include the commit short hash instead of just saying "git.master"
<apteryx>does anyone know why pulseaudio can't connect to an already started pulseaudio server when ran in a pure environment? Which environment variables should I leak?
<lubrito>Hi everybody. I'm an Outreachy Applicant. I had followed all the local environment setup instructions until "2.5 Building the source files". I could run ./bootstrap.sh but ./configure is giving me an error :"./configure: line 2365: syntax error near unexpected token `3.0'
<lubrito>./configure: line 2365: `GUILE_PKG(3.0 2.2)' ". I would appreciate if anyone could help me to understand it.
<tissevert>apteryx: isn't DISPLAY the xorg thing ? I'd be surprised it worked to fix pulseaudio
<morgansmith>apteryx: env | grep -i pulse might help. I'm not sure though
<civodul>mothacehe: i just did M-x build-farm, which i hadn't done in a while, and it seems to suffer from bitrot
<morgansmith>apteryx: also try exposing /tmp too. I've found that fixes common issues
<mothacehe>civodul: didn't even know it ever existed :p
<morgansmith>apteryx: oops, you said pure, not container. ignore the /tmp thing
<morgansmith>I think there is still some odd things going on though. outside of the environment I couldn't play my music until the environment had been shutdown for like 10 seconds.
<apteryx>no, it's working fine too. it seems the key was restarting pulseaudio on the host
<morgansmith>and if I start the environment with my music already playing, it can't find my audio devices. It seems like the environment trys to reserve the controls or something. If it's working for you, all the power to you, but it is certainly acting funny on my computer. But my audio setup is pretty terrible so it's probably just me :P
<apteryx>morgansmith: ah really? I've had that observation before; I could either run pulse in the environment, or on the host, but not both
<apteryx>when already running on the host in the pure environment it wouldn't be able to connect to; if starting a fresh one from inside the environment the inverse situation would occur (cannot connect to it from the host)
<morgansmith>ya idk. This is certainly above my pay grade. But at least we got the behaviour characterized. To go deeper I think you'd have to understand how pulse does its client server thing or whatever
<brendyyn>apteryx: morgansmith I think XAUTHORITY is also needed too. since you killed pulseaudio and ran it yourself it will work without it, but if your using gdm then pulseaudio will be started by it
<apteryx>OK! Good to know. I wouldn't have noticed as I'm using ratpoison, and the applications start the pulse server on demand (e.g., icecat)
<brendyyn>I was actually thinking of making a bisecting tool for environment variables. you could run a command in a loop, where each time it adds another env back in to the pure environment until it works
<morgansmith>oh my xauthority is totally messed up. I didn't want it appearing in my home so I set the environment variable but now it doesn't generate an xauthority anywhere from what I can tell. Am I supposed to set the variable to the file I want it to create or to a folder that exists?
<brendyyn>mine is set to /run/user/1000/gdm/Xauthority
<morgansmith>mine is set to /run/user/1000/Xauthority but there is not file there :/
<morgansmith>slightly offtopic, why we gotta shorten user to usr almost everywhere but not in /run/user? Are we really saving that many characters? Why does the command have to be umount instead of unmount? unix stuff makes me a little mad sometimes :/
<brendyyn>dunno i think if its unset ~/.Xauthority will be used ?
<morgansmith>that file used to exist but since I set the variable in my profile it stopped existing
<tissevert>plus I think /usr is actually supposed to stand for User System Resource but apparently that's a backronym and it was originally supposed to mean user like you said (in which case, being some super old arcane UNIX stuff, the length argument is probably most valid)
<morgansmith> Anyone know where the package transformations set the version? I want to make a patch so that the version would be something like "git.master-a0609772" instead of just "git.master". guix/transformations.scm looks pretty complicated :P
***morgansm` is now known as morgansmith`
<morgansmith`>oh wait, I don't know if that change is actually possible. It looks like the version is set in transform-package-source-branch which I think is run before we ever hit the remote server. Meaning we set the version before we know the commit.
***morgansmith` is now known as morgansmith
<morgansmith>leoprikler: Should I rebase my geiser patches on the wip-emacs branch so they can just be commited there instead?
<morgansmith>not going to lie, I did not test guile-studio. I built it, opened it, and then it complained about ivy so I just assumed something else must've already been broken. It didn't seem to complain about geiser
<morgansmith>also I'm not sure when alezost took over emacs-guix. I remeber when jsoo1 took it over, but I couldn't find any announcment from alezost
<leoprikler>tbf I'm not the target audience of guile-studio either, so 🤷️
<morgansmith>jsoo: You cool with us updating emacs-guix using the source from alezost? It seems to be 3 commits ahead of your copy
<morgansmith>Now I'm looking back at all the times I've used it to see if I've abused it or not. I guess most things do want to be right next to the elisp so I guess it makes sense. It'd be interesting to have a more generic include that is like an alist where you can specificy the output directory and then have that avaliable in all the build systems
<morgansmith>I don't think you're supposed to have to set that variable. Now that I've unset it I see the issue
<morgansmith>I think it's supposed to be able to grab implementation from geiser-implementations-alist
<i1l[m]>nckx: hi. will you ever unban the glat-agent? his term is ended i think.
<morgansmith>leoprikler: I think this is an upstream bug? The code looks a little funky. If you run run-guile to get a guile repl you can then run run-geiser and that will successfully run a guile repl because the active buffer is a guile repl.
<leoprikler>also package-internal relative paths are pretty sane on wip-emacs
<morgansmith>oh I see. we're trying to stop files from overlaping each other. We really should make unions throw errors when that happens. That's how the openrc bug happened, why our arm-none-eabi-gcc is currently messed up (someone please accept my patch), and I guess what we're fixing here
<morgansmith>I can't say I quite understand how the unions work but I'm seeing way too many bugs coming from overlaping files. I'd really like to have at least some kind of optional warning or something.
<leoprikler>you can crank up the verbosity to see all conflicts
<morgansmith>I'm just really really salty that no one is accepting my conflict patch for arm-none-eabi-gcc. Like once a week I gotta go bang my head against the wall because it's still broken. Like someone please. Who do I gotta pay off?
<morgansmith>and then I contributed the openrc thing and went to use it like a week later and found that someone else had changed the paths so there was a union conflict and then I couldn't use it. I just gave up at that point honestly
<morgansmith>yep. that's it. until that's accepted you cannot do non-trivial c++ on arm
<morgansmith>The minute you include any of the std library that overlaps it just dies
***EdmundMiller[m] is now known as Edmund[m]
<leoprikler>tbf I don't really understand paths like /arm-none-eabi/include/arm-none-eabi/c++/arm-none-eabi
<morgansmith>ya idk I didn't think to hard about it. I work in embedded and no-one seems to care about paths so they just get uglier and uglier over time.
<morgansmith>oh I now see why you couldn't open scheme files. Did geiser autostart on file open in version 0.12? I didn't think it did
<leoprikler>yes, it did, but it could guess the implementation
<morgansmith>bug 47325 is a great example of how no-one cares about paths. No-one uses the paths as they come out of the upstream project. Everyone just changes the names themselves for some reason. Except the upstream project creates files that refer to the renamed files. I really hate embedded a lot of the time. There isn't a single thing about it that feels clean or proper
<morgansmith>I was meaning to create a proper patch for 47325 (the current patch works but isn't proper) but I got discouraged because of bug 44750
<morgansmith>leoprikler: So I downloaded the official pre-built arm-none-eabi toolchain from arm.com and the include paths look like this: arm-none-eabi/include/c++/7.3.1/arm-none-eabi
<leoprikler>tbf I don't understand the issue in 47325 at all
<leoprikler>like why tf do you need a shell function to install the things to their correct location? that's what make install should do
<morgansmith>so gcc comes with a file that helps it find the libc or whatever. That little file says hey go look for libc_nano.a. but the upstream project only produces libc.a. this is because the upstream project is a fork of the fatter libc that creates a libc.a file. but also the file that says go look for libc_nano.a is in the upstream too somehow? It gets confusing real quick cuz there is sorta two upstreams in this specific case
<morgansmith>also the shell function clearly copies, but we should probably symlink or something. maybe hardlink? I've never done a hardlink before
<morgansmith>oh dear. the pre-built has a differnt sha1sum for libc.a and libc_nano.a. I guess we're supposed to just have one toolchain that supplied both the fat one and the nano one
<morgansmith>I think it makes more sense the more you know. I think the idea is that the nano lib deviated as little as possible from the project it's based on to limit the work they have to do but then people wanted toolchains that supported both newlibs instead of just one. So to build these toolchains, custom scripts where made
<leoprikler>As a user of Guix, it still doesn't make sense :P
<morgansmith>although that explanation still doesn't justify the nano.specs references to libc_nano.a. ugh. Ok make it doesn't make sense
<morgansmith>ok so the pre-built has a path of c++/7.3.1 but ours has a path of arm-none-eabi/c++. I guess I should figure out why that is...
<pkill9>here's an idea: if you try to open unknown filetype/URI with xdg-open, it offers you software that can be used to open it and guix gets the software ot open it
<morgansmith>that'd mean we'd make a system package that includes a custom desktop file that points to a script in the same package? Seems doable I think.
<morgansmith>if we can't do it using a custom desktop file we'd have to wrap xdg-open, right?
<morgansmith>Would this mean we'd extend the package definition to include an alist of binaries and the filetypes/URI's they open? Or is there a better way to collect this metadata
<morgansmith>oh actually the metadata would need to include the calling convention for the binaries as well I think
<leoprikler>well, you could just install a bunch of .desktop files, that launch guix environment with appropriate parameters instead
<pkill9>which is why I need all the .desktop files of all the packages
<morgansmith>would you have to scrape every package for it's desktop files then? So we'd have a package that depends on every other package? I feel like collecting the metadata is the hardest part right?
<pkill9>well ideally the guix data service would be extended to allow you to search for and download individual files from all the packages
<pkill9>which would be useful for other things, like finding out which packae provides a given library or binary
<morgansmith>the other day I was trying to figure out what package provided the dig binary. That is a really hard thing to do currently.
<morgansmith>I'm much more interested in that feature then the xdg-open stuff
<morgansmith>leoprikler: so the arm-none-eabi/include/arm-none-eabi path doesn't exist and I made a mistake on the axoloti patch. I really think my gcc patch is gold though. I'm looking at axoloti now
<Arnik>I have configured my confi.scm in this way: http://ix.io/2Va3 and I get this error: "guix system: error: service 'console-font-tty1' provided more than once". How can I fix this problem? please give me an example of corrected config.scm.
<morgansmith>tty1-7 are already defined. You could switch your tty definition to tty8 if you want.
<Arnik>morgansmith: How can I edit the previous defined , please show me an example.
<lfam>So, you are trying to figure out why Guix is warning you that it's getting old?
<echosa>Yes. But I already switched to an older generation (9, because of the misunderstanding), deleted the newer generations (they were just upgrades, no new installs), and am running pull and upgrade.
<morgansmith>Yo, I cannot figure out this damn console-font-service-type for the life of me. I got some error like this somehow: guix system: error: invalid character `*' in name `console-keymap.***-builder'
<morgansmith>is this not how you're supposed to do it? (modify-services %base-services (console-font-service-type s => (map (match-lambda ((tty . font) `(,tty . ,my-font))) s)))
<leoprikler>there's some wip in the mailing lists, but afaiu it's not yet very clear how we want them to be applied
<leoprikler>(other than that we certainly don't want to be gentoo)
<morgansmith>leoprikler: So about bug 44750, I'm super convinced that the gcc-arm-none-eabi v3 patch there is correct. I just sent a new patch (v4) that does axoloti a little nicer. So if you could commit those two patches, I would be super grateful!
<morgansmith>roptat: like at all? Is it against policy to mention it even if you condone it in the same sentence?
<utkarsh181>So how the functional aspect of Guix help you in your day-to-day task?
<morgansmith>Not arguing, I just want to be know the policy so I can follow it
<roptat>clearly, even if you condone them in the sentence, you're still encouraging users to use non-free software, that's a big no :)
<morgansmith>roptat: Sounds good. I apologize for mentioning them. I should've clued in when I read leoprikler's response. I won't do it again
<apteryx>is anyone actively using the go importer?
<vagrantc>i vaguely recall talk of releasing 1.2.1 april 18th ... is that still likely to happen? will there be release candidates over the coming week?
<morgansmith>utkarsh181: Instead of writing a 42 page document on how to setup an embedded development environment and build our projects I can just write a package definition that is only like 50 lines long. Easy reproducibility is crazy cool. That's probably the main time save for me :P
<vagrantc>nicer to have a release candidate tarball to run my magical spellcheck powers over :)
<leoprikler>morgansmith: regarding embedded development environments, tbph I don't have the guts to touch bootstrap packages of arches I don't use
<vagrantc>in similar news, would be nice if there was a "make dist" job running on ci.guix.gnu.org that exported the tarball somewhere
<morgansmith>leoprikler: do we actually use that package for much? To be clear, this toolchain is for bare metal development. So I doubt it is in heavy use at all. There is a completely separate toolchain for compiling packages to run on linux or herd on arm. This toolchain is completely different from that one.
<utkarsh181>Is this true that mojority of guix user are also emacs user?
<morgansmith>leoprikler: I'm like 99% certain I already investigated every other thing in guix that uses it and I've vetting it on multiple other projects.
<lfam>The CI makes installer images as part of its regular activity
<morgansmith>utkarsh181: I think it'd be hard to be a guix user without also being a guix developer. I keep finding myself needing to make more packages to keep up with the tools I use. Guix is built using scheme, and I'd say it's likely that most scheme/lisp developers use Emacs.
<vagrantc>lfam: but i need a release tarball, not an installer image :)
<leoprikler>To the extent, that I don't know how well parts of our manual would be received by users of other editors.
<roptat>utkarsh181, you don't have to use emacs to use guix :) I'm a vim user
<lfam>vagrantc: The binary installer tarball for Guix on other distros?
<vagrantc>lfam: when i've run it manually ... it tends to pick weird versions ... e.g. git describe --match=v'*' tends to return 1.0.1 or something
<morgansmith>so about bug 44750, is it going to just remain in limbo? Is there someone that feels comfortable with embedded stuff enough to commit to the arm-none-eabi toolchain? I do want to point out that the toolchain is very clearly broken currently and I don't think we can make it too much worse
<lfam>vagrantc: To clarify, which command are you running?
<kisaja[m]>about mentioning non free software. Maybe there should be a link to h-node so ppl can easily check their components before hopping on
<vagrantc>e.g. on current git master: $ git describe --match=v'*'
<leoprikler>thing is, I tried checking out v3 1/2 (which exists in patchwork), but it doesn't yield a useful comparison either
<echosa>lfam, I did it for both. `guix package --profile=$HOME/.config/guix/current --list-generations` shows 9 generations, all only involving `guix` package. gen 9 is the march 25 generation shown by `guix describe`. On the other hand, `guix package --list-generations` shows 4 gens, with my user packages (emacs, httpie, rlwrap, etc) with a date of april 7 (today).
<leoprikler>I can't promise you that patchwork delivers results for the rebuild quickly, though.
<lfam>Okay. `guix pull` is similar to `apt-get update`. It updates the list of available packages (and services, on Guix). Whereas `guix upgrade` is like `apt-get upgrade`; it updates the packages you've installed
<lfam>echosa: Is it not upgrading correctly? What happens if you run `guix pull` now?
<morgansmith>leoprikler: I'm upset because this patch is really important to my work and got stalled. The moment I can say it's no longer stalled, I'm happy. It doesn't need to be in today. It'd just be nice if someone said they would do it eventually.
<echosa>lfam, guix pull downloaded a bunch of things then said "nothing to be done". guix upgrade still says its out of date.
<echosa>and guix package --profile=$HOME/.config/guix/current --list-generations still shows march 25 as the latest/current generation
<morgansmith>ok, I've been stumbling around in the dark for long enough I guess. I'd like to learn about the support systems we have running for guix. Like the data service, and patchwork, and all the other things. Where can I find information on all the services?
<lfam>Hm, can you share the full output of `guix pull`, too? It's weird that it doesn't see that there is new code available
<roptat>something you can try is have a look at the cached checkout you have in ~/.cache/guix/checkouts (in one of the directories, I have pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq, but it can be another directory for you), check with "git status" that it's not dirty, and with "git log" that it's on the latest commit
<leoprikler>And wow, will you look at this, the package I've submitted is already scheduled.
<BlackMug>apteryx yeah i know but since ssh-server included by default any vulnerability exploited (known or unknown) will give malicious access to the distro before even fully installing it
<echosa>lfam roptat I deleted the checkouts directory and ran guix pull. It recloned the git repo, but it is still at the same commit and I still get the "x days old" warning. However, this time, the `git status` says I'm 474 commits behind. I don't konw why `guix pull` isn't updating it or why I seem to be stuck on this particular git commit.
<nckx>i1l[m]: No, the earth will hurtle into a dying sun at great speed with G.L.A.T. and their agents banned in #guix. The name itself is designed to troll, and that's the *cheritable* interpretation.
<nckx>Assuming that all who claim to've sent $ were trolling in return.
<echosa>roptat, Yes. `guix describe` now shows gen 10 and is commit 02297d3fe680371a4b97b9c1b770932cbdd55615 from Apr 07 2021 14:38:16
<nckx>Strange seeing all of lfam's commits/mails go by. But for the best.
<raghavgururajan>Unable to initialize SMTP properly. Check config and use --smtp-debug. VALUES: server=smtp.migadu.com encryption=tls hello=localhost.localdomain port=465 at /gnu/store/842fj3y7kv2vdlrddbnf04nm973wzml8-git-2.31.1-send-email/libexec/git-core/.git-send-email-real line 1566.
<nckx>(I think you can add assume8bitEncoding = UTF-8 to the [sendemail] section to skip that first prompt.)
<nckx>465 is suspicious, raghavgururajan. Sure it shouldn't be 587?
<civodul>apteryx: re qt-build-system, sure! efraim also listed a number of issues, but i haven't yet taken the time to look at them
<raghavgururajan>Few Reasons I chose Migadu:  Web-portal works without JS  People behind it are fellow free software activists  Fair billing (by usage and not by no. of address/mailboxes/aliases etc.)  Excellent Support  They are working with SourceHut folks to create JS-free webmail system.
<raghavgururajan>Yo! When can I expect response for my application for commit access. :D
<BlackMug>nckx what prevent malicious package to run commands within guix system? I tried to find that in the wiki but i failed. e.g malicious maintainer -> malicious package order it after installation to execute guix do x or (passwordless) sudo do x
<nckx>I can't say. I think it's delayed (more than usual :) for various other unrelated reasons.
<BlackMug>i know sandboxing is not yet implemented within guix, but any other mechanism used to defend suck attacks?
<nckx>BlackMug: We're a traditional distribution in that as a user you implicitly trust maintainers (committers). Unix isn't built to defend against malicious software you yourself run; we haven't yet adapted any of the retrofitted hacks like sandboxing.
<BlackMug>i know maintainer -> attacker -> distro is good defended by guix , but wonder if the maintainer himself is intended to develop malicious package what are the defends against that
<nckx>None; that's not a threat model unixes ever addressed.
<raghavgururajan>sneek, later tell lle-bout: It have sent patches to #47643. Could you specify the spots you were referring to regarding comments, via replies? I'll edit and resend that patch. Also, could you start a new branch 'wip-gnome' on savannah please? Thanks!
<BlackMug>rekado_ i didnt say better, but preferable because it solves the complexity issue
<lfam>The way that Debian works is that maintainers upload binaries, and that's what users get. In Guix, we upload source code, and binaries are built from the source code
<lfam>It's categorically better in terms of how much you have to trust the distro
<lfam>But, in both cases, you have to trust the people involved
<BlackMug>exactly thats why i think android AOSP is a head upon solving this issue
<lfam>Anyways, if you are very concerned about security, I advise you to avoid Linux
<BlackMug>in gnu/linux world something can be achieved within Qubes is having Appvm removed from roots rights (but sorta complex to reach to that point but yeah maybe i would call best security available)
<zzappie>Im not sure that debian is the best example btw since they have ReproducibleBuilds. But I don't know much about it
<lfam>Yeah, you see how hard it is to even begin securing it
<BlackMug>zzappie debian is heavily you must trust their devs, malicious package would take over your entire distro
<lfam>Until Debian builds their packages centrally based on source code...
<lfam>Not to put them down. Debian is still my main OS
<BlackMug>yeah same here i only use debian and Qubes