Guix QA: trigger rebuild

[Andy Tai]

Hi,  if Guix QA shows a patch build is failing and an updated patch
has been sent, how to trigger the build to be restarted? Thanks for
info

Guix QA: trigger rebuild

[Andy Tai]

Hi,  if Guix QA shows a patch build is failing and an updated patch
has been sent, how to trigger the build to be restarted? Thanks for
info

Re: Packaging Grafana

[Katherine Cox-Buday]

Katherine Cox-Buday  writes:

Sorry, I had a bug in my format one-liner which gave versions parenthesis. This 
should be copy/pastable:

--8<---cut here---start->8---
scheme@(guix import go)> (for-each (lambda (p) (format #t "guix import go -r 
~a@~a >> grafana.scm~%" (car p) (second p))) $11)
guix import go -r google.golang.org/genproto@v0.0.0-20220421151946-72621c1f0bd3 
>> grafana.scm
guix import go -r google.golang.org/grpc@v1.45.0 >> grafana.scm
guix import go -r 
github.com/grafana/prometheus-alertmanager@v0.24.1-0.20221012142027-823cd9150293
 >> grafana.scm
guix import go -r github.com/grafana/xorm@v0.8.3-0.20220614223926-2fcda7565af6 
>> grafana.scm
guix import go -r github.com/hashicorp/go-hclog@v0.16.1 >> grafana.scm
guix import go -r github.com/grafana/saml@v0.4.9-0.20220727151557-61cd9c9353fc 
>> grafana.scm
guix import go -r github.com/moby/moby@v0.7.3-0.20190826074503-38ab9da00309 >> 
grafana.scm
guix import go -r github.com/gomodule/redigo@v1.8.9 >> grafana.scm
guix import go -r github.com/russellhaering/goxmldsig@v1.1.1 >> grafana.scm
guix import go -r 
github.com/grafana/go-mssqldb@v0.0.0-20210326084033-d0ce3c521036 >> grafana.scm
guix import go -r gopkg.in/warnings.v0@v0.1.2 >> grafana.scm
guix import go -r golang.org/x/mod@v0.7.0 >> grafana.scm
guix import go -r go.opentelemetry.io/proto/otlp@v0.16.0 >> grafana.scm
guix import go -r go.opentelemetry.io/otel/exporters/otlp/internal/retry@v1.7.0 
>> grafana.scm
guix import go -r github.com/yudai/pp@v2.0.1+incompatible >> grafana.scm
guix import go -r github.com/xlab/treeprint@v1.1.0 >> grafana.scm
guix import go -r github.com/xanzy/ssh-agent@v0.3.0 >> grafana.scm
guix import go -r github.com/wk8/go-ordered-map@v1.0.0 >> grafana.scm
guix import go -r github.com/valyala/fasttemplate@v1.2.1 >> grafana.scm
guix import go -r github.com/pierrec/lz4/v4@v4.1.12 >> grafana.scm
guix import go -r github.com/mschoch/smat@v0.2.0 >> grafana.scm
guix import go -r github.com/mitchellh/go-wordwrap@v1.0.1 >> grafana.scm
guix import go -r github.com/mitchellh/go-homedir@v1.1.0 >> grafana.scm
guix import go -r github.com/labstack/gommon@v0.3.1 >> grafana.scm
guix import go -r github.com/labstack/echo/v4@v4.9.0 >> grafana.scm
guix import go -r github.com/kylelemons/godebug@v1.1.0 >> grafana.scm
guix import go -r github.com/klauspost/compress@v1.15.5 >> grafana.scm
guix import go -r 
github.com/kevinburke/ssh_config@v0.0.0-20201106050909-4977a11b4351 >> 
grafana.scm
guix import go -r 
github.com/jbenet/go-context@v0.0.0-20150711004518-d14ea06fba99 >> grafana.scm
guix import go -r github.com/imdario/mergo@v0.3.12 >> grafana.scm
guix import go -r github.com/grpc-ecosystem/grpc-gateway/v2@v2.10.3 >> 
grafana.scm
guix import go -r github.com/google/go-github@v17.0.0+incompatible >> 
grafana.scm
guix import go -r github.com/golang-jwt/jwt@v3.2.2+incompatible >> grafana.scm
guix import go -r github.com/go-logr/stdr@v1.2.2 >> grafana.scm
guix import go -r github.com/go-logr/logr@v1.2.3 >> grafana.scm
guix import go -r github.com/go-git/go-billy/v5@v5.3.1 >> grafana.scm
guix import go -r github.com/go-git/gcfg@v1.5.0 >> grafana.scm
guix import go -r github.com/ghodss/yaml@v1.0.1-0.20190212211648-25d852aebe32 
>> grafana.scm
guix import go -r github.com/emirpasic/gods@v1.12.0 >> grafana.scm
guix import go -r github.com/elazarl/goproxy@v0.0.0-20220115173737-adb46da277ac 
>> grafana.scm
guix import go -r 
github.com/dgryski/go-metro@v0.0.0-20211217172704-adc40b04c140 >> grafana.scm
guix import go -r github.com/coreos/go-semver@v0.3.0 >> grafana.scm
guix import go -r 
github.com/chromedp/cdproto@v0.0.0-20220208224320-6efb837e6bc2 >> grafana.scm
guix import go -r github.com/caio/go-tdigest@v3.1.0+incompatible >> grafana.scm
guix import go -r github.com/blugelabs/ice@v1.0.0 >> grafana.scm
guix import go -r github.com/blevesearch/vellum@v1.0.7 >> grafana.scm
guix import go -r github.com/blevesearch/snowballstem@v0.9.0 >> grafana.scm
guix import go -r github.com/blevesearch/segment@v0.9.0 >> grafana.scm
guix import go -r github.com/blevesearch/mmap-go@v1.0.4 >> grafana.scm
guix import go -r github.com/blevesearch/go-porterstemmer@v1.0.3 >> grafana.scm
guix import go -r github.com/bits-and-blooms/bitset@v1.2.0 >> grafana.scm
guix import go -r 
github.com/axiomhq/hyperloglog@v0.0.0-20191112132149-a4c4c47bc57f >> grafana.scm
guix import go -r github.com/acomagu/bufpipe@v1.0.3 >> grafana.scm
guix import go -r github.com/RoaringBitmap/roaring@v0.9.4 >> grafana.scm
guix import go -r 
github.com/ProtonMail/go-crypto@v0.0.0-20210428141323-04723f9f07d7 >> 
grafana.scm
guix import go -r github.com/Microsoft/go-winio@v0.5.2 >> grafana.scm
guix import go -r 
github.com/AzureAD/microsoft-authentication-library-for-go@v0.4.0 >> grafana.scm
guix import go -r 
github.com/Azure/azure-sdk-for-go/sdk/keyvault/internal@v0.2.1 >> grafana.scm
guix import go -r github.com/Azure/azure-sdk-for-go/sdk/azcore@v0.22.0 >> 
grafana.scm
guix import go -r 

Re: Getting tree-sitter grammars in Guix

[Katherine Cox-Buday]

Demis Balbach  writes:

> Hello, I was wondering what the "correct" way would be to get grammars
> for the tree-sitter library available in Guix when using tree-sitter
> with Emacs 29+.
>
> There is https://github.com/emacs-tree-sitter/tree-sitter-langs, but I
> don't think it has been packaged in Guix yet. I started packaging the
> grammar for JS/TS:
>
> (define-public tree-sitter-javascript
>   (let ((commit "7a29d06274b7cf87d643212a433d970b73969016")
> (revision "0")
> (version "0.20.0"))
> (package
>  (name "tree-sitter-javascript")
>  (version (git-version version revision commit))
>  (source
>   (origin
>(method git-fetch)
>(uri (git-reference
>  (url "https://github.com/tree-sitter/tree-sitter-javascript;)
>  (commit commit)))
>(sha256
> (base32 "1pk6d9g6a7bzhxmwnvfiycarcgz76wq2rgfqr0xjh7y7swfw5hvw"))
>(file-name (git-file-name name version
>  (build-system gnu-build-system)
>  (native-inputs
>   (list gcc))
>  (arguments
>   `(#:tests?
> #f
> #:phases
> (modify-phases
>  %standard-phases
>  (delete 'configure)
>  (delete 'install)
>  (delete 'build)
>  (add-after 'unpack 'create-dirs
> (lambda _ (mkdir "lib")))
>  (add-after 'create-dirs 'compile
> (lambda* (#:key inputs outputs #:allow-other-keys)
>   (let* ((out (assoc-ref outputs "out"))
>  (gcc (string-append (assoc-ref inputs "gcc") 
> "/bin")))
> (copy-file "grammar.js" "src/grammar.js")
> (with-directory-excursion
>  (string-append "./src")
>  (invoke (string-append gcc "/gcc") "-fPIC" "-c" 
> "-I." "parser.c")
>  (invoke (string-append gcc "/gcc") "-fPIC" "-c" 
> "-I." "scanner.c")
>  (invoke (string-append gcc "/gcc")
>  "-fPIC" "-shared" "parser.o" "scanner.o" "-o"
>  "libtree-sitter-javascript.so")
>  (add-after 'compile 'symlink
> (lambda* (#:key inputs outputs #:allow-other-keys)
>   (let* ((out (assoc-ref outputs "out"))
>  (lib (string-append out "/lib")))
> (install-file "src/libtree-sitter-javascript.so" 
> lib)))
>   (home-page "https://github.com/tree-sitter/tree-sitter-javascript;)
>  (synopsis "JavaScript and JSX grammar for tree-sitter.")
>  (description "JavaScript and JSX grammar for tree-sitter.")
>  (license license:expat
>
> But I'm not sure if packaging each grammar is the correct way. I
> hesitate to continue working on this because there are not other
> grammars packaged in Guix (yet). With tree-sitter being built into
> Emacs 29+ I expected grammars to be packaged already (hence why I'm
> asking if this approach is correct).


This seems correct to me, but you might get more informed opinions on
guix-devel@gnu.org (CCed), since this is a packaging question.

>
> Thanks in advance!

-- 
Katherine

Re: Packaging Grafana

[Katherine Cox-Buday]

phodina via  writes:

> Hi Guix,

Hey Petr, thanks for having a go at packaging this! It would be awesome
to have Grafana in Guix!

I was able to troubleshoot this a little. I agree with the sentiment[1][2]
that the Guix importer should just use Go tooling; however, I don't
think it's at fault here.

By default, the importer uses https://proxy.golang.org to fetch a
module's go.mod file. Let's see what that says:

--8<---cut here---start->8---
$ curl 
https://proxy.golang.org/github.com/grafana/grafana/@v/v5.4.5+incompatible.mod
module github.com/grafana/grafana
--8<---cut here---end--->8---

Weird.

Also, pkg.go.dev versions seem to disagree with both Git tags and
Grafana's stated latest version, v9.3.2:

--8<---cut here---start->8---
$ git ls-remote --tags g...@github.com:grafana/grafana.git |awk '{print $2}' 
|sort |tail -4
refs/tags/v9.3.2
refs/tags/v9.3.2^{}
refs/tags/vtest-new-release-pipeline
refs/tags/vtest-new-release-pipeline^{}
--8<---cut here---end--->8---

Then there's this commit[3], stating:

**Warning:** Do not use `go get` to download Grafana. Recent
  versions of Go have added behavior which isn't compatible with
  the way the Grafana repository is structured.

OK, so I think even Go's toolchain is having issues with this.

If I start a REPL, we can test out theory:

--8<---cut here---start->8---
$ guix repl
scheme@(guile-user)> ,m (guix import go)
scheme@(guix import go)> (http-fetch* 
"https://raw.githubusercontent.com/grafana/grafana/v9.3.2/go.mod;)
$9 = [removed lengthy go.mod output]
scheme@(guix import go)> (parse-go.mod $9)
$10 = [removed lengthy parsed representation]
scheme@(guix import go)> (go.mod-requirements $10)
$11 = (("google.golang.org/genproto" "v0.0.0-20220421151946-72621c1f0bd3") 
("google.golang.org/grpc" "v1.45.0") [etc..])
scheme@(guix import go)> (length $11)
$12 = 319
--8<---cut here---end--->8---

That looks plausibly correct.

So to work around Grafana's weirdness, we can just manually import all
of its requirements, recursively. I think you should be able to
cut-paste this and, if there are no more weird packages, you'll be off
to the races :)

--8<---cut here---start->8---
scheme@(guix import go)> (for-each (lambda (p) (format #t "guix import go -r 
~a@~a >> grafana.scm~%" (car p) (cdr p))) $11)
guix import go -r 
google.golang.org/genproto@(v0.0.0-20220421151946-72621c1f0bd3) >> grafana.scm
guix import go -r google.golang.org/grpc@(v1.45.0) >> grafana.scm
guix import go -r 
github.com/grafana/prometheus-alertmanager@(v0.24.1-0.20221012142027-823cd9150293)
 >> grafana.scm
guix import go -r 
github.com/grafana/xorm@(v0.8.3-0.20220614223926-2fcda7565af6) >> grafana.scm
guix import go -r github.com/hashicorp/go-hclog@(v0.16.1) >> grafana.scm
guix import go -r 
github.com/grafana/saml@(v0.4.9-0.20220727151557-61cd9c9353fc) >> grafana.scm
guix import go -r github.com/moby/moby@(v0.7.3-0.20190826074503-38ab9da00309) 
>> grafana.scm
guix import go -r github.com/gomodule/redigo@(v1.8.9) >> grafana.scm
guix import go -r github.com/russellhaering/goxmldsig@(v1.1.1) >> grafana.scm
guix import go -r 
github.com/grafana/go-mssqldb@(v0.0.0-20210326084033-d0ce3c521036) >> 
grafana.scm
guix import go -r gopkg.in/warnings.v0@(v0.1.2) >> grafana.scm
guix import go -r golang.org/x/mod@(v0.7.0) >> grafana.scm
guix import go -r go.opentelemetry.io/proto/otlp@(v0.16.0) >> grafana.scm
guix import go -r 
go.opentelemetry.io/otel/exporters/otlp/internal/retry@(v1.7.0) >> grafana.scm
guix import go -r github.com/yudai/pp@(v2.0.1+incompatible) >> grafana.scm
guix import go -r github.com/xlab/treeprint@(v1.1.0) >> grafana.scm
guix import go -r github.com/xanzy/ssh-agent@(v0.3.0) >> grafana.scm
guix import go -r github.com/wk8/go-ordered-map@(v1.0.0) >> grafana.scm
guix import go -r github.com/valyala/fasttemplate@(v1.2.1) >> grafana.scm
guix import go -r github.com/pierrec/lz4/v4@(v4.1.12) >> grafana.scm
guix import go -r github.com/mschoch/smat@(v0.2.0) >> grafana.scm
guix import go -r github.com/mitchellh/go-wordwrap@(v1.0.1) >> grafana.scm
guix import go -r github.com/mitchellh/go-homedir@(v1.1.0) >> grafana.scm
guix import go -r github.com/labstack/gommon@(v0.3.1) >> grafana.scm
guix import go -r github.com/labstack/echo/v4@(v4.9.0) >> grafana.scm
guix import go -r github.com/kylelemons/godebug@(v1.1.0) >> grafana.scm
guix import go -r github.com/klauspost/compress@(v1.15.5) >> grafana.scm
guix import go -r 
github.com/kevinburke/ssh_config@(v0.0.0-20201106050909-4977a11b4351) >> 
grafana.scm
guix import go -r 
github.com/jbenet/go-context@(v0.0.0-20150711004518-d14ea06fba99) >> grafana.scm
guix import go -r github.com/imdario/mergo@(v0.3.12) >> grafana.scm
guix import go -r 

Re: My first package

[zimoun]

Hi Tobias,

Sorry for this late reply.

On Thu, 15 Sep 2022 at 09:35, Tobias Platen  wrote:

> I've created my first package for guix, the sekai speech synthesis
> toolkit which I use mainly for producing singing voice with lilypond.
> I'll also plan a talk at the gnu hackers meeting how I make Desktop
> Music using the Guix System. Two more packages will follow next.

Cool!  Thank you for your contribution.

For easing the merge, could you send to guix-patc...@gnu.org this patch
using git-format-patch with a commit message.  Well, please give a look
at the section « Submitting Patches » [1] from the manual. :-)


1: 


Two minor comment starting the review. :-)

>#:use-module (gnu packages textutils))
>  
> +

Here, you introduced an extra line.

> +(define-public sekai
> +  (package
> +(name "sekai")
> +(version "0.6.0")
> +(source (origin
> +  (method git-fetch)
> +  (uri (git-reference
> +(url "https://notabug.org/isengaara/sekai;)
> +(commit "0.6rc0")))
> +  (sha256
> +   (base32
> +"0j55pipx3hcp0xl4v0d72fdwysnz9a9a40x65a9lxpl4k6wyp4nm"   
>
> +(build-system cmake-build-system)
> +(arguments '(#:tests? #f))

The tests are disallowed.  Any specific reason?  If yes, the usual
practise is to add a one line comment.  For example,

   (arguments '(#:tests? #f)); no tests


> +(inputs `(("fftw" ,fftw)
> +  ("libsndfile",libsndfile)
> +   ("pkg-config",pkg-config)
> +   ("gsl",gsl)
> +   ("jsoncpp",jsoncpp)
> +   ("boost",boost)
> +   ("jack" ,jack-1)
> + ))

Now, you can use directly,

(inputs (list fftw
  libsndfile
  pkg-config
  gsl
  jsoncpp
  boost
  jack-1))

Cheers,
simon

Re: Packages grow, no longer fit on a 

[Akib Azmain Turja]

b...@bokr.com writes:

> On +2023-01-20 23:34:53 +0600, Akib Azmain Turja wrote:
>> Csepp  writes:
>> 
>> I have a slow machine from about 10 years ago, and I'm really happy with
>> it.  (I'm writing from this machine.)  I also have a slow unstable
>> internet connection, so I understand the pain of download hundreds of
>> MB of data without pause and resume support.  (I couldn't download the
>> latest Guix GNU/Hurd QEMU image (just around 293 MB maybe?) even trying
>> 8-10 times.)
>>
>
> Could you somehow use
> wget -c 
> to continue an interrupted download?
> Or does the source not support that?

Yes, the infamous https://ci.guix.gnu.org server.

>
> (see wget --help |less -- and scroll down to Download: section)
>
>> -- 
>> Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
>> Fediverse: akib@hostux.social
>> Codeberg: akib
>> emailselfdefense.fsf.org | "Nothing can be secure without encryption."
>
> --
> Regards,
> Bengt Richter

-- 
Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
Fediverse: akib@hostux.social
Codeberg: akib
emailselfdefense.fsf.org | "Nothing can be secure without encryption."


signature.asc
Description: PGP signature

[bug#59453] [PATCH core-updates] gnu: mesa: Fix library paths in Vulkan layer manifests.

[Kaelyn]

Hi Guix devs,

Now that it's been a couple of months, I wanted to bump my core-updates patch 
to Mesa which fixes the library paths in Mesa's Vulkan layer manifest files 
(https://issues.guix.gnu.org/59453). The patch also resolves 
https://issues.guix.gnu.org/58251.

Cheers,
Kaelyn

[RFC] refactoring extra-special-file; an /etc/tmpfiles/ equivalent

[Attila Lendvai]

hello Guix,

context 1:

i want to write a string into a file at boot to disable wake-up by my keyboard 
(so that it doesn't immediately wake up my laptop after i suspend it). it 
requires doing this once per boot:

echo XHC >/proc/acpi/wakeup

the standard solution on systemd distros is to use a 
/etc/tmpfiles.d/disable-usb-wake.conf file, which systemd interprets (see e.g. 
https://forums.linuxmint.com/viewtopic.php?f=42=312953).


context 2:

i need to create an empty directory in an image created by `guix system vm ...` 
(for "reasons"; this is the simplest way i'm aware of to hack forward).


in Guix we have extra-special-file (what a strange name!) that in fact can do 
one thing: a (single shot?) shepherd service that can symlink something 
somewhere.

what i need is something like extra-special-file, but with a few more keyword 
arguments that would allow creating empty directories, and 
appending/overwriting files with content given as literals.

or something else that i'm not aware of?


solution 1:

i think i could backwards compatibly extend extra-special-file with the keyword 
args.

solution 2:

introduce a new abstraction (preferrably with a better name), and mark 
extra-special-file obsolete.

dear maintainers, any thoughts on which way i should start digging?

also, any suggestion for the API? the naming of the keyword args?

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Angry people want you to see how powerful they are… loving people want you to 
see how powerful You are.”
— Chief Red Eagle

Re: Expensive builds when computing channel instance derivations

[Christopher Baines]

Ludovic Courtès  writes:

> Christopher Baines  skribis:
>
>> I think I figured out that it's related to grafts. I've attached a test
>> script which computes the channel instance derivation for mips64el-linux
>> which I'm not set up to build things for (if you can build for
>> mips64el-linux, replace this with a system you can't build for). You'll
>> need to use the attached patch (also present on [2]) when running this
>> script.
>>
>> 2: 
>> https://git.cbaines.net/guix/log/?h=channel-instances-manifest-graft-control
>>
>> When I run this script locally, it first succeeds in computing the
>> channel instance derivation when grafts are disabled, but then fails
>> when grafts are enabled:
>>
>>   while setting up the build environment: a `mips64el-linux' is required
>>   to build
>>   `/gnu/store/g40shyhsd00r5dq3mm76c2b1krnr1njh-guile-bootstrap-2.0.drv',
>>   but I am a `x86_64-linux'
>>
>> Even though I think this shows that grafts are involved, I'm not sure
>> what this means? I'm guessing that the effects of grafts aren't as clear
>> cut as for packages here, since the grafts are happening here as part of
>> computing a derivation I'm guessing that the derivation is actually
>> built with the grafted outputs, which differs from how grafts affect
>> packages. Given this, I guess computing the derivation without grafts
>> means that the replacements that would be grafted in are just not used
>> at all.
>>
>> To recap on my aim here, I really just want to be able to compute
>> channel instance derivations without performing any expensive builds, or
>> if that's not possible, it would be good to understand why?

For some reason I didn't follow up on this thread at the time, I can't
remember now it's been so long. This issue has remained at the back of
my mind though since within the Guix Data Service, I think it's becoming
more impactful.

> In general, computing the derivation of a package may incur
> builds/downloads due to the way grafts work: depending on the *build
> result* of a package, ‘package->derivation’ might return a grafting
> derivation or it might return the original derivation.
>
> The “Computing Guix derivation” bit of ‘guix pull’ is no exception: it
> computes the derivation of objects that depend on packages that may need
> to be grafted.  Thus, it ends up triggering builds as part of this
> process.

While that's a way of thinking about it to highlight the similarities,
it's the differences I'm interested in here.

For package derivations, I think about grafts as a layer on top. First
you build the packages normally, then you apply any grafts including
building any replacements as required. I don't know if that's an
entirely correct way of thinking about it, but it seems to work as a
mental model. For bordeaux.guix.gnu.org to provide substitues, it's
sufficient to build the packages (including replacements) without any
grafting, because that's a separate concern.

I don't think the same can be said for the channel instance derivations
though, probably because of the difference you highlight above regarding
grafts actually affecting how the derivations involved are constructed,
rather than acting as a layer on top.

> It would be tempting to turn off grafts in this case.  But then, ‘guix
> pull’ would always give us an ungrafted Guix, which is undesirable.  For
> the purposes of the Data Service though, you could consider turning off
> grafts globally.

I get that not applying grafts to guix could be undesirable, but I'm
still don't see why there aren't other options?

What would be the implications of treating it like package grafting. As
in, you'd always build guix without grafts, then you'd apply the
grafting process to the ungrafted output? That would be more consistent
with the way it works for packages, and it would probably go all or some
of the way to resolve the issues for the Guix Data Service.

There's maybe other options as well, although as I raised in my initial
email, it's hard for me to think about this since I haven't worked out
why the grafting here doesn't work like packages grafting for packages
in the first place.

Thanks,

Chris


signature.asc
Description: PGP signature

Re: Org 9.6: void org-element--cache-active-p on fresh

[zimoun]

Hi,

On Mon, 16 Jan 2023 at 20:43, zimoun  wrote:

>> --8<---cut here---start->8---
>> org-get-buffer-tags: Symbol's function definition is void: 
>> org-element--cache-active-p
>> --8<---cut here---end--->8---

>> Well, is it a bug on Guix side or is it a bug on Org-mode side?  Or from
>> my config?

Fixed upstream by 5d9c9c27c68f1af1159dfeb62352b2fa610b1d9f [1].

1: https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5d9c9c27c


Cheers,
simon

Re: FOSDEM’s coming!

[zimoun]

Hi,

I am late to the party.

On Thu, 19 Jan 2023 at 16:58, Ludovic Courtès  wrote:
> Hello Guix!
>
> I’ve prepared a blog post about FOSDEM and the Guix Days that we could
> publish tomorrow (Friday) or Monday:

Thanks for maintaining the communication up. :-)

>   
> https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/drafts/meet-guix-at-fosdem-2023.md

LGTM.  Except the Guix Days dates:

*Thursday Feb. 2nd and Friday Feb. 3rd**

> Please take a look and send patches if needed!  If someone can come up
> with some kind of a logo for the Guix Days, that’d be great; otherwise
> we’ll just reuse the one from last year.

A quick comment about:

Believe it or not, it’s the [9th year Guix is represented at
FOSDEM](https://guix.gnu.org/en/blog/tags/fosdem/)!  There are
several talks that will let you learn more about different areas
of the joyful Hydra Guix has become.

When submitting a proposal for a stand (that had been refused :-(), I
collected all the presentations – if I have not missed some; let me
know.

In this FOSDEM 2023 session, we have 10 talks about Guix, compared to
the 31 ones counted over the past years.  Is Guix becoming trendy?  ;-)

2014 [1]
2015 [2]
2016 [3-6]
2017 [7-14]
2018 [15]
2019 [16-19]
2020 [20-25]
2021 [26-29]
2022 [30-31]

1: https://archive.fosdem.org/2014/schedule/event/gnuguix/
2: https://archive.fosdem.org/2015/schedule/event/the_emacs_of_distros/
3: https://archive.fosdem.org/2016/schedule/event/guixhurd/
4: https://archive.fosdem.org/2016/schedule/event/guix/
5: https://archive.fosdem.org/2016/schedule/event/guixdistro/
6: https://archive.fosdem.org/2016/schedule/event/guixmodules/
7: https://archive.fosdem.org/2017/schedule/event/hpc_deployment_guix/
8: 
https://archive.fosdem.org/2017/schedule/event/composingsystemservicesinguixsd/
9: https://archive.fosdem.org/2017/schedule/event/futureofguix/
10: https://archive.fosdem.org/2017/schedule/event/guixintroduction/
11: https://archive.fosdem.org/2017/schedule/event/guixpackages/
12: https://archive.fosdem.org/2017/schedule/event/guixhurd/
13: https://archive.fosdem.org/2017/schedule/event/guixworkflowmanagement/
14: https://archive.fosdem.org/2017/schedule/event/guixsdbootstrap/
15: https://archive.fosdem.org/2018/schedule/event/guix_workflows/
16: 
https://archive.fosdem.org/2019/schedule/event/gnu_guix_new_approach_to_software_distribution/
17: https://archive.fosdem.org/2019/schedule/event/guixinfra/
18: https://archive.fosdem.org/2019/schedule/event/gnuguixminimalism/
19: https://archive.fosdem.org/2019/schedule/event/gnumes/
20: https://archive.fosdem.org/2020/schedule/event/guix/
21: https://archive.fosdem.org/2020/schedule/event/reprod_jupyter_guix/
22: https://archive.fosdem.org/2020/schedule/event/ggaaattyp/
23: https://archive.fosdem.org/2020/schedule/event/gnumes/
24: https://archive.fosdem.org/2020/schedule/event/gexpressionsguile/
25: https://archive.fosdem.org/2020/schedule/event/gnuguixpackagemanager/
26: https://archive.fosdem.org/2021/schedule/event/gnumes/
27: https://archive.fosdem.org/2021/schedule/event/declarativeminimalistic/
28: https://archive.fosdem.org/2021/schedule/event/gnuguix/
29: https://archive.fosdem.org/2021/schedule/event/minimalismguix/
30: https://archive.fosdem.org/2022/schedule/event/guixdeclare/
31: https://archive.fosdem.org/2022/schedule/event/gnuguixci/


Cheers,
simon

Re: Packages grow, no longer fit on a 

[bokr]

On +2023-01-20 23:34:53 +0600, Akib Azmain Turja wrote:
> Csepp  writes:
> 
> I have a slow machine from about 10 years ago, and I'm really happy with
> it.  (I'm writing from this machine.)  I also have a slow unstable
> internet connection, so I understand the pain of download hundreds of
> MB of data without pause and resume support.  (I couldn't download the
> latest Guix GNU/Hurd QEMU image (just around 293 MB maybe?) even trying
> 8-10 times.)
>

Could you somehow use
wget -c 
to continue an interrupted download?
Or does the source not support that?

(see wget --help |less -- and scroll down to Download: section)

> -- 
> Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
> Fediverse: akib@hostux.social
> Codeberg: akib
> emailselfdefense.fsf.org | "Nothing can be secure without encryption."

--
Regards,
Bengt Richter