Re: package update patches and "core-update" branch

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

Hi Andy,

On Thu, Nov 24, 2022 at 5:05 PM Andy Tai  wrote:
>
> Curious is there any guideline on when, and what type of, patches
> should target core-update? Thanks

The manual probably explains that better and more accurately than I
could. Please have a look at the checklist item #9 here. [1]

Kind regards
Felix Lechner

[1] https://guix.gnu.org/manual/devel/en/html_node/Submitting-Patches.html

package update patches and "core-update" branch

[Andy Tai]

Hi, I sent in some patches for package updates for guix which got
merged; thanks for that. The review comments ask for future patches to
indicate if they should be for the core update branch.

Curious is there any guideline on when, and what type of, patches
should target core-update? Thanks

Re: issue tracking in git

[Arun Isaac]

Hi Giovanni,

> Please Arun is there a devel mailing list dedicated to tissue so we can
> discuss details of the project?

There isn't one yet, but I will set up a public inbox soon.

> I'm not a Guile developer but I would like to help with testing and (the
> lack of) documentation, if I can.

Yes, please. Patches are always welcome. I can use all the help I can
get. Here are a list of issues and feature requests you can work on:
https://tissue.systemreboot.net/search Your ideas adding to these are
also very welcome.

> I'd also like to understand and possibly discuss the overall
> architecture design of tissue, in particular compared to git-issue
> internals [1]

Until the public inbox is ready, you can always mail me and/or Pjotr
directly.

> Last but not least: what about to have tissue packaged [2] in Guix?
> :-D

Yes, definitely. A tissue 0.1.0 release and a Guix package for it have
been long overdue.

I'm in the middle of uprooting and moving across continents for
work. So, my time is somewhat limited. But, I promise to work on
this. Pjotr suggested off-list that I might make a FOSDEM talk out of
all this. I think it's a good idea. I'll work towards that goal.

Cheers!
Arun

[RFC] package-with-features

