On Wed, May 20, 2020 at 01:28:13PM +0200, Marius Bakke wrote:
> The print infrastructure (CUPS, ghostscript) does not use Pango, so I
> think gs-fonts still work there.
>
> Might be difficult to work with when the end user applications don't
> recognize them though.
>
> What do you expect from a
On Sun, May 17, 2020 at 04:50:12PM +0200, Marius Bakke wrote:
> This is a hack to make (some) fonts working when users don't have fonts
> specified in their system configuration, and (crucially) places where
> the fontconfig cache may be unavailable such as 'guix pack's.
>
> I'm not sure whether
On Wed, May 13, 2020 at 03:08:26AM +0200, zimoun wrote:
> Based on these 2 messages [1,2], what is the consensus between
> git-fetch and url-fetch?
Do we need a consensus? Sometimes it's enough for the reviewer to 1)
bite their tongue or 2) fix before pushing. Often it's a matter of taste
and it
On Mon, May 11, 2020 at 09:50:57PM +0200, Pierre Neidhardt wrote:
> I'm planning to work on a probably-GTK graphical installer as part of
> the NLNet grant I've received in the coming month. Let's keep in touch!
Congratulations!
signature.asc
Description: PGP signature
On Wed, May 06, 2020 at 06:27:31PM +0200, Vincent Legoll wrote:
> I grabbed a gnubee during the crowdfunding campaign, but the CPU
> is too low spec to do a lot of compilation on it.
I'm not an expert on MIPS but I *think* the GnuBee uses a different
architecture than what Guix was ported to.
On Wed, May 06, 2020 at 06:27:31PM +0200, Vincent Legoll wrote:
> From the manual or from the CI, to let the build farm do more useful things
> I'm not against, but is it really making maintenance difficult by still being
> in
> the codebase ?
It's not really a maintenance burden currently since
On Mon, May 04, 2020 at 09:31:46AM -0400, Maxim Cournoyer wrote:
> There's a new blog post about a recent update to the GNU Guix maintainer
> collective [0]. I won't repeat the blog post here, but in a few words,
> Ricardo Wurmus is stepping down from his role and Mathieu Othacehe
> is joining
On Tue, Apr 28, 2020 at 03:17:06PM +0200, Marius Bakke wrote:
> Leo Famulari writes:
>
> > I reconfigured my Guix System based on core-updates, and afterwards I
> > was unable to login, either remotely over SSH, or on the Linux console.
>
> Do you still have the logs fro
On Sun, Apr 26, 2020 at 08:05:34PM +0300, Efraim Flashner wrote:
> I squashed all the cargo commits together and pushed them. I didn't push
> the one with adding rav1e to ffmpeg, I wasn't sure how much that would
> add to 'guix size'.
It's okay to delete the wip-rav1e branch now, right?
On Sun, Apr 26, 2020 at 08:05:34PM +0300, Efraim Flashner wrote:
> I squashed all the cargo commits together and pushed them. I didn't push
> the one with adding rav1e to ffmpeg, I wasn't sure how much that would
> add to 'guix size'.
Amazing, thank you!!!
I intended the FFmpeg commit as a
I reconfigured my Guix System based on core-updates, and afterwards I
was unable to login, either remotely over SSH, or on the Linux console.
After cutting the power to the computer and turning it back on, I was
able to log in.
I've attached my configuration file for your reference.
;; This is
I'm doing `guix pull --branch=core-updates`, with a `guix describe` of
commit a533c5a183 (core-updates from 2 weeks ago), on Debian, in tmux,
and I see this weird thing:
--
substitute: updating substitutes from 'https://private.mirror'... 100.0%
@ substituter-started
On Fri, Apr 24, 2020 at 01:24:23AM +0200, Marius Bakke wrote:
Testing now!
First feedback, this warning is new IIRC, based on commit 69c2e01:
Computing Guix derivation for 'x86_64-linux'... WARNING: (guix build
emacs-build-system): imported module (guix build utils) overrides core binding
On Thu, Apr 23, 2020 at 11:40:19AM +0200, Ludovic Courtès wrote:
> Hello,
>
> guix-comm...@gnu.org skribis:
>
> > commit 5483a2d0a913fe533744699e9ef5757c6e3f6983
> > Author: Raghav Gururajan
> > AuthorDate: Wed Apr 22 15:07:01 2020 -0400
> >
> > gnu: font-gnu-freefont: Add otf and woff font
On Tue, Apr 21, 2020 at 10:50:09PM +0200, Pierre Neidhardt wrote:
> Makes sense, thank you for the details.
>
> What about adding the above example to the manual page of `guix environment'??
Take a look at the existing docs on X.509 Certificates and see if we can
improve them or the
On Tue, Apr 21, 2020 at 08:59:31PM +0200, Mathieu Othacehe wrote:
> On my computer, this takes 6m50 versus 2h30 for the master version. I
> tested the image in QEMU, everything seems fine.
Wow! Why did it take 2h30? Do you have KVM?
On Tue, Apr 21, 2020 at 06:17:58PM +0200, Pierre Neidhardt wrote:
> Note that the "--expose=/etc/ssl/certs/" is important.
>
> Should we consider this a bug? If not, then should we document
> it?
No, it's not a bug.
TLS X.509 certificates need to be looked up dynamically at run-time,
because
On Wed, Apr 08, 2020 at 08:32:00PM +0100, Christopher Baines wrote:
> I was wondering about MIPS support, mainly because the Guix Data Service
> uses QEMU to emulate different systems so that the channel instance
> derivations can be computed (like [1]). I'm not sure if the emulation is
> really
On Wed, Apr 08, 2020 at 01:52:14AM +0200, Jan wrote:
> If it succeeds, I will need a way to copy contents of the store on my
> powerful machine to my potato machine. Is "guix copy" the tool I can
> use?
Yup! You'll need to authorize the building machine's key on the potato.
On Sat, Apr 04, 2020 at 05:52:37PM +0200, Julien Lepiller wrote:
> Before I send a patch series (~200 patches if i count well),
It will be more convenient for reviewers if you pushed a
wip-maven-build-system branch to Savannah.
On Fri, Feb 21, 2020 at 04:15:43AM -0500, Martin Becze wrote:
> sort2.scm will sort a files exported packages alphanumerically.
I'm working on packaging rav1e for Guix again and so I'm using sort2.scm
on the big 'gnu/packages/crates-io.scm' module.
One problem I noticed with sort2.scm is that
On Thu, Apr 02, 2020 at 07:43:13PM +0200, Tobias Geerinckx-Rice wrote:
> Tobias Geerinckx-Rice 写道：
> > > If you do `git show --format=full` on these commits, it shows who
> > > actually committed them to the repo.
> >
> > Are you sure this isn't trivially spoofable?
> >
> > Not that it would be
On Thu, Apr 02, 2020 at 10:03:27AM -0700, John Soo wrote:
> Hi Guix!
>
> I think I am reported as the author of commits
>
> 0cc8cdbe1b0018ec37b1de9032c9eca884bedb6e
> a97b943b5590c6406a85cb0f2f03fa69d7e3b7d8
> c26fd5648c2a24dbd71f4c0851f8b5eced75e0f1
If you do `git show --format=full` on these
As reported on help-debbugs and the #guix IRC channel, the mailing lists
and debbugs are currently not working. I'm not sure if this message will
go through.
It seems to manifest as silent failure of mail delivery, and debbugs not
responding to commands.
There are a couple messages here about
On Thu, Mar 26, 2020 at 08:06:44PM +0100, Marius Bakke wrote:
> Vincent Legoll writes:
> > For the tests they will be native-inputs, so only increase dependencies
> > for building, is that a problem ? I would have thought that test coverage
> > is more important (especially on such important
On Sat, Mar 21, 2020 at 03:43:32PM -0400, Leo Famulari wrote:
> I poked around a bit. Debian achieves the smaller size by referring to
> data rather than copying it around, and only including delta changes.
> Hopefully we can copy their technique.
We are discussing it on #guix
On Sat, Mar 21, 2020 at 04:37:05PM +0100, Ludovic Courtès wrote:
> Thoughts? How do other distros deal with this? Are we missing some
> trick to compress locale data?
I noticed that downloading glibc-locales, it's 10.8 MiB. On disk, the
store item is ~220 MiB. I'm not sure how guix size
On Thu, Mar 19, 2020 at 05:29:37PM +, Carl Dong wrote:
> I'm wondering where best to start with this. Perhaps it'd be informative to
> know
> how regular releases are done and see what's missing there (and perhaps what
> needs automation)?
Check the release target in our Makefile. I remember
On Wed, Mar 18, 2020 at 04:07:22PM +0100, Ludovic Courtès wrote:
> As for ‘glibc-utf8-locales’ vs. ‘glibc-locales’: the reason for choosing
> the former by default over the latter is size (14 MiB vs. 917 MiB).
Oof! I was going by the manual, which says 110 MiB. That does change
things...
Warning! Locales! New users seem to have trouble with Guix locales every
day.
I think we can improve the situation.
First, we can deprecate the glibc-utf8-locales package and not mention
it in the manual section Application Setup. I've seen users think they
had to install it in order to get
On Sun, Mar 15, 2020 at 12:22:08PM +0100, leven...@mmer.org wrote:
> Was this patch merged? I haven't found it in guix-patches and commits
> =(. I came across the same problem today by just doing guix pull. In
> addition, a package (texlive-hyph-utf8) uses svn:// scheme which I am
> not sure does
On Tue, Feb 18, 2020 at 03:58:19PM +0100, Pierre Neidhardt wrote:
> Some packages are frequently without substitutes, like Racket and MAME.
> Link between the two? They both take a long time to build. So I wonder
> if this is not because the build somehow timeouts.
The logs of the failing
On Sat, Feb 29, 2020 at 09:41:17PM +0100, Bengt Richter wrote:
> IMO auto-update is like buying an appliance and giving
> the install crew a permanent key to the kitchen door.
I don't think this metaphor is wrong, but it's not very exact. Short of
auditing every single line of code in a package,
On Sat, Feb 29, 2020 at 04:26:57PM +0100, Vincent Legoll wrote:
> The attached (crude, WIP, RFC) patch allowed to find the following
> packages that have unecoded space characters in their URIs:
Can you explain a little more about these characters and why we want to
avoid them?
On Sat, Feb 29, 2020 at 11:37:19AM +0100, Vincent Legoll wrote:
> https://ci.guix.gnu.org
> https://tarballs.nixos.org
> https://archive.softwareheritage.org
[...]
> but when reading guix/download.scm, I don't find those urls listed for
> the gnome mirror, what I am missing ?
These URLs
On Fri, Feb 28, 2020 at 10:14:19PM +0530, Arun Isaac wrote:
> I agree that auto updaters should be disabled where applicable. But,
> ideally, like you said, this should be implemented upstream as a
> configuration option we can set at build time.
I also agree we should make an effort to disable
I'm wondering if I can just push the crates as a single commit, after
inserting them alphabetically and fixing any cosmetic issues, and also
handling the semver-compatible package updates.
I know that we don't usually do this when adding packages to an existing
module. We do add packages en masse
On Wed, Feb 26, 2020 at 09:09:05AM +0200, Efraim Flashner wrote:
> Short of resorting them I'd start with ones that have no dependencies,
> just rely on rust-quote & friends or are older versions. Some packages,
> like rust-futures-*, should be updated as a group since they all expect
> to be the
On Tue, Feb 25, 2020 at 01:21:18PM -0800, John Soo wrote:
> You should be committing packages in topological order but the file
> order is alphabetical.
>
> Good luck, rust is a ton of work.
Okay, that makes sense.
I tried to use `guix graph` to learn the shape of the package graph but
it
On Fri, Feb 21, 2020 at 04:15:43AM -0500, Martin Becze wrote:
> On 2/20/20 5:43 PM, Leo Famulari wrote:
> > And if so, should it
> > be done as a single commit? Or one-by-one?
>
> One-by-one unfortunately
I've been working on this and I've committed about 3000 lines of t
00:00:00 2001
From: Leo Famulari
Date: Sat, 22 Feb 2020 16:48:51 -0500
Subject: [PATCH] gnu: rust-wasm-bindgen-macro-0.2: Upgrade to 0.2.58
* gnu/packages/gnu/packages/crates-io.scm (rust-wasm-bindgen-macro-0.2):
Upgrade to 0.2.58
---
gnu/packages/crates-io.scm | 113 +++---
On Fri, Feb 21, 2020 at 04:15:43AM -0500, Martin Becze wrote:
> 2) Sort the packages, `guile -s ./sort2.scm mypackage.scm > mypackage.scm`
> (you will probably also want to sort crates-io.scm, i think some packages
> may be out-of-order now)
I sorted rav1e.scm and crates-io.scm, no problem...
>
On Fri, Feb 21, 2020 at 04:15:43AM -0500, Martin Becze wrote:
> I have a small tool I have been working will make the new packages easier to
> commit its very much WIP but if I would appreciate any feedback.
> Attached is sort2.scm and merge.scm
Awesome, thanks. I will give it a try!
I've pushed a branch wip-rav1e to Savannah:
https://git.savannah.gnu.org/cgit/guix.git/log/?h=wip-rav1e
With this branch I can successfully (slowly!) encode AV1 video using
librav1e in FFmpeg.
I need some advice about the Rust packages. I used Martin Becze's
recursive version-aware Rust crate
On Fri, Feb 14, 2020 at 12:08:08PM -0500, Jack Hill wrote:
> Leo and Guix,
>
> I noticed that you recently updated syncthing and many of its dependencies.
> Did you do this by hand? I'm wondering if it would make things easier if we
> had a recursive importer.
Yes, I did it by hand. I look at
On Wed, Feb 05, 2020 at 04:59:01PM +0100, Ellen Papsch wrote:
> The first is the rather unflexible Makefile based build system. It
> would require some patching on Guix side. For example, the install
> phase installs into a hard coded prefix (/usr). I played with the
> thought of adding a meson
On Thu, Nov 28, 2019 at 11:57:19AM +0100, Jonathan Brielmaier wrote:
> I own now a RaptorCS Blackbird[0] with an 8 core CPU and 32GiB RAM for
> half a year. I use it as my daily desktop driver. It runs openSUSE
> Tumblweed[1].
>
> Setup was quite easy if you only want to use it as server without
On Wed, Nov 13, 2019 at 11:16:53AM -0500, Mark H Weaver wrote:
> For these reasons, I'm inclined to think that parallel downloads is the
> wrong approach. If a single download process is not making efficient
> use of the available bandwidth, I'd be more inclined to look carefully
> at why it's
On Sat, Nov 09, 2019 at 06:40:56PM +0100, Ludovic Courtès wrote:
> Like I wrote, it’s not that simple (we’d first need the daemon to
> distinguish substitution jobs from other jobs, but note that there are
> also “downloads” that are actually derivation builds), and it’s not
> clear to me that
On Tue, Nov 05, 2019 at 06:38:05PM -0500, Kei Kebreau wrote:
> > - The patch for libdazzle only changes the xorg-server, as it already
> >is at version 3.33.90 in master. It still makes sense as a patch,
> >but the title indicates a version downgrade.
> >
>
> Good catch! I'd correct
On Tue, Oct 22, 2019 at 03:20:54PM +0200, Ludovic Courtès wrote:
> Please share what you’d like to see or to write about as a Guix user!
I'd like to see a section on real-time audio and JACK or related sound
server. It would be great to show how Guix can be used to make a
reproducible audio /
On Wed, Aug 14, 2019 at 03:06:17PM -0400, Leo Famulari wrote:
> I'll push a Git branch 'go-consolidation' on Savannah soon and will push
> it to master soon-ish, pending your comments.
Here it is:
https://git.savannah.gnu.org/cgit/guix.git/log/?h=wip-go-consolidation
It includes a minor
On Thu, Aug 15, 2019 at 11:19:06AM +0300, Efraim Flashner wrote:
> So to summarize, while it is techincally possible to "build" them, in
> actuality they are used in source code form as part of the build
> process.
That's true for Guix but not if you were building Go software outside of
Guix. In
We can improve the organization of some of our Go language packages in a
way that will make it easier to use and maintain them, and will also
more closely match the way they are developed and used upstream.
For example, take go-golang-org-x-crypto-pbkdf2 and
go-golang-org-x-crypto-salsa20. These
On Wed, Jul 03, 2019 at 02:13:12PM -0400, Leo Famulari wrote:
> An update on this:
>
> The initial plan is to add the Guix signing key to the new
> abuse-resistant keyserver at . Once that has been done
> we can update the manual and HACKING to point at this.
Thi
On Tue, Jul 02, 2019 at 11:54:17AM -0400, Leo Famulari wrote:
> This is also being discussed privately with the Guix maintainers. I
> expect to push an update for the manual and HACKING today.
An update on this:
The initial plan is to add the Guix signing key to the new
abuse-resistant key
On Sun, Jun 30, 2019 at 11:44:04AM +0200, Giovanni Biscuolo wrote:
> This means we should quckly patch Guix manual: I've no time to propose a
> patch today, I'll work on this tomorrow
>
> We also nees to address this for **all** guix contributors: we require a
> GPG signed commit, so each and
On Tue, Jun 18, 2019 at 03:19:41PM +0200, Ludovic Courtès wrote:
> Many thanks to everyone who helped maintain this service over the years,
> and in particular to Mark H Weaver for all the energy put into making it
> run as smoothly as possible!
Indeed, Mark worked tirelessly behind the scenes
On Wed, Apr 24, 2019 at 06:01:49AM +0200, Dexter Morgan wrote:
> My friend introduced me to GNU/Linux and installed GuixSD on my laptop. I am
> just getting started on Bash. I find that there is absence of VPN clients as
> an
> alternative to OpenVPN. Can some one please package the following
On Thu, Apr 25, 2019 at 06:44:07PM +0200, Ludovic Courtès wrote:
> The attached config file can be used to produce a 2.9G QCOW image
> (uncompressed) that internally appears to have a 20G file system:
A little big but I don't think we can shrink it any more unfortunately.
> What do people think?
On Wed, Apr 17, 2019 at 02:28:13PM +0200, Ludovic Courtès wrote:
> Merging ‘core-updates’ is no longer an option for 1.0: I’m seriously
> still aiming for around April 30th. Let’s get our act together!
>
> Likewise, I don’t think the OpenSSL upgrade can be merged on time. But
> that’s OK: we
On Thu, Apr 04, 2019 at 04:56:51PM +0200, Ludovic Courtès wrote:
> I had criticism about the VM image:
[...]
> Thoughts?
Originally I added the VM image to address a specific use case at one VM
hoster. I had hoped it would catch on more than it did and that the VM
image would be improved to avoid
On Tue, Nov 06, 2018 at 07:43:21PM +0100, swedebugia wrote:
> I stumpled on this hard-wrapping default behavior when editing .bash_profile
> on GuixSD
This issue should be fixed with commit
cdfb69b46abbdaa2ac0a80b5f92172cd1290a782, which upgrades our nano
package to nano 4.0.
This release
On Fri, Mar 15, 2019 at 09:40:15PM -0500, Katherine Cox-Buday wrote:
> There is a larger change coming that I think we need to account for. Go
> modules are here (and in v1.13 will be on by default). This feature
> allows Go code to be built outside of a $GOPATH. I'm unsure how this
> information
On Thu, Mar 14, 2019 at 11:51:06PM +0100, Pierre Neidhardt wrote:
> Agreed! This should also make the Go importer more trivial to write/finish!
Okay, I'll try it.
The only part I'm not sure about is what to "build" or "test" for these
library collections. Currently many of them run test suites,
On Thu, Mar 14, 2019 at 11:54:30PM +0100, Pierre Neidhardt wrote:
> Erratum: You've packaged go-github-com-kr-text a second time :p
Oops! Fixed in 10b30b97735ba9037f4ce58867f47678d78f4970
> This has happened to me once. I think we should have a linter to protect
> against this. Thoughts?
I
On Thu, Mar 14, 2019 at 02:31:36PM -0400, mikadoZero wrote:
> # Proposed idea
>
> * Add a "programs" field to package definitions that list the programs
> that are included in a package.
> * Include this field in search results.
> * Have this field factor into the search result relevance
On Sun, Mar 10, 2019 at 08:47:59PM -0700, Chris Marusich wrote:
> In addition, CloudFront reports that traffic came from the following
> locations (sorted by bytes transferred):
>
> Location Request Count Request % Bytes
>
I just pushed a revamped Go build system with commit
e3900a4d64e4bf6f426809d6bff058e5a2ae9bc8.
The main change is that instead of putting the list of Go-language
dependencies store paths in the GOPATH environment variable, these store
paths are union-symlinked into the build directory, and GOPATH
On Wed, Mar 13, 2019 at 11:44:20AM -0400, mikadoZero wrote:
> system.scm line 537:
>
> net-tools ; XXX: remove when Inetutils suffices
>
> git log -L 537,537:system.scm outputs:
>
> commit 6f436c54d6d9698e62639de31a845cd9b9167423
> Date: Wed Jun 4 2014
>
> This comment was committed in
On Sun, Mar 10, 2019 at 12:13:55PM -0400, mikadoZero wrote:
> I think the confusion around the pronunciation of GIF would probably be
> a worst case scenario.
Non-techies rarely discuss JPEGs or PNGs, while GIFs are a cultural
phenomenon.
How to pronounce 'GIF'? Anyone can weigh in, and it
On Mon, Mar 11, 2019 at 08:31:40PM -0400, mikadoZero wrote:
> Reading the recent press release linked it is clear that Express Logic
> is continuing to invest more in their Guix trademarked product over
> time. As a result of this it is increasing likely that Express Logic
> could request that
On Sun, Mar 10, 2019 at 12:13:55PM -0400, mikadoZero wrote:
> I think the confusion around the pronunciation of GIF would probably be
> a worst case scenario.
Non-techies rarely discuss JPEGs or PNGs, while 'GIF' is a cultural
phenomenon.
How to pronounce GIF? Everyone has an opinion on this and
On Wed, Mar 06, 2019 at 09:04:17PM +0100, swedebugia wrote:
> 1. sqlite3 needs to be compiled with SQLITE_ENABLE_FTS3 (this results in
> a lot of builds, patch attached)
Check our Git history for previous work related to SQLITE_ENABLE_FTS3.
Maybe we should bring back that special package or maybe
On Wed, Mar 06, 2019 at 02:24:32PM +0100, Ludovic Courtès wrote:
> The checkout made by ‘wireguard-source’ is read-only. I suppose
> ‘jury-rig.sh’ somehow copies files from there, preserving read-only
> permissions and eventually leading to that “Permission denied”.
>
> Does that make sense?
On Sun, Mar 03, 2019 at 11:06:32AM -0500, Mark H Weaver wrote:
> I don't know about berlin, but hydra.gnu.org has *never* successfully
> built ungoogled-chromium. So far, it has made 3 attempts on
> x86_64-linux and 5 attempts on i686-linux:
[...]
> If the same is true on berlin.guixsd.org,
On Wed, Feb 27, 2019 at 02:18:57AM +0800, Alex Vong wrote:
> Leo Famulari writes:
>
> > On Tue, Feb 19, 2019 at 10:31:03PM +0100, Andreas Enge wrote:
> >> the package builds, but I see no need to keep it. Do you agree to remove
> >> it together with mozjs@17? The
On Sat, Feb 23, 2019 at 09:03:10PM -0500, guix-comm...@gnu.org wrote:
> iyzsong pushed a commit to branch master
> in repository guix.
>
> commit 590b989c95f5b72dfe4b9928d1426fb7d35d1428
> Author: Pkill -9
> Date: Sat Feb 23 10:12:32 2019 +
>
> gnu: font-awesome: Update to 5.7.2.
>
On Mon, Feb 25, 2019 at 09:31:48PM +0100, Ricardo Wurmus wrote:
> swedebugia writes:
> > If this is not explained in the manual could you send a patch to include
> > this?
>
> The service file already includes an “Environment” line.
Also, this 'Environment=' parameter is a feature of systemd
' to generate and apply the
patch at build-time so I will try that next.
[0]
https://git.zx2c4.com/WireGuard/tree/contrib/kernel-tree
[1] See the attached module
;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2019 Leo Famulari
;;;
;;; This file is NOT part of GNU Guix
On Tue, Feb 19, 2019 at 10:31:03PM +0100, Andreas Enge wrote:
> the package builds, but I see no need to keep it. Do you agree to remove
> it together with mozjs@17? The latter would require a little work, since
> all other mozjs packages inherit from it. If there is consensus, I can
> look into
On Wed, Feb 13, 2019 at 01:10:26PM -0500, Leo Famulari wrote:
> Can burp use the new version? If so I'll add it while keeping the old
> librsync for those other packages.
Okay, I grepped the burp source code and answered my own question: Yes,
it is aware of the new librsync. So I wil
On Wed, Feb 13, 2019 at 09:23:21AM -0500, guix-comm...@gnu.org wrote:
> commit 7b9b203a52fd31558d0d5c424da0dfb5f7dceef6
> Author: Ricardo Wurmus
> Date: Wed Feb 13 15:22:59 2019 +0100
>
> gnu: Add burp.
>
> * gnu/packages/backup.scm (burp): New variable.
[...]
> +(inputs
> +
There are lots of very old "unclassified" bugs in our bug tracker. There
are also some patches in guix-patches that are pretty old.
I'm spending some time closing the ones that seem hopelessly stale or
unactionable.
It would be helpful if everyone could search for the bugs they've
submitted that
On Mon, Feb 11, 2019 at 10:00:20PM +0100, Björn Höfling wrote:
> What I haven't found out is how/if you can use multiple subkeys for
> savannah.gnu.org. Does anyone know about that?
I use GPG subkeys and I use them for Guix.
Regarding Savannah, I think that the only thing required is to upload
On Mon, Feb 04, 2019 at 07:06:35PM +0100, Andreas Enge wrote:
> On Mon, Feb 04, 2019 at 12:16:12PM +0100, Björn Höfling wrote:
> > 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
On Tue, Jan 22, 2019 at 11:36:40AM +0100, Pierre Neidhardt wrote:
> I've noticed that `git clone ` fails if openssh is
> not in the user profile.
> Should we add openssh as an input to Git?
I guess that programs like Git and rsync (another SSH user that doesn't
depend on it explicitly) can use
On Tue, Jan 22, 2019 at 12:36:06PM +0100, Pjotr Prins wrote:
> > I have a mini-displayport to hdmi adapter that I'm bringing if anyone
> > needs. I also have a DVI->VGA adapter which I don't expect to be useful.
> > I'm not sure if VGA->HDMI exists so much, searching online they're
> > always
On Mon, Jan 14, 2019 at 09:49:14PM -0800, Sebastian wrote:
> Hello, Developer.
> I was intreged by the OS and decided to try it.
> I noticed that the GPG sig was bad and thought I should let you know.
> (or perhaps I did something wrong, let me know.)
Thanks for reaching out!
> seb@seb-pc
On Mon, Jan 07, 2019 at 05:48:39PM +0100, L p R n d n wrote:
> - Currently, I think the only way for a GuixSD installation to break is
> if something goes wrong with the bootloader. Might be nice to have a
> tool (in the install image I suppose) to recover the bootloader.
> Maybe 'guix
On Wed, Jan 09, 2019 at 09:52:53AM -0500, Joshua Branson wrote:
> Perhaps I would put it right after GNU Distribution > System
> Configuration. Perhaps I would call that section "Hardening
> Recommendations". Some of the things that I want to include are strong
> passwords, encrypted drives,
On Wed, Jan 09, 2019 at 07:14:38PM +0100, Pierre Neidhardt wrote:
> Jami is made of 3 packages and might drag in 2-3 packages that
> so far are not used by any other package.
>
> General question: where should those packages go?
>
> - ring.scm
If there is no longer a 'Ring' project, then let's
On Thu, Jan 03, 2019 at 09:12:35PM +0800, Alex Vong wrote:
> Btw, for security fixes, how long should I wait before I ping here?
If you are confident in the fix, it's fine to go ahead and commit if
there is no review. Otherwise, a day or two is probably fine. If the
vulnerability is particularly
On Wed, Dec 26, 2018 at 01:30:53PM +0100, Marius Bakke wrote:
> Efraim Flashner writes:
> > We're now about a year out from the official EOL for python2 (Jan 1,
> > 2020). So far we've been not adding python2 variants of packages that
> > are new unless they're actually needed for something. Do
On Wed, Dec 26, 2018 at 02:33:55PM +0100, Pjotr Prins wrote:
> A lot of software outside Guix still depends on Python2, for better or
> worse. I don't believe EOL means they are going to drop security
> updates. Leaf packages may well be in use today.
I do think it means that the current Python
On Wed, Dec 26, 2018 at 11:38:12AM +0200, Efraim Flashner wrote:
> We're now about a year out from the official EOL for python2 (Jan 1,
> 2020). So far we've been not adding python2 variants of packages that
> are new unless they're actually needed for something. Do we want to
> start removing
On Sat, Dec 15, 2018 at 07:19:49PM +0100, Pierre Neidhardt wrote:
>
> > So hmm, you’re right! I’m sure I saw go packages somewhere, dunno…
>
> Just looked at the source: after my Go 1.11 update, Syncthing was updated to
> use
> vendored dependencies, just like go-ipfs. This is why it does not
On Sat, Dec 15, 2018 at 07:19:49PM +0100, Pierre Neidhardt wrote:
>
> > So hmm, you’re right! I’m sure I saw go packages somewhere, dunno…
>
> Just looked at the source: after my Go 1.11 update, Syncthing was updated to
> use
> vendored dependencies, just like go-ipfs. This is why it does not
On Wed, Dec 12, 2018 at 09:17:23AM +0100, Giovanni Biscuolo wrote:
> > I’m in favour of moving them elsewhere, such as %desktop-services.
>
> yes please: sound related services are not-so-base, we do not need them
> on installation/web/mail/DNS et. al servers (and containers) and it does
> not
On Wed, Nov 28, 2018 at 03:50:14PM +0100, Ludovic Courtès wrote:
> Longer-term I think we should all push to a dedicated branch and have
> server-side automation apply to ‘master’ patches that pass a few tests
> (commit signed by an authorized key, ‘guix lint’, things like that.)
Some Ubuntu
401 - 500 of 3568 matches
Mail list logo
