Package update patch review

[Andy Tai]

Hi, Merry Christmas!  A question, how to call attention to package
definition update patches that may have been waiting for review for some
time in the issue tracker/debug database? Some may have responses to prev
review comments.  Basically some kind of "ping" for such patches hanging
there.  Thanks

Re: Example Nginx config from Guix manual does not work

[Kefir .]

Hi Felix!
Thank you for this solution. But my point was in starting nginx server without 
encryption. Probably it should be a separate argument or something.
In my case I used (local-file ) to set needed settings but your suggestion 
looks nice.

> On Dec 25, 2022, at 7:44 AM, Felix Lechner  wrote:
> 
> Hi Adam,
> 
>> On Sat, Dec 24, 2022 at 2:29 AM Adam Kandur  wrote:
>> 
>> Which will not work because it asks to listen on 443 with ssl, which is not 
>> possible because no certificates are provided.
> 
> I use this configuration [1] but also face a chicken-and-egg problem
> for new sites. I normally take nginx offline with
> 
>   sudo herd stop nginx
> 
> and then configure any newly needed certificates from Let's Encrypt with
> 
>   sudo certbot certificates --standalone
> 
> Then I start Nginx again.
> 
> At my convenience (but within ninety days) I then reconfigure the
> equipment while including both the new website in Nginx and the new
> Certbot definition in config.scm.
> 
> Hope that helps!
> 
> Kind regards
> Felix Lechner
> 
> [1] 
> https://codeberg.org/lechner/system-config/src/commit/2b6e49e466cb8bd4a3715111b4a4690192941ac8/host/wallace-server/operating-system.scm#L581-L743

Re: Example Nginx config from Guix manual does not work

[Development of GNU Guix and the GNU System distribution.]

Hi Adam,

On Sat, Dec 24, 2022 at 2:29 AM Adam Kandur  wrote:
>
> Which will not work because it asks to listen on 443 with ssl, which is not 
> possible because no certificates are provided.

I use this configuration [1] but also face a chicken-and-egg problem
for new sites. I normally take nginx offline with

   sudo herd stop nginx

and then configure any newly needed certificates from Let's Encrypt with

   sudo certbot certificates --standalone

Then I start Nginx again.

At my convenience (but within ninety days) I then reconfigure the
equipment while including both the new website in Nginx and the new
Certbot definition in config.scm.

Hope that helps!

Kind regards
Felix Lechner

[1] 
https://codeberg.org/lechner/system-config/src/commit/2b6e49e466cb8bd4a3715111b4a4690192941ac8/host/wallace-server/operating-system.scm#L581-L743

Re: Help needed adapting IceCat patches to 102

[Adam Faiz]

On 12/24/22 08:34, Adam Faiz wrote:
Gentoo's patches should be tested, I don't have the time but maybe 
someone else can do it.


The relevant patches can be found in Gentoo's 102esr-patches-07j.tar.xz:
Support-system-graphite2.patch
Support-system-harfbuzz.patch
Support-system-av1.patch
fix-av1-libs.patch

The patented H264 format absolutely shouldn't be encouraged, so the 
OpenH264 patches are probably not necessary.


Other Gentoo patches that might be of interest are the following:
fix-build-on-x86.patch

There may be other patches that should be considered in a separate issue.

Re: Stratification of GNU Guix into Independent Channels

[Joshua Branson]

Vagrant Cascadian  writes:

> On 2022-12-24, jgart wrote:
>> I wanted to ask you what are your thoughts on this idea. This is a
>> thought experiment at this stage.
>>
>> Should GNU Guix be a small core of packages (and services?)?
>>
>> For example, GNU Guix would be a core channel containing the reduced
>> binary seed bootstrap and a few other core packages to bootstrap the
>> system. That's it. Users subscribe to this channel to get started.
>
> I definitely am excited and hopeful to think this *could* be possible!
>
>
>> Users could then decide what channels they'd like to subscribe to/opt
>> in to by adding any of the following channels as they please:
>>
>> python-channel
>> rust-channel
> ...
>> scheme-channel
>> etc...
>>
>> The above channels would still be maintained under the auspices of GNU.
>>
>> What do you think would be the pros and cons of the stratified
>> approach versus the monorepo approach that we currently have?
>
> The pros would be only having to pull the small bits you actually want,
> and that could be faster to run "guix pull".
>
> This would certainly make it much easier to package a "core" subset of
> guix for other distros (e.g. I work on packaging guix in Debian) that
> having to package the whole entire guix universe.
>
> I suspect the "small bootstrap core set" to eventually pull in quite a
> bit of other things, and continually be at risk of needing to pull in
> more things...
>
> You would probably need to have inter-channel dependencies... which
> makes me wonder how many cyclic dependencies might result...
>
> git alone pulls in dependencies for perl, python, git, subversion,
> openssl ... and what is the dependency cycle for each of those? Guix
> apparently can generate pretty charts for this stuff, though I have yet
> to try. :)
>

