Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)
On Thu, 04 Apr 2024 12:34:42 +0200 Giovanni Biscuolo wrote: > Hello everybody, > > I know for sure that Guix maintainers and developers are working on > this, I'm just asking to find some time to inform and possibly discuss > with users (also in guix-devel) on what measures GNU Guix - the > software distribution - can/should deploy to try to avoid this kind > of attacks. What about integrating ClamAV into the build farms (if this isn't a thing already)? ClamAV could scan source files and freshly-built packages and perhaps detect obvious malware. AFAIK it can also detect CVEs. Guix already has ClamAV packaged so this shouldn't be that hard. -- Jan Wielkiewicz
Re: Should we include nss-certs out of the box?
On Wed, 03 Apr 2024 14:06:37 -0400 Maxim Cournoyer wrote: > Hi, > > It's been Guix policy to let people choose whether to install or not > TLS root certificates and which one to their machine. While I > applaud the idea to have the users make a conscious decision about > it, in practice I suppose very few of us choose to *not* install any > as that basically breaks using web browsers, especially ones like > IceCat which (by default) ensures HTTPS is used on every page. > > It apparently even makes it impossible to run 'guix pull', if I am to > believe bug#62026. > > Should we do as in bug#62026 and have this package be part of the > recommended basic installation? It'd be in the basic set of an > operating-system packages (via its default %base-packages set). It > could still be manipulated via the Guix API (filtered out/replaced > with something else). > > Is anyone opposed to having nss-certs in %base-packages? > Hello, IMO everything should work out of the box. Power users will be able to do their stuff if they need to, so the feature should be opt-out. -- Jan Wielkiewicz
Updating Minetest to 5.9.0
Hi, I plan upgrading Minetest to 5.9.0 but there are some technical issues that need to be addressed first. Minetest developers dropped development of "Minetest Game" (MTG) - the default game that was previously shipped with the engine: https://blog.minetest.net/2023/12/04/5.8.0-released/ There are other games for Minetest that are not MTG, e.g. MineClone2, NodeCore, etc. And mods made for the other games don't always work with MTG. As far as I can tell minetest-build-system tests all mods only against MTG. Given that MTG is not a default/official game anymore I decoupled the minetest package and added a new minetest-minetest-game package for people who for watever weird reason want to download the game anyway. The question is: what should I do about the build system? I also deprecated the irrlicht-for-minetest package, because minetest devs copied it directly into the game's directory tree and minetest is incompatible with upstream irrlicht anyway (https://github.com/minetest/minetest/commit/f638482fba9cf4148ced66e1598cb9027a60cdc9). The irrlicht-for-minetest package is not used outside of minetest. I also plan updating minetest mods in Guix because they're really out of date. -- Greetings Jan Wielkiewicz
Re: Updating minetest to 5.6.0?
On 18.09.2022 13:11, Jan Wielkiewicz wrote: Okay, I believe I covered all your objections and my changes are good to go now. I sent a patch series to the guix-patches mailing list, unfortunately I forgot to send subsequent patches to n...@debbugs.gnu.org (It's almost 2 years since the last time I contributed anything to Guix). Should I close these issues and send the series one more time properly or should I skip it this time to avoid making even bigger mess? Jan Wielkiewicz Never mind. Closed these three issues and sent it properly. Jan Wielkiewicz
Re: Updating minetest to 5.6.0?
On 17.09.2022 11:43, Maxime Devos wrote: On 17-09-2022 02:10, Jan Wielkiewicz wrote: Done. See the patches (I can't really find "git send-email" on Guix for some odd reason). The hacks in the Exile package are quite ugly, but I don't know a better way, see below. Try "guix show git", it will mention a 'send-email' output that you can install to have access to 'git send-email'. See ‘(guix)Packages with Multiple Outputs’ on how to install such outputs. Greetings, Maxime. Okay, I believe I covered all your objections and my changes are good to go now. I sent a patch series to the guix-patches mailing list, unfortunately I forgot to send subsequent patches to n...@debbugs.gnu.org (It's almost 2 years since the last time I contributed anything to Guix). Should I close these issues and send the series one more time properly or should I skip it this time to avoid making even bigger mess? Jan Wielkiewicz
Re: Updating minetest to 5.6.0?
Forgot the patches...From 0ec48989fd8cf47c20c2c7181f05469335753514 Mon Sep 17 00:00:00 2001
From: Jan Wielkiewicz
Date: Sat, 17 Sep 2022 01:10:58 +0200
Subject: [PATCH 2/2] gnu: Add minetest-exile, minetest-naturalslopeslib.
* gnu/packages/minetest.scm (minetest-exile,
minetest-naturalslopeslib): New variables.
---
gnu/packages/minetest.scm | 61 +++
1 file changed, 61 insertions(+)
diff --git a/gnu/packages/minetest.scm b/gnu/packages/minetest.scm
index 82c0b352bb..dc5dee11bd 100644
--- a/gnu/packages/minetest.scm
+++ b/gnu/packages/minetest.scm
@@ -747,3 +747,64 @@ (define-public minetest-basic-trains
advtrains up to version 2.2.1.")
(license (list license:cc-by-sa3.0 license:agpl3+))
(properties `((upstream-name . "orwell/basic_trains")
+
+(define-public minetest-naturalslopeslib
+ (package
+(name "minetest-naturalslopeslib")
+(version "1.5")
+(source (origin
+ (method git-fetch)
+ (uri (git-reference
+(url
+ "https://files.creativekara.fr/git/naturalslopeslib.git;)
+(commit version)))
+ (sha256
+ (base32
+"19j223lld415496ppk0q0d4g45hxrvygl3axxlmbvqilflsqp6n0"))
+ (file-name (git-file-name name version
+(build-system minetest-mod-build-system)
+(home-page
+ "https://content.minetest.net/packages/karamel/naturalslopeslib/;)
+(synopsis "Natural slopes library for Minetest")
+(description
+ "This Minetest mod is a library that adds stair-like nodes from soft
+ground nodes (sand, dirt, gravel...) that may change shape automatically
+according to their surroundings.")
+(license license:lgpl2.1)))
+
+(define-public minetest-exile
+ (package
+(name "minetest-exile")
+(version "v0.3.8d")
+(source (origin
+ (method git-fetch)
+ (uri (git-reference
+(url "https://github.com/jeremyshannon/Exile/;)
+(commit version)))
+ (file-name (git-file-name name version))
+ (modules '((guix build utils)))
+ (snippet #~(delete-file-recursively "mods/naturalslopeslib"))
+ (sha256
+ (base32
+"1h7792kznhcqrvxn127318dx1v4xbwvffxw7vav22fd85c839c5g"
+(build-system copy-build-system)
+(arguments
+ (list #:install-plan #~'(("." "share/minetest/games/exile"))
+ #:phases #~(modify-phases %standard-phases
+(add-after 'install 'install-dependencies
+ (lambda _
+(symlink (string-append
+ #$(this-package-input
+ "minetest-naturalslopeslib")
+ "/share/minetest/mods/naturalslopeslib")
+ (string-append
+ #$output
+ "/share/minetest/games/exile/"
+ "mods/naturalslopeslib")))
+(inputs (list minetest-naturalslopeslib))
+(synopsis "A survival game for Minetest")
+(description
+ "Exile is a wilderness survival game with simple technology using
+the Minetest game engine.")
+(home-page "https://content.minetest.net/packages/Mantar/exile/;)
+(license license:gpl3)))
--
2.37.3
From cf3af84978f8b630d432c2f042ee9b041aa9118d Mon Sep 17 00:00:00 2001
From: Jan Wielkiewicz
Date: Thu, 15 Sep 2022 22:19:05 +0200
Subject: [PATCH 1/2] gnu: minetest: update to 5.6.0.
* gnu/packages/minetest.scm (minetest, minetest-data): Update to 5.6.0.
* gnu/packages/games.scm (irrlicht-for-minetest): Update to 1.9.0mt7,
[inputs]: add libxi.
---
gnu/packages/games.scm| 7 +--
gnu/packages/minetest.scm | 7 ---
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/gnu/packages/games.scm b/gnu/packages/games.scm
index 60ce0167a6..1e2ec71da3 100644
--- a/gnu/packages/games.scm
+++ b/gnu/packages/games.scm
@@ -73,6 +73,7 @@
;;; Copyright © 2022 zamfofex
;;; Copyright © 2022 Gabriel Arazas
;;; Copyright © 2022 Maxim Cournoyer
+;;; Copyright © 2022 Jan Wielkiewicz
;;;
;;; This file is part of GNU Guix.
;;;
@@ -3626,7 +3627,7 @@ (define-public irrlicht-for-minetest
(package
(inherit irrlicht)
(name "irrlicht-for-minetest")
-(version "1.9.0mt5")
+(version "1.9.0mt7")
(source
(origin
(method git-fetch)
@@ -3635,8 +3636,10 @@ (define-public irrlicht-for-minetest
(commit version)))
(sha256
(base32
- "1jxk1x0f60n8lrz8a6x62aj2pqg0qnbajsld3lqncvwsfbi0xjx1")
Re: Updating minetest to 5.6.0?
On 16.09.2022 20:18, Maxime Devos wrote: How about modifying minetest-exile's phases to add a symlink in #$output /share/minetest/games/exile/mods/naturalslopeslib pointing to #$(this-package-input "minetest-naturalslopeslib")? (I don't know how to do that with copy-build-system though, does that build system support phases? I was thinking of a post-install phase or a post-unpack) (Also I don't know if Minetest allows symlinks inside mods) That way: * it doesn't have to be propagated (so naturalslopeslib only appears in the (non-game) mod if the user actually asked to install the Guix package, and not as a consequence of installing something else * by using a symlink instead of a copy, a little space, network IO, disk IO and build time is saved, e.g. when the user installs both minetest-exile and minetest-naturalslopeslib Done. See the patches (I can't really find "git send-email" on Guix for some odd reason). The hacks in the Exile package are quite ugly, but I don't know a better way, see below. I think it would be feasible to write a 'minetest-game-build-system' to mostly automatically do such things, but currently such a thing does not exist yet. Minetest has a pretty ugly way of managing dependencies, actually it doesn't manage them at all. So it's either up to (sub)game developers to bundle everything into their games or up to users to download all the dependencies they want. In the future the game will download dependencies automatically which is even worse from our perspective. I could possibly try hacking the build system to do something but I'm unfamiliar with Guix's guts. Greetings, Maxime. Jan Wielkiewicz
Re: Updating minetest to 5.6.0?
On 16.09.2022 10:59, Maxime Devos wrote: On 16-09-2022 00:45, Jan wrote: The minetest-mod-build-system has some (very basic) tests for testing that the mods at least load with the new Minetest. About that, I can never see mods installed with Guix in Minetest. Is the build system really working as intended? I'm running the latest Guix. Am I missing something? I don't see the mods on the current version nor the latest I packaged. Seems to work over here: $ guix shell --pure minetest minetest-mesecons [ in the GUI: ‘Select Mods’ ] [ GUI: ] + mesecons + Minetest Game mods [ in the GUI: select +mesecons ] [ ...] Make sure to install Minetest and its mods in the same profile, and to log out and in again if it's not done with "guix shell" or "guix environment --ad-hoc" but with "guix home" or "guix install", such that Guix can set appropriate environment variables (MINETEST_MOD_PATH). I tried installing a mod by force installing it into "share/minetest/mods/modname" using the copy-build-system just like mineclone2 is installed, but it doesn't work this way. minetest-mod-build-system does this too, in 'mod-install-plan' Greetings, Maxime. Thanks, it works now. I made a mistake and installed it from "guix shell -D guix --pure". Now that I installed it from my profile, both mods and games are visible in Minetest without a reboot. I also did a quick check and mods appear to work. Last one question before sending the patches: I'm adding a minetest game called Exile and it uses a mod called naturalslopeslib. I packaged both of them but Exile expects the lib to be installed in "/.guix-profile/share/minetest/games/exile/mods/naturalslopeslib/". Should I add the mod as a propagated-input of Exile or should I directly copy/link the lib into Exile's tree (if so, how do I go about that)? Users can easily download naturalslopeslib through Guix and enable it in the game's GUI but some may expect the dependency to be already there. My Exile package uses copy-build-system just like mineclone2. Jan Wielkiewicz
Re: wip-full-source-bootstrap: from a 357-byte `hex0' to 'hello'
Dnia 2021-01-04, o godz. 18:01:21 Jan Nieuwenhuizen napisał(a): > Hi! > > I have reset Guix' wip-full-source-bootstrap branch with a first > working implementation of the, well, "Full Source Bootstrap" for > x86-linux (and x86_64-linux). This bootstrap is rooted in the > 357-byte hex0-seed from the Stage0 project Great job! Looks like dark magic to me. It would be interesting to compare binaries made using the bootstrapped and the unbootstrapped system and look for *interesting stuff* like some decades old self-replicating code. > Greetings, > Janneke > > *) > https://git.savannah.gnu.org/cgit/guix.git/log/?h=wip-full-source-bootstrap > Jan Wielkiewicz
Re: A new paradigm for modifying operating system declarations
Dnia 2021-01-04, o godz. 15:38:38 raid5atemyhomework napisał(a): > Hi guix-developers, Hello. > ```scheme > (install-zfs > (operating-system > (kernel linux-libre-5.4) > ; ... other fields ... > )) > ``` I don't like this way of nesting the OS declaration inside of any other expression. > > ```scheme > (install-foo > (install-bar > (install-zfs >(operating-system > #;... This makes it even worse. > Which brings us back to the `decorate` form, which reduces nestedness: > > ```scheme > (decorate (install-foo >install-bar >install-zfs >operating-system) >#;...) Better but still don't like it. Can't we put the os declaration into a variable and then pass it to a procedure? Say: > ```scheme > (define OS > (operating-system > (kernel linux-libre-5.4) > ; ... other fields ... > )) > > (install-zfs OS) > (install-foo OS) > (install-bar OS) > (install-something OS) > > ``` > Thanks > raid5atemyhomework > Jan Wielkiewicz
Re: updating Jami to "Together", Qt update?
Dnia 2020-12-08, o godz. 00:03:31 Marius Bakke napisał(a): > Jan Wielkiewicz skriver: > > > Hello everyone, > > > > I managed to compile the latest release of Jami and I'll be sending > > patches soon. > > Is anyone planning to update Qt to 5.15.1? It would be nice if Jami > > used this version to stay close to upstream. > > I can update it if no one plans that. > > I have an update for Qt 5.15.2 lined up for the 'staging' branch that > will get pushed approximately tomorrow. :-) Nice. I'll try sending my patches but I'm quite busy and lazy in the same time and procrastinate on everything. Jan Wielkiewicz
Re: updating Jami to "Together", Qt update?
Dnia 2020-11-18, o godz. 20:17:54 Ryan Prior napisał(a): > On November 18, 2020, Pierre Neidhardt wrote: > > aviva writes: > > > > > nobody i know uses it. without a community of users, it has no > > purpose > > > > There must always be a first user ;) > > I use Jami regularly with a few adventurous friends who like peer-to- > peer things. We often have to fall back to another video system like > Jitsi to finish our calls, but keep returning for more punishment > because we believe in the dream. > > I have been specifically burned before by the Jami package in Guix. It > hasn't played well with other Jami software; I started having better > luck when I switched to using the Debian package. But if you get the > Together release working well I'm absolutely down to give it another > shot! Remember you can always let me know if something doesn't work with my package on this mailing list. I've never had luck with Jami to be honest and bringing the package to the point where it is now was about 7 months of building it on my core 2 duo system, finding bugs, missing dependencies, irreproducible bugs, etc. Stupid "DNDEBUG" flag pushed me into another months of trying to figure out why audio calls were crashing. Did you try Jami from Guix before or after my updates? I mostly started maintaining this package because it was 1. broken 2. building it from source on a different distro gave strange effects. Generally speaking I witnessed Jami (then Ring) going from absolutely broken, unusable software to the point I can use it to chat with friends, send files, etc. The last year of development fixed many disgusting bugs. Also remember that buggy routers and the unholy invention called NAT has a big part of making Jami and generally p2p applications less usable. Jan Wielkiewicz
Re: updating Jami to "Together", Qt update?
Dnia 2020-11-17, o godz. 21:06:44 aviva napisał(a): > On 11/17/20 8:45 PM, Jan Wielkiewicz wrote: > > Hello everyone, > > > > I managed to compile the latest release of Jami and I'll be sending > > patches soon. > > Is anyone planning to update Qt to 5.15.1? It would be nice if Jami > > used this version to stay close to upstream. > > I can update it if no one plans that. > > > > > > Jan Wielkiewicz > > > > > I wish I could find a reason to use it > > Works without a server, full p2p, can run in LAN without the Internet access, allows sending files p2p, allows audio/video calls, multi-platform, etc.
Re: updating Jami to "Together", Qt update?
Dnia 2020-11-18, o godz. 09:10:52 Pierre Neidhardt napisał(a): > Hi Jan! > > Jan Wielkiewicz writes: > > > I managed to compile the latest release of Jami and I'll be sending > > patches soon. > > Congrats and thanks again for your continuous effort! Thanks. > > Is anyone planning to update Qt to 5.15.1? > > Not that I know of, Qt support is always welcome! Well, I wouldn't call it a support because I have no idea about Qt development/packaging nor I know how to fully test it, but I can bump the version numbers and hope it compiles. I succesfully updated 3 Qt packages Jami depends on in my private repo and it worked. Jan Wielkiewicz
updating Jami to "Together", Qt update?
Hello everyone, I managed to compile the latest release of Jami and I'll be sending patches soon. Is anyone planning to update Qt to 5.15.1? It would be nice if Jami used this version to stay close to upstream. I can update it if no one plans that. Jan Wielkiewicz
Re: Latest Nyxt features a GUI for Guix :)
Dnia 2020-11-12, o godz. 10:20:10 Pierre Neidhardt napisał(a): > Ryan Prior writes: > > > On November 11, 2020, Jan Wielkiewicz > > wrote: > >> [web browsers are] a really poorly designed copy of > >> operating systems and its utilities. > >> > >> [...] > >> > >> I just don't understand why in the web browser. > >> I'll try it. > > > > The web browser is the primary operating environment for a lot of > > people. Just as Emacs users built web browsers, terminal emulators, > > and mail clients on the Emacs platform, the web platform also has > > all those things (including various elaborate in-browser code > > editors.) So I understand this as having the exact same genesis as > > the Guix interface in Emacs: people would like to manage their > > operating system using the interface they spend most of their time > > in, and for Nyxt power users that would be their browser. I'm not > > at all interested in managing my Guix packages using Nyxt, which is > > highly correlated to my not being a Nyxt power user. > > Exactly :) I see. > To add to what Ryan said, Nyxt has a interesting design feature: it > does not need to depend on a web browser! If this is the case, then I have nothing against it. I just don't like when programs depend on things they don't need to, like a calculator app written in with 500MB of dependencies in node_modules and Chromium. This isn't a joke, this is the reality we're living in. > Nyxt is rather a > "Common Lisp interactive framework" and it would be perfectly possible > to implement a textual interface à-la Emacs. Of course, web page > rendering would be much more limited though. > > I'd like to work on a pure GTK (or ) > version of Nyxt at some point. > Nice.
Re: Latest Nyxt features a GUI for Guix :)
Dnia 2020-11-12, o godz. 09:51:00 Ricardo Wurmus napisał(a): > > Jan Wielkiewicz writes: > > > I guess your choice comes from the lack of a proper GUI toolkit > > available, but I'm just not a big fan of web browsers generally. > > In fact I started writing my own GUI toolkit/application framework > > in Guile just for the purpose of bringing modularity to GUI > > applications, but I'm rather unexperienced and this might take a > > few years. > > Is guile-gi not working well enough for your use case? > 1. Never heard of it, but I'll check it out if it exists, maybe I can reuse some code or improve it or even build on top of it. ... Looking further into it I actually remember now what it is, just last time I checked the bindings for GTK+ were outdated and not maintained and guile-gi was in the early development stage. 2. I have some interesting ideas that would be a shame to waste. I actually don't care what displays the GUI, I'm working more on a modular desktop experience - the set of small GUI (and not only) programs working together by passing messages. 3. That's my project to learn programming in Guile. Thanks for mentioning guile-gi, this will speed up my experiments. Jan Wielkiewicz
Re: Latest Nyxt features a GUI for Guix :)
Dnia 2020-11-11, o godz. 19:35:57 Pierre Neidhardt napisał(a): > Hi Jan, > > Jan Wielkiewicz writes: > > >> I've just updated the Nyxt package to 2-pre-release-4 which > >> includes a package manager GUI that supports Guix! > > Did you and a GUI for the package manager into the browser...? :) > > Sorry, what did you mean? :) Sorry for I-had-a-stroke message. I often build my sentences non-linearly and end up with sliced streams of consciousness. What I was supposed to write: "Did you add a GUI for the package manager into the browser...? :)" > > I mean it's good to have a GUI for Guix, but isn't this against so > > called "UNIX Philosophy" or modularity, saying more precisely? > > What is against the Unix philosophy? I don't really like the term, because it became a buzzword recently, but generally what I mean is building a program on top of a giant framework such as a web browser isn't the best desing choice. I think programs should be build in the modular fashion, so each element is easily replaceable. I believe web browsers tend to do many things and do them badly - they're a really poorly designed copy of operating systems and its utilities. I guess your choice comes from the lack of a proper GUI toolkit available, but I'm just not a big fan of web browsers generally. In fact I started writing my own GUI toolkit/application framework in Guile just for the purpose of bringing modularity to GUI applications, but I'm rather unexperienced and this might take a few years. > I don't think GUIs are against anything. This GUI I've worked on a > merely an interface, it does nothing but use the Guix API. The first sentence made my point not clear - I have nothing against GUIs. > It makes searching and install/uninstall and generation delete > operations very convenient. Everything is much easier when you have > an interactive minibuffer with live fuzzy search ;) That's good, I just don't understand why in the web browser. I'll try it. > Cheers! >
Re: Latest Nyxt features a GUI for Guix :)
Dnia 2020-11-11, o godz. 15:41:33 Pierre Neidhardt napisał(a): > Hi Guixers! Hi Pierre! > I've just updated the Nyxt package to 2-pre-release-4 which includes a > package manager GUI that supports Guix! Did you and a GUI for the package manager into the browser...? :) I mean it's good to have a GUI for Guix, but isn't this against so called "UNIX Philosophy" or modularity, saying more precisely? I guess thats an Emacs thing, but I have never understood why. > You can: > > - describe-os-package > - install-os-package > - uninstall-os-package > - list-os-package-files > > - install-package-manifest > - edit-package-manifest > > - describe-os-generation > - switch-os-generation > - delete-os-generation > > All these commands support existing profiles. Profile creation is not > supported at the moment. > > Most of these commands work with multiple selections (C-space, M-a to > select all). > > Interested in your feedback! > > Happy hacking! > Jan Wielkiewicz
Strange ld error when building libring (Jami daemon) help needed
Hello everyone, I'm still trying to update Jami to "Together", fixed some errors already with the help from upstream, but I get the strange error nor me nor Sébastien (Jami developer) knows the reason of. See my last message in this issue: https://git.jami.net/savoirfairelinux/jami-packaging/issues/83 For some reason OpenDHT can't be linked with libring. I'm open to your ideas and suggestions, because currently I have none. I did some work already, but my git history is a mess. I can send my current work, if you need it - I mostly updated dependencies, fixed the patching procedure (whitespace errors) and that's basically it. Stay warm (or cool on the southern hemisphere), Jan Wielkiewicz
Trying to update Jami, patching pjproject fails
/turn_sock.c Hunk #1 succeeded at 1492 (offset 96 lines). patching file pjnath/src/pjnath/ice_session.c Hunk #1 succeeded at 1506 (offset 209 lines). patching file pjnath/src/pjnath/ice_strans.c Hunk #1 succeeded at 460 (offset 42 lines). Hunk #2 succeeded at 529 with fuzz 2 (offset 49 lines). Hunk #3 succeeded at 589 with fuzz 1 (offset 49 lines). Hunk #4 FAILED at 680. 1 out of 4 hunks FAILED -- saving rejects to file pjnath/src/pjnath/ice_strans.c.rej command "patch" "--force" "-p1" "-i" "sfl-patches/0013-Assign-unique-local-preferences-for-candidates-with-.patch" failed with status 1 builder for `/gnu/store/spfmrdl2g01rwd8lr3nwd2wlz45jwlmv-pjproject-jami-2.10.drv' failed with exit code 1 build of /gnu/store/spfmrdl2g01rwd8lr3nwd2wlz45jwlmv-pjproject-jami-2.10.drv failed View build log at '/var/log/guix/drvs/sp/fmrdl2g01rwd8lr3nwd2wlz45jwlmv-pjproject-jami-2.10.drv.bz2'. cannot build derivation `/gnu/store/xiw6p51mjapvkmwyi1xs74gmhmvmbw04-libring-20201005.1.392ac4d.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/q2hx2ws9282mfz2927d1zpchxq6p96m1-libringclient-20201005.1.392ac4d.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/ifqj0ya0m51xmra98rmxzcq78vr9jvx8-jami-20201005.1.392ac4d.drv': 1 dependencies couldn't be built guix build: error: build of `/gnu/store/ifqj0ya0m51xmra98rmxzcq78vr9jvx8-jami-20201005.1.392ac4d.drv' failed Jan Wielkiewicz
Re: IceCat-68.2.0-guix0-preview1 is now available on master
Dnia 2019-10-27, o godz. 12:44:00 Mark H Weaver napisał(a): > Hello fellow Guix, > > I'm pleased to announce that IceCat-68.2.0-guix0-preview1 is now on > the 'master' branch, and that substitutes for x86_64-linux are > available from ci.guix.gnu.org. > > This update includes fixes for CVE-2019-11757, CVE-2019-11759, > CVE-2019-11760, CVE-2019-11761, CVE-2019-11762, CVE-2019-11763, > CVE-2019-11764, and CVE-2019-15903. > > Note that IceCat 68 has not yet been released by the IceCat project. > This is a work-in-progress, and may not currently meet the > privacy-respecting standards of the IceCat project. > > I encourage you all to try it and report back with your experiences. > > Thanks, >Mark > Nice, thank you for maintaining IceCat for us! Only if the browser itself could get more contributors and the web technologies wouldn't be that bloated... If Mozilla dies completely, someone could make a GNUNet browser using Guile instead of HTML, CSS and JS - a browser where programs are data, that would be fun. Jan Wielkiewicz
Jami doesn't start libring on external distributions
Hello,
I don't know why, but my Jami package works properly only on Guix
System and fails on other distributions, for example Parabola. [1]
There's a comment in jami's package definition (jami):
(propagated-inputs
`(("libring" ,libring) ; Contains `dring', the daemon, which is
automatically by d-bus.
So it seems dbus doesn't start libring on external distributions.
Any ideas what can be the cause and how to fix it?
[1] https://lists.gnu.org/archive/html/help-guix/2020-07/msg00168.html
Jan Wielkiewicz
arm-none-eabi-toolchain fails to build, solution?
Hello, arm-none-eabi-toolchain fails to build as I reported here: https://issues.guix.gnu.org/42561 As you can see in the issue I kinda fixed compilation by changing gcc's version to 7, but I'm not sure if it's just a dirty hack or the right solution. Can someone take a look at it? Jan Wielkiewicz
Jami: Status update
Hello, I decided no to push my Jami from git version, because I discovered it lacks the typing indicator functionality from an unknown to me reason (maybe some dependencies are bundled in tarballs). Additionaly I got my code reviewed and therefore need some more time to make my commits more stand alone (didn't know it was the case). But I made a smaller, better patch set containing only the necessary changes to make Jami working and up to date, until I discover why the typing indicator is not there and clean up the mess. Question: Is it normal all changes should be stand alone? Guix is my first project I contribute to and first project I work on generally. It wasn't documented in the manual, is it buried somewhere in the coding standards? Jan Wielkiewicz
Re: Jami: Updating opendht needed
Hello, Dnia 2020-07-11, o godz. 14:49:58 Pierre Neidhardt napisał(a): > In this case the common procedure is to add a (non-public) > opendht-jami package at the right commit. > > This package can then safely be deleted when the next version of > opendht comes out. > > Cheers! > I made a patch already. https://lists.gnu.org/archive/html/guix-patches/2020-07/msg00283.html It seems opendht is just buggy there, as using one of its features causes compilation error, so I think it is okay to patch the bug. What's the point of keeping unusable software in the repo anyway? Devs from Savoir-faire linux use opendht features in Jami right from master, because they develop both. But I can't do that. Jan Wielkiewicz
Re: Jami: Updating opendht needed
Hello, Jami devs helped me - it turns out opendht 2.1.4 contains a bug, which was fixed on master. I can either wait for the next version where it works or add the commit fixing the bug as a patch. Opendht in Jami was bumped though, I can't downgrade in my wip. What do you think? Jan Wielkiewicz
Re: Jami: Updating opendht needed
Hello, Seems opendht is fine, but Jami just fails during compilation. Reported the issue here: https://git.jami.net/savoirfairelinux/ring-daemon/issues/261 It seems they build their package with meson now, but libring requires meson 0.54 or higher. Tried upgrading it quickly and dirty but glib or glibc failed to compile. I can't do anything until developers fix this or someone bumps meson, sorry. Jan Wielkiewicz
Jami: Updating opendht needed
Hello, I need someone to push this commit: https://lists.gnu.org/archive/html/guix-patches/2020-07/msg00226.html From this version, my toaster can't build opendht anymore and I'm stuck on Fedora on my newer now, where I have no Guix available. Can someone check if it compiles and push, so I can get back to working on Jami? The latest Jami version requires opendht 2.1.4. Jan Wielkiewicz
Re: Jami bug source investigation #4
Hi, I sent the patches to the mailing list. They should be soon available here: https://lists.gnu.org/archive/html/guix-patches/2020-07/msg00153.html Jan Wielkiewicz
Re: Jami bug source investigation #4
Nevermind, I've managed to write *I hope good commit messages*. Do not commit the fix yet, I will send all patches tomorrow. Jan Wielkiewcz
Re: Jami bug source investigation #4
Hi, On Sun, 05 Jul 2020 21:29:33 +0100 Christopher Baines wrote: > > So, I tried adding -DNDEBUG to the CFLAGS bit of the > #:configure-flags, and the package built. Testing it out seems to > work, I think I've experienced this issue with assertion failures, so > hopefully this will help. > > modified gnu/packages/jami.scm > @@ -141,7 +141,7 @@ > ;; against pjproject-jami: > ;; relocation R_X86_64_32S against `.rodata' can not > be used when ;; making a shared object; > - "CFLAGS=-fPIC" > + "CFLAGS=-fPIC -DNDEBUG" > "CXXFLAGS=-fPIC") > #:phases > (modify-phases %standard-phases > > Is there more to applying this fix, or will this change alone help? > I'm more than happy to review patches. > > Thanks, > > Chris That's it for the bug, if you want to have it fixed quickly, feel free to commit it. I didn't do it yet, because I'm busy writting commit messages for my refactored and updated package definitions. I'm also trying to catch up with the latest Jami version - they fixed some annoying stuff too. Is there a script for automatically writing commit messages compliant with the GNU coding standards? Jan Wielkiewicz
Re: Installer script on Fedora doesn't work properly
On Tue, 30 Jun 2020 14:07:44 +0200 Ricardo Wurmus wrote: > > Hi Jan, Hi! > > This means the daemon isn’t running. > > If you use SELinux in enforcing mode then the daemon is probably > prevented from starting. I'm not aware of this - I just picked all default settings, not that the choice was big. > > Sure. We have a draft SELinux policy for systems like yours, but it > is probably no longer current as Fedora’s SELinux policy is not > frozen in time. I encourage you to try it and help debug it to > adjust it for current versions of Fedora. That's my first day running Fedora, but if someone gives me right directions, I can help. > > These recommendations wouldn’t help in your case. We can’t feasibly > maintain a farm of different distros (some with SELinux and some > without) where we install Guix all the time. > Even manual testing before making a release would be good. Btw adding checkboxes to the issue tracker would make it easier for everyone. Anyway, Guix should work on disributions considered to be "industry standard" such as Debian, Fedora, etc. What about a list of distributions Guix was tested on in the manual, with a link to it somewhere on the main page. The first impression is really important. Jan Wielkiewcz
Installer script on Fedora doesn't work properly
Hello, I'm trying to install Guix on Fedora using the install script, but something is not right. I ran the script as root, it installed everything properly, but running "guix pull" ends up with an error message: "guix pull: failed to connect to `/var/guix/daemon-socket/socket': No such file or directory". I tried rebooting a few times, running "systemctl enable guix-daemon", "systemctl start guix-daemon", but with the same result. Any idea what's wrong? I think the installer script should *just work at all times* - this is crucial to make Guix popular on other distros. My suggestion: if it's not already done, consider adding automated tests, checking whether the installer script works on major distributions (on a VM) and if Guix works there. This should be checked every release. P.S. I'm going to resume my work on Jami soon, I've been busy with my exams lately :P Jan Wielkiewicz
Re: Jami bug source investigation #4
On Mon, 22 Jun 2020 09:32:50 +0200 Pierre Neidhardt wrote: > Great! Does this fix any other issue? > Does it warrant a package upgrade in Guix? > This alone didn't fix the problem, but as no other possibility was left than broken pjproject, I tried to fix it and succeeded. It is mandatory to pass "-DNDBUG" flag to turn off assertion. https://trac.pjsip.org/repos/wiki/FAQ#Performance https://trac.pjsip.org/repos/wiki/FAQ#assert "Release mode. Don't forget to set the appropriate compiler optimization flag, and disable assertion with -DNDEBUG." This surely fixes the bug the reason of I was chasing for several months, where after disconnecting from audio call, the daemon "crashed" (asserted). It is also possible this fixes some other issues with SIP, I didn't test, because I was uninterested. I'll prepare my messy code for committing once I have more time. I'm not sure whether I should fetch from git or use a tarball after doing all this work. Fetching from git adds more complexity to the packages, but it gives me more control over it plus I'm not sure if I can trust the tarballs anymore, after two cases where some files/folders were missing. Once I'll send the patches, would be cool if someone tested it. Jan Wielkiewicz
Re: Jami bug source investigation #4
Nevermind, I resolved the issue. Jami built from git repository instead of from tarball didn't fix the bug with audio call. Jan Wielkiewicz
Re: Jami bug source investigation #4
Hello, it turns out there is a directory in libringclient package - include/libringclient/web-chatview and it contains the missing files, including the "web.gresource.xml" make and configure complain about. I need to copy the files from include/libringclient/web-chatview of libringclient package to source/web/ of jami package. How do I do this? I tried using modify-phases and just copying the files, but it fails in the same manner, while in the build directory obtained using "--keep-failed", there are only links to the files. Jan Wielkiewicz
Packaging audacious
Hello, I'm trying to package the audacious music player, but I encountered a problem - in the source directory there are libraries used by audacious that is: libaudgui, libaudtag, audtool, libaudcore, libaudqt and libguess. When build without modifying the source, I get the following error: validating RUNPATH of 3 binaries in "/gnu/store/6ihw9w6ibs33k6v9dyqxblddwdvyx11m-audacious-3.10.1/lib"... /gnu/store/6ihw9w6ibs33k6v9dyqxblddwdvyx11m-audacious-3.10.1/lib/libaudgui.so: error: depends on 'libaudcore.so.5', which cannot be found in RUNPATH So I tried decoupling it, by making libaudcore package, packaging libguess and adding it as libaudcore's input, but it still wants to have the file there: g++: error: ../libguess/libguess.a: No such file or directory Failed to link libaudcore.so! How to do this correctly? P.S. Still waiting for pjproject in Jami to be bumped, they're also fixing some annoying bugs. Jan Wielkiewicz
Re: Maintaining Jami #4
Dnia 2020-02-17, o godz. 18:42:05 Pierre Neidhardt napisał(a): > What you need to do is the following: > > - Create an empty repo on GitLab. > - In your local checkout of Guix, add your GitLab repository as a Git > remote. > - Push to your GitLab repository. > - Create a wip-jami branch and commit your changes there. > - Whenever you want to update "master", simply "git fetch --all" then > rebase your wip-jami onto origin/master. > > Let me know if you want more details. > I guess that's it, here's my most up-to-date work: https://gitlab.com/kromka_chleba/jami-package-and-other-things-for-guix/ Now I must set up a channel and check how it behaves. Jan Wielkiewicz
Re: Maintaining Jami #4
On Mon, 17 Feb 2020 17:46:39 +0100 Pierre Neidhardt wrote: > What do you mean? Can you provide an example? > For example on notabug there was an option to make a mirror of existing repository, so I just pasted there: "https://git.savannah.gnu.org/git/guix.git; and it made a mirror I could work with. On gitlab I didn't see such an option, so I just initialized a fresh git repository and I would like to replace this repository with my clone of Guix with Jami changes. Jan Wielkiewicz
Re: Packaging pjproject
Dnia 2020-01-31, o godz. 18:12:07 Pierre Neidhardt napisał(a): > To be more specific, I have never touched pjproject. Sorry, didn't know that. > I was the 4th person so work on the Jami patch and I fixed pjproject-jami. > I sadly have no experience with pjproject beyond that. Now thats scary :D pjproject is a ghost package. I can try nagging people on pjproject mailing list, but don't know, if I'm up to the task. What should I ask them? "How to build pjproject without running make dep" or "Can I build pjproject using system libraries"? Should I learn more about build systems to be able to fix this, or is it implementation-dependent? My experience with packaging so far tells me there is no standard for build systems and every package is different. Jan Wielkiewicz
Re: Packaging Jami progress
I managed to debug jami client properly, the cause of the gdb error was
the "jami-gnome" file, which is acutally just a bash script, exporting
the path:
#!/gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/bash
export
LD_LIBRARY_PATH="/gnu/store/dha6b5g3kjqw2vfdbhv43sfnpa5d0m5v-sqlite-with-column-metadata-3.28.0/lib${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH"
exec -a "$0"
"/gnu/store/ab4wy29g68vgvcjv1x54bm4yklrvbw2q-jami-20191224.1.5c0154a/bin/.jami-gnome-real"
"$@"
I had to paste the export line before debugging using gdb, and
everything went well. I'm confused with this. Is it also the reason of
the bug, from Pierre's comment? I think we should probably get rid of
"jami-gnome" file. My brain is spaghetti now, thanks to this error :P
Jan Wielkiewicz
Re: Packaging Jami progress
Dnia 2019-12-27, o godz. 21:32:10 Gábor Boskovits napisał(a): > Hello Jan, > > Thanks for working on this. Jami is really painful to package :D > > You should look for packages with debug output. That is the way the > debugging symbol files are generated > for a package. Currently not too many packages define it, but from an > example you can easily find out how to > include that into the interesting package. You can find further > infomation here: > https://guix.gnu.org/manual/en/html_node/Installing-Debugging-Files.html > Tried adding some configure flags for enabling debugging, but it seems it's not the cause. But there's a comment, I guess Pierre left, showing a similar error: ;; TODO: We must wrap ring-client-gnome to force using the ;; `sqlite-with-column-metadata' package instead of `sqlite' or else it ;; fails with: ;; ;; /gnu/store/...-qtbase-5.11.2/lib/qt5/plugins/sqldrivers/libqsqlite.so: ;; undefined symbol: sqlite3_column_table_name16 ;; ;; qtbase is built against sqlite-with-column-metadata but somehow ;; jami-client-gnome ends up with both `sqlite' and ;; `sqlite-with-column-metadata' as inputs and it seems that ;; libqsqlite.so gets confused. I have no idea what does it means though. Could someone explain to me what needs to be done in *simple language* please? > > Best regards, > g_bor Jan Wielkiewicz
Re: Packaging Jami progress
Tested Jami with gnutls 3.6.10, but I get the same bug. I reported it to Jami developers, but they can't reproduce the bug. Here's more info, if anyone has any idea what could be the cause, then please tell me: https://git.jami.net/savoirfairelinux/ring-client-gnome/issues/1123 I need to find out what's wrong with our package. How do I debug something on Guix System? I used "guix environment guix", then "./pre-inst-env guix environment jami --ad-hoc gdb", then after running gdb and passing the proper path to it and pressing "r", it displays the following error: Reading symbols from /gnu/store/30jjbf7jkddw6z679c0h8zvifwaaakn0-jami-20191224.1.5c0154a/bin/.jami-gnome-real... (No debugging symbols found in /gnu/store/30jjbf7jkddw6z679c0h8zvifwaaakn0-jami-20191224.1.5c0154a/bin/.jami-gnome-real) (gdb) r Starting program: /gnu/store/30jjbf7jkddw6z679c0h8zvifwaaakn0-jami-20191224.1.5c0154a/bin/.jami-gnome-real [Thread debugging using libthread_db enabled] Using host libthread_db library "/gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/lib/libthread_db.so.1". [New Thread 0x7fffee145700 (LWP 4795)] [New Thread 0x7fffed944700 (LWP 4796)] ** Message: 19:45:55.037: Jami GNOME client version: 501cb99929f171ede62a96c675d51ffe0581ce5c ** Message: 19:45:55.038: git ref: unknown [New Thread 0x7fffeca91700 (LWP 4797)] No migration required /gnu/store/30jjbf7jkddw6z679c0h8zvifwaaakn0-jami-20191224.1.5c0154a/bin/.jami-gnome-real: symbol lookup error: /gnu/store/371gzl7v7c8p0waasm4kwkalvgqmskav-qtbase-5.12.6/lib/qt5/plugins/sqldrivers/libqsqlite.so: undefined symbol: sqlite3_column_table_name16 [Thread 0x7fffeca91700 (LWP 4797) exited] [Thread 0x7fffed944700 (LWP 4796) exited] [Thread 0x7fffee145700 (LWP 4795) exited] [Inferior 1 (process 4789) exited with code 0177] (gdb) Jan Wielkiewicz
Re: Packaging Jami progress
Dnia 2019-12-15, o godz. 22:46:06
Ricardo Wurmus napisał(a):
> The test appears to compare the hash of this file with the hash of a
> known good file. What are the contents? Can we adjust the test to
> test for what is actually of interest here?
>
> Otherwise it should be fine to disable it.
>
Okay, I haven't got any answer from the devs so far and I'm looking for
a way of disabling only the test that fails.
I tried to use substitute* to remove
"include $(SRC_PATH)/tests/fate/lavf-container.mak"
from the tests/Makefile, but it didn't work (don't know why) and tried
removing "FATE_LAVF_CONTAINER-$(call ENCDEC2, MPEG4, PCM_ALAW,
MOV)+= mov mov_rtphint ismv"
and
"fate-lavf-mov_rtphint: CMD = lavf_container "" "-movflags +rtphint
-c:a pcm_alaw -c:v mpeg4 -threads 1 -f mov""
from the "tests/fate/lavf-container.mak" file.
The fragment of code I wrote looks like this:
(add-before 'check 'skip-test
(lambda _
(substitute* "tests/Makefile"
(("include $(SRC_PATH)/tests/fate/lavf-container.mak")
"")) #t))
I also made the git checkout writeable.
Am I doing something wrong? Should I try deleting the test using
snippet or just skip all tests using #:tests? #f?
Jan Wielkiewicz
Re: Packaging Jami progress
On Sun, 15 Dec 2019 22:46:06 +0100 Ricardo Wurmus wrote: > Hi Jan, > > The test appears to compare the hash of this file with the hash of a > known good file. What are the contents? Can we adjust the test to > test for what is actually of interest here? > > Otherwise it should be fine to disable it. > Actually I have no idea, I downloaded the source code now and I couldn't even find the file, the closest one was "lavf-mov", but its contents doesn't look human-readable. I'll better ask Jami devs about it. Jan Wielkiewicz
Re: Packaging Jami progress
Forgot to add the error file. Here it goes. Jan Wielkiewicz lavf-mov_rtphint.err Description: Binary data
Re: Packaging Jami progress
Hi all, I made some progress with applying patches for dependencies. The function works now, I use it with pjproject-jami correctly. Tried luck with ffmpeg-jami, the compilation process works, but one test fails: TESTlavf-mkv_attachment TESTlavf-mov TESTlavf-mov_rtphint --- ./tests/ref/lavf/mov_rtphint1970-01-01 00:00:01.0 + +++ tests/data/fate/lavf-mov_rtphint 2019-12-15 20:04:09.880137614 + @@ -1,3 +1,3 @@ -7014419d8267c2751314303a8fb303c1 *tests/data/lavf/lavf.mov_rtphint -366449 tests/data/lavf/lavf.mov_rtphint +872f923297706823384923086147e2b4 *tests/data/lavf/lavf.mov_rtphint +370877 tests/data/lavf/lavf.mov_rtphint tests/data/lavf/lavf.mov_rtphint CRC=0xbb2b949b Test lavf-mov_rtphint failed. Look at tests/data/fate/lavf-mov_rtphint.err for details. make: *** [tests/Makefile:241: fate-lavf-mov_rtphint] Error 1 make: *** Waiting for unfinished jobs Could it be changing the date we do in Guix makes a test fail? Any ideas what could be wrong? Sould I skip the test? Jan Wielkiewicz
Re: Packaging Jami progress
Hi!
I tried both ways - the second works, but the first doesn't.
That's what I have in the file - if I didn't miss something, it is the
same as your example:
#:imported-modules (,@(source-module-closure
'((gnu packages jami)
,@%gnu-build-system-modules)))
#:modules ((gnu packages jami)
,@(@@ (guix build-system gnu) %default-modules))
And I get an ugly backtrace (could this be a bug or am I doing
something wrong?):
The following derivations will be built:
/gnu/store/xf6b58rlki7sb3k9fj2dxkm4ljiypdc0-pjproject-jami-2.9.drv
/gnu/store/aaqaz52fhjb86g233ar4ynnyjvrv7xa7-module-import-compiled.drv
building
/gnu/store/aaqaz52fhjb86g233ar4ynnyjvrv7xa7-module-import-compiled.drv...
Backtrace: In ice-9/eval.scm:
721:20 19 (primitive-eval _)
In ice-9/psyntax.scm:
1262:36 18 (expand-top-sequence _ _ _ #f _ _ _)
1209:24 17 (parse _ (("placeholder" placeholder)) ((top) #(# # ?)) ?)
285:10 16 (parse _ (("placeholder" placeholder)) (()) _ c (eval) ?)
In ice-9/eval.scm:
293:34 15 (_ #)
In ice-9/boot-9.scm:
2874:4 14 (define-module* _ #:filename _ #:pure _ #:version _ # _ ?)
2887:24 13 (_)
222:29 12 (map1 _)
222:29 11 (map1 _)
222:29 10 (map1 _)
222:29 9 (map1 _)
222:29 8 (map1 _)
222:29 7 (map1 (((guix monads)) ((guix records)) ((guix #)) (#) ?))
222:29 6 (map1 (((guix records)) ((guix base16)) ((guix #)) (#) ?))
222:29 5 (map1 (((guix base16)) ((guix base32)) ((gcrypt #)) # ?))
222:29 4 (map1 (((guix base32)) ((gcrypt hash)) ((guix #)) (#) ?))
222:17 3 (map1 (((gcrypt hash)) ((guix profiling)) ((rnrs #)) # ?))
2803:6 2 (resolve-interface _ #:select _ #:hide _ #:prefix _ # _ ?)
In unknown file:
1 (scm-error misc-error #f "~A ~S" ("no code for modu?" ?) ?)
In ice-9/boot-9.scm:
752:25 0 (dispatch-exception _ _ _)
ice-9/boot-9.scm:752:25: In procedure dispatch-exception:
no code for module (gcrypt hash)
builder for
`/gnu/store/aaqaz52fhjb86g233ar4ynnyjvrv7xa7-module-import-compiled.drv'
failed with exit code 1
Any ideas?
> Hope that helps, thanks for the work on Jami y'all!
No problem.
Dnia 2019-12-10, o godz. 09:59:40
Caleb Ristvedt napisał(a):
> #:modules and #:imported-modules are distinct arguments. #:modules is
> the modules that your builder is going to use (as in "they go in a
> (use-modules ...) form"), while #:imported-modules is the modules
> that need to be available
> in the build environment. It's complaining at build-time that it
> can't find that
> module to use, because you haven't told it to include that module in
> the build
> environment. #:imported-modules should give a superset of what
> #:modules gives,
> especially if a module in use is going to have indirect
> requirements. Thankfully, wrangling together those indirect
> requirements is already implemented in (guix modules) as
> source-module-closure.
>
> Thus, you could conceptually do
>
>
> (arguments
> `(#:imported-modules (,@(source-module-closure
> '((gnu packages jami)
> ,@%gnu-build-system-modules)))
>#:modules ((gnu packages jami)
> ,@(@@ (guix build-system gnu) %default-modules
>
> And in theory it would work. Note, though, that this would pull in the
> entire
> module dependency graph of (gnu packages jami), and this may include
> things that
> source-module-closure would have a hard time detecting and aren't
> really needed. Ideally this procedure would be generalized and put in
> (guix build ), but I can understand if that's not
> possible. Note also that you
> could simply splice in the definition of your procedure into the
> builder manually, like so:
>
> (define my-procedure-code '(lambda (a b c) ...))
>
> (arguments
> `(#:phases (let ((my-procedure ,my-procedure-code)) (modify-phases
> ...
>
> Hope that helps, thanks for the work on Jami y'all!
Jan Wielkiewicz
Re: Packaging Jami progress
Dnia 2019-12-05, o godz. 15:32:23
Pierre Neidhardt napisał(a):
> - To call a custom function from the builder, you need to include the
> module that defines it for the build system, e.g.
>
> (arguments
> `(#:modules ((gnu packages telephony)
> ,@%gnu-build-system-modules)
> ...)
>
Tried luck with the procedure, but it seems I can't provide the module
I'm currently in to the "arguments" field - Guile said it couldn't find
code for the module: "no code for module (gnu packages jami)". I mean
in the jami.scm file, defining (gnu packages jami) module,
I can't give this module as an argument.
(arguments
`(#:modules ((gnu packages jami)
,@%gnu-build-system-modules)
...)
By the way, I decided to move all Jami packages, procedures and
dependencies modified by the patches to a separate file -
jami.scm. It'll be much easier to maintain in this way.
The full error message:
The following derivation will be built:
/gnu/store/an28ny48d6iyfn79j2fhqk7mvd6jmahq-pjproject-jami-2.9.drv
building
/gnu/store/an28ny48d6iyfn79j2fhqk7mvd6jmahq-pjproject-jami-2.9.drv...
Backtrace: 10 (primitive-load "/gnu/store/dj185gjiag94gk1clrj0158xcal?")
In ice-9/eval.scm:
721:20 9 (primitive-eval (begin (use-modules (gnu # jami) # ?) ?))
In ice-9/psyntax.scm:
1262:36 8 (expand-top-sequence ((begin (use-modules (gnu ?) ?) ?)) ?)
1209:24 7 (parse _ (("placeholder" placeholder)) ((top) #(# # ?)) ?)
1209:24 6 (parse _ (("placeholder" placeholder)) ((top) #(# # ?)) ?)
285:10 5 (parse _ (("placeholder" placeholder)) (()) _ c (eval) ?)
In ice-9/boot-9.scm:
3377:20 4 (process-use-modules _)
222:17 3 (map1 (((gnu packages jami)) ((guix build #)) ((# ?)) ?))
3378:31 2 (_ ((gnu packages jami)))
2803:6 1 (resolve-interface _ #:select _ #:hide _ #:prefix _ # _ ?)
In unknown file:
0 (scm-error misc-error #f "~A ~S" ("no code for modu?" ?) ?)
ERROR: In procedure scm-error:
no code for module (gnu packages jami)
Is there some kind of "this" for the module in guile I could use in
order to be able to invoke the jami-apply-dependency-patches procedure?
I exported it correctly using #:export (jami-apply-dependency-patches).
Jan Wielkiewicz
Re: Packaging Jami progress
Dnia 2019-12-04, o godz. 18:01:39 Pierre Neidhardt napisał(a): > Can you share your current patch of the whole thing? > Here you go. jami-patches-04-12-2019.tar.bz2 Description: application/bzip
Re: Packaging Jami progress
Dnia 2019-12-04, o godz. 16:27:26 Pierre Neidhardt napisał(a): > You need to export the symbol. > To do so, you can either specify the symbol in the #:export part of > the module at the top of the file, or simply use `define-public` when > defining the variable. Okay, thanks. > Can you give an example? I don't understand what you mean. I would like to have something like this: (define-public jami-apply-dependency-patches (lambda* (#:key inputs patches dependency-name #:allow-other-keys) (let ((savoir-faire-linux-patches-directory "Savoir-faire Linux patches")) (mkdir-p savoir-faire-linux-patches-directory) (invoke "tar" "-xvf" (assoc-ref inputs "savoir-faire-linux-patches") "-C" savoir-faire-linux-patches-directory "--strip-components=5" (string-append "ring-project/daemon/contrib/src/" dependency-name)) (for-each (lambda (file) (invoke "patch" "--force" "-p1" "-i" (string-append savoir-faire-linux-patches-directory "/" file ".patch"))) patches)) #t)) And then invoke it like this (add-after 'unpack 'apply-patches (jami-apply-dependency-patches #:dependency-name "pjproject" #:patches '(*the list*) #:inputs inputs) I know it's a bit vague, don't really know what happens here with this lambda*. I would like to pass some arguments there, but if I understand this correctly, Guix does it for me - I give it a procedure and it executes it. Thanks in advance Jan Wielkiewicz
Re: Packaging Jami progress
re-linux-patches))
#t)
The question is - if I defined a procedure named "jami-apply-patches" or
whatever, will importing it using #:use-module (gnu packages telephony
jami-apply-patches) work, or do I need to explicitly export it?
Also how to add such procedure to the "add-after" field without causing
an error?
Jan Wielkiewicz
Re: Packaging Jami progress
Hello, I started working on updating Jami to the latest version and it seems it needs libnatpmp, because without it, compilation fails during doing something connected to UPnP. For that purpose I started packaging libnatpmp, but during the "install" stage, it fails with the following error: starting phase `install' install -p -d /usr/include install: cannot create directory ‘/usr’: Permission denied make: *** [Makefile:95: install] Error 1 command "make" "install" "prefix=/gnu/store/rn7h6irrjfcd5w2s7a1clrq91g8jxjhl-libnatpmp-20150609" failed with status 2 I tried chmoding and making files writable, but it didn't work or I did something wrong. Here's the sketch of the package: (define-public libnatpmp (package (name "libnatpmp") (version "20150609") (source (origin (method url-fetch) (uri (string-append "http://miniupnp.free.fr/files/; name "-" version ".tar.gz")) (sha256 (base32 "1c1n8n7mp0amsd6vkz32n8zj3vnsckv308bb7na0dg0r8969rap1" (build-system gnu-build-system) (arguments `(#:phases (modify-phases %standard-phases (delete 'configure) (delete 'check)) #:make-flags (list (string-append "prefix=" (assoc-ref %outputs "out") (home-page "http://miniupnp.free.fr/libnatpmp.html;) (synopsis "C Library implementing NAT-PMP") (description "libnatpmp is a portable and asynchronous implementaiton of the NAT Port Mapping Protocol (NAT-PMP) written in C.") (license license:bsd-3))) How do we deal with problems like these? I checked the makefile and it doesn't seem to have the "/usr" path hardcoded - it has the $(PREFIX) variable. Jan Wielkiewicz
Re: Packaging Jami progress
Dnia 2019-11-11, o godz. 09:38:49 Pierre Neidhardt napisał(a): > Jan Wielkiewicz writes: > > > Okay, I did the first one and I'm attaching the patches again, hope > > this time it'll work. > > It worked, thanks! > > > I am going to apply your patch for restinio and try to get Jami to > > work this weekend. > > OK, let me know how it goes and don't hesitate to ask for help! I fixed some small problems since then: I added a newer version of curl, because the build of something failed with an old version (didn't change the main package though, because I didn't want to break something); I removed restbed from the list of dependencies of opendht and libring; I updated gstreamer to the version not requiring the security patch anymore (1.16.1) and updated the gst-plugins-base to 1.16.1. Is it normal guix ran from "./pre-inst-env" builds everything from the source code? I ran "./pre-inst-env guix build jami --cores=2 --max-jobs=2" and Guix started to build webkitgtk, even though the substitute is available. Or did I change something that causes webkit to get rebuild. This made checking if Jami builds properly not possible, because my machine has only 3,1 GB of RAM. I could set up Guix on my second, more powerfull machine, but last time I tried, the installer script didn't work on Devuan. I don't know if it's a bug, or is the system not supported. I could install Guix System there, but the machine is highly proprietary and Guix isn't yet fully ready for the desktop use for me (not every package I use, including Jami, is available yet). But I suppose Jami will work this time, there's not much (or nothing) to fix now. I'm attaching all patches, including the most recent. > Good luck! > Thanks, Jan Wielkiewicz jami-wip-11-11-2019.tar.bz2 Description: application/bzip
Re: Packaging Jami progress
Dnia 2019-11-07, o godz. 21:37:52 Pierre Neidhardt napisał(a): > I think you produced the patchset against the wrong commit. > Try > > git format-patch origin > > or > > git format-patch LAST-UPSTREAM-COMMIT Okay, I did the first one and I'm attaching the patches again, hope this time it'll work. > where you replace LAST-UPSTREAM-COMMIT as appropriate. > > A pitfall is to write > > git format-patch YOUR-FIRST-COMMIT > > then you'd omit your first commit, which is probably what happened. > > > I also ran a strange command - "git cherrypick", when I was trying > > to figure out how to patch my commits. > > Git cherrypick allows you to apply specific commits on top of the > current HEAD. Good to know, thanks. I am going to apply your patch for restinio and try to get Jami to work this weekend. Jan Wielkiewicz jami-wip-08.11.2019.tar.bz2 Description: application/bzip
Re: Packaging Jami progress
Dnia 2019-11-07, o godz. 20:02:08
Pierre Neidhardt napisał(a):
> Hi Jan,
>
> Here is a quick 'n' dirty restinio package:
Cool, thanks!
>
> The CMakeLists are a bit convoluted, so I simply skipped the root one
> and when straight into the restinio subfolder.
>
> I'm too lazy to figure out how to run the tests at the moment.
As far as it works, we can skip this now. All I need is compiling Jami,
then I'll improve the quality of the package definitions.
>
> Note: the comma "," in Scheme means it "unquotes" the following
> expression, and thus the space must be put before it, not after.
>
> Wrong:
>
> ("boost", boost)
>
> Correct:
>
> ("boost" ,boost)
Right, this explains a lot. This is my brain and Scheme - I actually
read what it is and how it works, I use it in guile repl, but somehow
my brain had treated this comma as if it was C++.
Same thing with the fancy version of the Cookbook :)
>
> Cheers!
>
Thanks for everything, I'll check how it works with the Jami package
tomorrow.
Jan Wielkiewicz
Re: Packaging Jami progress
Dnia 2019-11-07, o godz. 20:10:01 Pierre Neidhardt napisał(a): > Jan, can you resend the your patch set, I think you forgot a commit. > The first patch does not apply, in particular this hunk: > > --8<---cut here---start->8--- > ;; Things we don't need: > ;; BaseClasses - contains libraries from Windows > SDK ;; we don't need it, at least not now. > - (list "BaseClasses" "bin" "g7221" "ilbc" "milenage" > + (list "BaseClasses" "g7221" "ilbc" "milenage" > "speex" "threademulation" "yuv" "bdsound" > - "gsm" "lib" "mp3" "resample" "srtp" "webrtc" > + "gsm" "mp3" "resample" "srtp" "webrtc" > ;; Keep only resample, build and README.txt. > "build/baseclasses" "build/g7221" "build/gsm" > "build/ilbc" "build/milenage" > "build/resample" --8<---cut > here---end--->8--- > > Cheers! > I sent everything I had, so don't know what's wrong. Can we skip this now and I'll make a new commit (don't know how intelligent git is)? There's a chance I modified and something, then ran "git checkout previous_commit_number", and then commited, but I'm not sure, since this is the first time I use git for something other than "git clone". I also ran a strange command - "git cherrypick", when I was trying to figure out how to patch my commits. Jan Wielkiewicz
Re: Packaging Jami progress
Dnia 2019-11-06, o godz. 11:30:19 Pierre Neidhardt napisał(a): > If you are still stuck, share your progress for restinio, I'll give > it a shot! :) > Yes please, I didn't have time nor knowledge to finish this. Let me know if you'll fix this. I also have to reread the packaging tutorial, because last time I checked it wasn't that fancy as the current one in the cookbook is. I send all patches, because I'm not a git wizard yet. Do I have to add copyright lines or something? Of course I license my work under the GPL v3 or any later as the project uses. Jan Wielkiewicz jami-patches-wip-06.11.2019.tar.bz2 Description: application/bzip
Re: Packaging Jami progress
Dnia 2019-11-04, o godz. 23:48:00
Gábor Boskovits napisał(a):
> Hello,
>
> This is most probably because fmt is missing from inputs.
> > This is because SObjectizer is missing from inputs.
> You can get further info about this in the cmake file:
> https://github.com/Stiffstream/restinio/blob/master/dev/CMakeLists.txt
I packaged SObjectizer and placed it in the gnu/packages/cpp.scm file.
I also added SObjectizer and fmt as inputs, but the result is the same,
even though I tried removing commands, which add the subdirectories
from CMakeLists.txt. What's the proper way of dealing with situations
like this? Am I missing something important? Should I copy outputs of
fmt and sobjectizer into the directories? If so, how can I do this?
(add-after 'unpack 'do-not-make-directories
(lambda _
(substitute* "dev/CMakeLists.txt"
(("add_subdirectory(fmt)")
"") (("add_subdirectory(so_5)") ""))
#t))
>
> This does not seem the upstream repo. Could you change it to the
> upstream one? (Albeit, it seems to be an official mirror.)
> (https://bitbucket.org/sobjectizerteam/restinio/src/default/)
> Or if there is a tarball available for the needed version, that would
> be even better (
>
> https://bitbucket.org/sobjectizerteam/restinio/downloads/), but I
> don't know if these archives are stable.
On the website, they say the software is hosted on github:
https://stiffstream.com/en/products/restinio.html
Also AFAIK git is always reproducible, whereas tarballs can get
rebuilt, so fetching using git is safer.
Jan Wielkiewicz
Packaging Jami progress
Hello everyone,
With some help from both you and Jami developers, I finally managed
to build pjproject-jami, which means the hardest task has been
already done! Now I have to package restinio, which replaced restbed in
Jami. I have already a sketch of the package, but I encountered a
problem I don't really know the meaning nor know how to fix it:
CMake Error at CMakeLists.txt:84 (add_subdirectory):
add_subdirectory given source "fmt" which is not an existing directory.
-- Found OpenSSL:
/gnu/store/k2m4q2av9hw73hw2jx6qrxqdyh855398-openssl-1.1.1c/lib/libcrypto.so
(found version "1.1.1c")
OpenSSL include dir:
/gnu/store/k2m4q2av9hw73hw2jx6qrxqdyh855398-openssl-1.1.1c/include
OpenSSL libraries:
/gnu/store/k2m4q2av9hw73hw2jx6qrxqdyh855398-openssl-1.1.1c/lib/libssl.so;/gnu/store/k2m4q2av9hw73hw2jx6qrxqdyh855398-openssl-1.1.1c/lib/libcrypto.so
-- Found PCRE:
/gnu/store/5j6w0x3aq0i5r9565w92lrh016vlmv2d-pcre-8.43/lib/libpcre.so
--
PCRE_LIBRARIES='/gnu/store/5j6w0x3aq0i5r9565w92lrh016vlmv2d-pcre-8.43/lib/libpcre.so'
--
PCRE_INCLUDE_DIRS='/gnu/store/5j6w0x3aq0i5r9565w92lrh016vlmv2d-pcre-8.43/include'
-- Found PCRE2:
/gnu/store/4jmnzz60hrm7k1lmn4565sh7xh447q1z-pcre2-10.33/lib/libpcre2-8.so
--
PCRE2_LIBRARIES='/gnu/store/4jmnzz60hrm7k1lmn4565sh7xh447q1z-pcre2-10.33/lib/libpcre2-8.so'
--
PCRE2_INCLUDE_DIRS='/gnu/store/4jmnzz60hrm7k1lmn4565sh7xh447q1z-pcre2-10.33/include'
--
PCRE2_LIBRARIES='/gnu/store/4jmnzz60hrm7k1lmn4565sh7xh447q1z-pcre2-10.33/lib/libpcre2-8.so'
--
PCRE2_INCLUDE_DIRS='/gnu/store/4jmnzz60hrm7k1lmn4565sh7xh447q1z-pcre2-10.33/include'
CMake Error at CMakeLists.txt:124 (add_subdirectory):
add_subdirectory given source "so_5" which is not an existing directory.
-- Found ZLIB:
/gnu/store/qx7p7hiq90mi7r78hcr9cyskccy2j4bg-zlib-1.2.11/lib/libz.so (found
version "1.2.11")
--
ZLIB_LIBRARIES='/gnu/store/qx7p7hiq90mi7r78hcr9cyskccy2j4bg-zlib-1.2.11/lib/libz.so'
--
ZLIB_INCLUDE_DIRS='/gnu/store/qx7p7hiq90mi7r78hcr9cyskccy2j4bg-zlib-1.2.11/include'
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Check if compiler accepts -pthread
-- Check if compiler accepts -pthread - yes
-- Found Threads: TRUE
-- Configuring incomplete, errors occurred!
See also
"/tmp/guix-build-restinio-0.6.0.1.drv-0/source/build/CMakeFiles/CMakeOutput.log".
See also
"/tmp/guix-build-restinio-0.6.0.1.drv-0/source/build/CMakeFiles/CMakeError.log".
command "cmake" "../dev" "-DCMAKE_BUILD_TYPE=RelWithDebInfo"
"-DCMAKE_INSTALL_PREFIX=/gnu/store/1xjcw3icsrmrzjikbqslr11ihrsz22nj-restinio-0.6.0.1"
"-DCMAKE_INSTALL_LIBDIR=lib" "-DCMAKE_INSTALL_RPATH_USE_LINK_PATH=TRUE"
"-DCMAKE_INSTALL_RPATH=/gnu/store/1xjcw3icsrmrzjikbqslr11ihrsz22nj-restinio-0.6.0.1/lib"
"-DCMAKE_VERBOSE_MAKEFILE=ON" failed with status 1
The package:
(define-public restinio
(package
(name "restinio")
(version "0.6.0.1")
(source (origin
(method git-fetch)
(uri (git-reference
(url "https://github.com/Stiffstream/restinio.git;)
(commit (string-append "v." version
(file-name (git-file-name name version))
(sha256
(base32
"1c25kpx652nng8m1sqf5an2c3c4g3k6zj85mkkaxzk88iwfzq1s8"
(build-system cmake-build-system)
(inputs
`(("zlib", zlib)
("openssl", openssl)
("boost", boost)
("asio", asio)
("pcre", pcre)
("pcre2", pcre2)))
(propagated-inputs
`())
(native-inputs
`())
(arguments
`(#:configure-flags '()
#:phases
(modify-phases %standard-phases
(add-after 'unpack 'change-directory
(lambda _
(chdir "dev")
#t)
(home-page "https://stiffstream.com/en/products/restinio.html;)
(synopsis "C++14 library that gives you an embedded HTTP/Websocket
server")
(description "RESTinio is a header-only C++14 library that gives
you an embedded
HTTP/Websocket server. It is based on standalone version of ASIO
and targeted primarily for asynchronous processing of HTTP-requests.")
(license license:bsd-3)))
I created a new thread, because the old one was too long, which is not
helpful for anyone.
Jan Wielkiewicz
Re: Maintaining GNU Jami package for Guix
Dnia 2019-11-03, o godz. 11:15:56 Pierre Neidhardt napisał(a): > Can you share the complete recipe? > Yes. I guess you want a patch of my entire work so far, because pjproject-jami is meaningless without changes in jami, so I'm attaching the whole patch. Also the commit messages are messy, any advice how should they look? Jan Wielkiewicz 0001-change-the-fetch-method-of-pjproject-to-git-fetch-th.patch 0002-add-libresample-needed-for-Jami.patch 0003-adding-resample-as-a-pjproject-dependency.patch 0004-bump-jami-version-to-20191025.1.074a237.patch 0005-bump-jami-to-20191029.2.32830e6.patch 0006-bump-gnutls-to-3.6.10-the-version-Jami-is-going-to-u.patch 0007-bump-Jami-to-20191031.3.40360d8.patch 0008-bump-jami-to-20191101.3.67671e7.patch 0009-make-files-in-pjproject-writeable-improve-formatting.patch
Re: Maintaining GNU Jami package for Guix
Sorry, wrong command, sending the patch again...
Jan
>From 2f67e4c77ffb675bed3019b4289b3135db140015 Mon Sep 17 00:00:00 2001
From: Jan Wielkiewicz
Date: Sun, 27 Oct 2019 01:16:52 +0200
Subject: [PATCH 1/9] change the fetch method of pjproject to git; fetch the
exact commit needed for Jami; do not remove folders, which are not present in
the checkout
---
gnu/packages/telephony.scm | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/gnu/packages/telephony.scm b/gnu/packages/telephony.scm
index 127a856cc3cc65ccc29b99d4e5d83143400b741e..d17124ed4b22139f87a1efa3010153e97dfd5bb2 100644
--- a/gnu/packages/telephony.scm
+++ b/gnu/packages/telephony.scm
@@ -555,10 +555,10 @@ calls and messages")
(version "2.9")
(source
(origin
- (method url-fetch)
- (uri (string-append
- "http://www.pjsip.org/release/; ;
- version "/" name "-" version ".tar.bz2"))
+ (method git-fetch)
+ (uri (git-reference
+ (url "https://github.com/pjsip/pjproject.git;)
+ (commit "5dfa75be7d69047387f9b0436dd9492bbbf03fe4")))
(modules '((guix build utils)))
(snippet
'(begin
@@ -566,9 +566,9 @@ calls and messages")
;; Things we don't need:
;; BaseClasses - contains libraries from Windows SDK
;; we don't need it, at least not now.
- (list "BaseClasses" "bin" "g7221" "ilbc" "milenage"
+ (list "BaseClasses" "g7221" "ilbc" "milenage"
"speex" "threademulation" "yuv" "bdsound"
- "gsm" "lib" "mp3" "resample" "srtp" "webrtc"
+ "gsm" "mp3" "resample" "srtp" "webrtc"
;; Keep only resample, build and README.txt.
"build/baseclasses" "build/g7221" "build/gsm"
"build/ilbc" "build/milenage" "build/resample"
@@ -591,7 +591,7 @@ calls and messages")
)
(sha256
(base32
- "0dm6l8fypkimmzvld35zyykbg957cm5zb4ny3lchgv68amwfz1fi"
+ "1ayj6n7zd5wvd1nzj2k9s57fb4ckc2fv92k5sjvhd87yg69k3393"
(build-system gnu-build-system)
(inputs
`(("portaudio" ,portaudio)))
--
2.23.0
>From a25f5ad984f01f41400a54a2dde07b6aee6e9e6c Mon Sep 17 00:00:00 2001
From: Jan Wielkiewicz
Date: Sun, 27 Oct 2019 14:26:08 +0100
Subject: [PATCH 2/9] add libresample needed for Jami
---
gnu/packages/audio.scm | 23 +++
1 file changed, 23 insertions(+)
diff --git a/gnu/packages/audio.scm b/gnu/packages/audio.scm
index 110903e2fe6b094f8021e4fb29eff3720fcf6511..63dbb1fd0ef20853d5d13e5ae70c4b54b3879c8b 100644
--- a/gnu/packages/audio.scm
+++ b/gnu/packages/audio.scm
@@ -2299,6 +2299,29 @@ aimed at audio/musical applications.")
(base32
"04fajrass3ymr72flx5js5vxc601ccrmx8ny8scp0rw7j0igyjdr")))
+(define-public resample
+ (package
+ (name "resample")
+ (version "1.8.1")
+ (source (origin
+ (method url-fetch)
+ (uri (string-append "https://ccrma.stanford.edu/~jos/gz/resample-; version
+".tar.gz"))
+ (sha256 (base32
+ "074zj8ydp05yy1hjcglfv3hkvj4cm50f9nralka1992pm6yf8yvy"
+ (build-system gnu-build-system)
+ ;; (inputs)
+ ;; (propagated-inputs)
+ (native-inputs
+`(("autoconf" ,autoconf)
+ ("automake" ,automake)
+ ("pkg-config" ,pkg-config)
+ ("libtool" ,libtool)))
+ (synopsis "")
+ (description "")
+ (license license:lgpl2.1+)
+ (home-page "https://ccrma.stanford.edu/~jos/resample/Free_Resampling_Software.html;)))
+
(define-public rubberband
(package
(name "rubberband")
--
2.23.0
>From bf8d0a15b289f7cb80f7f6d1b640163130a4fa27 Mon Sep 17 00:00:00 2001
From: Jan Wielkiewicz
Date: Sun, 27 Oct 2019 14:33:17 +0100
Subject: [PATCH 3/9] adding resample as a pjproject dependency
---
gnu/packages/telephony.scm | 1 +
1 file changed, 1 insertion(+)
diff --git a/gnu/packages/telephony.scm b/gnu/packages/telephony.scm
index d17124ed4b22139f87a1efa3010153e97dfd5bb2..2dc3ccfe596dd0e66e5e0e02f1eb6bd3e991b472 100644
--- a/gnu/packages/telephony.scm
+++ b/gnu/packages/telephony.scm
@@ -601,6 +601,7 @@ calls and messages")
`(("speex" ,speex)
("libsrtp" ,libsrtp)
("gnutls" ,gnutls)
+ ("resample", resample)
("util-linux" ,util-linux)))
(native-inputs
`(("autoconf" ,autoconf)
--
2.23.0
>From c7e4ff2c7eec7671efd0886c229dde82358e38f1 Mon Se
Re: Maintaining GNU Jami package for Guix
Dnia 2019-11-01, o godz. 20:01:26
Pierre Neidhardt napisał(a):
> Git preserves permissions, so if upstream made it read-only (probably
> a mistake), then it will be read-only in the checkout. No problem,
> you can make it writable with
> `make-file-writable'.
>
Don't know why, but it doesn't work...
It still tells me files are read-only.
I do something like this:
(modify-phases %standard-phases
(add-after 'unpack 'make-git-checkout-writable
(lambda _
(for-each make-file-writable (find-files "."))
#t))
(add-after 'unpack 'apply-patches
(lambda* (#:key inputs #:allow-other-keys)
(let ((savoir-faire-linux-patches-directory "Savoir-faire
Linux patches") ;; Comes from
;;
"ring-project/daemon/contrib/src/pjproject/rules.mak". ;; WARNING:
These amount for huge changes in pjproject. ;; Particularly, they add
support for GnuTLS. (savoir-faire-linux-patches
'("add_dtls_transport"
"android"
"disable_local_resolution"
Jan Wielkiewicz
Re: Maintaining GNU Jami package for Guix
Dnia 2019-11-01, o godz. 20:02:22 Pierre Neidhardt napisał(a): > Because gnutls with Jami patches should not be called gnutls: it's a > non-vanilla version of GnuTLS. And I doubt it would be useful to > anyone but Jami. Actually gnutls is without patches, just an older version. What has patches is pjproject. Jan Wielkiewicz
Re: Maintaining GNU Jami package for Guix
Dnia 2019-10-31, o godz. 23:26:39 Marius Bakke napisał(a): > Do you have a link to the patches that Jami/pjproject needs? You can find patches in the ring-project/daemon/contrib/src/pjproject directory from the latest source tarball here: https://dl.jami.net/ring-release/tarballs/ > It would be great if we could use system versions of GnuTLS and cURL, > because otherwise Jami risks not getting security updates. A bit unlikely, they update dependencies quickly, but they're slower than upstream. Keeping a separate version and updating it paralelly will prevent breaking the build process of the modified pjproject version. > If they really need special patched versions of some libraries, you > can do something along these lines to create a > cusctm variant: > > (define-public gnutls/jami > (hidden-package >(package/inherit > gnutls > (source (origin > (inherit (package-source gnutls)) > (patches (append (origin-patches gnutls) >(search-patches > "gnutls-jami.patch" Why can't we just keep paralell version for a package? Like gnutls @ 3.6.7, gnutls @ 3.6.9 etc? > I realize now that this won't do the right thing wrt grafts, but we > can deal with that later. :-) Don't really know what grafts are yet, so we can indeed skip this now :) Jan Wielkiewicz
Re: Maintaining GNU Jami package for Guix
Dnia 2019-10-27, o godz. 19:18:19 Pierre Neidhardt napisał(a): > Thanks for the update! :) > Which failing patch and what fails? Output? Sorry, I sent a mail explaining everything yesterday, but it seems it got lost somewhere - your or mine mail provider does something (blocks?) or the ML has a bug. Reposting it here, hope this time it'll work: Dnia 2019-10-26, o godz. 12:12:44 Pierre Neidhardt napisał(a): > Nice, thank you for getting in touch with the developers, this is > very informative. > > Have you tried using pjproject > 5dfa75be7d69047387f9b0436dd9492bbbf03fe4 ? > Does the patching still fail? I've tried this today and it still fails. Don't know if the fails with the exact commit are much different from 2.9 fetched from the tarball. If they're not different, then you can see what happens in one of my comments here https://git.ring.cx/savoirfairelinux/ring-project/issues/691 > Also it now depends on Restinio, I think we are missing this one, so > it would need to be packaged first. (But that's unrelated to the > patch issue.) I'm going to package it eventually, but for now I want to fix the current problems and then proceed with the rest. Jan Wielkiewicz
Re: Maintaining GNU Jami package for Guix
Dnia 2019-10-26, o godz. 12:12:44 Pierre Neidhardt napisał(a): > Nice, thank you for getting in touch with the developers, this is > very informative. > > Have you tried using pjproject > 5dfa75be7d69047387f9b0436dd9492bbbf03fe4 ? > Does the patching still fail? I've tried this today and it still fails. Don't know if the fails with the exact commit are much different from 2.9 fetched from the tarball. If they're not different, then you can see what happens in one of my comments here https://git.ring.cx/savoirfairelinux/ring-project/issues/691 > Also it now depends on Restinio, I think we are missing this one, so > it would need to be packaged first. (But that's unrelated to the > patch issue.) I'm going to package it eventually, but for now I want to fix the current problems and then proceed with the rest. Jan Wielkiewicz
Re: Maintaining GNU Jami package for Guix
Dnia 2019-10-27, o godz. 19:18:19 Pierre Neidhardt napisał(a): > Thanks for the update! :) > Which failing patch and what fails? Output? Sorry, I sent a mail explaining everything yesterday, but it seems it got lost somewhere - your or mine mail provider does something (blocks?) or the ML has a bug. Reposting it here, hope this time it'll work (it didn't work again - sending this the second time, don't know what's wrong - I use the "reply to all" option, it generally works, don't know why this case is different): Dnia 2019-10-26, o godz. 12:12:44 Pierre Neidhardt napisał(a): > Nice, thank you for getting in touch with the developers, this is > very informative. > > Have you tried using pjproject > 5dfa75be7d69047387f9b0436dd9492bbbf03fe4 ? > Does the patching still fail? I've tried this today and it still fails. Don't know if the fails with the exact commit are much different from 2.9 fetched from the tarball. If they're not different, then you can see what happens in one of my comments here https://git.ring.cx/savoirfairelinux/ring-project/issues/691 > Also it now depends on Restinio, I think we are missing this one, so > it would need to be packaged first. (But that's unrelated to the > patch issue.) I'm going to package it eventually, but for now I want to fix the current problems and then proceed with the rest. Jan Wielkiewicz
Re: Maintaining GNU Jami package for Guix
Dnia 2019-10-25, o godz. 17:03:01 Pierre Neidhardt napisał(a): > Hi Jan, > > any luck with Jami? Let me know if you need more specific help (my > previous message was maybe not too clear :p), I can dig into this > deeper in the coming days. > I had little time recently, but I've been trying different things in order to build pjproject. What I know is the current version of pjproject doesn't compile at all without Savoir-failre linux patches. I also talked with Jami developers about the current state of Jami and pjproject: https://git.ring.cx/savoirfairelinux/ring-project/issues/691 They're still applying patches for pjproject and the version they use is 2.9, tried updating jami-source and pjproject, but applying the patches failed. I suspect we're missing some dependencies of pjproject. I can post error messages, but have to sit down and build everything again. I'm going to try this weekend. Jan Wielkiewicz
Re: Maintaining GNU Jami package for Guix
Hello, Dnia 2019-10-19, o godz. 11:02:35 Pierre Neidhardt napisał(a): > Hi Jan, > > glad you are interested in picking this one up! :) > I'm the last packager of Jami, so I might be able to help. Yes, thank you, I definitely will need help. > After a quick glance, here is the situation it seems: > > Jami used to depend on their own fork of pjproject (as packaged in > Guix). > However it seems that recent versions have dropped the fork to use > upstream instead. _This needs to be confirmed._ It seems the latest version still has patches for pjproject in the source code, but I can ask the devs about it. > If this is the case, switching the pjproject input to use upstream > should work when updating Jami. I've tried updating Jami, but pjproject seems to be a problem - don't know what have changed, but now even the currently packaged version of pjproject won't compile. Here's the log: starting phase `autoconf' autoconf: error: invalid option `-vfi' Try `autoconf --help' for more information. command "autoconf" "-vfi" "-o" "aconfigure" "aconfigure.ac" failed with status 1 I've also tried updating pjproject to the current version Jami uses - 2.8, it throws the same error. I managed to skip that by removing the "-vfi" options by commenting it out like this: (add-before 'patch-source-shebangs 'autoconf (lambda _ (invoke "autoconf" "-o" ;"-vfi" "aconfigure" "aconfigure.ac"))) But then it fails later, while doing "make dep": make[2]: Entering directory '/tmp/guix-build-pjproject-2.8.drv-0/pjproject-2.8/third_party/build' make[2]: *** gsm: No such file or directory. Stop. make[2]: Leaving directory '/tmp/guix-build-pjproject-2.8.drv-0/pjproject-2.8/third_party/build' make[1]: *** [Makefile:7: dep] Error 1 make[1]: Leaving directory '/tmp/guix-build-pjproject-2.8.drv-0/pjproject-2.8/third_party/build' make: *** [Makefile:14: dep] Error 1 command "make" "dep" failed with status 2 Why are third party directories removed if they're necessary to build pjproject? Should I package contents of these folders as separate package? Also something is causing builds of Jami to be irreproducible - every time I run guix upgrade, Jami gets upgraded to the same version. Is there a way to check what exactly is unstable? > The rest should be mostly straightforward stuff. Don't hesitate to > come back to me if you need more help. Okay, thanks. > Cheers! > Jan Wielkiewicz
