Request for merging "go-team" branch

[Sharlatan Hellseher]

Hi!

I'm tempted to merge go-team to master today/tomorrow. Nothing major was
added since last time I've rebased it and the build coverage looks
positive without regression. ARM builds are still scheduled, but as I
noticed it's quite normal.

--
Thanks,
Oleg


signature.asc
Description: PGP signature

ruby-team - submodules, time to split

[Sharlatan Hellseher]

Hello Guix!

While browsing issues tracker I've noticed there more and more Ruby
packages targeting lonely (gnu packages ruby) module :-) which whould be
a pleasure for maintainers to be spited with some common logical
submodules e.g. ruby-xyz, ruby-maths, ruby-web etc.

WDYT?

--
Oleg


signature.asc
Description: PGP signature

Re: Status of python-team branch

[Sharlatan Hellseher]

Hi,

CC python-team

Let's prepare the branch to be merged?

I took a flag to fix build issues on python-team after introducing
adjustment to pyproject-build-system requiring python-setuptools and
python-wheel somtimes to be availalbe in inputs.

I try to minimise the amount of changes and just add missing inputs or
update the packages if it helps to fix the build.

** TODO 20241104203753-python-team
- [X] 1306855-4351017 python-mrkd-0.2.0
  - https://ci.guix.gnu.org/build/4351017/details
  - error: Test failed: 
  - [X] fix chain [1/1]
- [X] remove python-mrkd

- [X] 1306855-4350959 python-m2r-0.3.1
  - https://ci.guix.gnu.org/build/4350959/details
  - AttributeError: module 'mistune' has no attribute 'BlockGrammar'
  - [X] fix chain [3/3]
- [X] python-altair
  - [X] remove python-m2r
- [X] python-automat
  - [X] update 20.10.0->22.10.0
  - [X] remove python-m2r
  - [X] add python-setuptools and python-wheel
  - [X] swap to pyproejct-build-system
- [X] remove python-m2r

- [X] 1306855-4350978 python-mistune-next-2.0.4
  - https://ci.guix.gnu.org/build/4350978/details
  - ModuleNotFoundError: No module named 'setuptools'
  - [X] fix chain [16/16]
- [X] python-kiwisolver
  - [X] update to 1.4.6
  - [X] add python-setuptools and python-wheel
- [X] python-array-api-compat
  - [X] update 1.6->1.9.1
  - [X] add python-setuptools and python-wheel
- [X] python-assay
  - [X] add python-setuptools and python-wheel
- [X] python-botocore
  - [X] update 1.24.35->1.35.54
  - [X] add python-setuptools, python-wheel, python-jsonschema and 
python-pytest,
python-pytest-xdist
  - [X] enable tests
- [X] python-boto3
  - [X] update 1.21.35->1.35.54
  - [X] add python-setuptools, python-wheel, python-pytest-xdist
  - [X] enable tests
  - [X] swap to pyproejct-build-system
- [X] python-s3transfer
  - [X] update 0.5.0->0.10.3
  - [X] add python-setuptools, python-wheel, python-pytest-xdist
- [X] awscli@1
  - [X] update 1.22.90->1.35.20
  - [X] add python-setuptools, python-wheel, python-pytest-xdist
- [X] python-daft
  - [X] add python-setuptools and python-wheel
- [X] python-django
  - [X] add python-setuptools and python-wheel
- [X] python-immutables
  - [X] update 0.18->0.21
- [X] python-jplephem
  - [X] add python-setuptools and python-wheel
- [X] python-jsonpickle
  - [X] add python-wheel
- [X] python-lazy-loader
  - [X] add python-setuptools and python-wheel
- [X] python-lightning-utilities
  - [X] add python-setuptools and python-wheel
- [X] python-optree
  - [X] add python-setuptools and python-wheel
- [X] python-parameterized-next
  - [X] add python-setuptools and python-wheel

I've stoped on python-pillow-simd which failes on master.

More hands required =) 

--
Oleg


signature.asc
Description: PGP signature

Re: [PULL] Request for pull/commit some old & easy updates

[Sharlatan Hellseher]

Hi Steve,

Thank you for digrest!

I'll try to review and apply when I have some time slot.

Oleg

On Sat, 2 Nov 2024 at 22:31, Steve George  wrote:
>
> Hi Sharlatan,
>
> I've been working on going through the bugtracker to find some 'old' but 
> low-risk patches. As I don't have commit access, would you would be willing 
> to Pull from my tree?
>
> It saves me re-exporting to email, sending etc.
>
> They're all low-risk as don't cause any dependent rebuilds to be required. 
> I've applied each one, built/installed it and where possible run it.
>
> I can go through and close the bugs when you're done.
>
> The following changes since commit 80d8996192520e9af7418ea9248a5fcecad6ac30:
>
>   gnu: stargate: Switch to Qt6. (2024-10-31 14:26:17 +0800)
>
> are available in the Git repository at:
>
>   https://codeberg.org/futurile/guix-dev.git patch-review1
>
> for you to fetch changes up to 15f574ab5ba62f04a190d44f1e72d3709aeda13a:
>
>   gnu: python-heatwave: New variable. (2024-11-02 22:22:42 +)
>
> 
> (from the branch description for patch-review1 local branch)
>
> Patch reviews on master
> 
> "Paul A. Patience" (2):
>   gnu: debug-assert: New variable.
>   gnu: type-safe: New variable.
>   #69126
>
> Christian Miller (1):
>   gnu: kvirc: New variable.
>   #68239
>
> Greg Hogan (1):
>   gnu: Add git-extras.
>   #69548
>
> Juliana Sims (2):
>   gnu: nicotine+: Update to 3.3.0.
>   gnu: nicotine+: Use G-expressions.
>   #69277
>
> Luis Guilherme Coelho (2):
>   gnu: font-meslo-lg: New variable.
>   gnu: font-meslo-lg-dz: New variable.
>   #68013
>
> Stefan (1):
>   gnu: google-roboto-mono: New variable.
>   #67869
>
> Wilko Meyer (2):
>   gnu: Add python-monthdelta.
>   gnu: python-heatwave: New variable.
>   #69548
>
> terramorpha (1):
>   gnu: newsraft: New variable.
>   #68063
>
>  gnu/packages/cpp.scm | 86 
> +-
>  gnu/packages/fonts.scm   | 72 
> 
>  gnu/packages/irc.scm | 42 
> ++
>  gnu/packages/nicotine.scm| 85 
> ++---
>  gnu/packages/python-xyz.scm  | 36 
>  gnu/packages/syndication.scm | 31 +++
>  gnu/packages/version-control.scm | 75 
> +++
>  7 files changed, 387 insertions(+), 40 deletions(-)
>
> Thanks!
>
> Steve / Futurile
>


-- 
VCS: https://github.incerto.xyz/; https://git.sr.ht/~hellseher/
GPG: 9847 81DE 689C 21C2 6418 0867 76D7 27BF F62C D2B5

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

Re: python-dbus-python changes triggered many rebuilds

[Sharlatan Hellseher]

Hi,

I've canceled the pending builds.

Sorry it was me, not expected that order of the same inputs would trigger the
build.

The reasoning was to refactor the indentation and higlight that
python-meson-python has to be replaced by meson-python.

Thanks,
Oleg

On Sat, 2 Nov 2024 at 00:20, Vagrant Cascadian  wrote:
>
> A large rebuild was triggered by:
>
> commit a9abf9a7b30f6801e122cae759df87b44c458773
> Author: Sharlatan Hellseher 
> Date:   Fri Nov 1 21:10:04 2024 +
>
> gnu: python-dbus-python: Fix indentation.
>
> * gnu/packages/python-xyz.scm (python-dbus-python): Fix indentation,
> adjust order of fields, sort inputs alphabetically.
>
> Change-Id: I895518f041bd2cfc9c2f94774a9d1db47b26ffc3
>
> Guix refresh claims this would trigger 3987 builds on x86_64-linux, and
> ci is cranking away at over 13000 builds across several architectures:
>
>https://ci.guix.gnu.org/eval/1772855
>
> Anyone able to cancel that evaluation?
>
>
> I pushed a commit reverting the ordering changes, which I think appears
> to not trigger the rebuild:
>
> commit ea11d3608566174c4bae70faa4f9d0c67748d2db
> Author: Vagrant Cascadian 
> Date:   Fri Nov 1 16:55:02 2024 -0700
>
> gnu: python-dbus-python: Revert ordering change on native-inputs.
>
> A large number of rebuilds (3987 according to guix refresh) was triggered 
> by:
>
>   a9abf9a7b30f6801e122cae759df87b44c458773 gnu: python-dbus-python: Fix
>   indentation.
>
> Reverting the ordering changes does not trigger any rebuilds.
>
> * gnu/packages/python-xyz.scm (python-dbus-python): Unsort native-inputs.
>
>
> Hopefully that was the right thing to do!
>
>
> live well,
>   vagrant



-- 
VCS: https://github.incerto.xyz/; https://git.sr.ht/~hellseher/
GPG: 9847 81DE 689C 21C2 6418 0867 76D7 27BF F62C D2B5

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

Re: SageMath packaging work

[Sharlatan Hellseher]

Hi,

70924 is merged

Figuring out which patches from V3 56729 may be easy pass forward

Thanks,
Oleg

On Wed, 10 Jul 2024, 00:55 Vinicius Monego,  wrote:

> Hi Ada,
>
> Em ter, 2024-07-09 às 07:27 +, Ada Stevenson escreveu:
> > Hi Vinicus,
> >
> > On 01/06/2024 6:43 am, Vinicius Monego wrote:
> > > Em qua, 2024-05-22 às 09:19 +, Ada Stevenson escreveu:
> > > > Hi Guix, science team!
> > > >
> > > > I was reaching for SageMath today and couldn't find it in the
> > > > package
> > > > repository. I notice there's a sagemath.scm file, but no actual
> > > > SageMath
> > > > package proper. Is there any work being done on packaging it at
> > > > the
> > > > moment? Are there any particular blockers preventing its
> > > > packaging
> > > > (excessive dependencies, difficult build etc.)?
> > > >
> > > > Having SageMath in Guix would be really handy for me, so I'm
> > > > happy to
> > > > give packaging it a go if the only reason is that there's not
> > > > enough
> > > > interest (I will just have to wait until after exams, so in about
> > > > 3-4
> > > > weeks).
> > > >
> > > > Hope you are all doing well!
> > > >
> > > > Warmly,
> > > > Ada
> > > >
> > >
> > > Hi Ada,
> > >
> > > SageMath has a lot of dependencies which you can see on
> > > https://doc.sagemath.org/html/en/reference/spkg/
> > >
> > > These are my current notes (I'm not sure how to organize them
> > > online):
> >
> > Thank you! This is a great resource. Sorry for not responding
> > earlier, I
> > was in the midst of exams. I just want to check if this is still up
> > to
> > date, as far as you know. I want to start helping out with this
> > effort.
> >
>
> Yes, it is up to date.
>
> I am still waiting for the python-team branch to be merged because it
> also introduces dependencies for jupyterlab, which I am interested in
> packaging. Issue 70924 could be merged already, if anyone wants to
> review, and then I merge it in the weekend.
>
> > >
> > > Standard packages:
> > >
> > > + Available in the python-team branch (not yet merged):
> > >
> > > - fqdn (python-team)
> > > - isoduration (python-team)
> > > - jupyter-events (python-team)
> > > - jupyter-server-terminals (python-team)
> > > - notebook-shim (python-team)
> > > - overrides (python-team)
> > > - referencing (python-team)
> > > - rfc3986-validator (python-team)
> > > - uri-template (python-team)
> > >
> > > + Series 1 (submitted as issue 70924):
> > >
> > > - async-lru (review)
> > > - calver (review)
> > > - memory-allocator (review)
> > > - pplpy (review)
> > > - primecount (review)
> > > - primecountpy (review)
> > > - pyproject-api (review)
> > > - types-python-dateutils (review)
> > >
> > > + Series 2 (currently working on, not yet submitted):
> >
> > How are you going with this series? Is there anything I can help
> > with?
> >
>
> I think the best approach right now is to update the packages from
> issue 56729. Some of these have been submitted there but are out of
> date, and some others I updated in 70924. I'll help reviewing your
> submission. Also, I didn't go any further on the list since my last
> message.
>
> > >
> > > - gfan (NEXT)
> > > - gnumake-tokenpool (v0.0.7+ needs Python 3.11+)
> > > - jupyter-lsp (needs updated jupyter-core)
> > > - palp http://hep.itp.tuwien.ac.at/~kreuzer/CY/CYpalp.html (NEXT)
> > > - pytz-deprecation-shim (OK but temporary usage only)
> > > - sympow
> > > - tachyon: http://jedi.ks.uiuc.edu/~johns/raytracer/files/
> > >
> > > + Remaining standard packages:
> > >
> >
> > I'll give these a go.
> >
>
> Sounds good.
>
> > > - combinatorial-designs
> > > - comm
> > > - conway-polynomials
> > > - elliptic-curves
> > > - graphs
> > > - jmol
> > > - jsonschema-specifications
> > > - jupyter-jsmol
> > > - jupyterlab
> > > - jupyterlab-mathjax2
> > > - pari-galdata
> > > - pari-seadata-small
> > > - polytopes-db
> > > - pplpy-doc
> > > - sage-conf
> > > - sage-docbuild
> > > - sage-setup
> > > - sagenb-export
> > > - sagetex
> > > - sphinx-inline-tabs
> > > - threejs
> > >
> > > Optional packages:
> >
> > Wow, that is a lot!
> > >
> > > - admcycles
> > > - benzene
> > > - buckygen
> > > - coxeter3
> > > - csdp
> > > - cunningham-tables
> > > - cylp
> > > - d3js
> > > - database-cremona-ellcurve
> > > - database-cubic-hecke
> > > - database-jones-numfield
> > > - database-knotinfo
> > > - database-kohel
> > > - database-mutation-class
> > > - database-stein-watkins
> > > - database-stein-watkins-mini
> > > - database-symbolic-data
> > > - dsdp
> > > - e-antic
> > > - frobby
> > > - gap-jupyter
> > > - gap-packages
> > > - github-cli
> > > - glucose [looks easy]
> > > - jupymake
> > > - kenzo
> > > - latte-int
> > > - libsemigroups [looks easy]
> > > - lidia
> > > - mathics
> > > - mathics-scanner
> > > - matroid-database
> > > - mcqd
> > > - meataxe
> > > - msolve
> > > - nibabel [looks easy]
> > > - normaliz [looks easy]
> > > - notedown
> > > - onetbb
> > > - ore-algebra
> > > - p-group-cohomology
> > > - pandoc-attributes
> > > - papilo
> > 

Re: Go Package with multiple subpackage

[Sharlatan Hellseher]

Hi Denis,

