bug#57762: dragon-drop package's binary is missing

[bdju]

On Mon Sep 12, 2022 at 10:32 PM CDT, bdju via Bug reports for GNU Guix wrote:
> After upgrades I no longer have the `dragon` command that is used by the
> dragon-drop package, making the program unusable. The package is still
> in my manifest file that I applied, still shows up in a search, and I
> also tried to manually `guix install` it again. No luck.
>
> I use this in a lot of scripts due to gtk file pickers crashing software
> for me a lot and trying to avoid them. A fix would be very much
> appreciated.

I found that doing the following:
find $(guix build dragon-drop)

revealed that `dragon` is inside .../bin/bin instead of just /bin.
Perhaps this could cause issues with setting the PATH properly.

bug#57543: emacs-telega is broken

[Giovanni Biscuolo]

Hi André

I was able to swith back to a previous profile generation and use
emacs-telega again, see below

current emacs-telega is still broken, AFAIK

André A. Gomes  writes:

> Giovanni Biscuolo  writes:

[...]

>> André please could you try to switch back to a previous profile
>> generation and test it, reporting the errors you get in Emacs *Messages*
>> buffer in ~/.telega/telega-server.log (unless you configured another
>> telega directory)?
>
> Hi Giovanni,
>
> I switched back to a previous profile generation and I was able to start
> the telega server only after deleting all database files located at
> ~/.telega/.  Before doing that I was also getting errors.

the last few lines of ~/.telega/telega-server.log could have been
useful so we could compare them with mine, but nevermind

AFAIU just deleting the database files could not be enough since there
could be some "status" (other files in ~/.telega) giving problems

> Some things look off in in *Telega Root* buffer tough, and I can't use
> emacs-telega as before.  I can't say it's working properly.

have you tryed renaming the whole ~/.telega folder to ~/.telega.BACKUP?

> Does this make sense?

Yes it makes sense

> Can you reproduce what I've detailed?

Yes, I renamed the telega folder as suggested above and started
emacs-telega;  I had to authenticate my desktop client again and now
AFAIU all is working as before

[...]

Happy hacking! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

bug#50567: [core-updates-frozen] icedtea-6 fails to build.

[Marius Bakke]

Julien Lepiller  skriver:

> Again this is exactly where I was blocked. There is a checksum being 
> generated in classlist files from java code during the build. The classlist 
> file is exactly the same as the one in master, so it's correctly generated. 
> Fowever, at some point, the process needs toqload that file, and that 
> ultimately calls some C code (identical to the java code) that re-computes 
> and compares the checksum. After printing some values, it seems that it 
> always computes "0…031" as the hash of any classlist file, despite running 
> the function and taking everything into account. I think this is again an 
> optimization issue, anl it's not clear how to work around that.

For the record, this showed up again after switching to GCC 11.  I ended
up disabling optimizations for dump.cpp in 321e866b1cea4916e3568efb
instead of trying to fool the compiler.

Probably it would be better to figure out exactly which optimization
causes this problem, but that's a journey for a different time.


signature.asc
Description: PGP signature

bug#57581: Failing to build the website

[Ludovic Courtès]

Hi,

"pelzflorian (Florian Pelz)"  skribis:

> zimoun  writes:
>> The culprit seems the package ’qtserialport’ in ’packages-builder’ from
>> (apps packages builder).  Maybe introduced by commit
>> 1ef04fb2288dade3ad2883026ae286a68ef13a1e.
>
> This was a first failing commit for me too, but the reason the website
> does not build appears to be the license field of qtshadertools in
> commit 1d65ff8fdeb20cc2db956093f0ecb1f3f72afc0e (Cc to Maxim).  I could
> make a patch but not today.  Maxim, would you fix it?

Fixed in e61c581805b2338ea8feaac86617c5d7bff41c41, thanks for the
investigation!

> I don’t know if there is a way to catch such mistakes early.  Field
> sanitizers?

Yes, we should do that.  We can arrange to have most checks done at
compile time, similar to how the ‘synopsis’ and ‘description’ sanitizers
work (well, with extra macro magic).

Ludo’.

bug#57775: guix shell --root fails

[Ricardo Wurmus]

This fails on the first try:

