***Guest6324 is now known as sturm
<EternalZenith>If the source for a package is available from git, should that be used to fetch it according to release instead of url-fetch? <mange>Ideally we only want 'guix refresh' to choose actual releases (not just "most recent commit"), so using git doesn't necessarily help the refresh use case. <mange>If there are packaged source releases then we tend to use those, but if there aren't then using the git repository is still good. <mange>You can, but then guix refresh needs to know how to detect a release (is it a tag? how is it formatted? or maybe it's a branch?). <EternalZenith>It seems to me like most projects use tags, but that makes sense <mange>We have a github updater, which looks at github releases, but git itself lends itself to lots of different workflows. <mange>I wouldn't expect so. Do they have the same API? <EternalZenith>I don't think so, but I think it handles things in a similar fashion <mange>They're another function of the importers, so guix/import/*.scm. Github, for instance, is in guix/import/github.scm. At the end of the file it defines %github-updater. <EternalZenith>Wait, does this mean that guix can attempt to import projects from github? <EternalZenith>Nevermind, I see that it's missing much of the things the other importers have <mange>Yeah, I think the github one only has an updater. <mange>Which makes its presence in guix/import all the more surprising. <EternalZenith>It'd be interesting if it could generate a basic package definition by filling in all the fields it can <mange>I imagine that wouldn't be too hard to build, but it wouldn't be able to fill in anything related to actually building the checkout. <EternalZenith>It's sad how many packages from other distrobutions skip any and all integrity checking and signature verification <EternalZenith>Looking at arch PKGBUILDs for reference, very few seem to actually check the hashes of the downloaded files <EternalZenith>That's bitten me several times, where a page fails to load, and instead of a package being installed, you get odd things <EternalZenith>E.g., the source for a package on the AUR came from a website that was blocked on the network I was using, and somehow the install continued and made my system unable to start graphically untill I manually deleted all the corrupted files and reinstalled later at home <mange>Yeah, okay, that sounds pretty unsafe. <EternalZenith>Yup, I had a school "This website is blocked on the network" html pages installed in /etc <lfam>Roughly how recent was this? <mange>Surely that can't be common, though. That just sounds so obviously wrong. <lfam>In that case you sort of got lucky because it was an accident and things were obviously broken <EternalZenith>It happens frighteningly often, since so many people who make AUR packages add something like "md5sums=('SKIP')" into their PKGBUILDs <EternalZenith>If something gets corrupted, the package might just fail spectacularily to build, or it might slip through <lfam>Hm... in my opinion, that being possible goes too far towards the convenience side of the convenience / security spectrum <mange>Seriously! That's not even "security", that's just reliability. Trusting that the download was successful and had nothing wrong is already a problem. <lfam>Well, a lot of people complain about how TLS / HTTPS is slowly becoming mandatory. It can be really inconvenient sometimes <lfam>So, I understand their complaints. But I agree with the direction the big browsers are going in this regard <lfam>In the firmware package recipe you linked, does 'git+https://' mean that it will try the Git and / or HTTPS protocols? <lfam>The Git protocol doesn't feature any authentication or privacy. Maybe it just means "Git clone this HTTPS URL" <lfam>So, is that PKGBUILD how Arch Linux builds the Linux firmware for all users? Or is it some special AUR / community repo? <EternalZenith>The users aren't usually building it though; it's being built locally, tested, and then pushed to users through one of the mirrors <EternalZenith>Even still, that issue pops back up if you want to build it locally or for any of the frighteningly many of the 50k AUR packages that have this same issue <lfam>Yeah, and also the Arch maintainers will not be immune either <lfam>Although Guix is designed to require a source hash, we should be watchful that we don't have similar problems due to mistakes and other oversights <lfam>Most of the big distros have discovered critical package authentication bugs in the past years <lfam>Typically to the point where they might as well have not bothered signing the packages <lfam>So, I think it demonstrates that these kinds of implementation or design mistakes are really easy to make <EternalZenith>I used to think that my laptop was a bulwark of security with its fancy aes-xts-512 block device encryption, a hardened kernel, limited nonfree firmware, a nice firewall, and sandboxing, among other things <EternalZenith>I'm now coming to see that such a sense of security is a big illusion <lfam>I agree, computing is still in its infancy as a human endeavour, and we understand it very poorly <EternalZenith>Guix and its philosophies seem like a step in the right direction <EternalZenith>So, hydra.gnu.org is the current source of official substitutes based on Nix's Hydra, and berlin.guix.info is the future one based on Guix's Curaiss? <lfam>EternalZenith: That's right, although you could consider them both "official" in the sense that they are both maintained by Guix developers and we distribute their signing keys in the Guix source code <lfam>Also, I *think* the canonical URL for berlin is <berlin.guixsd.org>, but not sure. rekado is the main person behind that system <lfam>That's how the signing key is named, anyways, so it must be the preferred URL :) <civodul>sounds like it could be a lot of fun <g_bor>I have a reproducible javadoc for icedtea-6 now. <g_bor>It seems to me that when you check, only the first differing output is listed. Is that correct, or I did not pay proper attention to the output? <civodul>i haven't followed closely but thumbs up <g_bor>I mean when you guix build --check, or --rounds=2, I did not see that the second output also differs until I fixed the first. <civodul>it's possible that only one output is reported, not sure <g_bor>fortunately rekado has a fix for the out output on icedtea-8, so I will backport that, and hopefully finish icedtea-6. <civodul>are you coming to the R-B summit BTW? <roptat>by the way, I didn't get answers to my patches for openjdk 9 and 10, is it ok to push them? <g_bor>roptat: I did not see them yet. <roptat>I tagged them WIP because I'm pretty sure they can be improved <roptat>they are good enough (they build and work properly) but, the default output might be a bit big, and I'm sure there's a lot of bundled code we could get rid of <g_bor>roptat: ok, I had a quick look at that. <g_bor>They seem to be ok for now, I would leave polishing for jdk11, we can clean up 9 and 10 later. WDYT? <g_bor>Also do we actually need 9 and 10,or just 11 would do? <g_bor>Do you know anything why we need to keep them in? Bootstrapping? <g_bor>Or some packages are still depending on them? <roptat>you can build 9 with either 8 or 9; 10 with either 9 or 10; 11 with either 10 or 11... <g_bor>I would go with them as is, and handle them as we do with icedtea-6 and icedtea-7, part of bootstrap, it should work, be reproducible, but not need to be perfect. <roptat>I don't think any package depends on them because you're supposed to be able to build any version of java lower than or equal to your jdk's version <roptat>(I mean if you need a java 7 compiler, you can use jdk11) <roptat>civodul: is it ok to push them to core-updates (no rebuild, but they depend on core-updates's gcc)? <roptat>or I could wait until core-update is merged <civodul>roptat: the patches that add openjdk 9 and 10 can go to core-updates IMO <civodul>is there no IcedTea for these versions BTW? <roptat>civodul: no, icedtea is just an overlay to openjdk. it was required for 6, 7 and 8 because they missed a few things, but starting from openjdk9, everything is freely available <roptat>although, I'm not sure what happened to icedtea-web <g_bor>I'm trying to get a 0.11.0 guixsd up to date. <g_bor>I'm a bit stuck, istm that there is some problem with a guile-git depedency, it is redirected to a github sign-in page. <civodul>g_bor: i'm afraid this is going to be difficult :-/ <civodul>main reason is that 0.11 provided a rudimentary 'guix pull' that did not produce a standalone Guix <civodul>what you could do is 'guix copy' a full Guix from another machine <amz3>I just installed guix in fresh VM and I am trying to build guix from git. I did 'guix pull && guix package -u' and 'guix environement guix' and then running ./configure tells me: configure: error: Guile-Gcrypt could not be found; please install it. <amz3>(I solved my problem with apparmor and sent a mail the mailling list about a solution) <civodul>amz3: i think you need to install Guile-Gcrypt ;-) <civodul>well ok, 'guix environment guix' should provide it if you did 'guix pull' before <civodul>could it be that you're not running the just-pulled 'guix'? <civodul>try with ~/.config/guix/current/bin/guix environment guix <civodul>(then make sure it's in $PATH, run "hash -r", etc.) ***astronavt_ is now known as astronavt
<dustyweb>I thought it did but there's a bunch of really old crap in there <civodul>dustyweb: it does, but there was/is a bug with file names with a weird encoding <dustyweb>well, just wiped a bunch of stuff manually :) <deadman007>hi, does any configuration for lxqt desktop on guixsd ? <nico202>can someone help me in sending a patch? I sent it using git format patch + git send-email, I tried sending it to myself and it worked, but sending it to guix-patches@gnu.org does not seems to work.. <roptat>nico202: if that's the first time you send an email to that list, it might take some time before it is accepted ***astronavt_ is now known as astronavt
<lfam>libssh: By presenting the server an SSH2_MSG_USERAUTH_SUCCESS message in place of the SSH2_MSG_USERAUTH_REQUEST message which the server would expect to initiate authentication, the attacker could successfully authentciate without any credentials. *lfam prepares the upgrade <lfam>Hm, trickiness with their Git repo <lfam>It uses the "dumb" HTTP transport and so it doesn't support shallow clones / fetches, and our code's fallback doesn't seem to be working in this case <lfam>Either that, or the clone just takes forever... <lfam>I think it's just very slow <efraim>"no, I know I'm good, just let me in" <lfam>Woooooow, this bug was reported to Mitre in May 2018, but only fixed yesterday :/ <vagrantc>EternalZenith: if you use "sudo -E guix ..." then you can just update as the user <vagrantc>EternalZenith: and root will use the guix from the user's profile <vagrantc>if you actually log in as root, then you might need to update them indiviudually <EternalZenith>I've been using sudo -i, could that potentially cause problems or require that I run 'guix pull' multiple times? <lfam>EternalZenith: It's different in that it logs you in as root (-i is short for --login) <lfam>Whereas with -E, root just inherits your unprivileged user's environment <EternalZenith>Yeah, I was doing that as I assumed that if I updated root's guix, it would carry over to my user <lfam>With --login, you end up with separate Guix's, one per user <lfam>Or... Guixs. It's hard to pluralize this word :) <EternalZenith>Is there any way to get my user to inherit Guix from root, or does it do that anyway? <lfam>It doesn't do that automatically, and it would require making parts of root's files available to unprivileged users <EternalZenith>But I thought that those files would be in the guix store, and just symlinked to the user's profile? <lfam>I used to know how to do it but with the recent changes in how profiles are stored I'm not sure if my old methods still work. Basically, make one user's profiles a symlink to the other users <lfam>The safe way to do it would be to use the profiles in /var/guix/per-user/profiles, rather than exposing ~root/.guix-profile <lfam>It depends on if you want to use the profiles or Guix itself. To avoid multiple `guix pull`s, symlink the result of `guix pull`, which is in ~/.config/guix/current <EternalZenith>I'm asking this because I've been running 'guix pull' as root and my user, and then updating with 'guix system reconfigure /etc/config.scm' and then 'guix package -u' as my user <lfam>It sounds like you've been missing `guix package -u` as root <lfam>Unless you don't have any packages installed for root <lfam>Okay, then you don't need to do it as root <EternalZenith>I assume 'guix package -u' only affects things in a manifest? <lfam>Profiles can be created from manifests <lfam>They can also be created imperatively with `guix package --install`, etc <EternalZenith>That's how I've been doing things as my user, but that feels kind-of lazy <EternalZenith>I originally thought that there would be something like a system config for users where I could install and configure things <EternalZenith>Is there some way to use 'guix download' for downloading and getting the checksum of a git repo at a certain tag or commit? <EternalZenith>I haven't been able to successfully run 'guix system reconfigure' in several days <EternalZenith>My system becomes almost entirely unresponsive whenever it tries to build the icecat derivation and I have to force it to shut down <EternalZenith>The mouse moves, but only very slowly with a bunch of latency; i3 and everything else become almost entirely unresponsive as well <EternalZenith>I tried letting it run for a few hours, but nothing happened <amz3>EternalZenith: hardware spec? <EternalZenith>I realize that Icecat would take a while to compile, but 4 hours seems a bit much <EternalZenith>And the way everything stops working after 10 minutes or so is odd <amz3>does 'dmesg' command says anything useful? <amz3>and how much RAM do you have? <EternalZenith>I have 8 gb of ram, and I'm not sure how to find the dmesg logs from the last boot <EternalZenith>How do I find the build logs for a specific derivation? I have no idea where in /var/log/guix/drvs/ to look for the last build <pkill9>oh cool, didn't know that exists <EternalZenith>But that directory contains the logs of literally every build run on the system <pkill9>the logs are timestamped, so you could find the newest log for a particular package <EternalZenith>How long does that usually take? I'd think that with 4 cores/8 threads and 8 gb of ram Icecat should be able to finish in a few hours <ngz>I wonder why gexps are used in services but not in packages. <civodul>ngz: historical reasons: they didn't exist back then <EternalZenith>How do I state in a package definition that a package cannot coexist with another? <civodul>but note that if two packages have the same name, they cannot be installed in the same profile <EternalZenith>I'm trying to package i3-gaps, should I just leave its name as i3-wm and rely on it coming from a different place? <civodul>if it's called "i3-gaps", i'd just call it that way <civodul>then i'd say it's up to users to not install both in the same profile <pkill9>also if there's any file conflicts, then guix will raise an error, so you wouldn't be able to install i3-wm and i3-gaps to the same profile anyway <EternalZenith>'guix weather' isn't working for me; it just returns "guix weather: error: build failed: derivation `/gnu/store/ad97mln4w2rg474dyy694mnq38rhdir4-git-checkout.drv' has incorrect output `/gnu/store/7ygy97wz9d1zcbz3k2kg1ga9g389bd7b-git-checkout', should be `/gnu/store/2669wx1lhr57nh0f2f5cdfvmhl7nxx8v-git-checkout'" <amz3>EternalZenith: try to rebuild icecat and check dmesg when is slow <amz3>EternalZenith: it might a mal function of the cooling system