Fun fact of the day, the OpenBSD crowd is creating got, which is a
rewrite of git, with less features, in C.  :)

>
> I have the (perhaps mininformed) impression nix has a split more along
> these lines with the core of nix being one thing, and then collections
> of packages being other repositories.
>
>
>> GNU Guix proper would be a solid core of packages that is very easy to
>> maintain. This would greatly reduce the maintenance burden since
>> maintaining a world of rust, golang, or python packages is opt in by
>> those who want to do that particular work.
>
> If it is possible, it seems likely to make releasing more regularly and
> less stressfully...
>
>
>> Would being subscribed to just the hypothetical small core channel in
>> this proposal increase download/installation speeds given the
>> availability of substitutes?
>
> I suspect it would significantly increase guix pull speeds, at the very
> least.
>
>
> live well,
>   vagrant

LaTeX packaging policy

[Josselin Poiret]

Hi everyone,

While using a bit of LaTeX recently, I've noticed some packages don't
work "out-of-the-box", at least on LuaLaTeX, and need some additional
propagated inputs.  Examples would be babel-french needing scalefnt,
fontspec needing luaotfload, or hyperref needing stringenc.  Is there
any established policy for what propagated-inputs need to be included in
package definitions?  Should we add some LaTeX specific packaging
guidelines in the manual, like for Python or Rust (the former is
outdated by the way, mentioning Python 2 packages).

I can work on those if there's some sort of consensus, but just need
some advice from more experienced LaTeX packagers.

Best,
-- 
Josselin Poiret

Re: Stratification of GNU Guix into Independent Channels

[Josselin Poiret]

Hi jgart,

IMO, having everything in one repo, while going against the "modularity"
philosophy, really helps a lot when updating packages.  In my experience
with the Other Channel That We Should Not Talk About, there often are
breaking changes in the main repository that lead to the other channel
being broken for a couple of days.  It would take way longer for changes
to propagate things to the "leaf" channels.

Also, you can't reasonably expect programs to be categorized that well
(although I'm pretty sure there could be consensus on non-PITA
vs. PITA-packages with the usual suspects :) ).

I don't think there is a way to reconcile the "complete system
distribution" and "completely modular distribution" viewpoints, at least
at that level.  The channels approach that exists for now is a nice
pragmatic solution that still allows quite a lot of freedom.

Best,
-- 
Josselin Poiret

Re: Stratification of GNU Guix into Independent Channels

[Liliana Marie Prikler]

Am Samstag, dem 24.12.2022 um 03:49 + schrieb jgart:
> Hi Guixers,
> 
> I wanted to ask you what are your thoughts on this idea. This is a
> thought experiment at this stage.
> 
> Should GNU Guix be a small core of packages (and services?)?
No, it should be a functional operating system.

> What do you think would be the pros and cons of the stratified
> approach versus the monorepo approach that we currently have?
I think monorepo is a weird term to apply to Guix.  Yes, it is just a
single repository, but notably, it doesn't collect the sources of every
other package out there to put it into a single tree.  Instead, it
contains a recipe per package.  This makes it no different from Debian,
Arch, Gentoo, or any other package manager out there.

> GNU Guix proper would be a solid core of packages that is very easy
> to maintain. This would greatly reduce the maintenance burden since
> maintaining a world of rust, golang, or python packages is opt in by
> those who want to do that particular work.
No, it wouldn't.  Suppose this bootstrap Guix consisted only of
packages up to GCC.  Then any change to it would result in non-local
changes (and potential breakages) in every other channel in existence
and the local CI would never catch that.  As it currently stands, GCC
breaking some other package would be caught on core-updates.

