Hi,
nix channels are series of snapshots of nixpkgs that were succesfully
build by hydra and we subscribe and update them via nix-channel - for
users of nixpkgs this is great!
As maintainers of nixpkgs and users who keep custom patches, we also
have one or more local checkouts of
What is the reasoning to have these in a separate repository?
What do you think about adding tags like I proposed?
On Tue, May 19 2015, Domen Kožar wrote:
We have https://github.com/NixOS/nixpkgs-channels that has branches that
track latest channel updates
On Tue, May 19, 2015 at 9:56 AM,
Hi Florian,
What is the reasoning to have these in a separate repository?
We don't want notification e-mails sent out every time the channel
updates, which would happen if these branches were pushed to the main
repository.
Best regards,
Peter
___
Wouldn't it be better for version numbers to always exist? That way it's
simple to know the exact version of your package that you're installing,
even if it's just one package. I'd prefer for it not to be random.
On 16/05/2015 7:27 AM, Vladimír Čunát wrote:
Hi.
On 05/15/2015 11:09 PM, Amy de
We have https://github.com/NixOS/nixpkgs-channels that has branches that
track latest channel updates
On Tue, May 19, 2015 at 9:56 AM, Florian Friesdorf f...@chaoflow.net wrote:
Hi,
nix channels are series of snapshots of nixpkgs that were succesfully
build by hydra and we subscribe and
We have this.
Read about it in a making patches section [1]
[1]
https://github.com/jagajaga/nixpkgs/blob/addition/contributing/CONTRIBUTING.md
Sincerely,
Arseniy Seroka
On 19 May 2015 12:15:00 Florian Friesdorf f...@chaoflow.net wrote:
Hi,
nix channels are series of snapshots of nixpkgs
Will NixOS be affected by the leap second issue that's coming up on June
30 2015?
--
Founder of Matrix AI
http://matrix.ai/
+61420925975
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Excerpts from Roger Qiu's message of Tue May 19 05:56:30 + 2015:
Wouldn't it be better for version numbers to always exist?
You're totally right that the
mkDerivation {
name =name-version
}
version should always exist. Thus if you find cases just create a topic
branch, fix, and
What is exactly the issue with this leap second, and what do you mean by
NixOS being affected?
On Tue, May 19, 2015, 11:56 Roger Qiu roger@polycademy.com wrote:
Will NixOS be affected by the leap second issue that's coming up on June
30 2015?
--
Founder of Matrix AI
http://matrix.ai/
On 05/19/2015 11:22 AM, Florian Friesdorf wrote:
What do you think about adding tags like I proposed?
Listing the tags will quickly become unwieldy, but for a persistent
reference it will be more readable to have channel-date than some random
hash (or maybe channel/date or something). It might
Hi,
On 19/05/15 07:10, Roger Qiu wrote:
Will NixOS be affected by the leap second issue that's coming up on June
30 2015?
You shouldn't have issues if you're running ntpd.
--
Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
___
nix-dev
A few days ago, I ran `nixos-rebuild --switch` using the up-to-date
unstable channel, and everything worked fine. Last night I updated
the channel again and rebuilt, but when I started my computer this
morning, it doesn't prompt for the encryption password anymore, and
home doesn't mount. Any
http://serverfault.com/questions/403732/anyone-else-experiencing-high-rates-of-linux-server-crashes-during-a-leap-second
On 19/05/2015 8:06 PM, Kirill Elagin kirela...@gmail.com wrote:
What is exactly the issue with this leap second, and what do you mean by
NixOS being affected?
On Tue, May
Yeah, leap second(s) are a big issue since that's the code that nobody
really tests. NixOS is going to have as much problems as the software
you're running has bugs.
Google is smart here, they're adding microseconds over a longer span of
time via their NTP, so the extra second doesn't disrupt any
On 19-05-2015 12:08:30, Vladimír Čunát wrote:
I'm uncertain if there might be some performance implications when
working on a repo with too many tags, but as this won't be in the main
repo, we can easily chance it.
From a git point of view, there won't be any performance implications
besides
15 matches
Mail list logo
