IRC channel logs


back to list of logs

<NiAsterisk>would be nice if debian jessie would get letsencrypt. says "in a few weeks" looks like I have to build it myself because I don't want to wait
<piyo>NiAsterisk: offtopic but isnt debian jessie a feature frozen distro?
<NiAsterisk>ah, yes, offtopic. sorry. I only learned about it going public now and found it in guix, but not there. yes, I have to use it because I had no choice with the current server other than debian.
<piyo>NiAsterisk: maybe you are expecting letencrypt in jessie-backports etc?
<NiAsterisk>might be
<lfam>sneek later ask NiAsterisk: Did you have some problem with the letsencrypt package?
<Cw>Hey guys
<Cw>Anyone here ?
<lfam>Cw: Yup
<lfam>Guess he was trying to be alone ;)
<rekado>hmm, the axoloti software seems to require JavaFX, which doesn't seem to be part of OpenJDK 7.
<rekado>(BTW: we really should rename the "icedtea*" packages to "openjdk", but I don't know how to ensure that installed "icedtea*" packages will be updated.)
<rekado>(maybe just add an alias?)
<amz3>tsyesika: yes `pass' fails too, on my side, after 3600, I'm running build --keep-failed to inspect what happened
<lfam>rekado: That sounds like a question for the ML
<rekado>huh, I just learned that pacman of "Arch Linux" was ported to Cygwin and thus can be used on Windows. The project is called "MSYS2".
<efraim>python-efl is really driving me crazy. it seems like it should be such an easy build
<piyo>rekado: offtopic but iirc msys2 is used as the basis for building Git for Windows >=2.5.x. also msys2 is a fork of cygwin thus are different things. how is guix related to this? GoW ?? ;-)
<efraim>where would I find rm, uname and grep?
<efraim>while using the least amount of dependencies
<davexunit>efraim: coreutils and grep
<sneek>Welcome back davexunit, you have 1 message.
<sneek>davexunit, ArneBab_ says: for recordmydesktop, try --on-the-fly-encoding
<efraim>davexunit: thanks
<efraim>of course grep would be in grep :)
<paroneayea>hello, *!
<alimiracle>hi all
<efraim>i had planned on building go with trivial-build-system, but its starting to look like using gnu-build-system and replacing the build phase will be easier
<alimiracle>is guix will use systemd in end??
<davexunit>alimiracle: no.
<davexunit>we use GNU dmd, because it is written in Guile and thus has great integration with Guix.
<alimiracle>but kde and GNOME nede systemd to run
<davexunit>alimiracle: they require certain daemons that are part of systemd such as logind, yes.
<davexunit>but we have extracted parts of systemd for this purpose.
<davexunit>we have elogind, for example.
<davexunit>just last week I ran gnome-shell on GuixSD
<alimiracle>this good news
<alimiracle>in fact I dont love systemd
<davexunit>we have nothing against systemd, it's just not a good fit for us.
<rekado>is there a simple way to compare the outputs produced by "guix build --rounds=2 pkg"?
<davexunit>no idea
<davexunit>haven't tried
<rekado>I'm trying to figure out why my new junit package is non-deterministic. I suspect it's because of "jar" and I've been fiddling with additional arguments for some time now.
<rekado>would be nicer if I didn't have to do this blindly.
<alimiracle>It tries to replace everything
<alimiracle>After years gnu parts did not remain
<alimiracle>it wil be systemd linux
<alimiracle>not gnu linux
<rekado>is there a problem with having both gnu+linux and systemd+linux?
<rekado>piyo: yeah. Sorry for my poor choice of words. I just found it interesting that there's pacman for Windows.
<alimiracle>replace gnu parts tio systemd parts
<rekado>Guix on cygwin/msys2 would be funny.
<rekado>alimiracle: nobody is forced to use systemd. So GNU is not going anywhere.
<alimiracle>systemd will replace gnu parts to systemd parts
<alimiracle>gnu will ded
<alimiracle>The only solution is make systemd part from gnu
<rekado>nong: hi.
<nong>rekado: nice to meet you
<rekado>to answer my question: "cp -a" on the output, then "guix gc -d $out", then rebuild, then "diff --text"
***marxistvegan_ is now known as marxistvegan
<rekado>bleh, archives produced by "jar" (or "fastjar") are not deterministic.
<rekado>even without manifest, without compression, and after resetting timestamps a few bytes differ on each line.
<rekado>might be a sorting problem.
<rekado>no, it's timestamps.
<rekado>yes! Just needed to *recursively* reset the times on all generated files.
<davexunit>rekado: victory at last!
<rekado>can't use ant's "jar" task, though, because that one doesn't allow me to disable generating manifests.
<rekado>maybe I should just add a step to unpack, touch, and then repack the generated jar.
<rekado>towards an ant-build-system...
<NiAsterisk>I seem to not get notifications or playback messages here. I read the one yesterday from someone only because I read the backlog on, searching for something. No, I had no issues with the letsencrypt package.
<sneek>NiAsterisk, you have 1 message.
<sneek>NiAsterisk, lfam says: Did you have some problem with the letsencrypt package?
<NiAsterisk>apparently I do get them :D
<swedebugia> is anybody packaging php?
<swedebugia>i'm done with slurm and about to send it to the ML
<davexunit>swedebugia: I tried and failed along time ago.
<davexunit>would love it if someone else could get it to work
<swedebugia>ah, would you like to send me your draft if you have it?
<davexunit>not sure where it is
<davexunit>this was at least a year ago
<swedebugia>php7 is out now it seems
<swedebugia>davexunit: ok, just a thought to continue where you left
<davexunit>swedebugia: if I find it I'll give it to you
<lfam>NiAsterisk: the sneek bot waits to give you your "saved messages" when you say something on the channel. That way, it won't give the messages to what may be an unattended IRC bouncer or something like that
<swedebugia>davexunit: thanks :)
<NiAsterisk>ah, thanks
<lfam>Your frustration with Debian that you mentioned earlier is one reason I like Guix so much. It's just so easy to package things for private use. And it's also easy to get those things into the GNU Guix packages as well.
<NiAsterisk>I wonder how useable guix is already on a minimal debian server image. If I don't migrate to a single dedicated server I will split what I have now into 3 individual vservers
<NiAsterisk>in-berlin (ISP) sets up some basic image with ssh access and that's it.
<rekado>I'm using GuixSD as my main system on three machines already. Very usable.
<NiAsterisk>I can't use guixsd though.. guix would work then.
<lfam>And my primary workstation (a laptop) is a Debian minimal installation with Guix
<lfam>I installed xorg from Debian because I installed the OS before I even knew of Guix but you could even install a DE from Guix on Debian.
<NiAsterisk>i use guixsd on all laptops I have, and switched from gentoo to debian on the desktop, but with servers I meant virtual servers far away (berlin) from me
<lfam>For a server, it should be very simple
<davexunit>I use guix on top of debian on my VPS
<lfam>I use Guix on top of NixOS on my ec2 VPS
<NiAsterisk>i'll give it a try. or migrate things, so I have some more packages to add to the list I need to test and build and send in
<lfam>Guix plays nice ;)
<NiAsterisk>I'm not sure if I can manage to finish gnunet-gtk.. the errors I get with glade3-3.18, well I get some where searching for it on google leads me to the guix-dev list and 29 other results, that's it
<lfam>Send your current patch so we can look at it!
<NiAsterisk>something with xorg and fontpaths.. I'll do it tomorrow :) watching talks from 32c3 now
<lfam>Also, if you install do a Debian Jessie non-graphical installation, you'll probably have issues with `systemd --user`, which IMO is a killer feature of systemd. You'll have to install libpam-systemd in order to properly enable the user sessions.
<lfam>I know that Debian has added the package to their base but I don't know if they are making the change in Jessie
<lfam>The symptom of a "stupid" coupling between the graphical environments and user sessions...
<NiAsterisk>the setup isn't done by myself (would love to, like I did with every other ISP before) but by them
<rekado>NiAsterisk: why glade3-3.18? We have a glade3 package --- does this not work?
<NiAsterisk>no, gnunet-gtk needs gladeui iirc which is not build with the current version in guix and gnunet-gtk even requires an newer version of glade
<rekado>really requires or just checks for a particular version which may be too high?
<NiAsterisk>one sec.
<rekado>anyway, just post your WIP to the mailing list with a description of your problems. Then we can play with it.
<lfam>I'm not familiar with glade and its "ecosystem" but it might be worth it to just upgrade the glade we have rather than packaging a specific version separately
<rekado>I only know glade as a graphical GUI editor.
<NiAsterisk>but i'm not sure if it introduces issues to other packages, that's why I started a new package
<lfam>NiAsterisk: You can do `guix refresh -l foo` to see the all the packages that depend on foo. It will give you a sense of what might break when you change a package.
<rekado>as far as I can see "glade" is a leaf package.
<NiAsterisk>3.8 or 3.10 of glade
<rekado>other packages only depend on "libglade".
<lfam>There is also libglade. Like I said, I'm not sure what's what
<rekado>libglade seems to be independent.
<lfam>rekado: Are you our Java expert? ;) I'm working on a jitsi package and struggling to configure ant. I'm just going to put it on the ML soon and ask for advice.
<NiAsterisk>i am not sure. I came from gentoo packaging, and if I remember correctly there was no separation, glade had options to pull in gladeui
<rekado>gnunet-gtk requires GTK 3.0.0 or higher and libgladeui-1 or
<rekado>libgladeui-2 (i.e. 3.8 or 3.10). glade-3.8 should be used to edit the
<rekado>lfam: pff, "Java expert"!
<rekado>purely by circumstance.
<lfam>Heh, I read your messages regarding ant
<rekado>by now I'm pretty familiar with ant. What's the problem?
<lfam>Well, all the runpaths are totally wrong after the build, but I can't find an option to provide the proper paths while compiling. In nixpkgs, they use patchelf but I get the sense that we are trying to reduce use of that.
<lfam>And many releated issues regarding paths
<rekado>could you point me to the build.xml?
<lfam>The other problem reading XML
<rekado>NiAsterisk: according to the README our glade3 package should be enough.
<rekado>NiAsterisk: and you were right: it comes with libgladeui-1.*
<NiAsterisk>then I will try again tomorrow to see *why* I did this in the first place
<rekado>lfam: yeah... I wrote some SXML today to generate ant targets for packages that have no build.xml.
<rekado>SXML is so much nicer!
<lfam>That would be nice :)
<lfam>To be honest, I'm not sure if we really need jitsi or not. But I recently saw it used and I'm impressed that it is free software with commercial backing, so I'd like to make it more accessible.
<NiAsterisk>I'm curious, but I've read too much today, can't read and look at build output this evening
<rekado>I tried it more than a year ago when I was about to move from China back to Germany.
<rekado>didn't work too well unfortunately.
<lfam>Oh :(
<rekado>could not call from jitsi to empathy.
<rekado>(and I'm sure it was jitsi's problem)
<NiAsterisk>is this xmpp phone/video clal function?
<lfam>You're not the only one:
<rekado>(I think it's called "jingle")
<lfam>Do we have anything else beside gajim that does this sort of thing?
<lfam>Any thoughts on gajim?
<rekado>it was also pretty hard to get enough debug data. Very hard so I gave up.
<NiAsterisk>I've heard it rarely works in any software. I never tested it myself, but the complaints can't be for nothing
<rekado>well, it worked very well from empathy to empathy.
<rekado>did this a couple of times from Germany to China.
<lfam>NiAsterisk: Are you referring to gajim or jitsi?
<NiAsterisk>xmpp videocall in general.
<lfam>Right... xmpp in general
<rekado>xmpp jingle is only about negotiating a separate channel for streaming audio and video.
<rekado>that part usually works really well.
<rekado>(except when using jitsi with empathy)
<lfam>Nevertheless, I like free software with a commercial base, because at least those situations have a very good chance at being sustainable
<rekado>lfam: is this it: ?
<rekado>if so, could you post some of the errors you get?
<lfam>rekado: yes, I posted it upthread
<lfam>Sure, I'll put the package definition and the log-file on a paste site
<rekado>oh, sorry, I missed that.
<lfam>I should have "pointed" it at you
<lfam>Building now, to get a fresh log-file. The jitsi distribution tarball also has a bunch of "installation" resources but I'm not sure if they are relevant. Soon I will start asking upstream for help.
<rekado>I see that it also depends on junit for tests.
<rekado>today I finished building junit, but it's going to take me some more time before I can submit it upstream.
<lfam>I had disabled the tests for now because some of them want network access. I need to figure out how to disable those.
<rekado>Trying to find a better way to deal with Java projects using Ant.
<lfam>Yeah, I noticed you musing about an ant-build-system. Probably the right thing to do once we have a good idea about how to do it
<rekado>the basic plumbing needs to be fixed.
<rekado>use "ant" rather than "make"
<rekado>pass make-flags to "ant"
<rekado>set JAVA_HOME, automatically add "ant" and "openjdk".
<rekado>these kind of things.
<rekado>too many of the java packages I work on do very similar things.
***aeva` is now known as aeva
<lfam>Phew, the log-file was too big for a pastebin! Here is the log-file and the patch on gnu/packages:
<lfam>Here you can see what nixpkgs does:
<lfam>Sorry, I should say the patch is "on gnu/packages", that is be confusing. Just apply the patch normally if you desire
<lfam>*shouldn't say
<lfam>Wow! What a mess of a sentence
<rekado> "inflating: jitsi/lib/native/linux-64/"
<rekado>this is not good.
<rekado>it's bundling pre-built libraries.
<rekado>and then these don't contain the right RUNPATH.
<rekado>they should really be built.
<lfam>So its amazingly short list of dependencies is not so short after all
<lfam>Dang it
<rekado>everything in "jitsi/lib/native/linux-64/" should be added as an input.
<rekado>but they don't look normal to me.
<rekado>"" -- what's that?
<rekado>a forked version of
<rekado>jn --> "jitsi native"?
<lfam>Sounds like a good guess
<rekado>also "jitsi/lib/bundle/" should be replaced.
<rekado>these are binaries.
<rekado>I'm working on log4j, but I'm not there yet.
<rekado>I don't think we'll get jitsi soon :(
<lfam>No, I don't think so. I started it "on a lark" and don't have a need for it.
<lfam>Thanks for taking a look!
<lfam>On to something more fun: music software! I noticed that there are synthesizers in audio.scm, music.scm and also cursynth.scm. Should we consolidate them in music.scm?
<rekado>the package in nixpkgs is a hack: junit and log4j are not among the inputs and the binaries are mostly used after some patching.
<rekado>(re synths)
<rekado>this has bothered me too.
<lfam>Okay, I will try to put them all in music.scm
<lfam>And audio.scm can be for the boring stuff ;)
<rekado>sounds good to me.
<rekado>I wonder if we placed something in audio.scm to avoid dependency cycles.
<lfam>Yeah, that's what I was thinking about with "try"
<lfam>It seems like a problem that will just get worse as we get more packages.
<rekado>updating the "glade3" package right now.
<rekado>but now I wonder: will this be an obstacle when building gnunet-gtk...?
<NiAsterisk>what exactly do you mean?
<NiAsterisk>anyway, livestream talk about crypto, so I'll just test gnunet-gtk building tomorrow and see if it succeeds.
<rekado>well, the README said we need glade 3.8 or 3.10, but the latest version is 3.18.3.
<rekado>I don't want to update the glade package in place when this makes it impossible to build gnunet-gtk.
<rekado>(and then we'd have to re-add the glade package as it is now)
<rekado>so I'll better hold off on updating glade until you gave gnunet-gtk another try (or give it up).
<lfam>Wow, audio.scm and music.scm are impressive. We have so much in there.
<rekado>so much fun stuff!
<NiAsterisk>lfam: but no tracker software like milkytracker? or did this change since I decided to do milkytracker soon?
<NiAsterisk>rekado: okay, I'll do some testing tomorrow and try to provide as much info as possible in email and patch.
<rekado>I tried to package Radium, but it was quite terrible.
<lfam>NiAsterisk: Help wanted!
<rekado>lots of bundled patched third-party software, so I decided to fork and clean it u.
<rekado>ended up throwing out too much and then gave up on the project.
<lfam>Get a tracker so I can make some jungle ;)
<rekado>I'm not a fan of trackers; never used them much, so I didn't package any.
<NiAsterisk>my initial wish & will-contribute list has grown much, might be a bit too much.
<lfam>I love watching this video:
<rekado>I'll eventually package qtractor. And maybe some more lv2 plugins.
<rekado>why would one use a tracker instead of a pattern-based MIDI sequencer?
<lfam>rekado: I think they lead you to make different sorts of music
<lfam>I think that step-sequenced drum machines like the Roland X0X stuff led to one style, the trackers led to a totally different style.
<lfam>X0X being 606, 707, 808, 909, etc
<rekado>(I must say, though, that I haven't yet found a MIDI sequencer that I really like.)
<lfam>The interface is the hardest part of creating any music software IMO.
<lfam>The human interface, that is
<rekado>currently I use lilypond to generate MIDI files. Feels very strange. (But I'm not using MIDI in performances anyway, so it doesn't matter.)
<lfam>I have a long-standing dream of creating a very easy interface to my DX7
<lfam>A beautiful instrument crippled by the crappy interface
<NiAsterisk>hm. the talk on diffie-hellman is interesting
<rekado>so, I have an updated glade package; builds fine but the tests still fail. I put this away for now.
<rekado>lfam: hardware interface for the DX7? Or software?
<rekado>I have a Wavedrum which is equally crippled by a terrible interface.
<rekado>it's fun trying to hack the firmware, though, so I'm kinda glad that it's crappy.
<lfam>rekado: Probably a hybrid. I'd have to write some hack to get the information in and out of the DX7 in "real-time" since it doesn't really have a way to do that. But it will need a physical interface of some sort. The DX7 programming interface consists of 1) a slider 2) a "+" button and a "-" button. That's it! For one of the most complicated synthesis engines ever
<lfam>I could buy a "raw" hardware interface with a lot of knobs and faders
<lfam>But create a new programming "paradigm" in the software
<lfam>To be honest, I don't know if it's really worth it. It's all digital so there's nothing special about the DX7 itself except for the 12-bit DAC, which I could just rip out and re-use and buy another of
<lfam>I might as well do it all in software. But I don't really want to build it on top of a general-purpose OS.
<lfam>And if I'm not yet skilled enough to build the interactive interface, who knows when I'll be able to learn a real-time OS or do it on a microcontroller or whatever?
<NiAsterisk>I would love an free/open hardware and software equivalent to the PODHD500 or equal gear since I stopped using rehearsal rooms (and can't play amplifiers).. that's a long dream I have. I had some sources on this.
<rekado>[offtopic] lfam: microcontrollers are very easy to learn. You could write PC software to send MIDI SysEx and have a stupid microcontroller unpack the control messages and "talk" to the DX7 by banging out some patterns.
<rekado>has anyone tried Beast?
<rekado>packaging this now. Apparently it uses Guile.
<lfam>rekado: The SysEx would probably be the easy part. The bummer is that the DX7 can't update patches in "real-time" so it's not as interactive as programming an subtractive or additive synth engine. The engine will "stop" the sound while updating the patch.
<lfam>NiAsterisk: That looks like a cool side project! I guess the interesting part would be creating the modeling engine. Then you could let people submit "patches" for different amps
<NiAsterisk>there was something like this already i think.
<NiAsterisk>I have to filter out bookmarks
<lfam>rekado: So, it's a graphical programming environment like PD but very focussed on synthesis?
<rekado>NiAsterisk: the problem with DSPs as used in digital effects is often that there is no free toolchain.
<lfam>Looks very cool. I love graphical programming for signals processing
<lfam>And most people are all too happy to "lock up" their art in proprietary systems...
<rekado>I had to write a disassembler for the SHARC ADSP in the Wavedrum to understand the code :-/ And for uploading a modified firmware I depend on the bootloader. It's impossible to get a free compiler for the DSP.
<lfam>You should send a bill to Korg
<rekado>that's why I like the Axoloti board. Free hardware design and free software. (If only it didn't depend on JavaFX...)
<NiAsterisk>(offtopic) I bought into what I have now without thinking about it back then as I used rackmounted amplifiers and other gear you can no longer sell, so software and music wasn't a thing I thought about years ago.
<lfam>How does the axoloti programming environment compare to PD?
<rekado>(should we move this discussion?)
<lfam>To where?
<lfam>Nobody else is trying to talk "on-topic" right now, and maybe other Guix users will find it interesting...
<rekado>"axoloti patcher" is for building patches for the axoloti board. It looks like PD but is not general purpose.
<rekado>patches are turned into C code and then compiled for the STM32F4.
<lfam>It would be nice if they had based it on PD since that already exists and has a ton of work put into it. But oh well. The examples are impressive:
<lfam>I wonder if you can configure the "patch cords" to be straight lines :P that always drives me nuts
<lfam>Unfortunately I lost most of my PD patches at some point. I had a very nice sample-based 808, and some cool FM synths.
<lfam>Wow, axoloti is really cool. I'm glad you mentioned it.
<rekado>I ordered two boards; looking forward to playing with it. I hope it'll work as a versatile effects box for my Chapman Stick.
<lfam>Heh, there is a message on the mailing list suggesting we adopt Docker, Github, and language specific package managers.
<lfam>Perhaps Guix needs to do some better marketing...
<davexunit>lfam: who suggested we adopt docker?
<davexunit>I mean, we'd certainly accept a Docker package, but we aren't going to bring Docker into our workflow
<davexunit>since Guix eliminates the need for Docker
<lfam>davexunit: There's a message on help-guix. I'm going to let other people reply
<lfam>I just don't think the person really understands what Guix is or what its goals are
<davexunit>I haven't subscribed to that yet
<lfam>BTW I'm still having trouble getting srt2vtt from your site. Are you able to download it with curl?
<davexunit>lfam: what problem are you having?
<rekado>(I haven't seen the message on help-guix. I'm subscribed.)
<davexunit>I think we just need to politely address the concerns raised here and explain *why* we do things so much differently with Guix
<lfam>davexunit: I don't know what happened. that's a bad link
<davexunit>yeah it's spam
<davexunit>perhaps your computer is not accepting of let's encrypt certs yet?
<lfam>Perhaps, but I can download from my domain, which also uses let's encrypt certs
<davexunit>yeah it doesn't like my cert
<lfam>Hmm, you'll have to remove the backslash from that link. Sorry for all the false starts
<davexunit>sorry about that but I don't know what I can do about it
<lfam>Oh you're right. curl is downgrading to http when downloading from my domain.
<rekado>oh, now I got it.
<rekado>thanks for the link though.
<lfam>The difficulty in moving packges between modules is figuring out which module imports can be deleted from the old module.
<lfam>Is there a way to determine that programmatically?