IRC channel logs


back to list of logs

<civodul>i just did some PHP
<civodul>for the first time in my life
<bavier>how was it?
<civodul>unfortunately it's not done yet
<civodul>i'm running a subset of Savane to extract the news items from Savannah
<paroneayea>civodul: is a pretty accurate view on PHP IME
<paroneayea>(sorry, I guess that doesn't raise your spirits!)
<civodul>i'm done!
<civodul>i invite you to browse the news section of the site :-)
<paroneayea>civodul: beautiful! :D
<civodul>i'm sure there's room for improvement, but that's already so much better
<paroneayea>civodul: now that you're runnign haunt, you could use davexunit's guile-syntax-parse thing to highlight those sexps :)
<paroneayea>really cool as is though :)
<paroneayea>ACTION is using that on
<nckx>\\o/ noos.
<paroneayea>civodul: anyway, very cool
<paroneayea>civodul: news releases with guix will be much nicer now.
<civodul>paroneayea: yes we'll use the syntax highlighting thingie
<civodul>but here i just imported everything as-is
<civodul>well we can still tweak the result
<civodul>but Haunt 0.2 doesn't have that, does it?
<civodul>oh i didn't rewrite links to news entries
<civodul>oh well
<civodul>ACTION -> zZz
<Common_Era>How can I generate a GPG key in GuixSD without a GUI? I'm being given a no pinentry message. I've looked it up, but none of it applies here.
<BostonEnginerd>Common_Era: gpg --gen-key should get you there.
<BostonEnginerd>in the terminal
<lfam>sneek: later tell Common_Era: Assuming you are using GnuPG 2.1, you need to install a pinentry program (probably pinentry-tty) and then give the path to your pinentry program as the value of 'pinentry-program' in ~/.gnupg/gpg-agent.conf. Or, use an older version of GnuPG that doesn't require the gpg-agent / pinentry
<rekado>looks like Emacs 25.1 with xwidgets leaks memory. According to htop my Emacs uses 20.6 percent of my memory, leaving only very little for my massive browser session.
<rekado>gotta try what will become 25.2, which uses webkit2gtk+
<htgoebel1>I can't find thunderbird in guix thus assume it is still missing, Or does it have a different name?
<htgoebel1>Is anybody known to work on thunderbird?
***htgoebel1 is now known as htgoebel
<efraim>I don't think anyones worked on it yet
<civodul>Hello Guix!
<rekado>htgoebel: I don't know if anyone is working on Thunderbird. AFAIK nobody has called dibs on it :)
<ng0>can we packageit though?
<ng0>there was a reason why ice-whatever-for-thunderburd existed
<ng0>one I can imagine is the mozilla store, present in all(?) mozilla products
<rekado>Fixed the R / spams bug.
<rekado>just by defining NO_C_HEADERS before including the R headers.
<rekado>the NEWS file says that the manual always said that R headers should not be included from within an extern "C" block. All applications that are broken because of this 3.3.0 change ignored this advise.
<rekado>looks like it's SWIG that produced the wrong code.
<civodul>rekado: good that you found out!
<civodul>it's unsual to expect *users* to add 'extern "C"'
<civodul>good practice is to add #ifdef __cplusplus extern "C" { #endif
<civodul>in all public headers
<rekado>I guess now I can fix shogun 4.1.0 as well. It also uses swig to generate bindings to R.
<htgoebel>ng0, rekado: Sounds like for thunderbird one needs to have dee knowledge about internals ans gotchas?!
<ng0>is the ice-variant now a) obsolete or b) no longer developed?
<ng0>the only problem I see for guix is mozilla store, that's all
<ng0>icedove was the name
<ng0>one of those tripped-out animal logos
<ng0>icedove-45.4.0-1 .. looks active?
<htgoebel>I think to remember some message that debian is discontinue icecat and reverts back to firefox, since copyright issues are now solved.
<htgoebel>Mabe the same for icedove?
<ng0>no, that's just an exception for debian
<ng0>doesn't apply to other systems
<ng0>from what I understand
<ng0>iceweasel was discontinued and they use now firefox. icecat is a different project. and icedove is still in debian as they have an open bug on it
<civodul>htgoebel: it's not a copyright issue but a trademark issue
<civodul>but yeah, ISTR that Mozilla's trademark policy has changed in the right direction since then
<htgoebel>This is irritating: debian has firefox again, but thunderbird is still icedove
<ng0>read the bottom of the page, it's just a matter of fixing the bugticket
<ng0>I already closed the page, but there was something about "future considerations: move to official branding" or something like that
<ng0>with a link to a bug ticket
<htgoebel>so we are going with thunderbird and thunderbird-esr?
<marusich>civodul, how is it that the operating system configs defined in gnu/tests/install.scm get run?
<civodul>hey, marusich!
<marusich>Hi there. I've got patches ready for the 'guix system' stuff, but no tests.
<civodul>marusich: they are run via 'make check-system'
<civodul>and also on hydra
<marusich>I mean, what runs them when you run make check-system?
<civodul>'check-system' starts a tiny script, build-aux/run-system-tests.scm
<marusich>I grepped for the defined variables, but found nothing, so probably there's something fancier than I expected collecting them and running them?
<marusich>I see
<marusich>I'll look into it.
<civodul>and the script automatically discovers public variables that match 'system-test?'
<civodul>with <system-test> being defined in (gnu tests)
<marusich>I see.
<marusich>Are all the tests supposed to pass? Two of them fail - the nss-mdns and the encrypted-root-os.
<marusich>I get the feeling like they've never passed on my system
<marusich>(even on origin/master)
<thomasd>after running `guix gc` fonts in emacs are not anti-aliased anymore. I also get a "Fontconfig error: cannot load default config file". Any ideas?
<htgoebel>I'm still stuggling with "guix system vm". This build the vm and gives me a script, but
<htgoebel>a) how to access the ssh server running in there?
<htgoebel>b) it seems to be a read-only vm, since the lsh-random-seed is generated on each boot. How do i easily get a vm which keeps this state?
<htgoebel>I volunteer for updating teh manual once I have it running :-)
<ng0>it was suggested to me to copy the vm out of the store
<ng0>I went on to test what I write on a system I do not need
<ng0>way easier than figuring out what is broken for me
<ng0>well not broken but something which behaves differently than qemu on other systems
<htgoebel>ng0: copying out of the store is what the manual says.
<htgoebel>But this is messy
<htgoebel>You need to copy some image and adopt the script :-(
<htgoebel>Very inconvenient
<htgoebel>If I'd be more used to this guile stuff, I'd write a patch, So I can only write a bash or python script for myself :-(
<ng0>it takes time to get used to and learn it.. system-services are where I am slow now. I thought by now I'd be finished with all 3 of the services I write
<ng0>if you can figure out how to make the "system vm" more convinient, that would be great :)
<wingo>i never had video conferencing work on this guixsd laptop -- icecat and never worked, obviously no hangouts, etc
<wingo>but! seems to work fine
<Petter>wingo: Have you tried with IceCat 38? This always crashed for me. Haven't tried IceCat 45 though.
<wingo>Petter: this is 38.8.0
<Petter>Oh. Interesting.
<htgoebel>Reading I think qemu networking woes
<htgoebel>Hard to understand, hard to implement for average users
<alezost>thomasd: I think your problem is <>
<thomasd>alezost: thanks
<htgoebel>Hmm, even after copying the vm-image out of the store, lsh wants a random-seed on every boot.
<htgoebel>There must be another trick
<marusich>civodul, I've sent the patches. I might try adding system tests later. I'm pretty tired, so I'm gonna go to sleep now. Goodnight!
<marusich>htgoebel, what are the command line flags you're passing to the vm?
<marusich>the -snapshot flag will make it so that any changes you make will be lost, so if that's being used, that's the problem.
<htgoebel>maurisch: none. Just those in the script
<marusich>Maybe it's the disk image? You could inspect it with qemu-img
<marusich>Anyway, good luck and good night!
<htgoebel>marusich: good night
<ng0>civodul: regarding pypi-uri in import pypi: there was a patch series in october of 2015 by cyril roelandt, I'm not sure if it got merged
<ng0>starting with: [ 32: Cyril Roelandt ] [PATCH 00/12] Tons of patches to run "guix-tox" on python-keystoneclient!
<htgoebel>civodul: The the manual "guix system" is hidden in section 7.2.13, while all other utilities are listed in 6.x. Any reason for this? Otherwise I'd make 7.2.13 to 6.x, too.
<civodul>htgoebel: it's because it's under "GNU Distribution", which talks about GuixSD
<civodul>there was a proposal to move everything under "GNU Distribution" one level up
<civodul>which would be a good thing
<rekado>I told Guix in my arm VM to "guix environment gcj" and it now compiles binutils-cross-boot0-2.25.1
<rekado>maybe it misunderstood...?
<rekado>why would it need the cross binutils for building gcj?
***Gottox_ is now known as Gottox
<civodul>rekado: it's "cross-boot0", the "fake cross-binutils" used for bootstrapping
<civodul>that said, it shouldn't depend on it, or that'd means that %final-inputs indirectly do
<civodul>davexunit: hello!
<civodul>davexunit: starts with <feed> instead of <feed xmlns="">
<civodul>could that be a problem?
<civodul>or does everyone ignore XML name spaces in practice?
<civodul>(except Firefox)
<davexunit>civodul: I don't know that much about Atom, but if it's better to have the xmlns in the <feed> tag then I think it would be a good idea to include it.
<davexunit>civodul: but wait, does this mean that the guix site is using haunt now?
<civodul>paroneayea: is missing
<civodul>davexunit: yup! :-)
<civodul>which also means you'll have to make a release ;-)
<davexunit>alright, so there's a few things to patch in haunt right now, then a release is in order.
<davexunit>I think paroneayea also mentioned my guile-syntax-highlight project at some point
<davexunit>that needs an initial release, I think.
<civodul>ah yes, i thought it was part of Haunt master
<davexunit>no it's separate since it's a general-purpose thiong
<davexunit>so far it works well enough to highlight everything on my own blog
<davexunit>but surely there are bugs somewhere
<davexunit>example code snippet here:
<civodul>looks nice
<davexunit>yeah I think it will make the Scheme snippets in the Guix news posts more appealing
<civodul>more readable, too
<rekado>civodul: thanks for converting the news page! It's so much prettier now.
<paroneayea>civodul: oops :)
<civodul>anyone knows of an news reader or someting to check whether the links in the feed are valid?
<paroneayea>some fun reading for the lisp machine of... er, emacs of distros: ;)
<civodul>i'd like to make sure before giving the new URL to the planets
<paroneayea>great article
<paroneayea>civodul: liferea is a nice feed reader; there's also elfeed for emacs, which I think is already packaged
<davexunit>civodul: I just opened my feeds in icecat to test them out
<davexunit>and they worked fine there, but maybe testing with more readers will reveal problems
<efraim>from the first item in the feed: has an extra '/news' in the middle
<davexunit>efraim: good catch
<efraim>i tried to load the page :)
<davexunit>now, is that just a simple mistake or a haunt bug...
<davexunit>here's my atom feed generated by haunt
<davexunit>for comparison
<thomasd>civodul: feeds also work fine in "feedly"
<rekado>I remember that there's a bug in haunt relating to feeds.
<rekado>something about my atom feeds on was wrong.
<rekado>there's a TODO item in my org files about this I think
<davexunit>ACTION needs a bug tracker...
<davexunit>ACTION doesn't know of anything good
<rekado>I used to use "bugs everywhere"
<rekado>it's a bug db that's part of your repo
<davexunit>rekado: I guess I was hoping for something web-based
<rekado>don't know any good ones :-l
<civodul>davexunit: your feed has the xmlns thing, mine doesn't
<civodul>davexunit: maybe there's a fix in Haunt master?
<rekado>I have the xmlns in my feed too
<rekado>I used Haunt from what was then the latest commit in master
<civodul>paroneayea: elfeed is nice!
<civodul>it's able to read the atom without xmlns
<katco>rekado: hey, sorry just catching up on your message yesterday re. calibre
<katco>rekado: i am interested in a more general question about guix: how do we maintain package quality? shouldn't failing packages be rolled back to the prior revision or removed from the public offering?
<katco>rekado: and shouldn't there be some kind of gating process for landing new revisions? (or is there?)
<civodul>actually does have the xmlns thing
<civodul>bah, sorry for the noise
<paroneayea>civodul: cool
<paroneayea>civodul: I've been meaning to set up elfeed here.
<atheia>elfeed's very nice. And pretty damn fast!
<rekado>katco: we have continuous integration with hydra. Packages that fail their build can be seen there.
<rekado>then we have people who check this list and see if they can do something to fix this.
<rekado>arguably there are not enough people who do this
<katco>rekado: ah ok, ty for the context :)
<katco>rekado: so, the issue with calibre is (obviously) known, but no one has been available to fix it?
<rekado>in the case of calibre it's not a problem with calibre itself, but with a larger change in a dependency
<katco>rekado: wait... i thought this was the entire point of guix? shouldn't the calibre package be pinned to a certain version of the lib.?
<rekado>katco: I started packaging the missing component, but it's big and has quite a few dependencies, and it's competing with other things for my attention
<rekado>if you had an older version of calibre it should still work
<rekado>i.e. installed before the change
<rekado>we usually don't pin things because breakage is relatively rare
<katco>ah i see
<rekado>in this case it's a little difficult to undo the change because it's largely positive
<katco>so in this case, would the quick path forward be to just update calibre to pin the lib to the old working dep?
<htgoebel>civodul: Remember my patch a view days ago changing the cmake build system? When should I commit this and where?
<rekado>more context: Qt comes with a web browser widget, and that widget bundles chromium.
<rekado>and chromium bundles uncountable libraries
<davexunit>the great bundled bundle
<rekado>which means: lots of potential security vulnerabilities
<rekado>to fix this obvious problem for the distribution we disabled that widget
<civodul>htgoebel: i forgot the details of the patch, but it seems it should go to 'staging' (which you would create)
<rekado>katco: we also split up Qt into separate modules
<civodul>htgoebel: however i'd prefer to do that once we've merge core-updates
<katco>rekado: ahhh ok this begins to make sense to me :)
<rekado>katco: now to fix this it's better to just package the needed module separately and only add it where it's really needed
<rekado>so far this hasn't happened
<katco>rekado: i see
<rekado>texmaker is also affected
<htgoebel>civodul: So I'm still postponing it until we have `staging`.
<katco>rekado: ty for taking the time to explain, this makes sense
<davexunit>katco: you touch upon a common misunderstanding with guix. if you use the *same* version of guix, you get the same results. but when we update a package in guix, that new version of guix includes new version of the packages that are affected by the change.
<rekado>I'll get more memory for my laptop tomorrow, so I hope I'll be able to build Qt components soon without my machine locking up
<civodul>htgoebel: yes, this admittedly isn't a great situation :-/
<thomasd>(FYI I just submitted a qtwebkits package, couldn't this solve the Calibre problem?)
<katco>davexunit: but a version of guix can have multiple versions of packages, so it's still possible to pin a package to another isn't it?
<davexunit>katco: sure, but in general that is undesirable.
<katco>davexunit: can you explain why?
<davexunit>whether or not to keep multiple versions of a package around is done on a case by case basis.
<davexunit>we want uniformity in the dependency graph
<katco>ah, so not a general rule
<davexunit>it's a general rule
<katco>no i meant, not a general rule to keep old versions around :)
<davexunit>the places where we have multiple versions are exceptions to that rule
<rekado>thomasd: oh, you did? Cool!
<davexunit>using the latest stable releases as often as possible is important for maintainability and security.
<katco>so this confuses me a bit, because to me one of the great benefits of guix is i can update things independently w/o affecting other packages... but if the goal is dep uniformity, how is that goal met?
<rekado>thomasd: this might be enough, actually. I can't really review any patches until next week, though.
<rekado>katco: you can do this as a user
<thomasd>I'm in no hurry
<katco>davexunit: i thought grafts were useful for this?
<davexunit>katco: again, you are misunderstanding.
<katco>i don't doubt it :) i have not delved very deep into guix. i mainly use it passively
<davexunit>the benefit you're talking about is multiple users (or a single with many profiles) being able to manage software environments independently without interfering with each other
<katco>ah so i'm at the wrong level of abstraction
<katco>i see the distinction
<davexunit>in guix itself, each package doesn't have a completely separate dependency graph. that would be unmaintainable.
<davexunit>a complete combinatorial explosion of madness.
<davexunit>if you look at any given package recipe. it will reference variables defined in other modules that are bound to package objects.
<davexunit>thus, if you change the package that is bound to that variable, it in turn changes the things that use it.
<katco>so in that sense it's not dynamically coupled, it's "statically" coupled
<davexunit>that's a feature for us.
<davexunit>I don't know the distinction you're trying to make
<davexunit>but yes, I think. ;)
<katco>i think i'm on the same page, just not expressing it well
<davexunit>think of each change made as a new version of guix
<davexunit>distinct from the previous revision
<katco>yeah, i misunderstood the goal of guix itself
<rekado>"statically coupled" is actually not a bad expression: the binaries really do retain static references to their dependencies
<davexunit>yeah, that's true.
<rekado>this is what allows you to keep multiple versions of any package around
<rekado>(and have installed software remain unchanged no matter what you do)
<davexunit>right, even if the version of guix you are using no longer describes the software you have installed, it's still there and you can still use it.
<rekado>so in principle you *could* use a version of Guix from before the change to Qt and install Calibre from that point.
<rekado>and it would work.
<rekado>(unfortunately you won't get any binaries from hydra because space is finite)
<katco>rekado: i tend to go directly to the most base questions i can think of, and to usability/ease. in this case, new users won't have all this context and will only know that calibre is broken in guix
<rekado>in other news: I'm nearing the end of my quest to upgrade ipython + notebooks + jupyter
<katco>rekado: so wondering how to mitigate that
<davexunit>katco: generally we check the number of rebuilds that will occur when updating a package
<rekado>katco: with the patch provided by thomasd :)
<davexunit>if the number is large, we typically put the patch in a special branch and have the CI system build it
<rekado>it would be nice if we had the capacity to keep updates separate from additions.
<davexunit>and merge it once everything is rebuilt and there is a good success/failure ratio
<rekado>a stable branch
<rekado>but that's hard to pull off
<davexunit>I think eventually we'll have that
<davexunit>but right now it's more important to keep pressing forward
<rekado>both in terms of developer power and in backporting patches
<katco>very true
<katco>glad to see level heads have considered all of this :D
<davexunit>at my job we use guix on some servers. I rarely update the version of guix we use to ensure stability.
<rekado>level heads are the natural result of bumping into these problems repeatedly :)
<rekado>same here at the MDC.
<katco>do you have to update guix to get new grafts?
<katco>i.e. how do you manage cves?
<rekado>as a sysadmin I guarantee availability of all software we need, so I update whenever all of our packages are available
<davexunit>we just patch them
<rekado>the work I do here for our site is very much like what a stable branch would be like
<katco>davexunit: so you fall out of guix to do security patches?
<davexunit>fall out of guix?
<katco>davexunit: sorry: you don't use guix to manage cves
<davexunit>still not sure how to answer that
<davexunit>guix devs update packages in response to CVEs
<rekado>katco: we never patch software in the store manually, if that's what you meant
<katco>davexunit: sorry: i use guix to keep my guix-deployed software secure: e.g.: guix pull; guix package -u
<rekado>instead we'd backport changes to package definitions
<katco>davexunit: it sounds like you manage cves without invoking guix?
<davexunit>yeah backporting is one way to do it. in the future an official guix stable branch will be the answer.
<rekado>katco: most of us run Guix from a git checkout.
<davexunit>my dependency graph is small enough that I don't have to update for much.
<rekado>katco: there we can update individual package definitions and update the packages we have installed.
<katco>ok :)
<katco>rekado: davexunit: ty both for your patient explanations
<rekado>no problem!
<rekado>so... I have python-jupyter now. But I don't know what to do with it...
<rekado>ACTION goes to read the manual
<civodul>core-updates failures compared to master:
<rekado>I cut corners by not upgrading to ipython 5.x; this is still at ipython 4.0.0
<rekado>the r-* failures look like they are fixed on master
<rekado>mostly bioconductor stuff with unstable URLs :-/
<rekado>lots of python failures
<rekado>both ardour and mod-host fail to find -lfftw3f_threads
<rekado>I'll try to reproduce this later
<htgoebel>rekardo: concratulations
<htgoebel>rekardo: I suggest naming the package just "jupyter" now, since it is no longer specific to python.
<kyamashita>Has anyone here packaged software with the program files written in DOS format?
<kyamashita>My patches won't apply, and I was wondering if there was a way around it.
<kyamashita>ACTION will be back eventually
<lfam>Does anyone know a fast way to test an update to libwebp?
<lfam>I mean, what's a cheap way to see if the new updated + patched libwebp works as expected?
<Petter>lfam: 'dwebp' looks promising. Search for it here,
<lfam>Howdy nckx
<lfam>Did you notice we both updating btrfs-progs? :p
<lfam>Tricky merges!
<lfam>Hm, it seems that for beautifulsoup4, the Python 2 package should be the "primary" package, and the Python 3 variant should be tacked on. The reverse of what we normally do. Beautifulsoup4 is still developed in Python 2, and distributors are expected to use a provided conversion script to build with Python 3
<lfam>How can I "clear" the (arguments) of the python2-variant of beautifulsoup4, which inherits from python-beautifulsoup4?
<lfam>Giving an empty list to (arguments) in python2-beautifulsoup4 does not work. It even causes Python 3 to be involved for some reason!~
<lfam>Everything seems to work when I manually specify `(#:python ,python2) in the arguments of python2-beautifulsoup4, but that doesn't seem like it should be necessary
<lfam>So, python-wsgiproxy2's test suite depends on restkit, which does not yet fully support Python 3:
<nckx>lfam: ...I did now :-)
<lfam>It makes me wonder what we missed!
<nckx>Your guix-commits notification arrived a day or so late (I need to yell at my mail host again), I remember thinking ‘huh, lfam cherry-picking my patch to core-updates. Weird.’ and promptly forgot about it.
<nckx>Didn't realise it was a dupe until just now.
<lfam>I should have made the commit on master anyways. I was just thinking of it as a core-updates build failure fix, but there's no reason not to have done it on master
<nckx>That said, I don't think btrfs-progs needs to go to core-updates. Not that it would usually matter, of course.
<lfam>At this point, we are merging master into core-updates frequently, to get ready for the new release. That's why it should end up on core-updates
<lfam>At least that's my understanding
<nckx>lfam: But through master, right? (For non-rebuild-intensive packages.)
<lfam>nckx: Yes, and that's what I should have done for btrfs-progs
<lfam>And what I just did do for several things
<lfam>I'm working through all the Python test suites that we never ran before. I wouldn't mind some help :)
<lfam>I've made the ugly choice of simply disabling them in the cases where it's not easy to run them. I figure this is okay since we weren't running them previously. Those who depend on the packages can pick up the slack :)
<lfam>Does anyone understand the python-sqlalchemy-utils failure on core-udpates?
<lfam>I'm stumped!
<lfam>python-seaborn's tests fail because it can't find a graphical display
<kyamashita>ACTION is finally back
<janneke>welcome back kyamashita
<kyamashita>Thanks, janneke. :-)