[Nix-dev] btrfs-progs (was: contributing to nixpkgs/nixos)

[Mathijs Kwik]

On Mon, Dec 12, 2011 at 10:29 PM, Michael Raskin <7c6f434c at mail.ru> wrote:
> <87fwgplnk6.fsf_-_ at write-only.cryp.to>
> <E1RaAfX-0006WK-00.7c6f434c-mail-ru at smtp12.mail.ru>)
> Mime-Version: 1.0
> Content-type: text/plain; charset="UTF-8"
>
>>>>The maintainer of btrfs-progs seems to be Michael Raskin. Michael, do
>>>>you have any opinion in this matter?
>>>
>>> I do run BtrFS on my notebook for most partitions and sometimes use
>>> BtrFS progs. I didn't update NixPkgs to latest git mostly because I
>>> didn't see if anyone else uses BtrFS (otherwise, it is not worth the
>>> discussion whether upstream bleeding edge is the right choice).
>>>
>>> Currently all allegedely unstable trees I know seem to work quite
>>> reliably. I would not bet on a sane tarball release in the upcoming
>>> month, so I can either apply a patch or just put my changes from
>>> configurations/ into the main tree.
>>
>>Waiting a little more is fine with me, upstream seems to be wrapping
>>up and working towards a stable release (maybe we will finally have
>>btrfsck :).
>
> They are working towards btrfsck for a few years now...

I know, I still have 2 partition images waiting to recover when that
day comes ;)

>
> I hope they don't hit another proof of Edward Shishkin being right in
> the process.
>
>>However, I do feel that packages that don't build (because their
>>source tarball isn't available anymore) are a concern.
>>It's nice to have binaries backing up most installs, but I would like
>>to be able to build from source no matter what.
>
> Could you link me a precise revision? I just don't use git, so I would
> prefer to apply a patch. Or I can commit what I use.

Just commit what you use until an official tarball gets out.
My concern with sources being unavailable is not just this package.
it's just something I need to keep in mind for now that can get in the
way of rebuilding my full system using just a backup of /etc/nixos.


>
>>Does hydra keep mirrored copies of sources around for every binary it serves?
>>And I guess it won't build the same package every night if no inputs
>>change, so if sources become unavailable, won't maintainers notice?
>
> Hydra keeps sources for some time, but they are not GC-pinned.
>
>
>