> Users can opt out of certain channels. For example, there might be
> some users that want absolutely no rust or some other language or
> ecosystem of packages from being downloaded on their machine for
> whatever reason. Same goes for any other languages.
You can not opt out of Rust if you depend on librsvg.  In future, you
might not even be able to opt out of Rust when using the Linux kernel.
Yes, this is possibly the worst timeline to live in, but we need
solutions to actually deal with it, not burying our heads in sand.

> Would being subscribed to just the hypothetical small core channel in
> this proposal increase download/installation speeds given the
> availability of substitutes?
Not really, because for a functional system you would have to pull in
other channels.  With a stricter module layout we could possibly
modularize guix pull further, thus decreasing individual derivation
time, but that alone is a daunting task and not guaranteed to bring big
improvements.

What does work is convincing upstreams to pull in less dependencies and
drop the outdated ones, because that makes it so that eventually Guix
has to ship less packages.

Cheers

Help needed adapting IceCat patches to 102

[Adam Faiz]

Hello everyone,

I don't know what I'm doing wrong with adding configure options, but 
icecat-102.6.0-guix0-preview1/moz.configure still doesn't recognise 
--with-system-ogg after applying the attached patches.
I think the problem is that it's not registering properly in 
toolkit/moz.configure or maybe also needs to be registered elsewhere.


The other --with-system options the patches aim to fix probably also 
don't work, because it fails with ogg first before the others when I 
added all the related --with-system ones to the #:configure-flags.


I've tried a few option registration variations found in 
icecat-102.6.0-guix0-preview1/moz.configure already, but it still fails.


It also doesn't help that the patches developing cycle is at least 20 
minutes long, to extract icecat and run the phases prior to configure. 
I'm not sure if it's faster on other machines, but I'm on a Thinkpad T410.


I'm hoping that once the options are recognised, building icecat will be 
smooth sailing. The adapted patches should be sent to the linked bug 
reports[1][2].


1: https://bugzilla.mozilla.org/show_bug.cgi?id=847568
2: https://bugzilla.mozilla.org/show_bug.cgi?id=517422From 557c2020d765c0802dd5fd55fe0742f61fb925a5 Mon Sep 17 00:00:00 2001
From: AwesomeAdam54321 
Date: Wed, 21 Dec 2022 14:32:12 +0800
Subject: [PATCH 1/3] icecat-avoid-bundled-libraries

Fixes needed when avoiding bundled libraries.
---
 dom/indexedDB/moz.build| 1 -
 storage/moz.build  | 1 -
 third_party/libwebrtc/rtc_base/rtc_task_queue_gn/moz.build | 2 --
 xpcom/build/moz.build  | 5 -
 4 files changed, 9 deletions(-)

diff --git a/dom/indexedDB/moz.build b/dom/indexedDB/moz.build
index 9282d91a..500366ed 100644
--- a/dom/indexedDB/moz.build
+++ b/dom/indexedDB/moz.build
@@ -116,7 +116,6 @@ LOCAL_INCLUDES += [
 "/dom/base",
 "/dom/storage",
 "/ipc/glue",
-"/third_party/sqlite3/src",
 "/xpcom/build",
 ]
 
diff --git a/storage/moz.build b/storage/moz.build
index 3bc84420..7ce5ca26 100644
--- a/storage/moz.build
+++ b/storage/moz.build
@@ -101,7 +101,6 @@ DEFINES["SQLITE_MAX_LIKE_PATTERN_LENGTH"] = 5
 
 LOCAL_INCLUDES += [
 "/dom/base",
-"/third_party/sqlite3/src",
 ]
 
 CXXFLAGS += CONFIG["SQLITE_CFLAGS"]
diff --git a/third_party/libwebrtc/rtc_base/rtc_task_queue_gn/moz.build b/third_party/libwebrtc/rtc_base/rtc_task_queue_gn/moz.build
index 7ddc659b..0dfa27fb 100644
--- a/third_party/libwebrtc/rtc_base/rtc_task_queue_gn/moz.build
+++ b/third_party/libwebrtc/rtc_base/rtc_task_queue_gn/moz.build
@@ -22,8 +22,6 @@ FINAL_LIBRARY = "webrtc"
 LOCAL_INCLUDES += [
 "!/ipc/ipdl/_ipdlheaders",
 "/ipc/chromium/src",
-"/third_party/libwebrtc/",
-"/third_party/libwebrtc/third_party/abseil-cpp/",
 "/tools/profiler/public"
 ]
 
