Just tested Jami on core-updates and no magic happened, the bug is
still there.
I'm out of ideas. I'm going to upload my work somewhere tomorrow.
Someone really needs to help me with this, I'm not experienced enough
to handle this kind of bugs myself.
Jan Wielkiewicz
On Wed, Apr 08, 2020 at 01:52:14AM +0200, Jan wrote:
> If it succeeds, I will need a way to copy contents of the store on my
> powerful machine to my potato machine. Is "guix copy" the tool I can
> use?
Yup! You'll need to authorize the building machine's key on the potato.
https://guix.gnu.org/
On Wed, 08 Apr 2020 01:06:14 +0200
Marius Bakke wrote:
> A git merge will merge all the commits, some of which are bound to
> cause conflicts. I will try to resolve those tomorrow.
>
> In the mean time, you should be able to "cherry-pick" your patches
> instead. Something along the lines of:
>
Jan writes:
> I get several merge conflicts when merging wip-jami into core updates.
> The wip-jami is based on the current master, rebased a minute ago.
> Is there a way to avoid this without pain?
A git merge will merge all the commits, some of which are bound to cause
conflicts. I will try t
I get several merge conflicts when merging wip-jami into core updates.
The wip-jami is based on the current master, rebased a minute ago.
Is there a way to avoid this without pain?
Jan Wielkiewicz
On Mon, 06 Apr 2020 20:26:36 +0200
Marius Bakke wrote:
>
> Do you have a patch we can use to reproduce this issue on Guix?
The patch set is pretty big right now - over 20 patches. I'll upload my
work to my online repository, but have little time right now.
> You can easily test the patch on cor
Jan writes:
> Hello everybody,
>
> I recently tested Jami using the latest pjproject version - 2.10 which
> was supposed to fix some strange bugs that are present only on Guix,
> but it didn't.
> https://git.jami.net/savoirfairelinux/jami-packaging/issues/63
> Jami developer - Sébastien Blin told
Hello everybody,
I recently tested Jami using the latest pjproject version - 2.10 which
was supposed to fix some strange bugs that are present only on Guix,
but it didn't.
https://git.jami.net/savoirfairelinux/jami-packaging/issues/63
Jami developer - Sébastien Blin told me: "Imho the probable iss
Hi Jan,
Thank you for working on Jami. Cool!
On Mon, 6 Jan 2020 at 20:09, Jan wrote:
>
> I just closed all 22 issues that I improperly started. How should I
> send the patches to create just one issue? When git send-email asks me
> if I want to send the patches, should I send only one and then
On Mon, 6 Jan 2020, Jan wrote:
Or should I send one mail to guix-patc...@gnu.org and
then send the rest to n...@debbugs.gnu.org?
Yes, I believe that sending to guix-patches first and then to NNN@debbugs
is the recommended way.
Best,
Jack
I just closed all 22 issues that I improperly started. How should I
send the patches to create just one issue? When git send-email asks me
if I want to send the patches, should I send only one and then wait?
How long? I tried sending the rest a few seconds later, but it didn't
work as indended. Or
Dnia 2020-01-04, o godz. 16:37:53
Pierre Neidhardt napisał(a):
> Please do!
>
Okay, don't know what was that, but I got an smtp error 250 during
sending patches aaand the mailing list looks like a mess now. I closed
four visible issues (out of 22), but don't know what's with the rest.
I think t
On Fri, 03 Jan 2020 07:33:38 +0100
Ricardo Wurmus wrote:
> That’s very unlikely as we would probably see errors like this in most
> packages then.
>
> cogl issues an optimized instruction (__memcpy_ssse3), which then
> fails.
>
> I’m just guessing, but I wonder if this comment is a hint at what
Jan writes:
> On Sat, 28 Dec 2019 10:40:09 +0100
> Pierre Neidhardt wrote:
>
>> This is indeed your problem, I suspect that something broke the
>> wrapper somehow.
>> Can you share your patch set again? I can have a look.
> I didn't really break anything - it works when launching Jami normall
Jan writes:
> Bad news:
> I still haven't got any response that would solve the bug present only
> in our package:
> https://git.jami.net/savoirfairelinux/ring-client-gnome/issues/1123
> I have not much experience with debugging and reading backtraces, but
> could it be there's something wrong
On Sat, 28 Dec 2019 10:40:09 +0100
Pierre Neidhardt wrote:
> P.S.: Have you managed to set up a public Git clone of Guix to share
> you patches?
>
Okay, good news: I finally have a public repo at
https://notabug.org/kromka_chleba/guix-jami/src/jami-wip
My changes are on the jami-wip branch. Wo
On Sat, 28 Dec 2019 10:53:33 +0100
Pierre Neidhardt wrote:
> Allow me to explain a little more:
>
> Binaries embed a value called RPATH which points to the locations
> where to load dynamic libraries (also called "shared objects").
>
> When building a binary, Guix automatically sets the RPATH
On Sat, 28 Dec 2019 10:40:09 +0100
Pierre Neidhardt wrote:
> This is indeed your problem, I suspect that something broke the
> wrapper somehow.
> Can you share your patch set again? I can have a look.
I didn't really break anything - it works when launching Jami normally
or using the ring.cx scr
Allow me to explain a little more:
Binaries embed a value called RPATH which points to the locations where
to load dynamic libraries (also called "shared objects").
When building a binary, Guix automatically sets the RPATH to that of the
required inputs.
Jami (indirectly) depends on both sqlit
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-sq
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
Hello Jan,
Thanks for working on this.
Jan Wielkiewicz ezt írta
(időpont: 2019. dec. 27., P, 20:11):
>
> 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 caus
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
On Wed, Dec 25, 2019 at 02:34:16AM +0100, Jan wrote:
> Never mind the question about removing not my commits - I rediscovered
> the guix pull --rebase option, Pierre showed me previously.
>
> There's also a problem - don't know if it's a bug or not, but Jami
> client encounters an error during scr
Never mind the question about removing not my commits - I rediscovered
the guix pull --rebase option, Pierre showed me previously.
There's also a problem - don't know if it's a bug or not, but Jami
client encounters an error during screen sharing. I suspect it could be
caused by the gnutls version
On Sun, 22 Dec 2019 08:48:31 +0100
Ricardo Wurmus wrote:
> The problem here is that “substitute*” expects regular expressions and
> “$”, “(”, “)”, and “.” all have special meaning in a regular
> expression context, so they need to be escaped. Escaping is done
> with a backslash, but using a back
Jan Wielkiewicz writes:
> 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
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.
>
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 disa
Forgot to add the error file.
Here it goes.
Jan Wielkiewicz
lavf-mov_rtphint.err
Description: Binary data
Hi Jan,
> TESTlavf-mov_rtphint
> --- ./tests/ref/lavf/mov_rtphint 1970-01-01 00:00:01.0
> + +++ tests/data/fate/lavf-mov_rtphint2019-12-15
> 20:04:09.880137614 + @@ -1,3 +1,3 @@
> -7014419d8267c2751314303a8fb303c1 *tests/data/lavf/lavf.mov_rtphint
> -366449 tests/dat
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/re
Okay, thanks. I'll use the second way then. I could also create a new
file - jami-utils.scm and use it as a module, but a file containing
only one procedure isn't good either.
On Tue, 10 Dec 2019 18:43:58 -0600
Caleb Ristvedt wrote:
> Jan Wielkiewicz writes:
>
> > I tried both ways - the secon
Jan Wielkiewicz writes:
> I tried both ways - the second works, but the first doesn't.
That would be the "in theory, it would work" part. On further investigation,
source-module-closure has a #:select? keyword argument, which takes a module
name and returns #f if it shouldn't be included in the
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
Wow, thanks for the explanation, it's very enlightening!
This should probably end up in the documentation somewhere. Maybe as
part of the packaging tutorial? Or for the long-due "Advanced Packaging
Tutorial"?
> (define my-procedure-code '(lambda (a b c) ...))
>
> (arguments
> `(#:phases (let
#: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
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
On Thu, 05 Dec 2019 15:32:23 +0100
Pierre Neidhardt wrote:
> Thanks!
>
> The first 5 commits look good overall.
Good to know.
> For the last one, I think there are a few confusions:
>
> - native-inputs takes packages or origins, it does not take a lambda.
>
> - To call a custom function from
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
On Wed, 04 Dec 2019 17:06:16 +0100
Pierre Neidhardt wrote:
> You need a lambda here:
>
> --8<---cut here---start->8---
> (add-after 'unpack 'apply-patches
> (lambda* (#:key inputs #:allow-other-keys)
> (let ((my-input (assoc-ref inputs "my-input")))
>
Jan Wielkiewicz writes:
> 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.
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 e
> 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?
You need to export the symbol.
To do so, you can either specify the symbol in the #:
Hi,
It turns out ffmpeg needs to be patched, just like pjproject and there
could be more packages to patch. I quickly searched for "*.patch" in
the contrib folder and that's what I got:
./argon2/pkgconfig.patch
./argon2/argon2-vs2017.patch
./pthreads/pthreads-uwp.patch
./pthreads/pthreads-vs2017.pa
On Tue, 03 Dec 2019 17:04:39 +0100
Pierre Neidhardt wrote:
> Hi!
>
> I suppose that if you deleted the 'configure phase, it's because there
> is no ./configure file.
> Is there a bootstrap file?
There's no ./configure, nor ./bootstrap.
> You probably want to use "PREFIX=" (in all caps).
> Also
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:
startin
On Sun, 01 Dec 2019 18:32:36 +0100
Pierre Neidhardt wrote:
> If it works for you, then I think it's ready!
I'll do some more tests - video/audio conference, but for now
everything works - chat, sending files.
As for updating, Sébastien Blin said that since then they had bumped
opendht and had pa
I see the changes got merged. Tested Jami and it works great :)
I guess the wrapper was the issue.
I am going to update it to the latest version, this time I'll try
sending the patches myself in order to learn something new.
I also told the devs about our success:
https://git.jami.net/savoirfaireli
On Wed, 27 Nov 2019 12:43:19 +0100
zimoun wrote:
> Hi Jan,
Hello,
> If you use Emacs, you can open Debbugs with: C-u M-x debbugs-gnu then
> RET guix-patches n y
> Then M-x debbugs-gnu-bugs RET 38211 RET
> So far so good.
> Select the patch set.
> Then M-x shell-command-on-region RET cd /path/to/y
Hi Jan,
On Tue, 26 Nov 2019 at 20:43, Jan wrote:
> P.S. I apply the patches using "patch" command, right?
What do you use?
If you use Emacs, you can open Debbugs with: C-u M-x debbugs-gnu then
RET guix-patches n y
Then M-x debbugs-gnu-bugs RET 38211 RET
So far so good.
Select the patch set.
Th
WebKitGTK is not rebuilt with my patch, because I removed the GnuTLS
update.
You can test with substitutes, it should work with no problem.
> P.S. I apply the patches using "patch" command, right?
With `git am`.
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signatur
On Tue, 26 Nov 2019 11:07:28 +0100
Pierre Neidhardt wrote:
> I was waiting for people to test the patch, since it does not run
> properly on my machine (the UI does not show up).
>
> Have you tried it yourself, Jan? Does ti work for you?
>
That's the chicken and the egg problem - I can't try
I'm not sure how to apply conflicting patches with Magit. Good
question, I'd like to know how to do it too! :)
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
Hi,
Thank you for working that.
On Mon, 25 Nov 2019 at 22:15, Jan wrote:
> Sorry for being impatient, but is it normal for patches to be merged
> that long? Is there something stopping the commits?
> I need those merged in order to continue working on Jami.
Two weeks are not that long. ;-)
I
I was waiting for people to test the patch, since it does not run
properly on my machine (the UI does not show up).
Have you tried it yourself, Jan? Does ti work for you?
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
Hi again,
Sorry for being impatient, but is it normal for patches to be merged
that long? Is there something stopping the commits?
I need those merged in order to continue working on Jami.
Jan Wielkiewicz
On Fri, 15 Nov 2019 10:07:38 +0100
Pierre Neidhardt wrote:
Hello,
When can I expect our changes to be merged? There's a new Jami version
(20191115.5.b0a579d), I would like to update it to, but a strange
conflict stops me from running "git pull". I also can't investigate the
issue, until webkit-gt
Hi Jan,
>> What do you mean? Guix can be installed on foreign distribution and
>> Jami would work there the same way it works on Guix System.
> I mean Windows (ReactOS in the future?), OSX, iOS, Android - Jami is an
> universal platform. AFAIK there's the option to build with
> --target=mingw64 o
On Thu, 14 Nov 2019 22:54:15 +0100
Pierre Neidhardt wrote:
> I don't think it's a Jami bug: as I mentioned the same bug affects the
> old package so I believe it comes from us.
Sorry, didn't read the entire message, I'm a bit tired, because of
exams.
> The thing is that those are 3 different bu
Jan writes:
> On Thu, 14 Nov 2019 19:07:56 +0100
> Pierre Neidhardt wrote:
>
>> See https://issues.guix.gnu.org/issue/38211.
>>
>
> Cool, thanks for building it!
> As for the issue, I don't know if the Jami version I use is
> stable, unfortunately some versions from the tarball repo contain bu
On Thu, 14 Nov 2019 19:07:56 +0100
Pierre Neidhardt wrote:
> See https://issues.guix.gnu.org/issue/38211.
>
Cool, thanks for building it!
As for the issue, I don't know if the Jami version I use is
stable, unfortunately some versions from the tarball repo contain bugs.
I can ask the devs about
See https://issues.guix.gnu.org/issue/38211.
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
Update: I've managed to build libring.
Jami should follow soon, stay tuned.
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
On Mon, 11 Nov 2019 16:04:30 +0100
Pierre Neidhardt wrote:
> The big rebuild is triggered by the gnutls version update.
> Is the update really necessary at the moment?
The version of gnutls has been bumped in Jami, so I guess that's
necessary. If that's a problem I can add gnutls-jami.
> If you
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
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'
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 t
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 do
Thanks, I'll look into it.
> 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.
Actually... It's should be the same
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, becau
If you are still stuck, share your progress for restinio, I'll give it a
shot! :)
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
Hello,
Jan Wielkiewicz ezt írta (időpont:
2019. nov. 5., Ke 17:50):
> 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
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/mas
Hello,
Jan Wielkiewicz ezt írta (időpont:
2019. nov. 4., H, 21:48):
> 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
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
76 matches
Mail list logo