--8<---cut here---start->8---
$ guix shell -D -f guix.scm --root=env-test
Backtrace:
  10 (primitive-load "/home/rekado/.config/guix/current/bin/guix")
In guix/ui.scm:
   2238:7  9 (run-guix . _)
  2201:10  8 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1752:10  7 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
In guix/status.scm:
815:4  6 (call-with-status-report _ _)
In guix/scripts/environment.scm:
   946:13  5 (_)
In guix/store.scm:
  2168:25  4 (run-with-store #f # #:guile-for-build _ #:system _ # _)
In guix/scripts/environment.scm:
   963:16  3 (_ _)
In guix/store.scm:
  2040:38  2 (_ #f)
   1475:0  1 (add-indirect-root #f "/home/rekado/dev/pigx/pigx_bsseq/env-test")
In ice-9/boot-9.scm:
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure struct-vtable: Wrong type argument in position 1 (expecting 
struct): #f
--8<---cut here---end--->8---

On the second try it does work and links the profile to ./env-test.

-- 
Ricardo

bug#57543: emacs-telega is broken

[André A . Gomes]

Giovanni Biscuolo  writes:

> Hi André
>
> I was able to swith back to a previous profile generation and use
> emacs-telega again, see below

Hi Giovanni!

It's working for me too, following your steps!

So, I believe we're agreeing that the commit we referred to should be
reverted.  Correct?

Thanks.


-- 
André A. Gomes
"You cannot even find the ruins..."

bug#57790: Strange behavior with emacs-build-system

[Fredrik Salomonsson]

Hi,

I encountered a strange behavior when using a guix.scm file to build and
run test in an emacs project. The project is called issue.el[0].

I have the following guix.scm:

---✀
(use-modules
  ((guix licenses) #:prefix license:)
  (guix packages)
  (guix gexp)
  (guix download)
  (guix git-download)
  (guix build-system emacs)
  (guix build emacs-utils)
  (gnu packages)
  (gnu packages emacs)
  (gnu packages emacs-xyz)
  (ice-9 popen)
  (ice-9 rdelim)
  )

(define %git-commit
  (read-string (open-pipe "git show HEAD | head -1 | cut -d ' ' -f2" 
OPEN_READ)))

(define (skip-git-directory file stat)
  "Skip the `.git` directory when collecting the sources."
  (let ((name (basename file)))
(not (string=? name ".git"

(package
 (name "emacs-issue-el")
 (version (git-version (emacs-header-parse "version" "issue.el") "HEAD" 
%git-commit))
 (source (local-file (dirname (current-filename))
 #:recursive? #t
 #:select? skip-git-directory))
 (build-system emacs-build-system)
 (arguments
  (list #:tests? (not (%current-target-system))
#:test-command #~'("ert-runner")))
 (native-inputs (list emacs-ert-runner))
 (propagated-inputs
  (list
   emacs-org-jira))
 (home-page "https://sr.ht/~plattfot/issue.el";)
 (synopsis "List issues from various issue trackers in emacs")
 (description
  "List issues from various issue trackers in a tabulated buffer in
@code{Emacs} and act on them.  Current supported issue tracker is
@code{jira}.")
 (license license:gpl3+))



If I name the local clone `issue.el` (name of the directory);
`guix build -f guix.scm` will fail. It will just copy the file
`issue.el` and then `ert-runner` fails as there is no test directory.

But if I name the local clone something else, e.g. `issue-el` then it
will copy all the files, `ert-runner` will be happy and
`guix build -f guix.scm` will succeed.

I'm not sure if this is an issue in `emacs-build-system`, `local-file`
or plain old user error.

[0] https://git.sr.ht/~plattfot/issue.el

-- 
s/Fred[re]+i[ck]+/Fredrik/g

bug#57581: Failing to build the website

[zimoun]

Hi Ludo,

On Tue, 13 Sep 2022 at 16:41, Ludovic Courtès  wrote:

>> I don’t know if there is a way to catch such mistakes early.  Field
>> sanitizers?
>
> Yes, we should do that.  We can arrange to have most checks done at
> compile time, similar to how the ‘synopsis’ and ‘description’ sanitizers
> work (well, with extra macro magic).

For the record, please see this thread [1] opening a discussion on the
topic.

1: 


Cheers,
simon