diff --git a/xpcom/build/moz.build b/xpcom/build/moz.build
index d86af97c..46de45da 100755
--- a/xpcom/build/moz.build
+++ b/xpcom/build/moz.build
@@ -100,8 +100,3 @@ LOCAL_INCLUDES += [
 "/docshell/base",
 "/js/xpconnect/loader",
 ]
-
-if CONFIG["MOZ_VPX"]:
-LOCAL_INCLUDES += [
-"/media/libvpx",
-]
-- 
2.38.1

From 8e64027b6b188d4c016fc8ca427965d1a2560687 Mon Sep 17 00:00:00 2001
From: AwesomeAdam54321 
Date: Wed, 21 Dec 2022 14:37:57 +0800
Subject: [PATCH 2/3] icecat-use-system-graphite2+harfbuzz

Allow building against system-wide graphite2/harfbuzz.
See 
Based on:
  https://svnweb.freebsd.org/ports/head/www/firefox-esr/files/patch-bug847568?revision=472833=co
Modified for use with patch -p1, and to apply cleanly to GNU IceCat.
---
 config/system-headers.mozbuild  | 13 +
 dom/base/moz.build  |  3 +++
 gfx/graphite2/moz-gr-update.sh  |  7 ++-
 gfx/moz.build   |  8 ++--
 gfx/skia/generate_mozbuild.py   |  3 +++
 gfx/skia/moz.build  |  3 +++
 gfx/thebes/moz.build|  8 +++-
 intl/unicharutil/util/moz.build |  3 +++
 netwerk/dns/moz.build   |  3 +++
 old-configure.in| 21 +
 toolkit/library/moz.build   |  6 ++
 toolkit/moz.configure   | 28 
 12 files changed, 102 insertions(+), 4 deletions(-)

diff --git a/config/system-headers.mozbuild b/config/system-headers.mozbuild
index 9c07dba2..5594d659 100644
--- a/config/system-headers.mozbuild
+++ b/config/system-headers.mozbuild
@@ -1293,6 +1293,19 @@ if CONFIG['MOZ_ENABLE_LIBPROXY']:
 'proxy.h',
 ]
 
