Re: Jami bug source investigation #4

2020-06-20 Thread Jan Wielkiewicz
Nevermind, I resolved the issue.
Jami built from git repository instead of from tarball didn't fix the
bug with audio call.


Jan Wielkiewicz



Re: Policy to remove broken packages

2020-06-20 Thread Christopher Baines

zimoun  writes:

> Dear,
>
> After Guix Days 2019, the idea of having an informal policy to remove
> broken packages had emerged.  Quoting the initial Björn's message [1]:
>
> > If a package is broken for  more than 6 months, we should just
> > remove it from Guix. Prior  to removing, we should announce on
> > the  dev  mailing  list,  maybe someone  will  care  about  it
> > then. If there is no response within 2 weeks, we really remove
> > it.
>
> And we all agreed. :-)
>
> How to make it happen?  Where is the correct place to mark list them:
> Data Service or Cuirass?
>
>
> 1: https://lists.gnu.org/archive/html/guix-devel/2019-02/msg00019.html

Do you have any examples of packages that are currently broken, and
which you'd like to remove?

My general views on broken packages is that it would be helpful to have
more information at the time changes are being made, like big version
upgrades. That might allow less things to be broken, or work arounds to
be put in place before things are broken, rather than trying to find
someone to fix the package after 6 months.

Thanks,

Chris


signature.asc
Description: PGP signature


Re: generate commit messages for package updates

2020-06-20 Thread Alex Sassmannshausen
Hi Ricardo,

Just used your committer tool for the first time and it's bloody lovely.

Thank you for sharing it :-)

Alex

Ricardo Wurmus  writes:

> Hi Guix,
>
> I’m currently working on upgrading all Bioconductor packages to the 3.11
> release.  The hardest work here is to write commit messages for the 200+
> packages that have changed.  Even with the “update” yasnippet and magit
> this takes a very long time.
>
> I wrote a little tool to reduce the amount of time needed to create
> commits.  It is not fully automatic yet as it requires my input to stage
> hunks, but the commit messages it produces take all input changes into
> account, which is something the “update” yasnippet does not do.
>
> After “guix refresh -t bioconductor -u”, manually verifying and
> implementing the suggested changes, and building all packages, I run
> “git add -p” to stage hunks that belong to the same package definition.
> Then I run the attached tool to make a commit:
>
> ./committer.scm | git commit -F -
>
> The tool works by looking at the unified diff in the staging area and
> generating two S-expressions corresponding to the original package
> definition and the changed package definition, respectively.  It then
> looks at the inputs, propagated-inputs, and native-inputs fields and
> generates a GNU ChangeLog-style commit message describing the changes.
>
> Here’s an example diff:
>
> --8<---cut here---start->8---
> modified   gnu/packages/bioconductor.scm
> @@ -2701,29 +2701,32 @@ gene and isoform level using RNA-seq data")
>  (define-public r-karyoploter
>(package
>  (name "r-karyoploter")
> -(version "1.12.4")
> +(version "1.14.0")
>  (source (origin
>(method url-fetch)
>(uri (bioconductor-uri "karyoploteR" version))
>(sha256
> (base32
> -"03jmfgmw35hrgn3pc5lq6pblzhfx9fp4l6dx50rp303lr7kjxp9v"
> +"0h0gk4xd95k5phy6qcsv7j931d7gk3p24i2fg4mz5dsk110lpifs"
>  (build-system r-build-system)
>  (propagated-inputs
> - `(("r-regioner" ,r-regioner)
> + `(("r-annotationdbi" ,r-annotationdbi)
> +   ("r-bamsignals" ,r-bamsignals)
> +   ("r-bezier" ,r-bezier)
> +   ("r-biovizbase" ,r-biovizbase)
> +   ("r-digest" ,r-digest)
> +   ("r-genomeinfodb" ,r-genomeinfodb)
> +   ("r-genomicfeatures" ,r-genomicfeatures)
> ("r-genomicranges" ,r-genomicranges)
> ("r-iranges" ,r-iranges)
> -   ("r-rsamtools" ,r-rsamtools)
> ("r-memoise" ,r-memoise)
> +   ("r-regioner" ,r-regioner)
> +   ("r-rsamtools" ,r-rsamtools)
> ("r-rtracklayer" ,r-rtracklayer)
> -   ("r-genomeinfodb" ,r-genomeinfodb)
> ("r-s4vectors" ,r-s4vectors)
> -   ("r-biovizbase" ,r-biovizbase)
> -   ("r-digest" ,r-digest)
> -   ("r-bezier" ,r-bezier)
> -   ("r-bamsignals" ,r-bamsignals)
> -   ("r-annotationdbi" ,r-annotationdbi)
> ("r-variantannotation" ,r-variantannotation)))
> +(native-inputs
> + `(("r-knitr" ,r-knitr)))
>  (home-page "https://bioconductor.org/packages/karyoploteR/";)
>  (synopsis "Plot customizable linear genomes displaying arbitrary data")
>  (description "This package creates karyotype plots of arbitrary genomes 
> and
> --8<---cut here---end--->8---
>
> …and this is the generated commit message:
>
> --8<---cut here---start->8---
> gnu: r-karyoploter: Update to 1.14.0.
>
> * gnu/packages/bioconductor.scm (r-karyoploter): Update to 1.14.0.
> [propagated-inputs]: Add r-genomicfeatures.
> [native-inputs]: Add r-knitr.
> --8<---cut here---end--->8---
>
> Obviously, this can be improved by avoiding the staging area and
> operating on all hunks in all selected files, so that more than one
> commit can be made at a time.  But I thought I’d share this hack anyway,
> crude as it is.