IRC channel logs


back to list of logs

<adfeno>LordShadowWing: Perhaps, but I find it strange that I did what was told in the documentation, and it worked.
<LordShadowWing>I have no clue
<adfeno>LordShadowWing: Don't worry, both of us don't have, we're trying to understand what's happening.
<LordShadowWing>though it doesn't say where to download the file, I assummed to wget it to /tmp
<LordShadowWing>adfeno, I might just go back to debian, everything just worked and the packages weren't so OLD
<LordShadowWing>Because Debian is free if you only use the main repo
<adfeno>Yes, but we cannot recommend it to general public.
<adfeno>... so that's a bad thing.
<LordShadowWing>Of course, that's why trisquel exists
<adfeno>LordShadowWing: I found something useful
<LordShadowWing>adfeno, What did you find
<adfeno>Try: sudo initctl reload-configuration
<adfeno>Now do: sudo initctl list | grep guix
<ng0>Only 3 tests left to fix and I can send the tcsh update
<LordShadowWing>adfeno, guix-daemon stop/waiting
<adfeno>Now we can do: start guix-daemon (if it's not running already)
<LordShadowWing>adfeno, It's just hanging
<adfeno>LordShadowWing: Mine did that too when I started it that way.
<LordShadowWing>adfeno, WOOT
<LordShadowWing>Now i need to fix warning: failed to install locale: Invalid argument
<adfeno>LordShadowWing: If, however, we let the system start it... It will work
<LordShadowWing>guix-daemon start/running, process 6526
<adfeno>LordShadowWing: That's perfect :)
<LordShadowWing>Now how to start mumble
<adfeno>LordShadowWing: Before caring for Mumble, let's see something important...
<LordShadowWing>export PATH="/home/logan/.guix-profile/bin${PATH:+:}$PATH"
<adfeno>I want to know if, by chance, "/root/.profile" has lines similar to the following ones:
<adfeno>export GUIX_LOCPATH="${HOME}/.guix-profile/lib/locale"; export GUIX_PROFILE="${HOME}/.guix-profile"; source "${HOME}/.guix-profile/etc/profile"
<adfeno>LordShadowWing: Please replace ";" with a line break, and remove the next space
<LordShadowWing>So replace all ;'s with \\ ?
<adfeno>If "\\ " means "new line"? yes
<adfeno>There should be only three lines.
<LordShadowWing>Why not send each thing as 3 individual; commands
<adfeno>export GUIX_LOCPATH="${HOME}/.guix-profile/lib/locale"
<adfeno>export GUIX_PROFILE="${HOME}/.guix-profile"
<adfeno>source "${HOME}/.guix-profile/etc/profile"
<adfeno>This floods the channel sometimes.
<LordShadowWing>that's my /root/.profile after the commsnds
<adfeno>Yep... That's mine too. :)
<adfeno>We can put the three lines I presented in the end of the file
<LordShadowWing>Will Guix installed apps show up in the "app menu"
<adfeno>LordShadowWing: Currently, it depends on which one you want to install.
<LordShadowWing>adfeno, I'm confuzed
<adfeno>LordShadowWing: Generally, to answer your question another way: Currently, there's no way for Guix to know that he should install an application when you click on an item in the "App menu".
<adfeno>This would be rater difficult to do for now.
<LordShadowWing>So I have to open all the programs from the terminal?
<adfeno>LordShadowWing: Not exactly... For some applications, you can copy a file which comes with the package you installed from Guix, and that file, when copied to a specific place, will let the application appear in the "App menu".
<atw>adfeno, LordShadowWing:
<adfeno>Or, even if the application doesn't provide one, you can right-click in the App menu (the one with Trisquel logo) and click Edit, and from there, create a menu item for the command.
<adfeno>atw: Oh...I see. that was a bug you were fixing.
<adfeno>LordShadowWing: In this case, the Mumble package from Guix provides a menu item for us, we just have to organize things here first
<LordShadowWing>adfeno, It seems like It's not working, I'm gonna reboot to see if things remain
<adfeno>... please... wait and follow along.
<LordShadowWing>adfeno, It does not survive a reboot
<adfeno>LordShadowWing: so I ask, did you insert the three lines I mentioned earlier in "/root/.profile"?
<LordShadowWing>adfeno, Yes
<adfeno>OK, now let's do similar thing with your normal user's ".profile" (it's in your home), however, the lines are somewhat different now.
<adfeno>Here they are:
<adfeno>export GUIX_PROFILE="${HOME}/.guix-profile"
<adfeno>export GUIX_LOCPATH="${GUIX_PROFILE}/lib/locale"
<adfeno>source "${GUIX_PROFILE}/etc/profile"
<adfeno>export PATH="${GUIX_PROFILE}/bin:${GUIX_PROFILE}/sbin${PATH:+:}$PATH"
<LordShadowWing>brb, logging out then back in
<LordShadowWing>Works Now
<adfeno>There are some other adjustments that need to be done according to the docs, and also according to some of my recommendations... But if you want we can stop here.
<ng0>2 tests to fix
<LordShadowWing>I want the "Best" experience
<ng0>filename substitution in tcsh is tricky
<ng0>also, is it a faux pas to add perl in the native-inputs to fix test 122 once and for all?
<adfeno>LordShadowWing: Hm... So you want us to continue?
<LordShadowWing>adfeno, please
<adfeno>LordShadowWing: OK
<adfeno>Let's see...
<ng0>is there anything really low level whic hdepends on tcsh but does not want perl?
<adfeno>LordShadowWing: We must do the following:
<adfeno>1. sudo --login
<LordShadowWing>adfeno, Use a pastebin for long lists please, termbin is awesome
<LordShadowWing>cat file | nc 9999
<adfeno>2. guix pull
<adfeno>↑ This one will take some minutes (not much).
<LordShadowWing>warning: failed to install locale: Invalid argument
<LordShadowWing>guix pull: error: failed to connect to `/var/guix/daemon-socket/socket': Connection refused
<adfeno>Let's see... Still in the same shell, do: ls -al "/var/guix/daemon-socket/socket"
<LordShadowWing>root@Relacore:~# start guix-daemon
<LordShadowWing>start: Unknown job: guix-daemon
<LordShadowWing>root@Relacore:~# ls -al "/var/guix/daemon-socket/socket"
<LordShadowWing>srw-rw-rw- 1 root root 0 Jan 8 17:09 /var/guix/daemon-socket/socket
<adfeno>LordShadowWing: Are you by chance running guix somewhere else?
<LordShadowWing>adfeno, no
<adfeno>Hm... whats the output of: ps -axo pid,args | grep guix
<LordShadowWing> 3481 grep --color=auto guix
<adfeno>What is the output of: status guix-daemon
<LordShadowWing>Unknown job
<adfeno>It seems Upstart isn't remembering that Guix exists... Let's see if we can fix this.
<LordShadowWing>Just reloaded the config and it's there again, but is lost upon reboot
<adfeno>Hm... Let's try doing:
<adfeno>sudo chown root:root ~root/.guix-profile/lib/upstart/system/guix-daemon.conf
<atw>adfeno: well, reporting, but yeah
<adfeno>atw: In both cases, it still helps. :)
<LordShadowWing>adfeno, I just did t hat
<adfeno>OK... Let's see if it helps now... Try rebooting.
<adfeno>Now... let's see the output of: status guix-daemon
<LordShadowWing>initctl list doesn't show guix
<LordShadowWing>adfeno, Upstart is broken
<adfeno>Perhaps... I'll see if there's a reason for it not to be remembering the Guix service.
<adfeno>Looking for it now.
<LordShadowWing>adfeno, thanks
<LordShadowWing>adfeno, I'm still considering switching back to Debian
<adfeno>LordShadowWing: Does it change the output if you do: sudo status guix-daemon
<LordShadowWing>Unknown job
<mystified>Hi Guys !
<mystified>I was given a link about 12 hrs ago for a GuixSd alpha installer, I've now lost the link.
<mystified>Can you guys point me in the direction of guixsd site with all the imgs
<davexunit>mystified: this?
<davexunit>ACTION notices that we got new graphics on this page
<davexunit>very nice!
<mystified>Thx kindly ! :0
<mystified>Thx kindly ! :)
<adfeno>LordShadowWing: I'll talk to Upstart project now, perhapst they have IRC channel.
<adfeno>Yes... they have
<atw>first time using debbugs...if I cc that should close the issue, right?
<LordShadowWing>adfeno, I'm assuuming that maybe some of my issues come from my hardware, Intel ME is Evil
<mystified>Hi again downloaded & extractedthe installer. Do I just dd the img to make bootable usb ?
<atw>mystified: yes, as described in
<ng0> Whonix wants to get guix packaged for debian
<davexunit>just saw that
<ng0>ah :) I'm in the offlist conversation for that
<LordShadowWing>adfeno, You now having the same issue?
<adfeno>LordShadowWing: Unfortunatelly... No.
<adfeno>LordShadowWing: I have a feeling that there must have been something we overlooked when installing Guix...
<LordShadowWing>Strange, Must be the 2015 Xeon
<adfeno>Particullarly, there must be an error when extracting the package and moving things around.
<LordShadowWing>I'm going back to debian, Back to KDE
<adfeno>Because, as far as I can tell, it was the only part of the installation for which I was not here to guide.
<LordShadowWing>adfeno, Thanks for the help
<adfeno>You're welcome.
<adfeno>Well... must be going now, unfortunatelly, it's 23:00 already, and eyes hurt.
<mystified>@atw Thxs :)
<mystified>gpg: key 197A5888235FACAC: public key "rekado <>" imported
<mystified>gpg: no ultimately trusted keys found
<lfam>mystified: Every Guix commiter's key should be available on our project page:
<lfam>mystified: You can also look into the --recv-key argument to gpg
***lewo_ is now known as lewo
***erdic_ is now known as erdic
<mystified>Ive downloaded it directly & unzipped it. It's come aou as a "binary pkg" is it alright to DD that as a binary !
<lfam>mystified: dd just moves data around, so it's fine to dd it to whatever file or device you're ready to overwrite
<Apteryx>How are debug symbols dealt with in Guix?
<Apteryx>ACTION RTFM, chapter 6.3 ;)
<Apteryx> Still not clear on how adding debugging information works. Does just adding a "debug" output automagically strips the binaries from the debug symbols and put those under the debug output?
<Apteryx>I guess if this is how it works, I would still need to use configure flags such as --enable-debug?
<Apteryx>How can I compare the size of a package before and after adding debug symbols?
<Apteryx>OK, so to answer one of my previous question, yes, adding the 'debug' output will automatically copy any debug symbols found to the debug output. A comment in guix/build/gnu-build-system.scm says: ;; If an output is called "debug", then that's where debugging information
<Apteryx> ;; will be stored instead of being discarded.
<Apteryx>I guess the more switches we flip on to generate debugging symbols, the better when we want to create the "debug" output.
<Apteryx>*we can flip on
<davexunit>paroneayea: listening to your HPR interview. very fun!
<davexunit>(and I'm not just saying that because you kindly mention me several times ;)
<Apteryx>paroneayea: I've listened to it as well, thanks for sharing!
<paroneayea>davexunit: Apteryx: glad you both liked it :)
<sankey>random question, any guix contributor live in boston?
<efraim>sankey: some live close enough to go to Libreplanet
<sankey>i was just curious because i live in boston
<sankey>in fact, i've gone to the last two libreplanet conferences
<sankey>i'm quite sure there was a guix talk at the last one, i didn't even go because i wasn't interested at the time :P
<atheia>I'm trying to get to grips with github/git based package recipes, but don't know how to use guix download to fetch the hash for a given recipe.
<atheia>Does anyone here know what the way to do that is?
<civodul>hey atheia
<civodul>atheia: just do "git clone foo; cd foo; guix hash -rx ."
<atheia>civodul: when I try that I get a hash mis-match.
<atheia>Presumably I should check out the commit that the recipe specifies before doing the "guix hash -rx ." command?
<atheia>(so, e.g. "git clone foo; cd foo; git checkout foo tag; guix hash -rx ."
<civodul>atheia: yes, right
<civodul>first checkout the right commit
<atheia>still no luck :-(
<atheia>$ git checkout v0.1.1
<atheia>HEAD is now at 03a897d... NEWS: Bump version to 0.1.1
<atheia> $ guix hash -rx .
<thomasd>Hi Guix, is there a reason why "guix import pypi" doesn't return a package description with (uri (pypi-uri ...)), but returns the full url as a string instead? Or would a patch be welcome?
<atheia>$ ./pre-inst-env guix build guile-ics
<atheia>output path `/gnu/store/vg5j89xzz3zfsyhapdg79v240n4sfx5n-git-checkout' should have r:sha256 hash `063lnvwp2jvjwkm9iimj1i5b6andnr3nw1m51g24b11g622xqhw6', instead has `1pvg6j48inpbq47hq00yh5hhl2qd2srvrx5yjl7w7ky1jsjadp86'
<roelj>Would it be possible to let a separate system user own /gnu/store (say 'guix' user), and when Linux user namespaces are enabled for unprivileged users, let guix-daemon run as 'guix' instead of as 'root'?
<roelj>That would end the need for super user privileges (apart from user namespaces) for guix-daemon.
<jmd>Could it be that if the url in a package definition has the schema "file://" then the hash check is skipped?
<efraim>if its already in the store then the hash check is skipped
<efraim>I don't think I've ever tried with file://
<jmd>efraim: So how does guix determine which item in the store I'm refering to?
<efraim>hmm, I might have it backwards
<efraim>it checks the hash, but it doesn't check if the url is valid if its already in the store
<jmd>So the hash is the hash of what exactly?
<efraim>sometimes the tarball gets updated in place, sometimes its the .tar.gz and not .tar.xz, there are a bunch of different things that could happen
<efraim>but it looks it up in the store by the hash
<roelj>jmd: Using file:// indeed skips the hash check.
<jmd>roelj: Is that a bug?
<ng0>do we have pidgin?
<roelj>jmd: I think it's a feature :)
<ng0>on 2017-01-06 there were many CVEs for pidgin
<roelj>jmd: It makes local development easier I believe.
<thomasd>ng0: according to `guix package -s pidgin`, we do
<ng0>maybe this was the wrong pigdin
<ng0>now it's gone from the results
<jmd>roelj: I had better ask on the list about this. It seems dangerous to me ...
<ng0>CVE-2016-2380 CVE-2016-2378 CVE-2016-2377 etc at
<ng0>sorry for the long link
<ng0>it states these issues
<ng0>we should update
<adfeno>ng0: Which issues?
<adfeno>ACTION is shaking, being a Pidgin user himself.
<ng0>read above
<ng0>I'm about to update it now
<ng0>oh, it is updated already
<ng0>tis is weird
<ng0>I think the CVEs were published late
<ng0>no recent commits on this in the pidgin source, other than the current release
<roelj>Is there a way I can modify the result of a Gexp before writing it to the store?
<roelj>I'm currently using gexp->script.
***jonsger1 is now known as jonsger
<thomasd>seeing as the guile devroom was moved to Sunday, who has any recommendations for Saturday at FOSDEM?
<roelj>What's the difference between 'guix download <url>' and downloading <url> when using
<roelj>'guix package -i <package>'?
<roelj>Is the latter handled by guix-daemon, and the former handled by the guix client?
<thomasd>roelj: I think there is no difference. I think both result in a store file, so they must both be handled by the daemon?
<roelj>Weird.. It fails to download from HTTPS when doing 'guix package -i ...', and then copying/pasting the failed URL 'guix download <url>' works fine! Then re-running 'guix package -i ...' works fine too (because the tarball is already in the store).
<thomasd>well, thinking about it again, the file could be downloaded by the client, and then passed to the daemon to intern it in the store. so i'm not sure...
<jmd>I thought there was no difference. "guix download <url>" is a convenience function for package development.
<thomasd>roelj: strange, according to the manual, guix download should check the certificates, too.
<thomasd>(how does it fail with package -i?)
<ng0>Oh, I need string-join, not string-append for the setenv PATH problem in the last patch i have sent, right?
<roelj>thomasd: Heh, it's in a build right now, so I'll have to wait for the next URL to fail.
<rekado_>new blog post:
<efraim>thomasd: I'm checking out the fosdem app on fdroid to choose what looks interesting. Also dont discount Bsd, they're generally interesting talks
<rekado_>I also updated; will announce later today.
<roelj>A haskell embedded in Common Lisp..! I didn't even knew it existed..!
<roelj>thomasd: Regarding the HTTPS problem with 'guix package -i ...'. It cannot load the (gnutls) module: "ERROR: In procedure module-lookup: Unbound variable: make-session". Yet, when doing 'guix download <url>', it does not error on the (gnutls) module.
<quiliro>bon matenon!
<civodul>bonan tagon quiliro! :-)
<civodul>roelj, rekado_: Lisp in bioinfo :-)
<ng0>do you think it'd be easy to get localized text string support into commonmark markdown (or any other variant of it)? Someone I know wrote their own markup language over the decades just because there's no markup language supporting this
<ng0>I'm thinking of Haunt and that I should not need a javascript to translate text
<ng0>Or am I wrong and there is some markup language which supports this?
<davexunit>I made a comment on HN today in a thread about debian and I ended up making an impromptu list of what makes a good upstream from a packager's perspective:
<davexunit>does anyone know of someone that has written a more comprehensive list? should I make a blog post about it?
<davexunit>civodul: hey there! I noticed %guile-static-stripped has a glibc reference removed in /bin/guile, and I have a hunch that is why dynamic-link doesn't work. strace reveals that it is using that /gnu/store/eeee... directory as a search path for dynamic libs. I haven't found anything in the guile source code that is clearly the culprit. do you happen to have any institutional knowledge on the subject? ;)
<civodul>davexunit: iconv tries to dlopen a bunch of stuff, and some of those you're seeing in strace come from that
<civodul>as for (dynamic-link), i think it simply doesn't work on a statically-linked program
<adfeno>quiliro: Would you do both of us a favor: Can you report the IceCat and Nautilus file naming issue to Guix's bug list?
<civodul>davexunit: when linking statically a program that uses dlopen, you get this ld warning:
<civodul>t.c:(.text+0xf): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
<davexunit>civodul: hmm not sure I saw that warning text, but I believe you.
<davexunit>maybe I want a dynamically linked guile after all...
<davexunit>I can bundle the libs I need easily enough.
<davexunit>thanks, that was the course correction I needed.
<civodul>yw :-)
<davexunit>I wrote a procedure called (for lack of a better name) package-with-fhs-build-system
<civodul>oh, that sounds fun!
<davexunit>that replaces the implicit inputs of the gnu build system with a set that has no ld-wrapper and a gcc compiled without the hacks that hardcode glibc/libgcc references
<civodul>ah ok
<davexunit>(among other things)
<civodul>i thought it was building using FHS directory names
<civodul>pretty cool still
<davexunit>that's why the name sucks!
<davexunit>so far I've produced and with no store references
<davexunit>oh and
<davexunit>so it seems to be a useful hack ;)
<civodul>you should share the conclusions of this experiment, i'm curious
<davexunit>civodul: I will consider it a success when I'm able to open a graphical window with guile-sdl2 on ubuntu.
<davexunit>I'll try with a dynamic guile later tonight if I have some time.
<davexunit>I wasn't sure if it was feasible, but I'm now convinced it is. mostly my own ignorance of linkers is holding me back.
<Akko_Teru>Can anyone here tell me how well MIDI controllers will work with GNU/Linux without using the CD of proprietary software that they ship with? I've been looking at Alesis Q25 and an AKAI 25 key.
***jonsger1 is now known as jonsger
<rekado_>Akko_Teru: if the USB MIDI hardware is class compliant it will just work.
<rekado_>I use the Tascam US-16x08 (audio interface with MIDI) and since it’s class-compliant it works out of the box with GuixSD.
<davexunit>I recently got a yamaha digital piano for my living room, and I discovered it has MIDI out. I want to try playing with some of the stuff rekado has packaged sometime
<rekado_>I also have the Swissonic EasyKey 49 with MIDI over USB. That also works just fine.
<rekado_>civodul, roelj: I’ve read this earlier today. Also interesting is that Ross Ihaka thinks about implementing the R of the future on top of Common Lisp:
<roelj>rekado_: Interesting
<quiliro>icecat cannot reproduce vimeo videos but youtube works
<ng0>blame vimeo
<ng0>it's still mostly flash
<ng0>mpv etc works
<bavier`>quiliro: youtube-dl works for downloading vimeo videos
<efraim>I got lumina to build, now I have to package fluxbox to test it out
<sankey>bavier`: quiliro: also mpv uses youtube-dl to download and play a video when given a URL on the command line
<nliadm>vimeo shouldn't be flash
<sankey>the issue is likely that youtube offers many videos with free codecs, whereas vimeo tends to only provide mp4 (or whatever patent-encumbered codec mp4 encapsulates)
<nliadm>although if another part of your system can play h264 files, you should be able to make your browser do it
<sankey>ACTION wonders if icecat/firefox uses the same multimedia library as mpv
<nliadm>iirc firefox uses gstreamer?
<sankey>guix commits e3cb00d2 and d505801a add x264 to gstreamer (icecat) and ffmpeg (mpv) respectively
<sankey>in the case of gstreamer, you may have to additionally install the gst-plugins-bad package, but it's unclear to me how a package can treat that as an input without rebuilding
<sankey>i'm guessing icecat in guix, as currently packaged without gst-plugins-bad as input, cannot play h264 video for this reason, and thus cannot play videos from Vimeo
<sankey>whereas mpv, which uses ffmpeg as an input, can play videos from Vimeo
<efraim>Rage from enlightenment will find gst-plugins-* if its built with gstreamer, I assume others are similar
<nliadm>sankey: that sounds right
<ng0>2f30 is interconnected with the suckless community. When I upstream my collection of packages of this community, should they go into suckless.scm or should they be moved into admin etc
<ng0>I have them in twoefthirty.scm in my guix_package_path currently
<ng0>I will go for suckless.scm
<quiliro>hello...thank you for your help.... i am installing gst-plugins-* and ffmpeg
<ng0>but I think "st" is in shells too, so I think others would be ok
<quiliro>what is the advantage of using the shell to run programs besides the fact that it is more powerful and light at the same time?
<bavier`>quiliro: it's (usually) programmable
<ng0>speaking of shells, is anyone interested in helping me to fix the last 2 failing tests for the tcsh update?
<quiliro>ng0: i am interested but lack the skills
<ng0>I've got stuck at those two tests
<adfeno>quiliro: To give you an idea: I made a script that automates inserting logos in some selected images where I used to work.
<adfeno>It was time-consuming to open Inkscape, measure where the unwanted part is, import the logo, resize the logo so it is at least greater than unwanted part, and place it upon this.
<adfeno>Besides, I would have to keep one extra file (inode) for the Inkscape/.svg project files.
<quiliro>adfeno: cool
<adfeno>So now, where I used to work for, they just need to keep two files: the original image, in case they want to do some other art with it, and the image with the logo inserted.
<adfeno>Besides, at least for those who use ext-and-some-number file systems, inode consumption is something that must be dealt with.
<sankey>adfeno: hah, here's a makefile that i used recently to automate inkscape
<sankey>that i wrote*
<sankey>it simply extracts objects from an svg file, something that was needed for my laser cutting workflow
<quiliro>i would like my setup to open web pages show in the chat (pidgin)
<adfeno>sankey: In my case, I used a mix of POSIX-compliant sh, find, grep, xdg-utils, and ImageMagick.
<ng0>Oh. st is in suckless. So maybe I really move all into suckless.
<quiliro>bit it would not open any browser
<quiliro>i have to copy the link
<sankey>ng0: weren't you talking earlier about splitting out suckless packages from suckless.scm into their respective categories?
<ng0>there's also qt.scm .. and kde-frameworks.scm etc
<lfam>jmd: Hi, can you undo that Imagemagick update and instead use the lastest release in the 6 series? That's what all the other distros are using, it's still maintained, and we haven't tested 7 with out packages AFAIK
<lfam>Maybe we should try the 7 series on an imagemagick-updates branch.
<quiliro>i probably need to specify mimetypes
<quiliro>would someone tell me how?
<jmd>lfam: According to upstream the 6 series is legacy.
<lfam>jmd: Understood, but my question stands
<lfam>We've held off updating to the 7 series since it seems that nobody has tested it across a whole distribution yet
<lfam>We can be the testers
<lfam>I can do the revert+update if you want; I was actually getting ready when you joined IRC
<jmd>Sure I can do that, but it seems like a curious course of action.
<jmd>As I understand it, we use what upstream maintainers recommend unless there is a good reason to do otherwise.
<lfam>The 6 series is maintained in parallel with the 7 series. Debian, Fedora, and Nixpkgs still use 6. I don't want to test 7 on the master branch.
<lfam>We can use Hydra to test it without causing disruptions for our users. And users are not missing some important security updates by using 6.
<lfam>The good reason to use 6 is that 7 is untested
<jmd>Would the same argument also not apply to every other package which gets updated?
<lfam>Well, it's untested across an entire software distribution. I'm sure the ImageMagick maintainers are testing it somehow
<lfam>Not every other package has two branches developed in parallel
<lfam>The are specifically helping us do this by maintaining both branches
<lfam>If they wanted us to stop using 6 immediately, they'd stop maintenance of it.
<lfam>For now, they've ported every bug fix back to 6 on the same day it was committed to 7
<jmd>Well I interpret their use of the word "legacy" to imply not recommended for use in new systems.
<lfam>(You might be able to tell that I've been paying attention to this)
<nliadm>whoa, I thought tcsh was dead as hell
<lfam>jmd: Correct, but we have packages that were developed to use 6, and we haven't yet tested their compatibility with 7. Those are "systems" too
<lfam>So, unless there is a pressing reason to make this potentially breaking change on the master branch*, I think we should do it in another branch
<lfam>*We shouldn't break things on master unnecessarily or users will be wary of updating and will learn to miss security updates
<jmd>Do we have reason to believe that it will break things?
<lfam>jmd: Did you read the 6->7 porting instructions?
<lfam>Several APIs have changed
<jmd>I also ran the tests. 7 of which failed - exactly the same behaveiour as the 6.x version.
<lfam>The APIs that other packages use to access ImageMagick have changed. Let's test the packages' compatibility on a branch
<davexunit>upgrading imagemagick will cause at least 110 rebuilds
<davexunit>we should try out an upgrade in a new branch
<jmd>davexunit: That is less than the threshold for staging.
<jmd>... if I recall correctly.
<lfam>Did anybody test that the referring packages are updated to use the new API?
<lfam>If not, I think we should revert the change, update to the latest 6, make a new branch that adds 7 alongside 6, and then we can make the 7-capable packages use 7. I don't think trying this on the master branch is appropriate
<rekado_>lfam: I agree
<lfam>110 rebuilds is fine for the master branch, but in this case we have reason to believe that packages will break, and so it's not appropriate for master.
<jmd>Anyway I've reverted it, but for future reference how should I know when it's ok to upgrage a package and when i is not?
<lfam>We can't always know. I just happen to know about this one; I've paid close attention since the "ImageTragick" bug was published
<jmd>Ok. Then I suggest you put a comment in imagemagick.scm "Do not upgrade".
<lfam>Okay, will do
<ng0>what if we have 7 and 6 as separate apckages?
<lfam>ng0: I think we should do that, and try using 7 with all the packages on an imagemagick-updates branch.
<jmd>I have another suggestion: Rather than doing commits Revert "Revert "Revert "Revert ....
<lfam>In general, I think we should try updating packages like this to latest series. If we can eventually drop the legacy series, that's good for upstream.
<jmd>why not just cherry-pick the original commit?
<lfam>jmd: Yes, good idea. My recent mess with nss and nss-certs is hard to read
<lfam>jmd: I sent some patches to guix-devel for starting the imagemagick-updates branch
<jmd>Soon we will have more branches than commits!
<efraim>i'm wondering if qtdeclarative should be a native-input by default, or if its always listed as a dependancy because its needed by so many other modules
<efraim>yay, I didn't realize we already had fluxbox packaged
***paolo_ is now known as paolo
<lfam>Is anyone else having trouble with Git and HTTPS?
***snape` is now known as snape
<lfam>For some reason my GIT_SSL_CAINFO environment variable stopped working as expected
<ZombieChicken>Anyone here know how to get qemu to handle 5 drives without barfing?
<ZombieChicken>One has to love it when a program can't find a file that exist, is readable and writeable, and that one has triple checked exist
<ZombieChicken>but can easily find all the other identical files in the directory without issue
<lfam>ZombieChicken: The error message is probably wrong
<lfam>Maybe it's trying to execute a program on said file, but the program can't be found. I've seen that
<lfam>You can use strace to see exactly what it's doing
<ZombieChicken>Well, it's qemu and I'm trying to start it up with 4 drives to simulate my desktop's setup to test a guix install on
<ZombieChicken>and those 4 files are empty qcow2s, the one with a problem is 1G, the other 3 are 5
<lfam>What happens if you try 3 drives?
<ZombieChicken>If I remove the 1G drive, it seems to work fine
<ZombieChicken>the only difference is the file names (replaced "-[0-9]"
<ZombieChicken>the only difference is the file names (replaced "-[0-9]" with "-boot" in the name, and 4G of space
<lfam>You're probably hitting the Linux limit of 4 primary partitions somehow
<lfam>How are you invoking QEMU?
<ZombieChicken>qemu-system-x86_64 --enable-kvm -cpu host -net nic,model=virtio -net user -usbdevice tablet -m 2G -usbdevice disk:guixsd-usb-install-0.12.0.x86_64-linux -hda file=guixSD-boot.qcow2 -hdb file=guixSD-1.qcow2 -hdc file=guixSD-2.qcow2 -hdd file=guixSD-3.qcow2
<ZombieChicken>My desktop runs a RAID5 and boots from a flashdrive
<ZombieChicken>hence 4 drives
<ZombieChicken>plus the LiveUSB for installing
<ZombieChicken>got it
<ZombieChicken>just had to remove "file=" from the -hd[abcd] lines
<ZombieChicken>Now to get it to realize the liveUSB is what it should boot from...
<ZombieChicken>there we go
<ZombieChicken>apparently qemu's automagical boot selection isn't great
<ng0>hrmmmmm... there must be some other solution to a first basic uclibc-ng build. before the checks I need to link linux-libre-headers into uclibc-ng /include directory, which feels awful given that there are many files in -headers
<ng0>but that's just needed for cross compile iirc. I'm happy if it compile on one arch first
<ZombieChicken>Anyone know if your can partition an encrypted volume? By that I mean run cfdisk over a LUKS-encryped drive?
<ng0>civodul: in case you are interested, this is tinycc / tcc-next. I don't work very often on it:
<ng0>ah, slowly i'm getting to a point where it's usable... pakcaging compilers is not so easy
<paroneayea>hello #guix