Listing processes that use old files

Enhancement request for a notice of processes running old files after upgrading a package. In this case, the upgraded package would be a dependency of another process. This is crucial for running patched software without security vulnerabilities. A guix command for listing the processes would be

Re: Monad code changes

Commit 81a9773 introduces a generic state monad in (guix monads), and the next commit makes ‘%store-monad’ an alias for ‘%state-monad’. The nice thing is that ‘%state-monad’ remains low-overhead thanks to the macro tricks¹ and the use of multiple-value returns to thread the state across monadic pr

Re: wip-gobject-introspection

Mark H Weaver skribis: > You're right to be wary of rebasing public branches, but I think it's > okay with short-lived experimental branches like this. If it turns out > that someone else has done work on it, the situation is easily remedied. Agreed. There’s the unwritten rule inherited from G

Re: wip-gobject-introspection

Federico Beffa writes: > On Sat, Jan 17, 2015 at 6:32 PM, Mark H Weaver wrote: >> At this point, it would be good to rebase (not merge) the >> 'wip-gobject-introspection' branch on current master. Presently, the >> branch is based on master before core-updates was merged, which means a >> consi

Re: wip-gobject-introspection

On Sat, Jan 17, 2015 at 6:32 PM, Mark H Weaver wrote: > At this point, it would be good to rebase (not merge) the > 'wip-gobject-introspection' branch on current master. Presently, the > branch is based on master before core-updates was merged, which means a > considerably different core system t

Re: wip-gobject-introspection

Hi Federico, Thanks for your work on 'wip-gobject-introspection'. At this point, it would be good to rebase (not merge) the 'wip-gobject-introspection' branch on current master. Presently, the branch is based on master before core-updates was merged, which means a considerably different core sys

Re: Fwd: [gnu.org #954922] Vague "licensing" for the symbola font.

Alex Kost skribis: > Ludovic Courtès (2015-01-16 23:37 +0300) wrote: > >> Ian Denhardt skribis: >> >>> Latest word on the Symbola font from the FSF: >> >> Thanks Ian for the update. >> >> I forgot the details, but IIRC Alex Kost was the initial submitter. >> What can be done here? > > Yes it was

Re: ‘gcc’ vs. ‘cc’

Federico Beffa skribis: > On Sat, Jan 17, 2015 at 11:40 AM, Ludovic Courtès wrote: >> 1. Someone (Fede? :-)) opens a bug against GCC at >> suggesting to install the ‘cc’ >> link. > > Given that gcc is also used on many proprietary UNIX systems, in my >

Re: Fwd: [gnu.org #954922] Vague "licensing" for the symbola font.

Ludovic Courtès (2015-01-16 23:37 +0300) wrote: > Ian Denhardt skribis: > >> Latest word on the Symbola font from the FSF: > > Thanks Ian for the update. > > I forgot the details, but IIRC Alex Kost was the initial submitter. > What can be done here? Yes it was me, so if I understand correctly,

Re: gobject-introspection typelibs and shared libraries

On Sat, Jan 17, 2015 at 10:46:35AM +0100, Federico Beffa wrote: > It would be the *GUIX project* the one who would benefit if decisions > would be taken based on technical arguments and merits instead of > feelings or the mood of the day. Why do you suggest that my message was inspired by feelings

Re: ‘gcc’ vs. ‘cc’

On Sat, Jan 17, 2015 at 11:40 AM, Ludovic Courtès wrote: > 1. Someone (Fede? :-)) opens a bug against GCC at > suggesting to install the ‘cc’ > link. Given that gcc is also used on many proprietary UNIX systems, in my opinion, handling of the cc name is

Re: ‘gcc’ vs. ‘cc’

John Darrington skribis: > If we choose to do that, then for consistency we should also > do (setenv "LEX" "flex") and (setenv "YACC" "bison") Possibly a few others > too. Bah, this suggests that it’s a can of worms. Maybe the symlink is better, then. Ludo’.

Re: ‘gcc’ vs. ‘cc’

On Sat, Jan 17, 2015 at 11:40:30AM +0100, Ludovic Courtès wrote: Federico Beffa skribis: > * such a symlink would have spared much frustration to Mark (see > earlier posts in this thread). Again, there have been few cases where this has caused problems (on the

‘gcc’ vs. ‘cc’

Federico Beffa skribis: > * such a symlink would have spared much frustration to Mark (see > earlier posts in this thread). Again, there have been few cases where this has caused problems (on the order of 10-20 packages out of 1000.) I agree it’s better if we can avoid these problems altogether

Re: gobject-introspection typelibs and shared libraries

Federico Beffa writes: >>On Thu, Jan 15, 2015 at 10:42:42PM +0100, Ludovic Courtès wrote: >>> If there’s consensus to install the symlink, that’s fine with me (if we >>> take that route, I would also suggest submitting a patch upstream so GCC >>> installs the symlink.) >> >>I am not in favour of

Re: gobject-introspection typelibs and shared libraries

>On Thu, Jan 15, 2015 at 10:42:42PM +0100, Ludovic Courtès wrote: >> If there’s consensus to install the symlink, that’s fine with me (if we >> take that route, I would also suggest submitting a patch upstream so GCC >> installs the symlink.) > >I am not in favour of adding such a symlink on our ow