+if CONFIG['MOZ_SYSTEM_GRAPHITE2']:
+system_headers += [
+'graphite2/Font.h',
+'graphite2/Segment.h',
+]
+
+if CONFIG['MOZ_SYSTEM_HARFBUZZ']:
+system_headers += [
+'harfbuzz/hb-glib.h',
+'harfbuzz/hb-ot.h',
+'harfbuzz/hb.h',
+]
+
 if CONFIG['MOZ_SYSTEM_LIBVPX']:
 system_headers += [
 'vpx_mem/vpx_mem.h',
diff --git 

[PATCH] gnu: Add python-tcod.

[Adam Kandur]

* gnu/packages/game-development.scm (python-tcod): New variable.
---
 gnu/packages/game-development.scm | 47 +++
 1 file changed, 47 insertions(+)

diff --git a/gnu/packages/game-development.scm 
b/gnu/packages/game-development.scm
index 8fec474d0b..2746c43a5f 100644
--- a/gnu/packages/game-development.scm
+++ b/gnu/packages/game-development.scm
@@ -64,6 +64,7 @@ (define-module (gnu packages game-development)
   #:use-module (gnu packages bash)
   #:use-module (gnu packages boost)
   #:use-module (gnu packages build-tools)
+  #:use-module (gnu packages c)
   #:use-module (gnu packages compression)
   #:use-module (gnu packages check)
   #:use-module (gnu packages curl)
@@ -86,6 +87,7 @@ (define-module (gnu packages game-development)
   #:use-module (gnu packages guile)
   #:use-module (gnu packages image)
   #:use-module (gnu packages linux)
+  #:use-module (gnu packages libffi)
   #:use-module (gnu packages llvm)
   #:use-module (gnu packages lua)
   #:use-module (gnu packages m4)
@@ -97,6 +99,7 @@ (define-module (gnu packages game-development)
   #:use-module (gnu packages pkg-config)
   #:use-module (gnu packages pulseaudio)
   #:use-module (gnu packages python)
+  #:use-module (gnu packages python-check)
   #:use-module (gnu packages python-web)
   #:use-module (gnu packages python-xyz)
   #:use-module (gnu packages readline)
@@ -2604,6 +2607,50 @@ (define-public libtcod
 utilities frequently used in roguelikes.")
 (license license:bsd-3)))
 
+(define-public python-tcod
+  ;; named branch is outdated
+  (let ((commit "d3419a5b4593c7df1580427fc07616d798c85856")
+(revision "1"))
+(package
+  (name "python-tcod")
+  (version "13.9.1")
+  (source
+   (origin
+ (method git-fetch)
+ (uri (git-reference
+   (url "https://github.com/libtcod/python-tcod;)
+   (commit commit)
+   (recursive? #true)))
+ (file-name (git-file-name name version))
+ (sha256
+  (base32
+   "1b0ligrswvz307bbx5jp8wnnqz52v5s4gcgakxy4i3jvccalm2if"
+  (build-system python-build-system)
+  ;; tests fail for a strange reason
+  ;; "ERROR docs/conf.py - FileNotFoundError",
+  ;; but this file is in the checkout
+  (arguments
+   '(#:tests? #f))
+  (native-inputs
+   (list sdl2
+ python-pcpp
+ python-pycparser
+ python-requests
+ python-pytest-runner
+ python-pytest-benchmark
+ python-pytest-cov))
+  (propagated-inputs
+   (list python-numpy
+ python-typing-extensions
+ python-cffi))
+  (home-page "https://github.com/libtcod/python-tcod;)
+  (synopsis
+   "This library is a Python cffi port of libtcod")
+  (description
+   "A high-performance Python port of libtcod.
+Includes the libtcodpy module for backwards compatibility with older 
projects.")
+  (license license:bsd-2
+
 (define-public warsow-qfusion
   ;; As of 2020-04-09, the latest stable version 2.1.0 is deprecated.
   ;; The 2.5 beta as published on the homepage is commit
-- 
2.38.1

Example Nginx config from Guix manual does not work

[Adam Kandur]

Hi guix!(service nginx-service-type    (nginx-configuration   
  (server-blocks  (list (nginx-server-configuration   
  (server-name '("www.example.com")) (root 
"/srv/http/www.example.com")) produce this nginx configuser nginx nginx;pid 
/var/run/nginx/pid;error_log /var/log/nginx/error.log info;events { }http {    client_body_temp_path 
/var/run/nginx/client_body_temp;    proxy_temp_path /var/run/nginx/proxy_temp;    fastcgi_temp_path 
/var/run/nginx/fastcgi_temp;    uwsgi_temp_path /var/run/nginx/uwsgi_temp;    scgi_temp_path 
/var/run/nginx/scgi_temp;    access_log /var/log/nginx/access.log;    include 
/gnu/store/dngffa0df8zsxlbi630656688zhly6p5-nginx-1.23.2/share/nginx/conf/mime.types;    server {  listen 
80;  listen 443 ssl;  server_name www.example.com ;  root /srv/http/www.example.com;  index 
index.html ;  server_tokens off;    }}Which will not work because it asks to listen on 443 with ssl, 
which is not possible because no certificates are provided. Removing the line "listen 443 ssl;" 
solves this problem.

Stratification of GNU Guix into Independent Channels, X-mas and Guix days!

[Pjotr Prins]

tis like packages under a X-mas tree

guix xmas add games
guix xmas add tex
guix xmas add paint
guix xmas add payamas

unlike debian these packages contain packages that can overlap too!

that would be interesting.

happy holidays Guix and thank you community! Hope to see you all at
Guix days in Brussels 2+3 Feb. Do sign up if you plan to come. We will
be there!

https://libreplanet.org/wiki/Group:Guix/FOSDEM2023

Pj.

On Sat, Dec 24, 2022 at 05:24:08AM +, jgart wrote:
> I think we also need a channel manager subcommand:
> 
> guix channel add python
> guix channel add rust
> guix channel add gaming
> guix channel add rde
> guix channel add guixrus
> guix channel add non
> etc.
> 
> The above commands would subscribe you to a given trusted Guix channel.
> 
> The last three are channels not under the auspices of GNU but I think that 
> this `guix channel` subcommand should allow you to extend the Guix "channel 
> webring" as you like.
> 
> Just another (un)related idea that I'd like to see someday.
> 
> all best,
> 
> jgart
>