Adding to Andreas's thesis - it's hard to be the first =) and extending
your concern - start with small; small series, small contribution,
small steps, but be persistent in your efforts and keep the attitude
(refering to Chris Hadfield's "An Astronaut's Guide to Life on Earth").

To ease you first step - just don't think about overwhelming complexity
of bringing all 500+ (or more) packages into Guix at one go, start with
short logical series say 5-10. Contribution in small series is,
personally as a commiter, easy to review and merge quickly than wait for
months when someone has a free time slot to review long chain (I
try to find time between family duties and main job).

Sending small series from larger count of involved contributors makes
propagation of new packages much faster, e.g. you may pack 10 projects
which will be in inputs for others sent by someone else etc.

Take a look at the current effort of unbundle (gnu packages ipfs) -
kubo. Bit by bit and we nearly unweaved the rainbow.

--8<---cut here---start->8---
I've also no idea about how many go packages use bundled dependencies,
so maybe if there is a way to somehow un-bundle part of the
dependencies it could be a road to improve the situations as the
maintenance the dependencies shared by many go packages could be shared
somehow (assuming people do check that when updating things it doesn't
break other packages).
--8<---cut here---end--->8---

This part may be addressed in go-build-system with default phase,
removing "vendor" directory - the only way to bundle in Go ecosystem.

--8<---cut here---start->8---
Another issue is that all that is statically built but that's part of
the default go compiler if I understood well, though given how Guix
works, it might easier to somehow use shared libraries (compared to
more standard distributions) if some compilers that support that since
we don't need very strict/strong ABI guarantees with Guix, and thanks
to that, reduce build times and resources consumption (like RAM, space,
etc).
--8<---cut here---end--->8---

There is nearly 0 linking to any libraries in Go ecosystem, each
"library" is a bunch of code which compiler use to build the final
binary, nothing is linked in terminology of C/C++ e.g. - library from
the Golang point of view is a source code (text, not blob)

--8<---cut here---start->8---
What would be the quality of the maintenance in the long run with
about 500 packages to update?
--8<---cut here---end--->8---

No need to update all the chain to make a fresh version of final binary
in most cases it's enough to refresh 2-3 packages to make build/test
green. Golang does not implement any pin mechanics for dependencie
versions like Rust/Cargo does.

So... let's get packages be packed and review in small consistence flow,
keep your altitude and let the curiosity be with you!

Keep hacking.

--
Oleg


signature.asc
Description: PGP signature

Re: Re: Go Package with multiple subpackage

[Sharlatan Hellseher]

Hi,

Some feed back from my latest experience with go refresh and sorting
packages task. Guix contain few packages with bundled dependencies (300+
each), it would be a peas-full time if they were packed fully in the
first place but it was not for some reason.

CC avp who makes an effort to 100% unbundle IPFS Kubo package.

On my radar to update and unbundle after go-team branch is merged:

- go-afero
- go-bitmask
- go-boxo
- go-cadvisor
- go-chezmoi
- go-libp2p-pubsub
- go-matterbridge
- go-rclone
- go-restic
- go-run
- go-runc
- go-vale
- go-viper
- go-xtaci-kcp-go-v5

Good news we have a fresh importer adjusments which deal with workspace
and sub-path tags in go-team.

--
Thanks,
Oleg


signature.asc
Description: PGP signature

Re: update golang version

[Sharlatan Hellseher]

Hi,

The fresh version of Golang and some core go packages are in the queue
to be merged into master branch. If you would like to
test/check/contribute feel free to opt in go-team branch.

https://git.savannah.gnu.org/cgit/guix.git/log/?h=go-team

--
Thanks,
Oleg


signature.asc
Description: PGP signature

Upgrading NumPy and friends

[Sharlatan Hellseher]

Hi Guix!

I would like to open a conversation on upgrading NumPy, Pandas, Numba
and SciPY.

It would be reasonable to refresh that core scientific packages for
Python after merging python-team which is nearly finished building.

Stats:
- branch :: master
- repository URL :: https://git.savannah.gnu.org/git/guix.git
- commit :: 48097f511929053468ce6f09e0a24644c90fe670

| Package   | Dependents | Guix version | Upstream version | Checked
|
|---++--+--+|
| python-numba  |136 |   0.56.4 |   0.60.0 | <2024-10-19 
Sat 08:42> |
| python-numpy  |   3394 |   1.23.2 |2.1.2 | <2024-10-19 
Sat 08:38> |
| python-pandas |423 |2.1.1 |2.2.3 | <2024-10-19 
Sat 08:43> |
| python-scipy  |334 |   1.12.0 |   1.14.1 | <2024-10-19 
Sat 08:42> |

I've started noticing that more and more projects require a fresh
version of NumPy during Astro upgrade monthly, sometimes it's captured
on sanity check phase, but most of the time the package is just not work
especially when it depends on python-astropy which heavily depends on
NumPy.

Does anyone work on that packages or would be interested in taking the
flag?

--
Thanks,
Oleg


signature.asc
Description: PGP signature

Request for merging "go-team" branch

[Sharlatan Hellseher]

Hi Guix!

After a few weeks of working on go-team it's ready for the final review
and merge to master.

My target was to update and move packages from (gnu packages golang) to
logical submodules and prepare bare minimal refreshed amount to complete
Prometheus packaging.

* Covered issues

- <https://issues.guix.gnu.org/69827>
  [PATCH 1/3] build-system/go: Add subdir parameter to go-version->git-ref.

- <https://issues.guix.gnu.org/73171>
  [PATCH] gnu: go-1.23: Update to 1.23.1.

- <https://issues.guix.gnu.org/73176>
  [PATCH] gnu: go-1.20: Build with gccgo-12 on some systems.

- <https://issues.guix.gnu.org/73299>
  [PATCH] build/go: Replace symlinks with a copy of the file.

- <https://issues.guix.gnu.org/73184>
[PATCH 0/5] Add some Golang libraries from the "awesome-go" list

- <https://issues.guix.gnu.org/69376>
[PATCH go-team] build-system/go: Allow providing additional test flags.

#69827 may cover/resolve few more:
- <2021-12-07> guix import go error https://issues.guix.gnu.org/52362
  by Stephen Webber 

- <2023-04-21> Go importer doesn't know MODULE/vX.Y version tags
  https://issues.guix.gnu.org/63001 by Timo Wilken  g...@twilken.net

- <2023-05-22> [PATCH 0/2] Fix annoyance with "guix import go"
  https://issues.guix.gnu.org/63647 by Simon Tournier
  

- <2023-06-12> [PATH] fix a bug on importing go packages.
  https://issues.guix.gnu.org/64035,
  https://issues.guix.gnu.org/64036 by Elbek

* Findings and potential refresh blockers

During refresh I've faced with go packages which still include vendor
directory and due to a large packaging efforts requiring to unbundle
them all might need some efforts distribution among volunteers.

Me and Artyom unbundling Kubo in our leisure time but the final step
(boxo) requires at least 300+ new packages.

- bitmask   : 0.21.11->0.24.8 requires 
go-github-com-xtaci-kcp-go
- chezmoi   : 1.8.10->2.52.2, 34+ new packages
- go-github-com-google-cadvisor : 0.0.0-0.2ed7198->0.50.0 216+ new packages
- go-github-com-ipfs-boxo   : to unbundle from Kubo, 218+ new packages
- go-github-com-spf13-afero : 1.2.2->1.11.0, 194+ new packages
- go-github-com-spf13-viper : 1.7.0->1.19.0, 225+ new packages
- go-github-com-xtaci-kcp-go: to update bitmask, 200+ new packages
- rclone: 1.52.3->1.68.0, 348+ new packages
- restic: 0.9.6->0.17.1, 221+ new packages

Some of them may intersect.

* Branch stats

--8<---cut here---start->8---
---[ Commits stats ]---
* from-to: caa9b4cbcb..ad39aa19
* count: 169

---[ Packages stats ]---
* added: 44
* fixed: 25
* adjusted: 2
* realocated: 21
* removed: 7
* updated: 44

---[ Contributors ]---
* Artyom V. Poptsov 
* Brennan Vincent 
* Christina O'Donnell 
* Efraim Flashner 
* Sharlatan Hellseher 
* Troy Figiel 

---[ Refresh inpact ]---
Building the following 764 packages would ensure 1686 dependent packages are 
rebuilt
--8<---cut here---end--->8---

* Script

--8<---cut here---start->8---
#!/usr/bin/env bash

REQUIRE=(
git
grep
awk
)

get_refreshed_pkg()
{
local start="$1"
local end="$2"
local pkgs=$(mktemp -t packages.XX)

git log "$start".."$end" --oneline |
awk -F: '/gnu:.*:.*\./{print $2}' |
sed -e 's/.*\/.*//' |
sort -u |
while read -r pkg
do
if ./pre-inst-env guix show "$pkg" &>/dev/null
then
printf "%s " "$pkg" >> "$pkgs"
fi
done

./pre-inst-env guix refresh --list-dependent $(cat "$pkgs") |
awk -F: '{print $1}'

rm "$pkgs"
}

main()
{
   local start="$1"
   local end="$2"

   printf -- "---[ Commits stats ]---\n"
   printf "* from-to: %s..%s\n" "$start" "$end"
   printf "* count: %s\n" $(git log "$start".."$end" --oneline | wc -l)

   printf -- "\n---[ Packages stats ]---\n"
   printf "* added: %s\n" $(git log "$start".."$end" --oneline | grep "gnu: 
Add" -c)
   printf "* fixed: %s\n" $(git log "$start".."$end" --oneline | grep 
"gnu:.*Fix" -c)
   printf "* adjusted: %s\n" $(git log "$start".."$end" --oneline | grep 
"gnu:.*Adjust\|gnu:.*Improve" -c)
   printf "* realocated: %s\n" $(git log "$start".."$end" --oneline | grep 
"gnu:.*Move to" -c)
   printf "* removed: %s\n" $(git log "$start".."$end" --oneline | grep "gnu: 
Remove" -c)
   printf "* updated: %s\n" $(git log "$start".."$end" --oneline | grep 
"gnu:.*Update" -c)

   printf "\n---[ Contributors ]---\n"
   git log "$start".."$end" --graph --pretty=format:'%an <%ae>' | sort -u

   printf -- "\n---[ Refresh inpact ]---\n"
   get_refreshed_pkg "$start" "$end"
}

main "$@"
--8<---cut here---end--->8---

--
Oleg


signature.asc
Description: PGP signature

Re: Status of python-team branch

[Sharlatan Hellseher]

Hi,

Same for me, starting resolving rebase conflict.

I'm finishing go-team right now and will have some free time on Sat.

Thanks,
Oleg

On Thu, 26 Sept 2024, 16:01 Christopher Baines,  wrote:

> Sharlatan Hellseher  writes:
>
> > Hi,
> >
> > I may volunteer myself to that
> > - rebase on current master
> > - resolve conflicts
> > - apply pending patches from issues
> > - push for testing
> > - merge to master
> >
> >  Is anyone interested in rebasing the branch?
>
> Are you still looking at rebasing python-team?
>
> I've looked at it myself, but I've got stuck with the big "gnu: Add
> python-setuptools/python-wheel where necessary."
> (Icd7699fc1dc56e974ae7568f2ae916dbf876bea5) commit.
>

Re: Status of python-team branch

[Sharlatan Hellseher]

Hi necto,

Please take a look at current merge status of the branch, it may be
delayed.

https://issues.guix.gnu.org/71408

--
Oleg 


signature.asc
Description: PGP signature

Go Package with multiple subpackage

[Sharlatan Hellseher]

Hi,

That issue is resolved on go-team branch which it's prepared for the
merge right now.

See 
- 
https://git.savannah.gnu.org/cgit/guix.git/commit/?h=go-team&id=45cbf468d25ddb0075db14f372caea8ba1add26c
- 
https://git.savannah.gnu.org/cgit/guix.git/commit/?h=go-team&id=d691b09392fa0034d4ccbcd5b1d9b5b71af609d9
- 
https://git.savannah.gnu.org/cgit/guix.git/commit/?h=go-team&id=23dbf8d073fa0eae4f3422d2997078c44d295074

I'm about to refresh/import all dependencies to upgrade/unbundle:

- go-afero:201
- go-boxo:223
- go-chezmoi:38
- go-matterbridge:300+
- go-rclone:352
- go-restic:225
- go-viper:227
- go-xtaci-kcp-go-v5:203

Feel free to check go-branch and how the import works now.
It also has fix for embed files via new key parameter #:embed-files and
additional #:test-flags.

--
Oleg


signature.asc
Description: PGP signature

Re: Updating rclone and non-free dependencies

[Sharlatan Hellseher]

Hi Attila,

I've pushed patches adjusting import from
 proposed by Christina O'Donnell
. As you may check the thread - all recent work on
improving import are mentioned and #69827 looks more tempting to be
applied as it implements logic to work with monorepo, stared to be
popular in Golang projects.

Recursive import did not break for a large chain for me, up to 400 inputs.

Update/unbundle stats:

- https://github.com/spf13/afero 1.2.2->1.11.0 require +209 packages
- https://github.com/rclone/rclone 1.53.2->1.68.0 require +360 packages
- https://github.com/restic/restic 0.9.6->0.17.1 requires +237 packages

- https://github.com/ipfs/boxo to unbundle from Kubo
- https://github.com/42wim/matterbridge 1.26.0 to unbundle, breaks on
some network issue on 330 something input

It gives me some confident to keep that change (#69827).

go-team contains updates of golang-build module which require to rebuild
most of the dependent packages.

There is also a patch series fixing issue with embed files
.

I'd like to merge #73299 and resolve all packages where needed, then the
branch is ready for review and hope soonish merge into master.

Containing changes will bring more smooth importing experiance and groud
work for final set of packages for Prometheus which I about to submit.

--
Oleg


signature.asc
Description: PGP signature

Updating rclone and non-free dependencies

[Sharlatan Hellseher]

Hi,

Thanks for taking the upgrade flag.

The go-team branch contains changes to importer which makes recursive
import much easier.

May you elaborate on non-free software please?

Guix has aws-sdk-go and aws-sdk-go-v2 for a long (5+y) time the license
is asl2.0 (Apache License) as most of the golang code are Expat (MIT).

- https://github.com/aws/aws-sdk-go?tab=Apache-2.0-1-ov-file#readme
- https://github.com/aws/aws-sdk-go-v2?tab=Apache-2.0-1-ov-file#readme
- https://github.com/Azure/azure-sdk-for-go?tab=MIT-1-ov-file#readme

I did estimation on packaging effort for rclone and restic both have
intersecting list of dependencies and they are about 250 in total.

--
Oleg


signature.asc
Description: PGP signature

Re: Status of python-team branch

[Sharlatan Hellseher]

Hi,

I may volunteer myself to that
- rebase on current master
- resolve conflicts
- apply pending patches from issues
- push for testing
- merge to master

Is anyone interested in rebasing the branch?
>

Oleg

>

Status of python-team branch

[Sharlatan Hellseher]

Hi Guix!

I'd like to check who is working on python-team branch to prepare it for
the merge? Especially I'd need to test a fresh version of python-attrs
which involves rebuild of 1000+ packages:

--8<---cut here---start->8---
> ./pre-inst-env guix refresh --list-dependent python-attrs
Building the following 472 packages would ensure  dependent packages
are rebuilt: <...>
--8<---cut here---end--->8---

It's during monthly Astro packages update which requires attrs>=22.2.0 

Update default Golang version on go-team branch

[Sharlatan Hellseher]

Hi Guix!

I had a courage to refresh the default Goang version to build packages
from 1.17 to 1.21 as all version before it are already EoL. After
rebuilt 900+ packages locally I've fixed some failing to build packages.

The packages in golang-build were refresh as well which involve to
rebuild about 1000+ packages depending on them.

The changes are pushed to go-team brunch to check any other failures.

My plan is to continue shifting packages from golang.scm to dedicated
submodules which may boost maintainability of Golang ecosystem.

I'd like to highlight a "feature" of the `go:embedded` build option
which fails to archive during build without this hack:
--8<---cut here---start->8---

  ;; FIXME: Pattern embedded: cannot embed directory embedded:
  ;; contains no embeddable files.
  ;;
  ;; This happens due to Golang can't determine the valid directory of
  ;; the module which is sourced during setup environment phase, but
  ;; easy resolved after coping to expected directory "vendor" within
  ;; the current package, see details in Golang source:
  ;;
  ;; - URL: 
  ;; - commit: 82c14346d89ec0eeca114f9ca0e88516b2cda454
  ;; - file: src/cmd/go/internal/load/pkg.go#L2059
  (add-before 'build 'copy-input-to-vendor-directory
(lambda* (#:key import-path #:allow-other-keys)
  (with-directory-excursion (string-append "src/" import-path)
(mkdir "vendor")
(copy-recursively
 (string-append
  #$(this-package-native-input 
"go-github-com-charmbracelet-glamour")
  "/src/github.com")
 "vendor/github.com")
(copy-recursively
 (string-append
  #$(this-package-native-input 
"go-github-com-alecthomas-chroma-v2")
  "/src/github.com")
 "vendor/github.com"
  (add-before 'install 'remove-vendor-directory
(lambda* (#:key import-path #:allow-other-keys)
  (with-directory-excursion (string-append "src/" import-path)
(delete-file-recursively "vendor")))
--8<---cut here---end--->8---

It might need some adjustment to go-build-system.

Related issues:
- https://issues.guix.gnu.org/71011

--
Oleg


signature.asc
Description: PGP signature

Re: python-duckdb stuck in its tests

[Sharlatan Hellseher]

Hi,

I've pushed update togather with https://issues.guix.gnu.org/71480. It
 fixed the build, check and sanity check phases in
ce98c3436c57e7b366a3ec06c47a7e8919c990fb.

Thanks,
Oleg

On Sun, 30 Jun 2024 at 11:02, Sharlatan Hellseher  wrote:
>
> Hi Andreas,
>
> It looks like updating to 1.0.0 has not issue wit passing test on my
> local checkout after applying this patch
>
> --8<---cut here---start->8---
> @@ -23334,20 +23334,24 @@ (define-public python-chevron
>  (define-public python-duckdb
>(package
>  (name "python-duckdb")
> -(version "0.8.1")
> +(version "1.0.0")
>  (source (origin
>(method url-fetch)
>(uri (pypi-uri "duckdb" version))
>(sha256
> (base32
> -"1sgfmii5xlkbx3hzyjxg80gl2ni1rxpabahl4gww9by2mgs3fkd5"
> +"0lyl6di1c7j31i2mk384j711kzyyf9rjd3nqx5mbgmf7gfvmk852"
>  (build-system pyproject-build-system)
>  (arguments
>   (list
>#:test-flags
>'(list "--ignore=tests/slow/test_h2oai_arrow.py"
> - ;; Don't install anything, thank you.
> - "-k" "not test_install_non_existent_extension")
> + "-k" (string-append
> +   ;; Don't install anything, thank you.
> +   "not test_install_non_existent_extension"
> +   ;; assert not ["error: duckdb failed to find <..>
> +   ;; site-packages/duckdb/__init__.py
> +   " and not test_generated_stubs"))
>#:phases
>#~(modify-phases %standard-phases
>;; Tests need this
> --8<---cut here---end--->8---
>
> But Sanity check is not happy with:
> --8<---cut here---start->8---
> starting phase `sanity-check'
> validating 'duckdb'
> /gnu/store/cvr5g1ivssavn3v5bhnbnpkm2zpwyj2s-python-duckdb-1.0.0/lib/python3.10/site-packages
> ...checking requirements: OK
> ...trying to load module adbc_driver_duckdb: ERROR:
> Traceback (most recent call last):
>   File "/gnu/store/iqsjkp55pcx5bfcp2jm9yj5rlx9a0whd-sanity-check.py",
> line 73, in 
> importlib.import_module(name)
>   File 
> "/gnu/store/4ncpi13lpwj8fk3j7adgnr5mi90dz311-python-3.10.7/lib/python3.10/importlib/__init__.py",
> line 126, in import_module
> return _bootstrap._gcd_import(name[level:], package, level)
>   File "", line 1050, in _gcd_import
>   File "", line 1027, in _find_and_load
>   File "", line 1006, in _find_and_load_unlocked
>   File "", line 688, in _load_unlocked
>   File "", line 883, in exec_module
>   File "", line 241, in _call_with_frames_removed
>   File 
> "/gnu/store/cvr5g1ivssavn3v5bhnbnpkm2zpwyj2s-python-duckdb-1.0.0/lib/python3.10/site-packages/adbc_driver_duckdb/__init__.py",
> line 24, in 
> import adbc_driver_manager
> ModuleNotFoundError: No module named 'adbc_driver_manager'
> ...trying to load module duckdb: OK
> ...trying to load module duckdb-stubs: OK
> error: in phase 'sanity-check': uncaught exception:
> %exception #<&invoke-error program: "python" arguments:
> ("/gnu/store/iqsjkp55pcx5bfcp2jm9yj5rlx9a0whd-sanity-check.py"
> "/gnu/store/cvr5g1ivssavn3v5bhnbnpkm2zpwyj2s-python-duckdb-1.0.0/lib/python3.10/site-packages")
> exit-status: 1 term-signal: #f stop-signal: #f>
> phase `sanity-check' failed after 0.2 seconds
> command "python"
> "/gnu/store/iqsjkp55pcx5bfcp2jm9yj5rlx9a0whd-sanity-check.py"
> "/gnu/store/cvr5g1ivssavn3v5bhnbnpkm2zpwyj2s-python-duckdb-1.0.0/lib/python3.10/site-packages"
> failed with status 1
> builder for 
> `/gnu/store/8i8z6fynmyg35x48dln3lgl1z1vqiygy-python-duckdb-1.0.0.drv'
> failed with exit code 1
> build of /gnu/store/8i8z6fynmyg35x48dln3lgl1z1vqiygy-python-duckdb-1.0.0.drv
> failed
> View build log at
> '/var/log/guix/drvs/8i/8z6fynmyg35x48dln3lgl1z1vqiygy-python-duckdb-1.0.0.drv.gz'.
> --8<---cut here---end--->8---
>
> Oleg
>
> On Sun, 30 Jun 2024 at 09:23, Andreas Enge  wrote:
> >
> > Hello the Python team,
> >
> > python-duckdb sticks out on the build farm, since it apparently gets blocked
> > in its tests after spending quite some CPU time for building, and finally
> > it times out after a day. It seems to happen consistently over seve

Re: python-duckdb stuck in its tests

[Sharlatan Hellseher]

Hi Andreas,

It looks like updating to 1.0.0 has not issue wit passing test on my
local checkout after applying this patch

--8<---cut here---start->8---
@@ -23334,20 +23334,24 @@ (define-public python-chevron
 (define-public python-duckdb
   (package
 (name "python-duckdb")
-(version "0.8.1")
+(version "1.0.0")
 (source (origin
   (method url-fetch)
   (uri (pypi-uri "duckdb" version))
   (sha256
(base32
-"1sgfmii5xlkbx3hzyjxg80gl2ni1rxpabahl4gww9by2mgs3fkd5"
+"0lyl6di1c7j31i2mk384j711kzyyf9rjd3nqx5mbgmf7gfvmk852"
 (build-system pyproject-build-system)
 (arguments
  (list
   #:test-flags
   '(list "--ignore=tests/slow/test_h2oai_arrow.py"
- ;; Don't install anything, thank you.
- "-k" "not test_install_non_existent_extension")
+ "-k" (string-append
+   ;; Don't install anything, thank you.
+   "not test_install_non_existent_extension"
+   ;; assert not ["error: duckdb failed to find <..>
+   ;; site-packages/duckdb/__init__.py
+   " and not test_generated_stubs"))
   #:phases
   #~(modify-phases %standard-phases
   ;; Tests need this
--8<---cut here---end--->8---

But Sanity check is not happy with:
--8<---cut here---start->8---
starting phase `sanity-check'
validating 'duckdb'
/gnu/store/cvr5g1ivssavn3v5bhnbnpkm2zpwyj2s-python-duckdb-1.0.0/lib/python3.10/site-packages
...checking requirements: OK
...trying to load module adbc_driver_duckdb: ERROR:
Traceback (most recent call last):
  File "/gnu/store/iqsjkp55pcx5bfcp2jm9yj5rlx9a0whd-sanity-check.py",
line 73, in 
importlib.import_module(name)
  File 
"/gnu/store/4ncpi13lpwj8fk3j7adgnr5mi90dz311-python-3.10.7/lib/python3.10/importlib/__init__.py",
line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 1050, in _gcd_import
  File "", line 1027, in _find_and_load
  File "", line 1006, in _find_and_load_unlocked
  File "", line 688, in _load_unlocked
  File "", line 883, in exec_module
  File "", line 241, in _call_with_frames_removed
  File 
"/gnu/store/cvr5g1ivssavn3v5bhnbnpkm2zpwyj2s-python-duckdb-1.0.0/lib/python3.10/site-packages/adbc_driver_duckdb/__init__.py",
line 24, in 
import adbc_driver_manager
ModuleNotFoundError: No module named 'adbc_driver_manager'
...trying to load module duckdb: OK
...trying to load module duckdb-stubs: OK
error: in phase 'sanity-check': uncaught exception:
%exception #<&invoke-error program: "python" arguments:
("/gnu/store/iqsjkp55pcx5bfcp2jm9yj5rlx9a0whd-sanity-check.py"
"/gnu/store/cvr5g1ivssavn3v5bhnbnpkm2zpwyj2s-python-duckdb-1.0.0/lib/python3.10/site-packages")
exit-status: 1 term-signal: #f stop-signal: #f>
phase `sanity-check' failed after 0.2 seconds
command "python"
"/gnu/store/iqsjkp55pcx5bfcp2jm9yj5rlx9a0whd-sanity-check.py"
"/gnu/store/cvr5g1ivssavn3v5bhnbnpkm2zpwyj2s-python-duckdb-1.0.0/lib/python3.10/site-packages"
failed with status 1
builder for 
`/gnu/store/8i8z6fynmyg35x48dln3lgl1z1vqiygy-python-duckdb-1.0.0.drv'
failed with exit code 1
build of /gnu/store/8i8z6fynmyg35x48dln3lgl1z1vqiygy-python-duckdb-1.0.0.drv
failed
View build log at
'/var/log/guix/drvs/8i/8z6fynmyg35x48dln3lgl1z1vqiygy-python-duckdb-1.0.0.drv.gz'.
--8<---cut here---end--->8---

Oleg

On Sun, 30 Jun 2024 at 09:23, Andreas Enge  wrote:
>
> Hello the Python team,
>
> python-duckdb sticks out on the build farm, since it apparently gets blocked
> in its tests after spending quite some CPU time for building, and finally
> it times out after a day. It seems to happen consistently over several
> evaluations. The last lines are:
> tests/fast/test_multithread.py::TestDuckMultithread::test_transaction[pandas0]
>  PASSED [  8%]
> tests/fast/test_multithread.py::TestDuckMultithread::test_transaction[pandas1]
>  PASSED [  8%]
> tests/fast/test_multithread.py::TestDuckMultithread::test_df_append[pandas0] 
> PASSED [  8%]
> tests/fast/test_multithread.py::TestDuckMultithread::test_df_append[pandas1]
>
> (see 
> https://bordeaux.guix.gnu.org/build/56359106-e402-49d2-8c6b-2f35de90b7da/log)
>
> Could you maybe have a look?
>
> Andreas
>


-- 
VCS: https://github.incerto.xyz/; https://git.sr.ht/~hellseher/
GPG: 9847 81DE 689C 21C2 6418 0867 76D7 27BF F62C D2B5

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

Re: 07/13: gnu: go-gopkg-in-cheggaaa-pb-v1: Rename to go-github-com-cheggaaa-pb.

[Sharlatan Hellseher]

Hi Christopher,

I've pushed changes fixing it
<https://git.savannah.gnu.org/cgit/guix.git/commit/?id=22482834c5412df9816adefecbf8915221999edb>.

Thanks for reporting.

Oleg

On Tue, 11 Jun 2024 at 12:33, Christopher Baines  wrote:
>
> guix-comm...@gnu.org writes:
>
> > sharlatan pushed a commit to branch master
> > in repository guix.
> >
> > commit 2ef0e4bce1f5b4c3b59cfa944e971a3f31afd2d2
> > Author: Artyom V. Poptsov 
> > AuthorDate: Sat Jun 8 14:44:06 2024 +0300
> >
> > gnu: go-gopkg-in-cheggaaa-pb-v1: Rename to go-github-com-cheggaaa-pb.
> >
> > * gnu/packages/golang-xyz.scm (go-gopkg-in-cheggaaa-pb-v1): Rename to
> >   go-github-com-cheggaaa-pb and sort alphabetically.
> >   (go-gopkg-in-cheggaaa-pb-v3): Inherit from go-github-com-cheggaaa-pb.
> >
> > Change-Id: I945bc8646b2b4a01cf0e81bfd47a2d4fd1075dca
> >
> > Co-authored-by: Sharlatan Hellseher 
> > Signed-off-by: Sharlatan Hellseher 
> > Change-Id: I42446da67c9c17aec35421a312120ad03c7fe83c
> > ---
> >  gnu/packages/golang-xyz.scm | 55 
> > -
> >  1 file changed, 29 insertions(+), 26 deletions(-)
>
> I think this change broke the wally-cli package definition. I've pushed
> 520d85bad4c0207df85273c72d59e9e7d7416538 to hopefully fix that but the
> wally-cli package fails to build.



-- 
VCS: https://github.incerto.xyz/; https://git.sr.ht/~hellseher/
GPG: 9847 81DE 689C 21C2 6418 0867 76D7 27BF F62C D2B5

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

Re: SageMath packaging work

[Sharlatan Hellseher]

Hi Ada,

It looks like it was missed in patches

https://issues.guix.gnu.org/search?query=SageMath+is%3Aopen

56729 patch[RFC PATCH 00/10] Add sagemath.
70924 patch[PATCH 00/10] Add some SageMath standard packages.

Maybe it needs some love to bring to the master branch.

I'll take a look while waiting for QA digest my Astro upate.

--
Oleg


On Wed, 22 May 2024 at 10:19, Ada Stevenson  wrote:
>
> Hi Guix, science team!
>
> I was reaching for SageMath today and couldn't find it in the package
> repository. I notice there's a sagemath.scm file, but no actual SageMath
> package proper. Is there any work being done on packaging it at the
> moment? Are there any particular blockers preventing its packaging
> (excessive dependencies, difficult build etc.)?
>
> Having SageMath in Guix would be really handy for me, so I'm happy to
> give packaging it a go if the only reason is that there's not enough
> interest (I will just have to wait until after exams, so in about 3-4
> weeks).
>
> Hope you are all doing well!
>
> Warmly,
> Ada



-- 
VCS: https://github.incerto.xyz/; https://git.sr.ht/~hellseher/
GPG: 9847 81DE 689C 21C2 6418 0867 76D7 27BF F62C D2B5

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

Re-activate Coirass specification

[Sharlatan Hellseher]

Hi Guix!

I might need to call for some advise from the person with Coirass
administration experience.

In short I'd like to set new specification for go-team
- I was provided with TLS cert (thanks to Maxim)
- Navigate to 
  - Fill up all fields, pick the name for the specification as "go-team" 
  - Try to submit and fail with error "Specification go-team already exists" 


   - Pick other name "golang-team"
  and
 successfully created it

In the end I've deactivated golang-team specification attempting to
resurrect already existing go-team one, but there is no any UI option to
re-activate the specification.

I've not skim the documentation yet for that case.

Question, is it possible to re-activate it via Web UI or I need some
DB/CLI tricks on backend?

Thanks, Oleg.


signature.asc
Description: PGP signature

Re: Request to add a go-team branch and set it on CI.

[Sharlatan Hellseher]

Hi,

I've set the branch go-team, not checked adding it on CI.

Is there any login precision to it?

Thanks,
Oleg

On Tue, 12 Mar 2024, 03:56 Maxim Cournoyer, 
wrote:

> Hi,
>
> Simon Tournier  writes:
>
> > Hi,
> >
> > CC: guix-maintainers
> > CC: guix-sysadmin
> >
> > On lun., 22 janv. 2024 at 19:58, Sharlatan Hellseher <
> sharlata...@gmail.com> wrote:
> >
> >> May I ask someone with admin rights to the build farm to set up
> >>  go-team branch, please?
> >
> > What is the status of this request?  Is it doable?  I do not see the
> > specification on <http://ci.guix.gnu.org>.  Do I miss something?
>
> IIRC, I think I had sent a private TLS client certificate to Sharlatan
> so they can manage the go-team branch creation/jobs themselves from the
> web UI.
>
> --
> Thanks,
> Maxim
>

Initialization of go-team branch.

[Sharlatan Hellseher]

Hello Guix!

After intitiating go-team branch (inspired by the rust-team) I started
pushing reviwed patches to it, which may require a full Golang rebuild.
My future plan is to update the existing Golang ecosystem to recent
versions, as most of the packages are quite dated (2-5 years old).

As an intial work golang-*.scm submodules are introduces and some
packages were extracted from golang.scm and placed into logical modules.

- golang-build.scm
- golang-check.scm
- golang-compression.scm
- golang-crypto.scm
- golang-web.scm
- golang-xyz.scm

I have CC'd Troy and Artyom as they are actively working on Golang updates.

Following these threads:
- https://lists.gnu.org/archive/html/guix-devel/2024-02/msg00026.html
- https://lists.gnu.org/archive/html/guix-devel/2024-01/msg00128.html

I might need some guidance on the following topics:
- Do I need to rebase to master or merge master into go-team while
  working on it?
- What is the approximate merge into master cycle?
- Do I need to send patches to guix-patc...@gnu.org even if I intend to
  push them to the go-team branch?

After reviewing:
- #69205 [PATCH] gnu: Add go-1.22 and its standard library.
- #68300 [PATCH] gnu: Remove go-1.14.
- #69015 [PATCH 0/2] Deprecate the go-etcd-io-bbolt variable,

I rebased on the latest master, then merged master, and finally pushed
to the go-team branch.

--
Oleg


signature.asc
Description: PGP signature

Re: Golang check phase skipping some tests?

[Sharlatan Hellseher]

Hi Simon!

> What is the status of this?  Is all fine?

There are new modules available which I use for moving packages from golang.scm
and other places e.g. syncthing.scm.

- golang-build.scm
- golang-check.scm
- golang-compression.scm
- golang-crypto.scm
- golang-web.scm
- golang-xyz.scm

I would push go-team branch to check some lower level modifications to
go-build-system which are queued right now. I need someone with admin access to
set the branch on CI as well ;-)

Thanks,
Oleg

-- 
VCS: https://github.incerto.xyz/; https://git.sr.ht/~hellseher/
GPG: 9847 81DE 689C 21C2 6418 0867 76D7 27BF F62C D2B5

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

Re: Golang mudules to follow common grouping

[Sharlatan Hellseher]

Hi Guix!

I've pushed split IV
https://issues.guix.gnu.org/69042

Now there are all base golang-* modules which I'm about to populate on demand
during patch review.

- golang-build
- golang-check
- golang-compression
- golang-crypto
- golang-web
- golang-xyz

These two may be added as well if I see enough packages related to that topic.
- golang-graphics
- golang-maths / golang-science

Thanks,
Oleg


-- 
VCS: https://github.incerto.xyz/; https://git.sr.ht/~hellseher/
GPG: 9847 81DE 689C 21C2 6418 0867 76D7 27BF F62C D2B5

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

Re: Golang mudules to follow common grouping

[Sharlatan Hellseher]

Hi,

I stick to this flow
- pick a package from golang.scm e.g. go-package-a
- identify destination (any of golang-*.scm)
- place go-package-a to e.g. golang-web.scm in alphabetic order
- remove go-package-a from golang.scm
- by using magit find all authors contributing to go-package-a
- place found copyright headers to golang-web.scm if they are unique
- grep -l -r go-package-a gnu/packages/
- identify if the module(s) missing use-module (gnu packages golang-web),
add if so
- guix build go-package-a
- build all dependent to go-package-a
- make a commit ...
...
repeat as many times as needed.


Batch of 40-50 is a golden median amount to review.

Thanks,
Oleg

Re: Golang mudules to follow common grouping

[Sharlatan Hellseher]

Hello,

Thank you for your research on that, I was not expected to go
far like you did :-)

My short plan was to follow existing naming model which is in
use for python-*.scm, lisp-*.scm, perl-*scm, java-*.scm.
I see that golang would need some extra modules in the future
and comparing with python-*.scm the package base is not big
yet.

Let's use  Occam's razor for now. We have few common groups,
the task is to drop use-module (gnu packages golang) for each
of them by sorting packages into recently introduced modules.

- golang-web.scm
- golang-check.scm
- golang-xyz.scm
- golang-crypto.scm

Thanks,
Oleg

Re: Golang mudules to follow common grouping

[Sharlatan Hellseher]

Hi,

I've pushed the split III to master.
- https://issues.guix.gnu.org/68605
- https://debbugs.gnu.org/cgi/bugreport.cgi?bug=68605

And it's picked up by CI.
- https://ci.guix.gnu.org/eval/1082575

> Hmm, there seems to be a limit in the degree of parallelizability in
> this process unfortunately. But if there's anything you can think of
> that could help (manually) in this effort, then I'd be happy to help!

I think you may help! The identification of the group is still human
decision making process and I'm not sure it may be automated in any point.
So...
There are golang dedicated modules now and few more coming soon!

Each of the module header contains a short annotation which packages it
expects to have, feel free to improve it to make it even more clear
for others.

- golang-check
- golang-web
- golang-crypto

TBA:
- golang-compression :: Anything related to that subject, see
  python-compression, java-compression, perl-compression.

- golang-build or golang-extension :: Any low level golang add-ons not
included in core distribution see  or
any 0 dependencies high reference modules.

- golang-xyz :: As any other *-xyz module would absorb anything else
  left behind.

Maybe:
- golang-graphics
- golang-maths / golang-science
- ...

> 1. Put a magic comment above each package that you would like to move.
> 2. Run a simple script that makes a note of all of these into a
> to-move-list.
> 3. Then stash the change with the comments you made (in case you need
> to change things)
> 4. Run another script that takes the package list and performs the
> move in one's repository.
> 5. Sort out the use-package declarations manually and run tests.
> 6. When satisfied, stash the change and keep just the use-package
> changes.
> 7. Run a final script that loops through all the packages and commits
> each one in turn.
> 8. Rebase to suit.

We may extend handy script accelerating committing process, see
"etc/committer.scm"

> - I'm not a scheme programmer, but I did use Haskell at university so
>  I'm familiar with thinking in a functional style.
Me too =), but you still can help by just providing some review to
existing code base and available packages in golagn.scm and trying to
identify close group for each of them.

> I'm also imagining some the possibility of having a script that can
> remove redundant #:use-module's in the future, though I don't know if
> we care about a few unneeded modules being included.
The clean up task may be organasied after sort process is completed, having
not required #:use-module does not hurt too much but for keeping modules
tidy and fast to load it definitely beneficial.

Regards,
Oleg


signature.asc
Description: PGP signature

Request to add a go-team branch and set it on CI.

[Sharlatan Hellseher]

Hi Guix,

May I ask someone with admin rights to the build farm to set up
 go-team branch, please?

It would be nice to test/re-build packages before merging to
 master branch.

It would help to cover cases where rebuild the world is required:

- https://issues.guix.gnu.org/68423: guix: go-build-system: use trimpath go
flag.
- https://issues.guix.gnu.org/68300: gnu: Remove go-1.14.
- https://mail.gnu.org/archive/html/guix-devel/2024-01/msg00128.html: Golang
check phase skipping some tests?
- https://mail.gnu.org/archive/html/guix-devel/2024-01/msg00219.html:
Golang modules to follow common grouping

Thanks,
Oleg

Re: Golang mudules to follow common grouping

[Sharlatan Hellseher]

Hi Christina,

> Would it be more organized if they was just one order: either
> in alphabetical order or grouped by function? My suggestion
> would be to use the file split to group by function and then sort
> each file alphabetically. Do you know how it is arranged for other
> languages?

I've added comments in commentary section in the top of the file
asking to keep packages alphabetically sorted seen in
julia-xyz.scm as well. python-*.scm ordered semi random grouped
closer to package purpose which require more thinking where to put a new
one : -)

> Another question I have: Is there any tooling that can help big package
> migrations like this go faster? Eg. a script to split one big diff into
> individual package moves with appropriate change-log entries.

Good point her, I did manual split, with Emacs keyboard macros,
magit history scan for copyright lines and manual check where
package was used to include new module name.

The split into golang-crypto is in review now and there would be 2 more
common grouping: golang-compression and golang-build (or
golang-extension). Rest packages which are hard to determine a
group wound go to generic golang-xyz sorted alphabetically.

Let me know your tooling which you familiar with I might think
about some sort of automation.

Thanks,
Oleg

Re: Golang mudules to follow common grouping

[Sharlatan Hellseher]

Hi,

Part III of the split is sent for review,
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=68605

Thank,
Oleg
-- 
VCS: https://github.incerto.xyz/; https://git.sr.ht/~hellseher/
GPG: 9847 81DE 689C 21C2 6418 0867 76D7 27BF F62C D2B5

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

Re: Golang check phase skipping some tests?

[Sharlatan Hellseher]

Hi Maxim,

Thank you for detailed replay.

> The branch workflow for teams is to use a *-team branch that is short
> lived, e.g. for the time needed to do the integration work; with an
> associated job spec in Cuirass (ci.guix.gnu.org) to build it.

Am I ok to push new go-team branch? And I'll push patches related to
split v3 soon this week.

Thanks,
Oleg

-- 
VCS: https://github.incerto.xyz/; https://git.sr.ht/~hellseher/
GPG: 9847 81DE 689C 21C2 6418 0867 76D7 27BF F62C D2B5

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

Re: Golang check phase skipping some tests?

[Sharlatan Hellseher]

Hi,

There are not too many Golang packages in Guix comparing to other
language spectific modules:

--8<---cut here---start->8---
grep -r "build-system go-build-system" gnu/packages | awk '{print $1}'
| sort | uniq -c | sort -rn
382 gnu/packages/golang.scm:
 47 gnu/packages/golang-web.scm:
 34 gnu/packages/syncthing.scm:
 17 gnu/packages/golang-check.scm:
  9 gnu/packages/web.scm:
  8 gnu/packages/version-control.scm:
  7 gnu/packages/databases.scm:
  5 gnu/packages/ipfs.scm:
  5 gnu/packages/bioinformatics.scm:
  4 gnu/packages/virtualization.scm:
  4 gnu/packages/networking.scm:
  4 gnu/packages/mail.scm:
  4 gnu/packages/games.scm:
  4 gnu/packages/docker.scm:
  4 gnu/packages/check.scm:
  3 gnu/packages/file-systems.scm:
  3 gnu/packages/admin.scm:
  2 gnu/packages/time.scm:
  2 gnu/packages/textutils.scm:
  2 gnu/packages/terminals.scm:
  2 gnu/packages/password-utils.scm:
  2 gnu/packages/messaging.scm:
  2 gnu/packages/irc.scm:
  2 gnu/packages/geo.scm:
  2 gnu/packages/education.scm:
  2 gnu/packages/curl.scm:
  2 gnu/packages/containers.scm:
  2 gnu/packages/backup.scm:
  1 gnu/packages/xdisorg.scm:
  1 gnu/packages/web-browsers.scm:
  1 gnu/packages/weather.scm:
  1 gnu/packages/vpn.scm:
  1 gnu/packages/tls.scm:
  1 gnu/packages/terraform.scm:
  1 gnu/packages/tcl.scm:
  1 gnu/packages/task-runners.scm:
  1 gnu/packages/task-management.scm:
  1 gnu/packages/sync.scm:
  1 gnu/packages/shellutils.scm:
  1 gnu/packages/radio.scm:
  1 gnu/packages/pulseaudio.scm:
  1 gnu/packages/music.scm:
  1 gnu/packages/monitoring.scm:
  1 gnu/packages/linux.scm:
  1 gnu/packages/image-viewers.scm:
  1 gnu/packages/hyperledger.scm:
  1 gnu/packages/high-availability.scm:
  1 gnu/packages/finance.scm:
  1 gnu/packages/disk.scm:
  1 gnu/packages/debug.scm:
  1 gnu/packages/crypto.scm:
  1 gnu/packages/configuration-management.scm:
  1 gnu/packages/compression.scm:
  1 gnu/packages/calendar.scm:
  1 gnu/packages/authentication.scm:
  1 gnu/packages/android.scm:
--8<---cut here---start->8---

We may enable it globally and rebuild each package and pack and place missing in
native inputs/propagated inputs depending on the purpose.

I would love to investigate the count of packages in  `34
gnu/packages/syncthing.scm:` :-)

Thanks,
Oleg

On Thu, 18 Jan 2024 at 21:31, Troy Figiel  wrote:
>
> Hi Oleg and others,
>
> On 2024-01-18 11:25, Sharlatan Hellseher wrote:
> > With small adjustment of the invok line, I could manage to trigger all 
> > tests to
> > be run, but it brings other issue of some not packed modules required for 
> > the
> > check phase.
>
> Thanks for the update! I noticed the same with `go-github-com-kr-text'.
> It was actually missing a propagated-input that has not been packaged
> yet, so I couldn't easily fix it.
>
> On 2024-01-18 11:25, Sharlatan Hellseher wrote:
> > As a quick ad-hoc to run all tests for some new package you may add a custom
> > check phase with the snippet you provided.
> >
> > I'm currently in review and split some packages from (gnu packages golang) 
> > into
> > (gnu packages golang-crypto) to simplify the maintenance. I try to play with
> > that option and see which packages are missed to satisfy passing all tests.
>
> Once the migration is over, what would you recommend for new packages? I
> could see two options here:
>
> 1. Change the default check phase and only replace it back to the
> previous one for packages that fail to build or
>
> 2. Replace the check phase for all packages one-by-one.
>
> I noticed this behaviour when I was packaging gotenberg and as with any
> reasonably sized Golang package, this one also has a gazillion
> dependencies... I would love to start on the right track :-)
>
> Best wishes,
>
> Troy



-- 
VCS: https://github.incerto.xyz/; https://git.sr.ht/~hellseher/
GPG: 9847 81DE 689C 21C2 6418 0867 76D7 27BF F62C D2B5

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

Re: Golang check phase skipping some tests?

[Sharlatan Hellseher]

Hi,

I can't say that I'm an expert in Golang :-), but I've got some experience in
building and deploying Glang daily for some time.

First things first the default behaviour of `go test ./...` is like this:

--8<---cut here---start->8---
find * -type f -name *_test.go | 
--8<---cut here---start->8---

Internally Golang tries to find any files with _test.go suffix in
provided module's
location and evaluate defined tests in them. If the directory of the module does
not have test files it's just ignored.

Now in actions.

If we investigate which test files we have for `go-github-com-stretchr-testify`
we'll see that for the current version packed in Guix there are some:

--8<---cut here---start->8---
guix describe
Generation 503  Jan 16 2024 13:15:09(current)
  guix 8520f00
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 8520f00d6989ff5ab22755a97dfcfd0375f6b5ca

guix time-machine --commit=8520f00d6989ff5ab22755a97dfcfd0375f6b5ca -- \
shell findutils -- \
find $(guix build go-github-com-stretchr-testify  --no-substitutes)
-type f -name "*_test.go"
/gnu/store/jpizwxbhr93wmday0raz0vk0ny5s5jiv-go-github-com-stretchr-testify-1.7.0/src/github.com/stretchr/testify/suite/suite_test.go
/gnu/store/jpizwxbhr93wmday0raz0vk0ny5s5jiv-go-github-com-stretchr-testify-1.7.0/src/github.com/stretchr/testify/suite/stats_test.go
/gnu/store/jpizwxbhr93wmday0raz0vk0ny5s5jiv-go-github-com-stretchr-testify-1.7.0/src/github.com/stretchr/testify/mock/mock_test.go
/gnu/store/jpizwxbhr93wmday0raz0vk0ny5s5jiv-go-github-com-stretchr-testify-1.7.0/src/github.com/stretchr/testify/package_test.go
/gnu/store/jpizwxbhr93wmday0raz0vk0ny5s5jiv-go-github-com-stretchr-testify-1.7.0/src/github.com/stretchr/testify/require/requirements_test.go
/gnu/store/jpizwxbhr93wmday0raz0vk0ny5s5jiv-go-github-com-stretchr-testify-1.7.0/src/github.com/stretchr/testify/require/forward_requirements_test.go
/gnu/store/jpizwxbhr93wmday0raz0vk0ny5s5jiv-go-github-com-stretchr-testify-1.7.0/src/github.com/stretchr/testify/assert/http_assertions_test.go
/gnu/store/jpizwxbhr93wmday0raz0vk0ny5s5jiv-go-github-com-stretchr-testify-1.7.0/src/github.com/stretchr/testify/assert/forward_assertions_test.go
/gnu/store/jpizwxbhr93wmday0raz0vk0ny5s5jiv-go-github-com-stretchr-testify-1.7.0/src/github.com/stretchr/testify/assert/assertion_order_test.go
/gnu/store/jpizwxbhr93wmday0raz0vk0ny5s5jiv-go-github-com-stretchr-testify-1.7.0/src/github.com/stretchr/testify/assert/assertion_compare_test.go
/gnu/store/jpizwxbhr93wmday0raz0vk0ny5s5jiv-go-github-com-stretchr-testify-1.7.0/src/github.com/stretchr/testify/assert/assertions_test.go
--8<---cut here---start->8---

Checking current implementation of the go-build-system.scm I realized that it
only runs test available in `import-path` and does not scan any farther like
the `./...` option does. In our case it is just one file, rest are ignored.

> /gnu/store/jpizwxbhr93wmday0raz0vk0ny5s5jiv-go-github-com-stretchr-testify-1.7.0/src/github.com/stretchr/testify/package_test.go

> guix/guix/build/go-build-system.scm
--8<---cut here---start->8---
;; Can this also install commands???
(define* (check #:key tests? import-path #:allow-other-keys)
  "Run the tests for the package named by IMPORT-PATH."
  (when tests?
(invoke "go" "test" import-path))
  #t)
--8<---cut here---start->8---

With small adjustment of the invok line, I could manage to trigger all tests to
be run, but it brings other issue of some not packed modules required for the
check phase.

--8<---cut here---start->8---
@@ -275,7 +275,7 @@ (define* (build #:key import-path build-flags
#:allow-other-keys)
 (define* (check #:key tests? import-path #:allow-other-keys)
   "Run the tests for the package named by IMPORT-PATH."
   (when tests?
-(invoke "go" "test" import-path))
+(invoke "go" "test" (string-append import-path "/...")))
   #t)

 (define* (install #:key install-source? outputs import-path
unpack-path #:allow-other-keys)
--8<---cut here---start->8---

As a quick ad-hoc to run all tests for some new package you may add a custom
check phase with the snippet you provided.

I'm currently in review and split some packages from (gnu packages golang) into
(gnu packages golang-crypto) to simplify the maintenance. I try to play with
that option and see which packages are missed to satisfy passing all tests.

Thanks,
Oleg

On Wed, 17 Jan 2024 at 20:25, Simon Tournier  wrote:
>
> Hi,
>
> CC:
> $ ./etc/teams.scm list-members go
> Katherin

Re: Golang mudules to follow common grouping

[Sharlatan Hellseher]

Hi Guix,

I'm about to prepare split and aggregation of all golag packages
 related to cryptography. The process would be the same as for
 golang-check and golang-web.


In progress:
golang-cryptography

Planned:
golang-compression
golang-build

Regards,
Oleg

On Mon, 30 Oct 2023, 01:17 Sharlatan Hellseher, 
wrote:

> Hi,
>
> Part II of the split https://issues.guix.gnu.org/66827
>
> Now we would have
> - golang.scm - which would be logically keep on minimal number of packages
> - golang-check.scm
> - golang-web.scm - in review
>
> Planed
> - golang-crypto.scm
> - golang-compression.scm
> - golang-build.scm - which would include low level 0 dependencies packages.
>
> I found a lot of golang packages in (gnu packages syncthing) which are not
> 100%
> related to syncthing itself, possibly the were left there long ago.
>
> Thanks,
> Oleg
>
> On Thu, 19 Oct 2023 at 10:40, Sharlatan Hellseher 
> wrote:
> >
> > Hi,
> >
> > I've accidentally included other patch to this series. I've re-sent it
> under the
> > new issue number https://issues.guix.gnu.org/66627.
> >
> > Thanks,
> > Oleg
> >
> >
> > On Mon, 16 Oct 2023 at 19:17, Sharlatan Hellseher 
> wrote:
> > >
> > > Hi,
> > >
> > > I'm about to create golang-check and golang-build modules, which both
> are core and would be in used by others. As Maxim mentioned, the most time
> consumption task would be migrating copyrights header properly.
> > >
> > > On Sun, 15 Oct 2023, 22:25 Wilko Meyer,  wrote:
> > >>
> > >>
> > >> Hi,
> > >>
> > >> Sharlatan Hellseher  writes:
> > >>
> > >> > I think it's time to split (gnu packages golang) into some logical
> groups, see
> > >> > Python, Lisp for example.
> > >> >
> > >> > Thoughts?
> > >>
> > >> IMHO this sounds like a good idea as it would improve the
> > >> maintainability of golang packages in the long run. We have 487
> package
> > >> definitions right now:
> > >>
> > >> (~/devel/guix-devel/gnu/packages) λ rg -c 'define-public' golang.scm
> > >> 487
> > >>
> > >> which already seems quite laborous to split into logical groups (while
> > >> getting the copyright information right as well and maintaining the
> > >> gitlog history etc.); so it probably classifies as a task that should
> be
> > >> tackled sooner than later as it'll cause more work over time the more
> > >> golang packages exist.
> > >>
> > >> --
> > >> Kind regards,
> > >>
> > >> Wilko Meyer
> > >> w...@wmeyer.eu
> >
> >
> >
> > --
> >
> > … наш разум - превосходная объяснительная машина которая способна
> > найти смысл почти в чем угодно, истолковать любой феномен, но
> > совершенно не в состоянии принять мысль о непредсказуемости.
>
>
>
> --
>
> … наш разум - превосходная объяснительная машина которая способна
> найти смысл почти в чем угодно, истолковать любой феномен, но
> совершенно не в состоянии принять мысль о непредсказуемости.
>

Commit Access: Sharlatan Hellseher

[Sharlatan Hellseher]

Hi Guix!

I am happy to have been granted commit access and I am ready to help
review pending issues and prepare queued packages for GNU packages in
astronomy. I would like to concentrate on the packages covered by the
Go, Lisp, Python, and Science teams.

I would like to thank the Guix team for allowing me to become a
committer member. I am looking forward to continuing our collaboration.

If anyone has a good patch review workflow using Emacs, Gnus, and Magit,
I would appreciate it ;-)

Regards,
Sharlatan Hellseher (Oleg)


signature.asc
Description: PGP signature

Re: Question on python-pydantic update, rust and maturin build tool

[Sharlatan Hellseher]

Hi Efraim,

I was about to update python-hvpy to v1.1.0 which requires

pydantic>=2.0.0

https://github.com/Helioviewer-Project/python-api/blob/v1.1.0/setup.cfg#L37

Pydantic 2+ (the latest is v2.5.3 2023-12-22) depends on pydantic-core (the
latest is v2.14.6 2023-12-21) which is built with Rust flavor.

pydantic-core==2.0.1

https://github.com/pydantic/pydantic/blob/v2.0/pyproject.toml#L64

Pydantic core is built with maturin 1, <2:

https://github.com/pydantic/pydantic-core/blob/v2.0.1/pyproject.toml


Currently I've prepared updates for anything which requires minimum overhead and
does not break built of dependent packages.

https://issues.guix.gnu.org/67915

Thanks,
Oleg


On Thu, 28 Dec 2023 at 11:56, Efraim Flashner  wrote:
>
> On Tue, Dec 26, 2023 at 12:27:38AM +, Sharlatan Hellseher wrote:
> > Hi Guix!
> >
> >
> > It might be addressed to rust/python teams.
> > https://github.com/pydantic/pydantic-core
> >
> > During update of some packages from (gnu packages astronomy) I've faced
> > with requirement for the fresh version of pydantic which depends on
> > pydantic-core built with rust and maturin.
> >
> > This thread is just conversation opener for the potential strategy to deal
> > with similar cases where python projects start using rust with rare but new
> > build tool.
>
> We have maturin packaged at 1.1.0 and I believe it is even used to build
> a couple of packages.  python-rpds-py, which just landed in the repo
> today, is probably the best short example of how to use a combination of
> cargo and any other build system to build a project that doesn't really
> need any phases overridden, just added/replaced.
>
> Is there a specific version of pydantic that you need? I might be able
> to put together something either using the crates in the master branch
> or a newer version on the rust-team branch.
>
> --
> Efraim Flashner  רנשלפ םירפא
> GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
> Confidentiality cannot be guaranteed on emails sent or received unencrypted



-- 

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

Question on python-pydantic update, rust and maturin build tool

[Sharlatan Hellseher]

Hi Guix!


It might be addressed to rust/python teams.
https://github.com/pydantic/pydantic-core

During update of some packages from (gnu packages astronomy) I've faced
with requirement for the fresh version of pydantic which depends on
pydantic-core built with rust and maturin.

This thread is just conversation opener for the potential strategy to deal
with similar cases where python projects start using rust with rare but new
build tool.


Thanks,
Oleg

Golang mudules to follow common grouping

[Sharlatan Hellseher]

Hi Guix,

Do you think it is correctly extracted to golang-web?

https://issues.guix.gnu.org/66827

Thank,
Oleg

Re: Golang mudules to follow common grouping

[Sharlatan Hellseher]

Hi,

Part II of the split https://issues.guix.gnu.org/66827

Now we would have
- golang.scm - which would be logically keep on minimal number of packages
- golang-check.scm
- golang-web.scm - in review

Planed
- golang-crypto.scm
- golang-compression.scm
- golang-build.scm - which would include low level 0 dependencies packages.

I found a lot of golang packages in (gnu packages syncthing) which are not 100%
related to syncthing itself, possibly the were left there long ago.

Thanks,
Oleg

On Thu, 19 Oct 2023 at 10:40, Sharlatan Hellseher  wrote:
>
> Hi,
>
> I've accidentally included other patch to this series. I've re-sent it under 
> the
> new issue number https://issues.guix.gnu.org/66627.
>
> Thanks,
> Oleg
>
>
> On Mon, 16 Oct 2023 at 19:17, Sharlatan Hellseher  
> wrote:
> >
> > Hi,
> >
> > I'm about to create golang-check and golang-build modules, which both are 
> > core and would be in used by others. As Maxim mentioned, the most time 
> > consumption task would be migrating copyrights header properly.
> >
> > On Sun, 15 Oct 2023, 22:25 Wilko Meyer,  wrote:
> >>
> >>
> >> Hi,
> >>
> >> Sharlatan Hellseher  writes:
> >>
> >> > I think it's time to split (gnu packages golang) into some logical 
> >> > groups, see
> >> > Python, Lisp for example.
> >> >
> >> > Thoughts?
> >>
> >> IMHO this sounds like a good idea as it would improve the
> >> maintainability of golang packages in the long run. We have 487 package
> >> definitions right now:
> >>
> >> (~/devel/guix-devel/gnu/packages) λ rg -c 'define-public' golang.scm
> >> 487
> >>
> >> which already seems quite laborous to split into logical groups (while
> >> getting the copyright information right as well and maintaining the
> >> gitlog history etc.); so it probably classifies as a task that should be
> >> tackled sooner than later as it'll cause more work over time the more
> >> golang packages exist.
> >>
> >> --
> >> Kind regards,
> >>
> >> Wilko Meyer
> >> w...@wmeyer.eu
>
>
>
> --
>
> … наш разум - превосходная объяснительная машина которая способна
> найти смысл почти в чем угодно, истолковать любой феномен, но
> совершенно не в состоянии принять мысль о непредсказуемости.



-- 

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

Re: Golang mudules to follow common grouping

[Sharlatan Hellseher]

Hi,

I've accidentally included other patch to this series. I've re-sent it under the
new issue number https://issues.guix.gnu.org/66627.

Thanks,
Oleg


On Mon, 16 Oct 2023 at 19:17, Sharlatan Hellseher  wrote:
>
> Hi,
>
> I'm about to create golang-check and golang-build modules, which both are 
> core and would be in used by others. As Maxim mentioned, the most time 
> consumption task would be migrating copyrights header properly.
>
> On Sun, 15 Oct 2023, 22:25 Wilko Meyer,  wrote:
>>
>>
>> Hi,
>>
>> Sharlatan Hellseher  writes:
>>
>> > I think it's time to split (gnu packages golang) into some logical groups, 
>> > see
>> > Python, Lisp for example.
>> >
>> > Thoughts?
>>
>> IMHO this sounds like a good idea as it would improve the
>> maintainability of golang packages in the long run. We have 487 package
>> definitions right now:
>>
>> (~/devel/guix-devel/gnu/packages) λ rg -c 'define-public' golang.scm
>> 487
>>
>> which already seems quite laborous to split into logical groups (while
>> getting the copyright information right as well and maintaining the
>> gitlog history etc.); so it probably classifies as a task that should be
>> tackled sooner than later as it'll cause more work over time the more
>> golang packages exist.
>>
>> --
>> Kind regards,
>>
>> Wilko Meyer
>> w...@wmeyer.eu



--

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

Re: Golang mudules to follow common grouping

[Sharlatan Hellseher]

Hi Maxim,

I identified about 17 packages related to check/assert/mock/lint
process and moved them to (gnu packages golang-check)

https://issues.guix.gnu.org/66619

Thanks,
Oleg

On Tue, 10 Oct 2023 at 04:52, Maxim Cournoyer  wrote:
>
> Hi,
>
> Sharlatan Hellseher  writes:
>
> > Hi Guix!
> >
> > I've noticed the number of Golang packages start growing. I expect more 
> > packages
> > to be reviewed and merged by quick check of Issues.
> >
> > I think it's time to split (gnu packages golang) into some logical groups, 
> > see
> > Python, Lisp for example.
> >
> > - golang-web
> > - golang-check
> > - golang-build
> > - golang-compression
> > - golang-crypto
> > - golang-xyz
> > - golang-...
> >
> > Thoughts?
>
> This sounds good to me.  Beware of correctly migrating the copyright
> lines though... these can be annoying to move.
>
> --
> Thanks,
> Maxim



-- 

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

Re: Golang mudules to follow common grouping

[Sharlatan Hellseher]

Hi,

I'm about to create golang-check and golang-build modules, which both are
core and would be in used by others. As Maxim mentioned, the most time
consumption task would be migrating copyrights header properly.

On Sun, 15 Oct 2023, 22:25 Wilko Meyer,  wrote:

>
> Hi,
>
> Sharlatan Hellseher  writes:
>
> > I think it's time to split (gnu packages golang) into some logical
> groups, see
> > Python, Lisp for example.
> >
> > Thoughts?
>
> IMHO this sounds like a good idea as it would improve the
> maintainability of golang packages in the long run. We have 487 package
> definitions right now:
>
> (~/devel/guix-devel/gnu/packages) λ rg -c 'define-public' golang.scm
> 487
>
> which already seems quite laborous to split into logical groups (while
> getting the copyright information right as well and maintaining the
> gitlog history etc.); so it probably classifies as a task that should be
> tackled sooner than later as it'll cause more work over time the more
> golang packages exist.
>
> --
> Kind regards,
>
> Wilko Meyer
> w...@wmeyer.eu
>

Golang mudules to follow common grouping

[Sharlatan Hellseher]

Hi Guix!

I've noticed the number of Golang packages start growing. I expect more packages
to be reviewed and merged by quick check of Issues.

I think it's time to split (gnu packages golang) into some logical groups, see
Python, Lisp for example.

- golang-web
- golang-check
- golang-build
- golang-compression
- golang-crypto
- golang-xyz
- golang-...

Thoughts?


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

Re: Failed to connect to `/var/guix/daemon-socket/socket': Connection refused

[Sharlatan Hellseher]

Hi,

In my case I had the same error after guix system reconfigure on
native Guix system.
The suggested brute method gave me no result.
I've deleted the socket file and restart daemon which helped to
resolve guix pull issue

Steps:
~$ sudo su   # to become root
~# rm -rfv /var/guix/daemon-socket/socket  # remove curpted socket file
~# herd restart guix-daemon# restart daemon
~# herd status guix-daemon# check daemon is running
~# guix pull  # make
sure pull is working again

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

Astronomy 2023/08 updates

[Sharlatan Hellseher]

Hi Guix!

The end of August Astronomy related packages udpates and new packages.
Hope QA will  green them
up soon :)

* Updates
- date-time :: 20230905T163102+0100
- commit :: 8d19ff23052bffb1c43f0d39f543eb0b1e363074
- issues :: https://issues.guix.gnu.org/65814
- quick [16/16][100%]
  - [X] libxisf :: would be upgraded from 0.2.8 to 0.2.9.
  - [X] python-astropy-healpix :: would be upgraded from 0.7 to 1.0.0.
  - [X] python-astropy :: would be upgraded from 5.3.1 to 5.3.2
  - [X] python-bayesicfitting :: would be upgraded from 3.1.1 to 3.2.0
  - [X] python-cdflib :: would be upgraded from 1.0.5 to 1.1.0.
  - [X] python-crds :: would be upgraded from 11.17.0 to 11.17.4.
  - [X] python-fitsio :: would be upgraded from 1.1.10 to 1.2.0
  - [X] python-jwst :: would be upgraded from 1.10.2 to 1.11.4
  - [X] python-photutils :: would be upgraded from 1.7.0 to 1.9.0
  - [X] python-pyvo :: would be upgraded from 1.4.1 to 1.4.2
  - [X] python-rad :: would be upgraded from 0.15.0 to 0.17.1
  - [X] python-roman-datamodels :: would be upgraded from 0.15.0 to 0.17.1
  - [X] python-stdatamodels :: would be upgraded from 1.7.1 to 1.8.0
  - [X] python-sunpy :: Enable more tests.
  - [X] python-tslearn :: would be upgraded from 0.6.1 to 0.6.2
  - [X] splash :: would be upgraded from 3.8.2 to 3.8.4.
- complex [0/8][0%]
  - [ ] python-asdf :: would be upgraded from 2.15.0 to 2.15.1.
Requires lower version of
python-jsonschema which and also contain vendorized version which
breaks all tests now,
https://github.com/asdf-format/asdf-standard/releases/tag/1.0.3
  - [ ] cfitsio :: would be upgraded from 4.2.0 to 4.3.0. Building the
following 22 packages would
ensure 66 dependent packages are rebuilt: alfa@2.2 splash@3.8.2
sextractor@2.28.0 imppg@0.6.5
stellarium@23.2 python-fitsio@1.1.10 glnemo2@1.21.0 siril@1.0.6
python-tslearn@0.6.1
python-regions@0.7 python-jwst@1.10.2 python-astroalign@2.4.2
python-sunpy@5.0.0
python-poliastro@0.17.0 julia-wcs@0.6.2 phd2@2.6.11 gnuastro@0.20
aoflagger@3.3.0 swarp@2.41.5
julia-fitsio@0.17.0 gwenview@23.04.3 labplot@2.9.0.
Need more love with dependents as some of them failed to build.
  - [ ] python-hvpy :: would be upgraded from 1.0.1 to 1.1.0. Requires
more fresh version of
python-pydantic, which depends on python-pydantic-core which
require brand new Rust based
package.
  - [ ] python-spherical-geometry :: would be upgraded from 1.2.22 to
1.2.23. Can't be updated to
the latest see:
https://github.com/spacetelescope/spherical_geometry/issues/227
  - [ ] aoflagger :: would be upgraded from 3.2.0 to 3.3.0. Build
failerur, more work requried.
  - [ ] casacore :: would be upgraded from 3.4.0 to 3.5.0. Build
failerur, more work requried.
  - [ ] indi :: would be upgraded from 1.9.9 to 2.0.3. stellarium failing.
  - [ ] libpasastro :: would be upgraded from 1.4.0-1.e3c218d to
1.4.1. Full package reformat is
requried.

* New packages
- [PATCH] gnu: Add python-casa-formats-io: https://issues.guix.gnu.org/65571
- [PATCH] gnu: Add WCSTools: https://issues.guix.gnu.org/65880


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

Re: Scheduled monthly update for (gnu packages astronomy)

[Sharlatan Hellseher]

Hi Guix!


Thank you for feedback, I've sent V2 for https://issues.guix.gnu.org/64201

It was built successfully from the latest master branch check out.

Thanks,
Oleg

On Mon, 24 Jul 2023, 18:36 Sharlatan Hellseher, 
wrote:

> Hi Andreas,
>
> Thank you for your time.
>
> This issue may be closed  https://issues.guix.gnu.org/64287 as Tobias
> applied all of it's patches.
> I'm not sure about the reason of splittingt them into smaller ones, it
> may be a question to him :-)
>
> I'll rebase patches from https://issues.guix.gnu.org/64201 to the
> current master branch and sent V2, hope they are look ok.
>
> Regards,
> Oleg
>
> On Mon, 24 Jul 2023 at 09:53, Andreas Enge  wrote:
> >
> > Am Sun, Jul 02, 2023 at 10:36:26PM +0200 schrieb Ludovic Courtès:
> > > You’re now well known so pretty much the only thing I would wait for as
> > > a reviewer before applying these updates is (1) a green light from
> > > qa.guix,
> >
> > This looks like it lags behind now.
> >
> > > and (2) a bit of spare time.
> >
> > Ah, we should not wait for the impossible to happen! ;-)
> >
> > The status of the patches is unclear to me, it looks as if some of them
> > have been rewritten and merged by Tobias (maybe this also confuses QA?
> > do the patches still apply?) But I find it difficult to understand what
> > needs to be done still. For instance, there is a patch "stuff: Update to
> > 1.26.0-0.9008dc0", but it is already at version 2.0.1 in master.
> >
> > How about sending a second version for the remaining patches on top of
> > current master?
> >
> > Andreas
> >
>
>
> --
>
> … наш разум - превосходная объяснительная машина которая способна
> найти смысл почти в чем угодно, истолковать любой феномен, но
> совершенно не в состоянии принять мысль о непредсказуемости.
>

Re: Scheduled monthly update for (gnu packages astronomy)

[Sharlatan Hellseher]

Hi Andreas,

Thank you for your time.

This issue may be closed  https://issues.guix.gnu.org/64287 as Tobias
applied all of it's patches.
I'm not sure about the reason of splittingt them into smaller ones, it
may be a question to him :-)

I'll rebase patches from https://issues.guix.gnu.org/64201 to the
current master branch and sent V2, hope they are look ok.

Regards,
Oleg

On Mon, 24 Jul 2023 at 09:53, Andreas Enge  wrote:
>
> Am Sun, Jul 02, 2023 at 10:36:26PM +0200 schrieb Ludovic Courtès:
> > You’re now well known so pretty much the only thing I would wait for as
> > a reviewer before applying these updates is (1) a green light from
> > qa.guix,
>
> This looks like it lags behind now.
>
> > and (2) a bit of spare time.
>
> Ah, we should not wait for the impossible to happen! ;-)
>
> The status of the patches is unclear to me, it looks as if some of them
> have been rewritten and merged by Tobias (maybe this also confuses QA?
> do the patches still apply?) But I find it difficult to understand what
> needs to be done still. For instance, there is a patch "stuff: Update to
> 1.26.0-0.9008dc0", but it is already at version 2.0.1 in master.
>
> How about sending a second version for the remaining patches on top of
> current master?
>
> Andreas
>


-- 

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

Scheduled monthly update for (gnu packages astronomy)

[Sharlatan Hellseher]

Hi Guix!

As you may noticed Guix's collection for astro[physics|nomy] is growing!

It is about 70+ packaged projects just in (gnu packages astronomy), and I
try to prepare more for review, sourcing, mainly, from Debian astro and
tracking the progress in the channel https://git.sr.ht/~hellseher/ffab.

Meanwhile I'd like to propose monthly update schedule for current packages,
which I may keep up to date with upstream.

This month updates (may be outdated):
- https://issues.guix.gnu.org/64201 qa:pending
- https://issues.guix.gnu.org/64287 qa:passed

I am open for any feed back to prioritize the order it add more project to
the queue (and welcome anyone to unofficial astro-team ;-)

Regard,
Oleg

RE: London Guix meetup

[Sharlatan Hellseher]

Hi,

I'm based in Manchester and would like to join but its mid week time not
realistic for me.

Next time lets group up in Manchester too!

Thanks,
Oleg

Re: Python feature branch

[Sharlatan Hellseher]

Hi,

I've fixed the build and updated chain of inputs for python-astropy,
posting here for wider awareness.



Thanks,
Oleg

Question on the process of packge withdrawal

[Sharlatan Hellseher]

Hi Guix!

  I've noticed a tendency in core-updates and staging of withdrawing old
  packages, packages which were created from forks in the past or
  packages failing to build due to increased complexity of the package.

  If we check
  

  commit removing jrnl variable which has it's source pointing to
   which is an old fork of original
  active project .

  Other example
  

  the reason it's not updated at  -
  development was moved to .

  That tendency concerns me as a packager it's not clear for me which
  criterias were used to make a division to withdraw the package(s). The
  age of project is not always a good measure for example example,
  [Common Lisp] ecosystem has quite ancient packages (5-8y old of not
  touched since the last commit) but still in active use (check
  [pgloader])

  It's an open discussion to drag some attention to this case and
  compile some common seance checklist before removing package from Guix
  ecosystem. From my experience it's sometimes hard to have new package
  to be included :).

  Thanks, Oleg

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

Re: Guix - installation script

[Sharlatan Hellseher]

Hi,

Thank you for feedback, I'll fix it on free time.

br,
sh

On 1 Aug 2017 11:55, "ng0"  wrote:

> Sharlatan Hellseher transcribed 5.6K bytes:
> > Hi,
> >
> > I've found your project very interesting. I've played with installation
> > instruction but it has a lot of different steps, for convenience purpose
> > I've wrote installation script which goes through all points of your
> guide.
> >
> > As far as I could say, there is no any official installation script for
> > Guix on existing OS. I would like take an opportunity to maintain this
> > process.
> >
> > If you could review it (Github) and give me some feedback I would be
> > appreciated.
> >
> > https://github.com/Hellseher/wds/blob/master/wds-guix-install.sh
> >
> > Best regards,
> > Oleg
>
> I don't mind very much if something like this exists or doesn't,
> but I have some short comments on it:
>
> Line 51: FTP_URL="ftp://alpha.gnu.org/gnu/guix/";
>   I'd change to using https instead of ftp.
>   https://alpha.gnu.org/gnu/guix/
>
>
> I think you are confusing terms in the script.
> Guix is not GuixSD. If you install this on top
> of another operating system you are installing "Guix".
> --
> ng0
> GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
> GnuPG: https://n0is.noblogs.org/my-keys
> https://www.infotropique.org https://krosos.org
>

Guix - installation script

[Sharlatan Hellseher]

Hi,

I've found your project very interesting. I've played with installation
instruction but it has a lot of different steps, for convenience purpose
I've wrote installation script which goes through all points of your guide.

As far as I could say, there is no any official installation script for
Guix on existing OS. I would like take an opportunity to maintain this
process.

If you could review it (Github) and give me some feedback I would be
appreciated.

https://github.com/Hellseher/wds/blob/master/wds-guix-install.sh

Best regards,
Oleg