[(]

Heya Guix,

This comment by oriansj on IRC:

   I am thinking in terms of gentoo builds and making
  it easy to avoid some packages from being downloaded or built
  like pulseaudio (I like alsa better) and trim down the dependencies
  to only those that are absolutely directly required.

made me wonder how we could incorporate such a feature into
Guix.

# Why it's Needed

Sure, it's already possible to create package variants:

  (define-public foo
(package
  (name "foo")
  (version "1.2.3")
  (source (origin
   ...))
  (build-system gnu-build-system)
  (arguments
   (list #:configure-flags
 #~(list "--enable-pulseaudio")))
  (inputs (list pulseaudio ...))
  ...))

  (define-public foo/without-pulseaudio
(package
  (inherit foo)
  (name "foo-without-pulseaudio")
  (arguments
   (substitute-keyword-arguments (package-arguments foo)
 ((#:configure-flags old-flags)
  #~(list #$@flags
  "--disable-pulseaudio"
  (inputs
   (modify-inputs (package-inputs foo)
 (delete pulseaudio)

This is currently manageable, but what if there's another optional
feature, say, pipewire support?

  (define-public foo/without-pipewire
(package
  (inherit foo)
  (name "foo-without-pulseaudio")
  (arguments
   (substitute-keyword-arguments (package-arguments foo)
 ((#:configure-flags old-flags)
  #~(list #$@flags
  "--disable-pipewire"
  (inputs
   (modify-inputs (package-inputs foo)
 (delete pipewire)

And it's entirely reasonable to want to disable both and just use
Ye Olde ALSA...

  (define-public foo/without-pipewire-or-pulse
(package
  (inherit foo/without-pipewire)
  (name "foo-without-pulseaudio-or-pulse")
  (arguments
   (substitute-keyword-arguments
   (package-arguments foo/without-pipewire)
 ((#:configure-flags old-flags)
  #~(list #$@flags
  "--disable-pulseaudio"
  (inputs
   (modify-inputs (package-inputs foo/without-pipewire)
 (delete pulseaudio)

We only have two features, pulseaudio and pipewire, and it's already
getting A Wee Bit Silly. Even worse if we have 3 features:

  /without-pipewire
  /without-pulse
  /without-jack
  /without-pipewire-or-pulse
  /without-pipewire-or-jack
  /without-pulse-or-jack
  /without-pipewire-pulse-or-jack

And now there are seven variants, and eight ``foo'' packages in total.
We can do better, surely? Here's my proposal: a new ``features'' field
for ``package'' that accepts a list of records like this:

  (define-public foo
(package
  ...
  (features
   (list (feature
  (name "jack")
  (default? #f)
  (description "JACK audio backend"))
 (feature
  (name "pipewire")
  (default? #t)
  (description "Pipewire audio backend"))
 (feature
  (name "pulseaudio")
  (default? #t)
  (description "PulseAudio audio backend"
  ...))

And then we'd simply have a ``feature?'' (or some other name) procedure
that we can use in a package definition.

  (define-public foo
(package
  ...
  (arguments
   (list #:configure-flags
 #~(list (if #$(feature? "jack")
 "--enable-jack"
 "--disable-jack")
 (if #$(feature? "pipewire")
 "--enable-pipewire"
 "--disable-pipewire")
 (if #$(feature? "pulseaudio")
 "--enable-pulseaudio"
 "--disable-pulseaudio"
  (inputs
   (append (list alsa-lib)
   (if (feature? "jack")
   (list jack)
   '())
   (if (feature? "pipewire")
   (list pipewire)
   '())
   (if (feature? "pulseaudio")
   (list pulseaudio)
   '(
  ...))

# Features and the CLI

When you ``guix show'' this package, it would display something like
this:

  name: foo
  version: 0.2.7
  outputs:
  + out: everything
  features:
  + jack (disabled): JACK audio backend
  + pipewire (enabled): Pipewire audio backend
  + pulseaudio (enabled): PulseAudio audio backend
  systems: x86_64-linux
  dependencies: alsa-lib@... jack[jack]@...
  + pipewire[pipewire]@... pulseaudio[pulseaudio]@...
  location: ...
  homepage: ...
  license: ...
  synopsis: ...
  description: ...

Note those square brackets; this is how we specify features in package
specifications, as they are treated as normal characters in POSIX-like
shells and Fish (probably most others, too).

This installs foo without the pulseaudio feature.

  guix install foo[!pulseaudio]

This installs foo with the jack feature and without the pipewire feature.

  guix 

Release progress, week 7

[Ludovic Courtès]

Hello Guix!

Release progress: week 7.

  • ‘make assert-binaries-available’ reports 99% coverage (details
below).  

  • Architectures:

 - i586-gnu: Instead of dropping i586-gnu from
   ‘etc/release-manifest.scm’, I fixed a few things, running ‘guix
   build’ on berlin to get substitutes there—almost there!

 - armhf-linux: I started builds manually on berlin and we’re almost
   done.

 - aarch64-linux, powerpc64le-linux: Likewise, filled the gaps
   manually and now we’re passing on both!

  • Installer:

We seem to be ready to call for testing.

  • Release issue  blocked by 1 open
bug (1 fixed, 1 removed, and 1 new since last week):

59519  LibreOffice 7.3.5.2 fails to build on i686-linux

• Others:

 - Some Cuirass, offload, and infrastructure issues were fixed:
 
 
   Others are investigated: .

 - Nautilus crash fixedL 

Mathieu created a ‘version-1.4.0’ branch.  As soon as ‘make
assert-binaries-available’ passes, I think we can produce a release
candidate (in the process we may find a couple of issues to fix) and
call for testing.  This could be done by next week.

Thoughts?

Ludo’.

Week 6: https://lists.gnu.org/archive/html/guix-devel/2022-11/msg00161.html
Week 5: https://lists.gnu.org/archive/html/guix-devel/2022-11/msg00026.html
Week 4: https://lists.gnu.org/archive/html/guix-devel/2022-11/msg00026.html
Week 3: https://lists.gnu.org/archive/html/guix-devel/2022-10/msg00293.html
Week 2: https://lists.gnu.org/archive/html/guix-devel/2022-10/msg00210.html
Week 1: https://lists.gnu.org/archive/html/guix-devel/2022-10/msg00137.html

computing 400 package derivations for x86_64-linux...
looking for 507 store items on https://ci.guix.gnu.org...
https://ci.guix.gnu.org ☀
  99.0% substitutes available (502 out of 507)
  at least 4,800.6 MiB of nars (compressed)
  8,080.7 MiB on disk (uncompressed)
  0.140 seconds per request (0.8 seconds in total)
  7.1 requests per second

  0.0% (0 out of 5) of the missing items are queued
  at least 1,000 queued builds
  aarch64-linux: 990 (99.0%)
  powerpc64le-linux: 8 (.8%)
  x86_64-linux: 2 (.2%)
  build rate: 339.14 builds per hour
  x86_64-linux: 302.52 builds per hour
  i686-linux: 41.67 builds per hour

Substitutes are missing for the following items:
  /gnu/store/c10jgnxjx5qx2h4lqy5h4ar6qidn7fmi-libreoffice-7.3.5.2   

 i686-linux
  /gnu/store/d30mmhijhyy4kkykxikc28bnj9iad7zh-gcc-toolchain-12.2.0-debug

 i586-gnu
  /gnu/store/gz7l1491gwznwhwssd2h13y5ykrks11q-gcc-toolchain-12.2.0  

 i586-gnu
  /gnu/store/sfaigxk5z4xxxn8y1v05c2lz3hgb63gy-gcc-toolchain-12.2.0-static   

 i586-gnu
  /gnu/store/v7xmdapgwgqgcnacf3qmapahgwfbgcsq-emacs-28.2

 armhf-linux