bug#66290: transmission-daemon-service-type not serving web interface

[elaexuotee--- via Bug reports for GNU Guix]

The documentation for transmission-daemon-service-type makes it sound like the
web interface should be up and running:

   Once the service is started, users can interact with the daemon
through its Web interface (at ‘http://localhost:9091/’) ...

However, the daemon throws 404 when accessing said url:

404: Not Found

Couldn't find Transmission's web interface files!

Users: to tell Transmission where to look, set the TRANSMISSION_WEB_HOME 
environment variable to the folder where the web interface's index.html is 
located.

Package Builders: to set a custom default at compile time, #define 
PACKAGE_DATA_DIR in libtransmission/platform.c or tweak tr_getClutchDir() by 
hand.

Anyone else seeing this?

Just for good measure, here is my config:

(transmission-daemon-configuration
  (rpc-authentication-required? #t)
  (rpc-username "transmission")
  (rpc-password "x")
  (rpc-whitelist-enabled? #t)
  (rpc-whitelist  '("::1" "127.0.0.1" "192.168.*"))
  (encryption 'require-encrypted-connections)
  (alt-speed-down (* 1024 1)) ; 1MB/s
  (alt-speed-up   512)
  (alt-speed-time-enabled? #t)
  (alt-speed-time-day  'weekdays)
  (alt-speed-time-begin(* 60 8))
  (alt-speed-time-end  (* 60 19))
  (watch-dir-enabled? #t)
  (watch-dir  "/var/lib/transmission-daemon/torrents"))

bug#65979: incorrect “guix hash” for FastQC

[Ludovic Courtès]

Hi,

Simon Tournier  skribis:

[...]

>> Clearly #2 is correct (it’s perfectly fine to have a ‘.svn’ directory in
>> a Git repo), whereas #1 is an approximation that, in corner cases like
>> this one, gives the wrong answer.
>
> These corner cases matter for some SWH loader implementing Nar hashes
> in Python.  Since they load sources.json (conversion of hash checksum
> from package recipe), read the Nar hash and compare it with the one
> they internal compute, then they need to implement in Python the
> correct behavior.

I agree, SWH needs something more robust than ‘vcs-file?’.

>> My take is that it’s OK to keep ‘vcs-file?’ as is: the best we could do
>> would be to add complicated heuristics in the hope corner cases like
>> this one would be better dealt with, but it wouldn’t be bullet-proof
>> anyway.
>
> Well, the question is what other VCS as 'svn-fetch', etc. are doing?

Remove the relevant metadata directory/directories.

> Maybe, we can just have a special case for Git repository.
>
> Somehow, since the problem needs to be solved for SWH, the same
> solution applies for vcs-file? and "guix hash", no?

Yes, ‘guix hash’ uses ‘vcs-file?’.

Now, SWH does not use ‘guix hash’ (I suppose) so they’ll have to address
that on their side (in Python code I guess).

Ludo’.

bug#63153: transfig build failure

[Bruno Victal]

Fixed with [1] in '337dbf6867597b6e3b72b0bdb2152a42a9f41dbc'.


[1]: 

-- 
Thanks,
Bruno.

bug#66207: Cannot boot VMs with grub-efi-bootloader

[Ludovic Courtès]

Hi,

Ricardo Wurmus  skribis:

> The manual for “guix system” gives a somewhat complicated invocation
> that I only found out about later:
>
>   image=$(guix system image --image-type=qcow2 \
>   gnu/system/examples/lightweight-desktop.tmpl)
>   cp $image /tmp/my-image.qcow2
>   chmod +w /tmp/my-image.qcow2
>   qemu-system-x86_64 -enable-kvm -hda /tmp/my-image.qcow2 -m 1000 \
>  -bios $(guix build 
> ovmf)/share/firmware/ovmf_x64.bin
>
> I haven’t tried it yet, but I assume that providing this extra “-bios”
> option would fix it.  It wasn’t necessary before, though, and I think
> it’s an inconvenient complication when running Guix VMs.

It means that ‘--image-type=qcow2’ can now end up creating EFI images.
Perhaps not so bad in practice since you can still create MBR images,
AIUI?

> Perhaps an example invocation of qemu-system-* could be added as a
> comment to the templates?

Yes, except maybe for those templates that are used as examples under
“Using the Configuration System”.

Ludo’.

bug#65979: incorrect “guix hash” for FastQC

[Simon Tournier]

Hi,

On Sun, 1 Oct 2023 at 17:07, Ludovic Courtès  wrote:

> >> My take is that it’s OK to keep ‘vcs-file?’ as is: the best we could do
> >> would be to add complicated heuristics in the hope corner cases like
> >> this one would be better dealt with, but it wouldn’t be bullet-proof
> >> anyway.
> >
> > Well, the question is what other VCS as 'svn-fetch', etc. are doing?
>
> Remove the relevant metadata directory/directories.

What does it mean "relevant"? :-)

Where do I have to look to implement the exact same behaviour of what
do the fetch methods?


> Now, SWH does not use ‘guix hash’ (I suppose) so they’ll have to address
> that on their side (in Python code I guess).

Yes for sure.  It does not change the fact that "guix hash" has a bug.

Cheers,
simon

bug#65889: texlive-acronyms is missing dependencies

[Bruno Victal]

Hi Josselin,

On 2023-09-14 14:13, Josselin Poiret via Bug reports for GNU Guix wrote:
> Couldn't we report those missing dependencies upstream then?

This can be done, in theory it's nothing too complicated and all it takes
is simply add a DEPENDS.txt file to the repository.
If you're interested in doing this, see [1] and [2] for information.

As Nicolas has pointed out, it's untenable to do an exhaustive listing of
the dependencies so I'd recommend installing some typical collections first
such as `texlive-collection-latexrecommended' and only then report the
missing non-obvious dependencies for inclusion in a DEPENDS.txt to upstream.


[1]: 
[2]: 

-- 
Furthermore, I consider that nonfree software must be eradicated.

Cheers,
Bruno.

bug#66297: guix-daemon not starting after boot

[Sharlatan Hellseher]

Hi Guix!

After the recent pull and system reconfigure I've started experiencing
guix-daemon not starting up after the system boot.

~# guix describe
Generation 29   Sep 27 2023 21:59:12(current)
  guix 0500af5
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 0500af5556307d0a4c14a23864e9e4bccd2643d7
  nonguix bb184bd
repository URL: https://gitlab.com/nonguix/nonguix
branch: master
commit: bb184bd0a8f91beec3a00718759e96c7828853de

~# guix pull
guix pull: error: failed to connect to
`/var/guix/daemon-socket/socket': Connection refused
~# herd status guix-daemon
Status of guix-daemon:
  It is stopped.
  It is enabled.
  Provides (guix-daemon).
  Requires (user-processes).
  Will be respawned.

Logs are empty:
~# tail /var/log/guix-daemon.log | wc -l
0


-- 
… наш разум - превосходная объяснительная машина которая способна
найти смысл почти в чем угодно, истолковать любой феномен, но
совершенно не в состоянии принять мысль о непредсказуемости.

bug#66207: Cannot boot VMs with grub-efi-bootloader

[Maxim Cournoyer]

Hi,

[...]

> It’s due to the bootloader.  This field from the bare bones template
> works:
>
>   (bootloader (bootloader-configuration
> (bootloader grub-bootloader)
> (targets '("/dev/sdX"
>
> but this from the desktop template doesn’t:
>
>   (bootloader (bootloader-configuration
> (bootloader grub-efi-bootloader)
> (targets '("/boot/efi"
>
> The manual for “guix system” gives a somewhat complicated invocation
> that I only found out about later:
>
>   image=$(guix system image --image-type=qcow2 \
>   gnu/system/examples/lightweight-desktop.tmpl)
>   cp $image /tmp/my-image.qcow2
>   chmod +w /tmp/my-image.qcow2
>   qemu-system-x86_64 -enable-kvm -hda /tmp/my-image.qcow2 -m 1000 \
>  -bios $(guix build 
> ovmf)/share/firmware/ovmf_x64.bin

Ah, I remember tripping on this.  GNOME Boxes can be built with ovmf
support and be able to boot with either a BIOS or UEFI bootloader but
bare QEMU cannot do so (and upstream appeared keen on keeping QEMU dumb
and keep the nicer abstractions for virtual-manager or GNOME Boxes
(maybe that's handled by libvirtd, I don't know).

> I haven’t tried it yet, but I assume that providing this extra “-bios”
> option would fix it.  It wasn’t necessary before, though, and I think
> it’s an inconvenient complication when running Guix VMs.
>
> Perhaps an example invocation of qemu-system-* could be added as a
> comment to the templates?

Or a simple nudge to the reference in the info manual?  This would avoid
duplicating the information (easing maintenance).  I think there's a way
to format it so that it opens directly as a URL in Emacs at least,
though I don't know the details.

-- 
Thanks,
Maxim

bug#66174: [BUG] poetry buil

[Danny Milosavljevic]

Hello,
This was broken by commits d477018b57d5b4c13b4dd35aa1c4ee1a00ca76e2and 21d6985a8b3c6e53aab648275dc27b72c7453437--one of which also hasan incorrect commit message. Obviously those commits can never haveworked since they require poetry in order to build themselves.
I've reverted commit d477018b57d5b4c13b4dd35aa1c4ee1a00ca76e2and followed up on the other one. It should work now.
This will cause 420 packages to be rebuilt.
Please try
  guix pull
and then try again.
For the record, it might still be nice to add an extra package for thenewer poetry, but not like this. I tried doing that, and then the build ofpoetry 1.4.2 broke because our python-virtualenv is too old for it.So as I said, it could never have worked like this.
 

bug#66207: Cannot boot VMs with grub-efi-bootloader

[Mathieu Othacehe]

Hey,

Some context around that.

Before recent commits, when we were producing qcow2 or raw images,
those were MBR images with an EFI partition. If the grub-bootloader
was used, then Grub was installed both in the post-MBR gap
and in the EFI partition. This means that a single image could be booted
with or without the qemu -bios option, i.e both in BIOS legacy
or in EFI mode.

Commit d57cab764122af69d52d8cc9c843456044e5d7bc changed the default
behaviour and the produced images were by default MBR images, without
EFI partitions.

I changed that with e5ed1712da049b1c3dcf01e0a7e02e48a8aff012 and
dfaeaae9c7e7283b99ad10aef3e61402e9820bc7 which introduced a new image
type called mbr-hybrid-raw, which is now the default image type,
restoring the previous behaviour.

Now it looks to me that what Ricardo is observing is not linked to any
of the changes mentioned above.  When using the grub-efi-bootloader,
Grub is never installed in the post-MBR gap. This was already the case
in 1.4.0 and is still true. Those images cannot be booted without the
qemu -bios option unless I'm mistaken.

Hope it helps,

Mathieu

bug#66279: Unexporting

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès  writes:

> Hi Maxim,
>
> Commit 03795e2ba27424fc98957da00f6c71325e7ae425 exports the
>  record type descriptor (RTD).
>
> Common practice is to keep RTDs private because by publishing them, we
> make it harder to change the ABI (because users might be matching fields
> positionally) and we make it trivial for users to forge records of that
> type, bypassing any checks we may have in the official constructor (such
> as “sanitizers”).

Perhaps we should document this?  More power to the users!

> What do you think of reverting this commit?  I don’t see references to
>  outside of its module.

I'd like to note there are also valid usages requiring a record type,
such as 'match-record' from (guix records).  Otherwise, I don't feel
strongly about it, but if if's done I think the rationale you gave above
should be documented in our contributing guidelines.

-- 
Thanks,
Maxim

bug#66207: Cannot boot VMs with grub-efi-bootloader

[Ricardo Wurmus]

Mathieu Othacehe  writes:

> Now it looks to me that what Ricardo is observing is not linked to any
> of the changes mentioned above.  When using the grub-efi-bootloader,
> Grub is never installed in the post-MBR gap. This was already the case
> in 1.4.0 and is still true. Those images cannot be booted without the
> qemu -bios option unless I'm mistaken.

FWIW I tried the 1.4.0 image at
https://ftpmirror.gnu.org/gnu/guix/guix-system-vm-image-1.4.0.x86_64-linux.qcow2,
which did boot just fine.

I suppose that one isn’t using the grub-efi-bootloader.

It’s quite possible that I’m one of only few people who are unaware of
the “-bios” option to qemu.  So there really isn’t any bug or regression
here, it’s just that my primitive mental model (use “guix system” to
build a VM, run with qemu) had not required upgrading until now.

For the benefit of people like me or newcomers perhaps the documentation
could make the dependency between the use of the grub-efi-bootloader and
additionally required qemu arguments a little clearer.

-- 
Ricardo

bug#57402: webkitgtk-with-libsoup2 fails to build on powerpc64le, breaking freecad

[Maxim Cournoyer]

reopen 57402
quit

Hi Marcel,

Marcel van der Boom  writes:

> I think this issue was wrongly retitled. While the
> webkitgtk-with-libsoup2 *was* also an issue (now fixed) the configure
> phase error as originally reported (reproduced below for clarity) is
> still there.
>
>
> CMake Error at
> /gnu/store/sigy8gnn715y6219syqh2a2fr70l5vly-qtbase-5.15.10/lib/cmake/Qt5/Qt5Config.cmake:28
> (find_
>  Could not find a package configuration file provided by
>  "Qt5WebEngineWidgets" with any of the following names:
>
>Qt5WebEngineWidgetsConfig.cmake
>qt5webenginewidgets-config.cmake
>
>  Add the installation prefix of "Qt5WebEngineWidgets" to
>  CMAKE_PREFIX_PATH
>  or set "Qt5WebEngineWidgets_DIR" to a directory containing one   of
> the above
>  files.  If "Qt5WebEngineWidgets" provides a separate development
>  package or
>  SDK, be sure it has been installed.
> Call Stack (most recent call first):
>  cMake/FreeCAD_Helpers/SetupQt.cmake:31 (find_package)
>  CMakeLists.txt:78 (include)

I'm not sure how you got so far, as on master it currently fails due to
the following dependencies failing to build [0]:

- netcdf-4.9.0 (due to  hdf4-alt-4.2.16-2)
- vtk-9.2.2 (also due to hdf4-alt-4.2.16-2)
- python-wxpython-4.2.0 (webkitgtk-with-libsoup2-2.40.5)
- python-matplotlib-3.5.2 (also webkitgtk-with-libsoup2-2.40.5)

[0]  https://ci.guix.gnu.org/build/2084250/details

Reopening as webkitgtk-with-libsoup2 is apparently still broken.

I tried fixing hdf4 but I got lost; Nix and Fedora are on 4.2.15 and
using Fedora's patches, which appear to me mostly obsoleted by changes
in 4.2.16; I reported the bug here [0] (that's the place linked on their
website although I also see they accept issues on Github [1]).

But it seems only 2 dependencies break freecad on powerpc64le.  Help
welcome!

[0]  https://jira.hdfgroup.org/browse/AES-11
[1]  https://github.com/HDFGroup/hdf4/issues

-- 
Thanks,
Maxim

bug#66174: [BUG] poetry buil

[Janneke Nieuwenhuizen]

Danny Milosavljevic writes:

Hi Danny,

> This was broken by commits d477018b57d5b4c13b4dd35aa1c4ee1a00ca76e2
> and 21d6985a8b3c6e53aab648275dc27b72c7453437--one of which also has
> an incorrect commit message. Obviously those commits can never have
> worked since they require poetry in order to build themselves.
>
> I've reverted commit d477018b57d5b4c13b4dd35aa1c4ee1a00ca76e2
> and followed up on the other one. It should work now.

It would be nice to have a (short) explanation in a revert commit log of
why a commit was reverted.

Thanks anyaway for your fix and the explananion here,
Greetings
Janneke

-- 
Janneke Nieuwenhuizen   | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com