<davexunit>rekado: figured out the gsch2pcb issue. m4 needs to be available in the environment. going to see if I can fix the package to include an absolute path to it <lfam>ACTION works on the samba update <slim404>ACTION trying to set up the display manager with french keyboard <slim404>just realised that gnome on guixsd is only 14 days old <bavier>slim404: you're on the bleeding edge :) <slim404>bavier: yes :) and i did not realize because everything was effortless and without glitches <lfam>slim404: Except for the french keyboard problem? <bavier>slim404: I'm glad it's working for you <slim404>lfam: yes, but that is just fun. Man the soundcard worked out of the box with all that pulseaudio thing on my little aspire one <lfam>Indeed, I was very glad when audio worked out of the box for me, especially since I have had bad experiences with PulseAudio in the past! <lfam>It would be nice to configure sound in the operating system declaration, but at least I can listen to MPD :) <lfam>Or, the `guix hash` of it? <bavier>0d7q058vsmpsxlqz33ngwlf0invjmc99x33ig7ny9cp657r8mh3 <lfam>Are you sure the last character isn't missing? <lfam>BTW, while you were doing that, I realized they sign their patches, but don't link to the signature from the security advisory page. But thanks anyways! <lfam>Wow, with my comment at the top, `wc -l` says it's 39533 lines long <bavier>lfam: could we not just do a release update? <lfam>I don't know their versioning system, so I went with the patch. Is it compatible with 4.3.6? <bavier>it sounds like 4.3.8 is the patched release for the 4.3 support branch <lfam>It seems that 4.3.7 and 4.3.8 are security releases on top of 4.3.6. One would assume 4.3.7 is equivalent to applying the patch. <lfam>I guess they issued the patch for distributions that don't like to bump version numbers <lfam>I'm testing to update to 4.3.8 <bavier>I think we should do the version update, since 4.3.6 itself was released just more than a month ago <bavier>if build/testing go smoothly that is <lfam>I have to rely on upstream's test suite since I don't use samba. <lfam>And I also rely on the assumption that a security update is compatible with what it replaced... <lfam>Well, our package disables the test suite. <bavier>that makes things more difficult <bavier>hrm, I'm trying to fix timestamp reproducibility issues in some packages I'm writing, but I'm having trouble deciding where to put the fixes <bavier>as patches/snippets in the origin, or as phases that do substitute* <lfam>samba 4.3.8 builds. Do you think I should apply the update? <lfam>Knowing that we didn't run the tests? <lfam>I think that if the changes require patching, and the patch fits easily in a (substitute*), then you should do that. It's better than hiding it in a patch file. <lfam>Although then users who checkout the source don't get your fix <lfam>I don't know. I think we should try to push these changes upstream if the upstream is active <bavier>yes, ideally they would be patches to upstream to support SOURCE_DATE_EPOCH <bavier>lfam: I think you could apply the samba update <lfam>Yes, I'm writing the email now <iyzsong>I'd put them in snippets, they're not guix specified patches. snippets also get applied into 'guix build -S'. <lfam>iyzsong: Good point. They could be useful on other systems <lfam>Although the nice thing about a patch file is that, if it's good, you can send it directly upstream <bavier>the snippets would be to fix a date string in the source <lfam>There's no bug report like a bug report with a patch <iyzsong>yep, patches is better for upstream. <bavier>I don't think that would disappoint anyone doing 'guix build -S' <lfam>Especially if you preserve upstream's behavior if SOURCE_DATE_EPOCH is unset <lfam>On this topic, I recently noticed timestamps in many man pages. We should work to get this fixed in the manpage generators <lfam>bavier: If you are interested in this stuff, you should checkout #debian-reproducible and #reproducible-builds on irc.oftc.net <lfam>And probably many others <bavier>lfam: oh, I didn't know there were irc channels <lfam>I've been ignoring Python 3 reproducibility issues until we get the bytecode compiler fixed, but many of them have timestamps in man pages <lfam>I need to start contributing to it <lfam>The database notes timestamps in manpages created by doxygen, yat2m, ronn, Pod::Man, sphinx, txt2man, help2man, docbook2x, docbook_xsl, docbook_utils, libwibble, pandoc, golang_cobra and autogen. <bavier>ample opportunities for success ;) <lfam>It will require so many emails... ;) <lfam>iyzsong: Thank you for fixing that bug! <dmarinoj>Does anyone run Guix as a package manager on Hurd here? Just installed Debian GNU/Hurd and am interested in using it as a second package manager. ***Basstard1 is now known as Basstard`
<slim404>I tried herd start gdm it did not work <slim404>guixsd gnome desktop is provided with SLIM as display manager in default install <slim404>since SLIM does not seem to support non US keyboards, I'm trying to replace it with GDM <alezost>slim404: it looks like we don't have a service for GDM, so you probably can't use it right now; but I'm not sure, iyzsong should know better <slim404>alezost: thanks. I installed the gdm package doing guix package -i gdm. Is it supposed to be started from command line? <slim404>iyzsong: shall I remove the package? <iyzsong>yes, gdm can't running now. it want to start /usr/bin/X, I haven't patch that. <slim404>alezost, iyzsong : btw, I can't find the shepherd startup script. documentation says it should be /etc/shepherd.scm but it's not there <iyzsong>slim404: it's in the gnu store, you can find that from '/proc/1/cmdline' or /run/current-system/boot <alezost>slim404: every system has its own shepherd config. Look at "/var/guix/profiles/system/boot": there is a link to "/gnu/store/…-shepherd.conf" ***joachifm is now known as Guest95269
***joachifm is now known as Guest84027
<civodul>iyzsong: gnome-updates hasn't been evaluated yet <civodul>something related to grafts is causing it to time out <phant0mas>davexunit: did you manage to get avr-gcc to work for you? <davexunit>phant0mas: yes, I followed up on the mailing list about it. <davexunit>I had to use a hack that isn't general enough to work everywhere <davexunit>no i686 compiler toolchain needed, at least. <davexunit>but what it proved is that you *don't* need another cross-compiler <davexunit>the host compiler will work, but the build system needs to understand that! <anthk_>builder for `/gnu/store/5zw29vysmzbf20ydbp6054lxkdf1rs40-gst-plugins-good-1.8.0.drv' failed with exit code 1 <anthk_>while doing a guix system reconfigure <davexunit>rekado: I'm not quite there yet, but I think I'm getting close to having geda-gaf configured correctly out of the box. ***piyo` is now known as piyo
<davexunit>for some reason it still doesn't generate a pcb from my schematic, but it does seem as though I've fixed all of the search paths. <davexunit>before, PCBLIBPATH, gsch2pcb:pcb-m4-command, gsch2pcb:pcb-m4-dir were not configured right. <davexunit>rekado: I'm assuming that you've seen this actually work before, right? <rekado>I've designed a couple of PCBs with gschem and pcb on GuixSD. <rekado>but it's been some time since I had to use gsch2pcb <rekado>do the elements in your schematic have an assigned footprint? <davexunit>rekado: I do not know. I'm a total n00b here. :) <davexunit>I didn't do anything explicitly. I just selected components with 'I', placed them, and then connected them with nets <rekado>davexunit: I think you still have to give them a footprint. <rekado>the schematic editor cannot guess what component package you will use on the PCB. <rekado>that's why there's a footprint field somewhere. <davexunit>maybe I glossed over this in the tutorial I was reading <davexunit>now to figure out the footprint that I want... <davexunit>for now I'd just like a footprint for a simple through-hole connector <davexunit>one of those little drilled circles with copper around it <rekado>I think you can use "CONNECTOR 1 1" <rekado>both gschem stuff and pcb stuff. <davexunit>now my issue is that when I open it in pcb I don't see anything <davexunit>the board is entirely white, but the cursor changes depending on where I move it <davexunit>rekado: anyway, I'll submit a patch for the improved geda-gaf package. now you do not need to specify the -d flag to gsch2pcb. <cehteh>haha .. remember when i told about the idea about software with expiry date? .. now the one who had the idea is in the news: <davexunit>rekado: your schematics are really cool. I have a lot to learn to be able to understand this. ***Basstard1 is now known as Basstard`
<ng0>cehteh: debian seems to do that.. <ng0>i mean debian seems to sleep on lts after lts ended. or something. <ng0>and some other distros <cehteh>you should check the xscreensaver packaged in guix .. possibly the same problem <ng0>idk.. i don't use it. <ng0>we should track versions somehow though <cehteh>well the discussion half a year ago was about if this expiry date for free software makes any sense <ng0>for archiving it doesn't, for general use maybe. <ng0>restrictions of freedom you run into <ng0>policies of distros, release cycles, package maintainer capacitiy, etc <cehteh>i dont want to continue this discussion .. just wanted to post that i found the initiator of that idea :D <ng0>i did not plan on starting one, just listing things off my head <ng0>were there problems of running guixsd in a vm? I'll probably end up doing that for some time now. the process and problems should be inthe manual and also outlined in past logs I'd assume. <davexunit>ng0: I've made many working guixsd vms in the past <kyamashita>Hello all. I may have a solution for building Red Eclipse successfully. <davexunit>I really want Xonotic in Guix, but building it was non-trivial. <kyamashita>First, how do I check out a source recursively in a package definition? <ng0>and building xonotic (including downloads and checking out) takes a really long time. <kyamashita>ng0: Red Eclipse will take a long time to check out and download as well. <davexunit>is this a git repo or something? are there no tarballs for this? <kyamashita>davexunit: I mean emulating 'git clone --recursive'. <davexunit>kyamashita: thanks for the context. there's a 'recursive' field you can set on the 'git-reference' object <ng0>that's alot of packages. <kyamashita>I thought that if I used the git repo, it'd be easier than *that* <davexunit>but it looks like using source tarballs is doable <kyamashita>Well yes, but I'm not sure how it translates to a Guix package definition. <davexunit>each of those source tarballs would be an input to the red-eclipse package <davexunit>and you can eliminate redundant code by mapping over a list of these things <kyamashita>This would be easier if I had more guile knowledge. I've just been basing my definitions on what I saw in the tree already. <kyamashita>How would I map over a list of the tarballs? Is there something like this already packaged in Guix? <davexunit>'(("acerspyro" "18718286a72298b0a016d147524bc53094c4ad3897859ec8422131b5acc9bd3f") ...) <davexunit>from there a procedure can generate the origin recorder ***kmic is now known as kmicu
<kyamashita>I see. And tarballs are preferable to fetching through git? <ng0>i will extent my discussion on gnunet-svn soon once i'm through with it with portage, there were some ideas so far we could apply. <kyamashita>Noted. I'll try implenting that function of yours, davexunit. I'll pipe up again if something interesting happens. <kyamashita>Prehaps with this method I could separate Red Eclipse and its data. <ng0>you could also git shallow if that's not already the default of git-fetch in guix <davexunit>an additional step after this would be to give a name to the ((name hash) ...) list so that you can re-use it in the build script <davexunit>since you'll need to write the equivalent of that for loop in the PKGBUILD file ***joachifm is now known as Guest49472
<davexunit>and now that I look at it more, it seems that "base" should be left out of the list. <davexunit>that should be the 'source' for the redeclipse package <kyamashita>Yes. That's what I was thinking. So redeclipse and redeclipse-data will be two separate definitions. <davexunit>I understand this might be a lot to take in, but this is *exactly* the sort of thing that makes Guix better than other tools. <davexunit>kyamashita: you could do that, but not necessarily <davexunit>I actually think that you can't do that in this case, though. <kyamashita>I'd prefer to keep them together in one since redeclipse would be useless without its data. <davexunit>try to do exactly what this PKGBUILD is doing <kyamashita>Cool. I'll get working on that. Also, is any progress being made on printing support in GuixSD? It's literally the only thing stopping me from running it at this point. <davexunit>kyamashita: would you like to join in on it? I'm not sure what the status is. <davexunit>I don't have a printer at home so I haven't tried any of the relevant software. <kyamashita>I'd like to try. I've never played around with system services before so it should be interesting. I'd need to move over to GuixSD for meaningful testing, though. <kyamashita>So I guess after Red Eclipse is functional, sure! <ng0>is red eclipse similar to red shift or what it was called? <davexunit>Snappy developer information for the next Ubuntu release <kyamashita>ng0: No. It's derived on the Cube 2 engine. Ever heard of Sauerbraten (not the dish)? <ng0>sure, the one xonotic originated from <ng0>or was it? Darksomething engine <ng0>i think i'll just look into red eclipse :) ***handsome1pirate is now known as handsome_pirate
<davexunit>Snappy makes me *extremely* worried about the future of the GNU/Linux desktop <davexunit>it seems made with the express purpose of papering over the packaging problem and enabling proprietary software <davexunit>not to mention the server components of Snappy have not been released AFAICT <civodul>"Push their free or paid apps to the Ubuntu Store" argh <kyamashita>daveunit: Definitely. It reminds me of a Windows app store sort of thing? <davexunit>civodul: Canonical is just the worst at this point. <davexunit>they *have to* know better than to do the "free or paid" thing <davexunit>they *know* that's confusing in our community <civodul>all these companies want to become Apple or Google <civodul>user freedom is a secondary concern at best <davexunit>kyamashita: yeah. the underlying technology shares many similarities to Guix. <davexunit>except Guix does it all better and provides many more features. <davexunit>the current, worrying trend is that most people now see two layers to their systems: the "base OS", and the "applications" <davexunit>the base OS is your traditional distro, and your applications are things will use Snappy or Docker or whatever. <civodul>right, and Canonical, RH, CoreOS, etc. all seem to be going in that direction <davexunit>I think it's a fundamental flaw to view the two as different in any way. <davexunit>we know very well through GuixSD that the whole system is connected <davexunit>and that the very same tools can manage the base system and everything elses that runs on top <ng0>a virtual system inside the virtual system layer which is your operating system. <kyamashita>The base OS is made up of applications, though. Most people don't (want to) see that. <davexunit>and we know that we can pick and choose the level of isolation that we desire for a particular problem. <davexunit>profiles, 'guix environment', containers, virtual machines, etc. <davexunit>what is accessible system-wide, what is available for one user, what is available just in a particular temporary shell, ... <davexunit>I'm ranting at this point, but this stuff really fires me up. <davexunit>we'll just have to keep waiting for people to give us a chance. <civodul>there's a convergence between those who want to get rid of the distro/upstream split (which i can understand), and those who want to push for an "app bundle" approach, which will turn out to work very well for proprietary "apps" <civodul>we should take this as an example to follow ;-) <jlicht>hello guix! I'm currently trying to package a piece of software that has a Makefile that requires hardcoding some variables. Is there any package definition that is already doing this? <bavier>jlicht: can the variable be passed when make is invoked? <jlicht>to clarify, there is line that contains eg 'VERSION = (some dynamic stuff)' <jlicht>bavier: I would say yes, but then I would still need to delete the line that re-sets the value <bavier>yes, there's many other packages that use 'substitute*' to overwrite such things <jlicht>bavier: substitute* seems to fit the bill. It is more versatile than I though :O <mck>I read some old logs; is the best solution for a cacerts keystore (java) still to use ca-certificates-java deb? <davexunit>or do you really need to edit the Makefile itself? <davexunit>sneek: later tell kyamashita you cannot download things in a build phase. you need to make those origin records inputs to the package. <davexunit>sneek: later tell kyamashita when the sources are inputs to the build, you can access them via the "inputs" keyboard argument to a custom build phase. there are many existing package recipes that refer to their inputs like this for you to read. <bavier>jlicht: See section 9.5 in the make manual <jlicht>bavier: I can figure it out from here, although this was apparently only 1 of what seem to be more and more challenges XD ;-) <fhmgufs>Some people said that they are running their normal guix from their git checkout. <fhmgufs>I created a symlink from ~/.config/guix/latest to it. <fhmgufs>How can I actually call it? "guix package -i guix" rebuilds guix from source. <fhmgufs>I mean "./pre-inst-env guix package -i guix" <civodul>iyzsong: i'd like to rebase gnome-updates on top of master, fine with you? <civodul>iyzsong: well, i went ahead, hope that's fine :-) <mck>rekado: wondering what certificate keystore you've been using with icedtea? <janneke>phant0mas, civodul: how to best resubmit my cleaned-up mingw cross patches? <janneke>wine hello.exe runs on top of wip-hurd or on top of master <janneke>more patches (ncurses, readline, libiconv, guile), to get guile.exe build and link, but guile.exe does not yet run in wine <bavier>I guess I missed the memo about changelog indentation <phant0mas>janneke: begin with the patches that are not in cross-base ***joachifm is now known as Guest31570
***sankey2 is now known as sankey
<phant0mas>davexunit: well I found out that all of the other distros just install the 32 bit glibc, which is dissapointing :/ <davexunit>phant0mas: weird! well I proved that you definitely don't need it! <sneek>Welcome back kyamashita, you have 2 messages. <sneek>kyamashita, davexunit says: you cannot download things in a build phase. you need to make those origin records inputs to the package. <sneek>kyamashita, davexunit says: when the sources are inputs to the build, you can access them via the "inputs" keyboard argument to a custom build phase. there are many existing package recipes that refer to their inputs like this for you to read. <phant0mas>davexunit: I was thinking that maybe we can create an empty stubs file <phant0mas>and gnu/stubs.h defaults to stubs32.h on any non x86_64 system <davexunit>that's where I learned that I can just pass -D__x86_64__ and avoid that issue :) <davexunit>kyamashita: I have a modified version of your package that I'm going to send you <davexunit>I'm currently seeing if it will download everything correctly <davexunit>it won't be complete. you'll still need to do all the data copying stuff. <davexunit>which will mean extracting each tarball into the data/ directory <kyamashita>That shouldn't be too much of a problem. I just need to learn the procedures. <phant0mas>davexunit: I will try to build avr-libc on my raspberry 2 running guix <janneke>phant0mas: thanks, i have only one in gcc -- all others depend on cross-base <davexunit>currently this recipe doesn't copy the data, nor does the install phase install the game to the right place. <janneke>so we'll have to do some more work first i guess <kyamashita>I really should learn Scheme one of these days. It looks pretty nifty. <davexunit>it certainly helps in situations like these ;) <davexunit>I hope my avr-libc isn't subtley broken from my hack <davexunit>but I built a whole bunch of firmwares from the KADE project. <davexunit>kyamashita: I think you need to move DESTDIR out of #:make-flags, because those flags aren't used for 'make install' <davexunit>you'll probably need to replace the install phase with your own <bavier>gnu-build-system passes #:make-flags during install <davexunit>I was just reading this code yesterday, too. <davexunit>okay, so the redeclipse installation fails for some other reason <kyamashita>davexunit: for some reason my guix installation doesn't like your match-lambda variable <davexunit>kyamashita: match-lambda is a macro defined in the (ice-9 match) module <davexunit>so import that in the module you are working in <davexunit>rekado: if you don't me asking: how did you learn so much about electronics that you were able to build all these neat things for your chapman stick? <htgoebel>I do not really understand how to specify build-time-only requirements. As far as I read the manual, all "inputs" are taken equal?! <bavier>htgoebel: see the "'package' Reference" section of the manual <htgoebel>bavier: This section tells different, at least how I read it: "‘native-inputs’ are built for the architecture of the _build_ machine" <htgoebel>Hmm, okay, one could read this as "build-time" dependency <htgoebel>‘native-inputs’ is typically used to list tools needed at: build time, but not at run time <civodul>htgoebel: guix-daemon determines the set of run-time dependencies by scanning the result and looking for /gnu/store references <civodul>where run-time deps are a subset of build-time deps <davexunit>civodul: this seems to be a frequent source of confusion. people are used to having to be explicit about what the runtime dependencies are <phant0mas>davexunit: I was thinking, we could move the parts of limits.h used in avr-libc to the avr-libc itself <phant0mas>and then kill the glibc dependency with fire :-) <htgoebel>davexunit: ACK. I already had understood that built-time dependencies are inputs plus native-inputs (so I do not need to specify things twice). But the wording in the manual is a bit confusing. <davexunit>phant0mas: civodul followed up on the mailing list and said it does seem odd that the build is using the host libc <davexunit>but I don't see how it could not use the host libc <phant0mas>well if it only needs the limits.h header we can cherry pick the part it wants and move to avr/include/limits.h <davexunit>I feel like there must be something we don't understand <phant0mas>well if it only uses the declarations from that header, they probably didn't thought about it too much ***ringst_ is now known as ringst
<davexunit>phant0mas: from what I saw, there's only one constant it was after <phant0mas>wow adding an extra dependency for just one constant ... <davexunit>if we replace that include with a proper definition of ULONG_MAX for AVRs we might be good <phant0mas>davexunit: look what I find in avr-libc's todo <phant0mas>Write for avr-libc [3] : stddef.h, sys/types.h, limits.h, <phant0mas>haha it seems they saw the error in their ways <davexunit>phant0mas: so perhaps we could send them a patch even ;) <bavier>strange, hdf5 wrote a ~300 line C code to use during their build process, but I'm pretty sure a ~10 line piece of sh might do the trick