<Petter>I'm a little stuck at the moment with Syncthing, http://sprunge.us/FgZB Are there any write constraints between different store items or something when building? <lfam>Petter: The store directories are immutable. Once they are built, they can't be modified <Petter>Oh, sounds like what I'm facing. <Petter>That gives me something to pursue at least. I was drawing a blank previously. Thanks! <Petter>By the way, with Syncthing itself I'm up to 55 packages now. <lfam>I hope that each of those packages doesn't have too many dependencies <Petter>I feel this is a solid number for a second package contribution ;) <Petter>I think they're all taken care of, and it's just the last stretch now. <lfam>In the build output that you pasted, is that the syncthing package trying to build its dependencies from within the syncthing build? <lfam>Like, why is the syncthing build process trying to write to directories in /gnu/store? <Petter>I don't know why it does that, hoping I can find this out. <lfam>I think you're at the point where it will be useful to try abstracting all the customization of gnu-build-system into a go-build-system, so you don't have to copy and paste it so many times. <Petter>Yes. I wanted to get it building first, and figured we could work on the build system and tweaking it later. <lfam>Sadly, I haven't written a build-system yet, so I can't offer very specific advice <lfam>Skimming those packages, it seems like packagers will need to supply the source URL, commit, and source hash. The src used in the unpack phase and the target for "go install" can both be calculated from that URL in most cases, right? <lfam>The version can be calculated from the commit. I actually think we should make a procedure to do this for all packages using git-references, since it requires a lot of boilerplate to build the version string correctly <Petter>Also, 6 characters is short enough that I type it rather than copying, which increases the chance of getting it wrong. <lfam>Let the computer do it :) <lfam>6 characters is also not a unique reference in large Git repos <lfam>Not that it really matters for the version string... <lfam>I find it interesting that the build phase calls `go install`, but then there is another install phase. <lfam>Does `go install` not actually install stuff? <Petter>Vaguely related, if you look at the last packages I've gone from the typical (from what I've gathered) file-name of `name "-" version "-checkout"` to `"domain.com-" version "-checkout"`. <Petter>It seemed like a good idea because several packages may use the same checkout. <Petter>And I'm assuming the checkout will be reused. <lfam>I don't understand yet. Why is the package name not enough? <Petter>When using the name the checkouts will be named differently while being they are the same. <lfam>The checkouts lack the .git metadata. Git reference'd sources `git checkout` the commit that the packager has selected and then delete the Git repo itself <lfam>So, the resulting source in /gnu/store will be a different thing <lfam>The .git directory changes over time, while the value of a given commit does not. We have to delete that .git metadata to ensure that the source is the same every time it's created. <Petter>Won't the previous examples both use, /gnu/store/8z7fm14frhhwi9p3pycd7gbsza1c6idz-go.googlesource.com-text-a71fd1-checkout ? <lfam>Yes, in that case they will <lfam>They use the same commit of the same Git repo, but build different parts of the source code in the repo <lfam>I still think the source code should contain the name of the package, however. <lfam>The linter recommends this :) <lfam>But your point about saving a download is a good one. This is bikeshedding. It can be decided later : <Petter>The linter can be reprogrammed :P <lfam>Let's not get our paintbrushes out just yet ;) <Petter>I agree, and bikeshedding is something I figured we could deal with later, when it works. <lfam>We still have to build the shed <Petter>I expect some raised eyebrows with the package names as well, (name "golang-org-x-text-unicode-norm") <lfam>Once the shed is built, who cares what color it is? Everyone will use the shed :) <Petter>You asked about the installation. <lfam>Yes, I'm curious about that <Petter>I'm using the 'install phase to copy from the /tmp/guix-build* to /gnu/store. <Petter>`go install` installs to $GOPATH/bin (unless GOBIN is set). <lfam>I found that Syncthing's build scripts don't respect GOBIN <lfam>Ah, that's different than without 'run', is it? <Petter>Yes. There's `go run`, `go build` and `go insall`. GOBIN is only consulted by the latter. <lfam>If you use `go build` in the build phase, does it save copying the files around? <Petter>Would you have done things differently with regards to 'build and 'install phase? <Petter>`go build` puts the binary in the either the project folder or current directory, not sure. <lfam>My naive perspective is that it's cleaner to use `go build` in the build phase and `go install` in the install phase <Petter>`go install` also puts package objects in $GOPATH/pkg, to avoid compiling unmodified code. <lfam>But you know better than me if that would work, if there are caveats, etc <Petter>I don't think GOBIN affects package objects. <lfam>Now I'm curious about what Debian did <Petter>I wonder if the logic for package objects works in the store, if it's based on timestamps or what. <lfam>It would be nice to avoid moving those files twice. Probably in many cases they won't actually get written to disk twice, but if RAM is constrained it could be annoying. <lfam>I'm going to reboot this machine. Hopefully I'm back soon ;) <Petter>Ah, just after the reboot world record. Sorry. <lfam>Lol. I actually did some stuff after the reboot. It's not that slow ;) <Petter>I like the idea of writing just to /gnu/store, rather than the going by /tmp/guix-build*. That's what you meant, right? <lfam>Petter: Yes, it seems more efficient <Petter>Indeed. Thought just never occurred to me. <lfam>Spending lots of time with Guix on a spinning disk has made me think about this issue more often :) <Petter>Ah, my X200 is so blazingly fast that even gross inefficiencies goes unnoticed. <lfam>I love seeing my 4 core machine's load spike to 25 <Petter>Luckily they go all the way up to 26, so when you really need it you can crank it up one more. <lfam>I'm sure mine goes higher than 26 ;) I can run `guix gc`, trigger some btrfs background operation, and run a backup all at once. Then it's a good time to take a break <Petter>Oh, I interpreted it as 25 being 100% for 4 cores. <lfam>25 is a computer where the only thing that responds is the mouse cursor <lfam>albertoefg: Hi! Want to play hedgewars? <lfam>Oh, I'm sorry to hear that :( <albertoefg2>sneek: tell lfam that albertoefg will beat your ass tomorrow don't worry <sneek>lfam, albertoefg2 says: that albertoefg will beat your ass tomorrow don't worry ***kelsoo1 is now known as kelsoo
<rekado>re cross-building for macOS: I looked at this a while ago, but it seems that you must have at least the XCode SDK to even get GCC to work. <rekado>there’s an ancient abandoned port of the glibc, but that doesn’t seem to be usable. ***ktosiek is now known as ktosiekk
***ktosiekk is now known as ktosiek
***ktosiek is now known as ktosie
***ktosie is now known as ktosiek
<Petter>lfam, LLLFAAAAAAAM. It works, it builds :D <civodul>Petter: great that you're working on Go! <Petter>I feel valuable experience was gained with Syncthing to work out a more robust build system than before. <efraim>with harmut's pyqt-5.6 patch, calibre builds with pyqt-5.6, which means we can drop pyqt-5.5 <Petter>I'm wondering; can, and would it make sense for, the build system to make the symlinks done in the 'build phase here, http://sprunge.us/aXEH ? <Petter>I think symlinks is the always-work-choice, while the GOPATH trick is more fragile. <fredmanglis>Hi there. Is there a way to reuse the build files retained with 'guix build -K' <fredmanglis>I find myself trying to package something that is taking a really long time to compile from scratch <civodul>Petter: i think the "go-build-system" should have a separate phase that sets up those symlinks <civodul>it's always better to separate phases: it allows people to skip them, override them, etc. <civodul>fredmanglis: yes: you can "chown -R /tmp/guix-build-whatever", then cd there, then "source environment-variables", and then build/debug from there <civodul>the 'environment-variables' files contains all the necessary env vars <jmd>Do we have any packages for mimeencoding files? <Petter>Separate phase sounds good. Making the symlinks behind the scenes would be great. <Petter>Can the build system get the url used in (source (origin))? <thomasd>probably something like (origin-uri (package-source my-package)) <thomasd>maybe you'd need to make the (guix packages) module available (not sure if it's available by default) <Petter>I'm working on the build system itself now, for Go. <Petter>In guix/build/go-build-system.scm. <Petter>I get "Unbound variable: origin-uri". <Petter>Maybe I need a phase that must always be replaced, where the "importpath" (Go thing) is specified. It can usually be derived from the url. <efraim>Check out python build system, it makes changes based on python2 or python3, it's not what you're looking for, but it might lead you in the right path <efraim>I'd also look for where the version of a package is pulled over, that's closer in that it would be evaluated later and not analyizing an input <Petter>Interesting, "(define* (pypi-uri name version" <htgoebel>efraim: Given that calibre still required Pyqt 5.5: Okay to push the three pyqt patches? <efraim>htgoebel: yeah, they all look good <roelj>Does Calibre actually run on your machines? <htgoebel>roelj: No, it fails with "ImportError: No module named QtWebKitWidgets" <roelj>Right. I've been having that for a long time. (hanging on to an old version ever since) <htgoebel>roelj: Do you want to take care of this? Would be great! <rekado>I'm working on a qtwebkit package, but it isn't ready yet <roelj>htgoebel: Unfortunately, I have a serious time deficiency to work on it. Sorry <thomasd>htgoebel roelj: have you tried switching to modular qt packages? <thomasd>that fixed the same issue for texmaker <thomasd>i.e. instead of "qt", use inputs "qtbase" and "qtwebkit" (possibly some others, too) <roelj>Yes, I tried. But I think Calibre needs PyQtWebkitWidgets <htgoebel>thomasd: Esp. the python bindings for qtwebkit are missing. <rekado>civodul: oh, indeed. What I'm working on is qtwebview and qtwebengine. <rekado>I have a problem with certificate validation again <rekado>running "guix import cran -a bioconductor MSnID" I get an error <rekado>guix/build/download.scm:383:6: In procedure tls-wrap: <rekado>guix/build/download.scm:383:6: X.509 certificate of 'hedgehog.fhcrc.org' could not be verified: <rekado>no SSL certs dir among the environment variables <rekado>it's fine after export SSL_CERT_DIR=/home/rwurmus/.guix-profile/etc/ssl/certs <htgoebel>civodul: We still have the test-case "guix gc --keep-going" open. You remember: there is a bug in nix-daemon freeing store locks for the same process. <htgoebel>I'd like to finish this task and enable the test-case later. <civodul>htgoebel: problem is the bug will take a bit of time to address <civodul>it's easily fixed, but several tests rely on the buggy behavior <civodul>so we'll need to carefully check what to do <civodul>i can't do that right now, so i think we'll have to postpone a bit <htgoebel>civodul: postbone the whole "guix gc --keep-going", or just the test-case? <civodul>htgoebel: both, we won't commit the thing without the test case :-) <civodul>unless maybe we can write the test case in a different way? <quiliro>i have successfully installed guixsd in 9 hours <quiliro>with just the base desktop.scm configuration <quiliro>what package should i install in order to reproduce html5? <davexunit>quiliro: you mean you want to download this video? you can use youtube-dl for that <quiliro>i do not like to download but just reproduce <quiliro>i would like to use the default software and its addons <quiliro>davexunit: I want a stack that an end user has all that they need <quiliro>i found that the gnome browser (GNOME Web) would download the videos and then you can click on downloads and reproduce them....but it will not do so in youtube <quiliro>buenouanq: i know i have tyo install it...but i don't know what to install <buenouanq>my unhelpful stance on this is that a wobbrowser has no right to be a mini virtual operating system - Videos should be played with a video player. <quiliro>buenouanq: that is something i would like to try.... <buenouanq>for things it can't play directly, youtube-dl and livestreamer are very nice and helpful <quiliro>but would not like to meke the user think too much about what to do <jin>quiliro: in Icecat you can see some videos <quiliro>jin: what is the difference between icecant and gnome web? <buenouanq>Icecat is GNU"s packaging of Mozilla"s Firefox browser - `Web' used to be Epiphany which was forked from Galeon but is still Gecko (Mozilla) based. or something <buenouanq>I disagree - End users need to stop pretending like they incapable of learning or doing something in a different way than what they're used to. <civodul>let's not call them "end users" to begin with :-) <quiliro>is it possible that the browser will open mvp or so if it you click a youtube video it is played directly with mvp without other actions necessary? <buenouanq>the first you can do simply with a plugin (though I don't remember which), the second is a little more complex and I've yet to find a good way to do it <civodul>quiliro: browsers play videos directly in their own window <davexunit>icecat won't play mp4s, which is frustrating <buenouanq>I'd never notice because I block everything anyway. <davexunit>it also doesn't have working webgl, which is also frustrating. <buenouanq>plays in Icecat if I disable some of my plugins <quiliro>it is possible to click on the download list (down arrow) on the browser and play the video <buenouanq>if you've downloaded the video, you can play it with any video player of your choice <quiliro>why will it play on icecat and not on gnome web? <buenouanq>no idea, but I can confirm now that it doesn't <quiliro>buenouanq: what would you call a user which does not want to use the command line <quiliro>buenouanq: oh...thank you for confirming <quiliro>how can i make Gnome Web download the video when i click on it? <quiliro>buenouanq: what is the advantage of mvp over totem? <quiliro>buenouanq: not all users want to learn about how computers work <quiliro>so making it easy for them is necessary <quiliro>or else they would not use computers <buenouanq>knowing how to call a program from the shell has nothing to do with knowing or learning how computers work <quiliro>\\many people are not interested in that <quiliro>so there is a choice we have to make <quiliro>help them or let them use nonfree systems that provide that help <quiliro>it is impossible to ban them from using nonfree software <quiliro>it is important to get them on our side <quiliro>if it were not possible to do with free software it is something else <quiliro>buenouanq: what reason is there not to provide such functionality to themn? <quiliro>the backlash is an unintended product of using an english keyboard <jmd>quiliro: I have an English keyboard. There is no backlash on any of my keys. <jmd>Well actually that is probably not exactly true. All keyboards will have a small amount of backlash. <buenouanq>I firmly believe that web browsers have no right in becoming the terrible bloated media player virtual operating systems they have - Luckily for you, I am a part of a very small minority in this. <jmd>Otherwise there would be a lot of key-bounce. <jmd>Oh you meant "back-slash". <quiliro>buenouanq: i am not against having the media player and web browser separate <jmd>Well on the English keyboard, the back-slash is to the left of Z <buenouanq>A reason might be that we already have perfectly good and often superior tools to do exactly what you ultimately want, and there are more important things to work on. <quiliro>jmd: perhaps it is international english the one i have <jmd>quiliro: More likely its a US keyboard. <quiliro>jmd: ok...i get your point now....it is like the act of calling only people from the US American and leaving the rest of America out of this denomination <quiliro>US versus UK and Unitedstatesian versus American <quiliro>perhaps there is no name for a USA citizen <jmd>It is interesting that the continent is named after a Spaniard. <quiliro>jmd: thank you for showing me the things in perspective <jmd>At work all our rooms are named after mountains of the world. I started a pressure campaign and got them to change the label on the one previously labelled "Ayre's Rock" <jmd>It is politically incorrect to use that name today. <jmd>Because the Abbos object to it/ ***reepca` is now known as reepca
<albertoefg>sneek: later tell lfam that albertoefg wants revenge <OriansJ>Is there something I can add to my configuration.scm file, which will force guix system init /mnt/etc/configuration.scm /mnt to build all of the binaries from source? <OriansJ>I of course know, I could simply always remember to put --no-substitutes but if it is in the configuration file deployed, I know it isn't going to be accidentially forgotten. ***kelsoo is now known as kelsoo1
***kelsoo1 is now known as kelsoo