FYI this landed in my Gmail spam folder. Maybe because of the
all-caps. :-)
Taylan
Andreas Enge writes:
> On Thu, Mar 10, 2016 at 08:24:44AM +1100, Jookia wrote:
>> As much as that's appealing, this breaks GNU conventions. I think it'd be
>> nice
>> to put the state in the store directory by default since it seems the two are
>> related, though this might not be the case in o
DISCLMAIMER: This commit isn't meant for merging, so donut merge it.
It's meant for people to use until we get something better. There's
also code I haven't fully checked is needed (particularly mknodes)
so there's duplicates. Use this at the risk of having to ask me
to fix it and possibly have me
DISCLMAIMER: This commit isn't meant for merging, so donut merge it.
It's meant for people to use until we get something better. There's
also code I haven't fully checked is needed (particularly mknodes)
so there's duplicates. Use this at the risk of having to ask me
to fix it and possibly have me
Nils Gillmann writes:
> I removed gplv3+ as addressed by ludo' and rekado,
> corrected the url in "website" (added missing ".net").
>
> Here's the new patch, rebased against current master.
Thanks!
>
> From f59e5027d4fb9559e179fb4693617820f6680223 Mon Sep 17 00:00:00 2001
> From: Nils Gillmann
>
iyzs...@member.fsf.org (宋文武) skribis:
> l...@gnu.org (Ludovic Courtès) writes:
>
>> Pulseaudio also propagates a few things.
> Yes, I think it should be splited into “out” and “dev”, if we can make
> only the “dev” output propagating libcap and gdbm.
Yeah.
>> Two things here:
>>
>> • Back in t
On Wed, Mar 09, 2016 at 10:37:43PM +0100, Danny Milosavljevic wrote:
> Hi,
Hi there, this is an old patch set so if you intend on using it you should use
my newer RFC posted earlier this month. :)
> just adding a few bits of information:
>
> It's true that libreboot can (and does) source other g
On Thu, Mar 10, 2016 at 08:24:44AM +1100, Jookia wrote:
> As much as that's appealing, this breaks GNU conventions. I think it'd be nice
> to put the state in the store directory by default since it seems the two are
> related, though this might not be the case in other situations.
This would also
Hi,
just adding a few bits of information:
It's true that libreboot can (and does) source other grub config files. GRUB
should also be able to chainload other bootloaders, however I tried that
several times now and it just doesn't work. Is this a known limitation?
insmod ahci
insmod ext2
insmo
On Wed, Mar 09, 2016 at 10:07:03PM +0100, Andreas Enge wrote:
> I still think we should make /var the default of localstatedir; this would
> avoid most problems.
>
> Andreas, doing his Cicero
As much as that's appealing, this breaks GNU conventions. I think it'd be nice
to put the state in the st
Hi,
In reference to ponderings on #guix, find minor doc patch attached.
Greetings,
Jan
>From fc6dd2108dae76e09e1bfcd6d04c36943469434f Mon Sep 17 00:00:00 2001
From: Jan Nieuwenhuizen
Date: Wed, 9 Mar 2016 22:18:48 +0100
Subject: [PATCH] Suggest `guix.scm' for upstream maintainers.
* doc/guix.t
On Thu, Mar 10, 2016 at 07:35:53AM +1100, Jookia wrote:
> This should hopefully stop people from running in to issues when
> building Guix from source as they have in the past.
I still think we should make /var the default of localstatedir; this would
avoid most problems.
Andreas, doing his Cicer
On Wed, Mar 09, 2016 at 02:28:03PM +0100, Ludovic Courtès wrote:
> Leo Famulari skribis:
>
> > On Tue, Mar 08, 2016 at 08:39:37PM -0500, Leo Famulari wrote:
> >> On Wed, Mar 09, 2016 at 01:25:04AM +0100, Tobias Geerinckx-Rice wrote:
> >> > On 09/03/2016, Leo Famulari wrote:
> >> > > [...] pass t
This should hopefully stop people from running in to issues when
building Guix from source as they have in the past.
* doc/guix.texi (Requirements): Add explanation of the localstatedir flag.
Discuss how to keep compatibility with binary installation and the package.
---
doc/guix.texi | 17
On Wed, Mar 09, 2016 at 03:27:33PM -0500, Leo Famulari wrote:
> Thanks for the notification! Updated with 89e58e8e8c.
It is difficult to beat you!
There was also a libotr-3 without any dependent package, so I simply
removed it.
Andreas
On Wed, Mar 09, 2016 at 08:59:20PM +0100, Nils Gillmann wrote:
> I have no time to do and testrun this upgrade myself (in the
> middle of testing gnunet related things), but someone if not
> already on this, could (more like should) upgrade our libotr
> package:
>
> https://lists.cypherpunks.ca/pi
While previously creating a GC root for GRUB's resources was the caller's
responsibility, it's much less repetitive to put it in install-grub now that
it's wrapped by error handling. This also means we can replace the install-grub*
function with a small definition inside perform-action named 'insta
I have no time to do and testrun this upgrade myself (in the
middle of testing gnunet related things), but someone if not
already on this, could (more like should) upgrade our libotr
package:
https://lists.cypherpunks.ca/pipermail/otr-users/2016-March/002581.html
thanks,
--
ng
personal contact:
On Wed, Mar 09, 2016 at 07:16:08PM +0100, Nils Gillmann wrote:
> Andreas Enge writes:
>
> > On Tue, Mar 08, 2016 at 06:22:23PM +0100, Ricardo Wurmus wrote:
> >> > Guix should provide a stable experience, but if stable means too
> >> > old to deliver a useable experience of an still in development
Andreas Enge writes:
> On Tue, Mar 08, 2016 at 06:22:23PM +0100, Ricardo Wurmus wrote:
>> > Guix should provide a stable experience, but if stable means too
>> > old to deliver a useable experience of an still in development
>> > network, what do we suggest? I would not replace gnunet and
>> > gn
On Tue, Mar 08, 2016 at 06:39:37PM -0500, Leo Famulari wrote:
> > + (delete 'check) ;; Don't run the 'make check' step of the
> > gnu-build-system
> When skippping the tests, we prefer to say why in the comment. It can be
> as simple as "no test suite" if that is the case.
And use in the a
On Tue, Mar 08, 2016 at 06:22:23PM +0100, Ricardo Wurmus wrote:
> > Guix should provide a stable experience, but if stable means too
> > old to deliver a useable experience of an still in development
> > network, what do we suggest? I would not replace gnunet and
> > gnunet-gtk, I would just make g
Multiple questions:
Hi,
I am curious (not impatient) about if people with commit access
are just busy and/or focused on other issues or if my way to
reply to my own messages and make threads a bit uncomfortable to
read and update information gets lost as I mainly use nntp access
via gmane.org now
l...@gnu.org (Ludovic Courtès) skribis:
> So, on this branch, I’d incorporate:
>
> dbus and dbus/activation
> eudev and eudev-with-blkid
> graphite2 and its replacement
> perl and its replacement
> openssl and its replacement
Done in ‘security-updates’.
I’ll get it built by Hydra if th
On Wed, Mar 09, 2016 at 10:50:46AM +0100, Andreas Enge wrote:
> Now I will try if libreoffice 5.1 builds without updating other libraries.
It does not, I think your patches are really necessary, Efraim. I pushed
the liblangtag one. Libreoffice 5.1 still checks for the old mdds, and
insists on the
Leo Famulari skribis:
> On Tue, Mar 08, 2016 at 08:39:37PM -0500, Leo Famulari wrote:
>> On Wed, Mar 09, 2016 at 01:25:04AM +0100, Tobias Geerinckx-Rice wrote:
>> > On 09/03/2016, Leo Famulari wrote:
>> > > [...] pass to ./configure '--disable-packagekit'. Would that work?
>> >
>> > So do ‘we’:
So! It seems that this time releasing is really hard. :-)
I’d like to do a rebuild without any package replacements, in the hope
that the release itself has no or few grafts in place, mostly because:
• performance is currently degraded in the presence of grafts, in
particular the repeated
Chris Marusich skribis:
> No, I'm not using that at the moment. In the future, if I set up any
> nginx servers to accomplish the same task, I will definitely use it. I
> would prefer to run my own servers, but for now this is something I can
> do immediately to help the project, so I decided to d
Andreas Enge skribis:
> On Tue, Mar 08, 2016 at 10:04:33AM +0100, Andy Wingo wrote:
>> Right now hydra.gnu.org is in this weird situation where people who use
>> it have to trust it, modulo "guix challenge" of course. But really all
>> we have to trust is the mapping from the derivation (like th
On Wed, 9 Mar 2016 10:45:44 +0100
Andreas Enge wrote:
> On Wed, Mar 09, 2016 at 11:16:16AM +0200, Efraim Flashner wrote:
> [...]
>
> Well, it is not quite a release, I would say, if they simply tag every git
> commit and do not even make sure that the tests succeed each time. Normally,
> our
Roel Janssen writes:
> One of the problems with the patch is probably the bulk of dependencies
> dragged in (for example, vcflib). They use specific versions so they
> are tied to this package (so that's why I cannot package them separately).
Yeah, this is worrying.
> From 38302e8cac77275694c
Hello,
I locally applied it, but changed the commit message as follows:
gnu: libetonyek: Update to 0.1.6.
* gnu/packages/libreoffice.scm (libetonyek)[source]: Update to 0.1.6.
[inputs]: Add required input liblangtag.
to record all modifications. This requires the 1.0 version o
On Wed, Mar 09, 2016 at 11:16:16AM +0200, Efraim Flashner wrote:
> Our current vim package is 2.5 years old, and the current patch set on top of
> it to bring it up to today is ~1500 patches. Interestingly, every. single.
> commit. is tagged in git, so updating to a more recent release is rather ea
Roel Janssen writes:
> Please let me know when something is wrong with the patch.
In addition to Leo’s comments here are mine:
> +(arguments
> + `(#:parallel-build? #f
Why is parallel-build disabled? Could you add a comment?
> + #:phases
> + (modify-phases %standard-phas
On Wed, 9 Mar 2016 10:39:08 +0100
Ricardo Wurmus wrote:
> Efraim Flashner writes:
>
> [...]
>
> Interesting.
>
> Both patches look good to me. If I was in nit-picking mode I’d say that
>
> “[source]: Use git-tags for downloading.”
>
> in the commit message is a little confusing beca
Efraim Flashner writes:
> Our current vim package is 2.5 years old, and the current patch set on top of
> it to bring it up to today is ~1500 patches. Interestingly, every. single.
> commit. is tagged in git, so updating to a more recent release is rather easy.
> This has been one of the things
Our current vim package is 2.5 years old, and the current patch set on top of
it to bring it up to today is ~1500 patches. Interestingly, every. single.
commit. is tagged in git, so updating to a more recent release is rather easy.
This has been one of the things that has kept me using Debian's vim
Andreas Enge (2016-03-05 18:27 +0300) wrote:
> commit 1068f26b797ed7c1475d93cab6eed53c9097c7f6
> Author: Andreas Enge
> Date: Sat Mar 5 16:26:55 2016 +0100
>
> doc: Typos and small stylistic changes.
>
> * guix.texi: Correct typos and make minor changes.
[...]
> @@ -5928,7 +5928,7 @@ s
Andreas Enge writes:
> On Sat, Mar 05, 2016 at 10:16:05PM +0100, Ricardo Wurmus wrote:
>> We could ask drobilla for a new suil release. I don’t think we should
>> package the development version as it’s not clear if dependent
>> applications would work with the latest suil.
>
> Sounds good. Wou
l...@gnu.org (Ludovic Courtès) writes:
> Nice! Are you using the nginx config that’s in guix-maintenance.git?
No, I'm not using that at the moment. In the future, if I set up any
nginx servers to accomplish the same task, I will definitely use it. I
would prefer to run my own servers, but for no
40 matches
Mail list logo
