text:
Create Notification with the same tag from two browser tabs does not work as expected on Firefox

Browser: Firefox 58.0.2 Quantum
When we are creating notifications from different tabs (i.e. from a SignalR event) and tag these notifications , the expected behavior is that it should open only one notification with the same tag and/or close all other notifications and reopen the last one.
This works as expected on Chrome - we don't get multiple notifications for the same tag.
With Firefox however no notification is visible at all. If we use just one browser tab it works fine.

I've checked your source code so it seems you are just passing the parameters along to the official web notification api in most cases.
From https://notifications.spec.whatwg.org/#tags-example it looks like my scenario should be supported (3.5.3. Using the tag member for multiple instances) - I honestly don't know what I'm doing wrong here.
I'm using the same tag from multiple instances and this should be supported - strange. Maybe that's a Firefox bug. :/

IMO, Firefox's implementation is a bit inferior to Chrome's in general, resulting in several unexpected behaviours.
I suggest trying to wrap your notification creation in a Timeout and see if that works.
Rest assured, this is an unrelated bug with push.js per se. Please feel free to reopen the issue if you feel otherwise. Thanks

authors: McTristan theLufenk


text:
🛑 cedro is down

In c80acc8, cedro (https://www.cedro.org) was down:

HTTP code: 0
Response time: 0 ms

Resolved: cedro is back up in 2678747.

source: gharchive/issue

repo: NicolasAbihaggle/serviciosestados

license: MIT

license_type: permissive

license_source: github-api


text:
Alternate Pem Keys

I needed the ability to use pems other than one sitting locally with the app.  Added the optional alternate_pem argument to public methods in APNS to give users the option of sending a different pem with each notification.
Also did some housekeeping and moved duplicate code into it's own methods.

This is now over 4 years old. No need to keep it open. Closing

source: gharchive/pull-request

repo: NicosKaralis/pushmeup

license: mit

license_source: bigquery


text:
[FEATURE] Raise a non-zero exit code on DQ failure when action is set to fail

Is your feature request related to a problem? Please describe.
I use exit codes to determine if I should move to the next step in my pipelines and ideally we would have a non-zero exit code when a dataquality check is set to fail and fails.
Describe the solution you'd like
we would have a non-zero exit code when a dataquality check is set to fail and fails.
Describe alternatives you've considered
We can use other mechanisms for indicating failure of course, but exit codes are already understood by most pipeline tools.
Additional context
See 57 minute mark at https://www.youtube.com/watch?v=bNvvPKv-dmQ

@holdenk I was looking at this and found that Spark-Expectations is giving non-zero exit codes when it fails. Upon further investigation found that you have an "echo" command in your code which results always to exit code zero -
https://github.com/high-performance-spark/high-performance-spark-examples/blob/9d5395cdba58856d6d9c8254b382ffeaaec9b563/run_pyspark_examples.sh#L48

Ooooh! Good catch sorry for the incorrect bug report 😊

Thanks, closing the bug report!

Ok so I just redid this without the OR (or well it still has the OR but exits with the same error code unless there is a .fail file) and I checked by executing invalid SQL and it got a non-zero exit, but I did it with a row dq and an agg dq rule and it did not work (see se_complex.json example / minute ~85 in https://www.youtube.com/watch?v=usYELWSZgmE )

@holdenk just to make sure that I understand , you are expecting the return code to be non zero because the query_dq should fail and hence the process should exit with non zero ?
But, the query_dq condition (select count(*) from 3rd_fake_view) < (select input_count from local.dq_stats WHERE table_name='local.3rd_fake' LIMIT 1) will be evaluated to true because
select input_count from local.dq_stats WHERE table_name='local.3rd_fake' LIMIT 1 --- 15267
select count(*) from 3rd_fake_view --- 4961.
and hence the process is exiting with zero
3rd_fake_view: This view is created after the _row_dq process to run the target agg_dq and query_dq which is input_count-error_count as the action_if_failed is set to drop
Let me know if my understanding is not correct, or do you have a different perspective on this?

Ah that's a good point :) For whatever reason I thought the view would have less records but when I flip flop it does fail correctly :)

authors: asingamaneni holdenk phanikumarvemuri

repo: Nike-Inc/spark-expectations


text:
CODE_OF CODUCT

issue #35

@nisha331 As u know levels is updated so i will give it to u later..

@Niketkumardheeryan . it would be great if you could assign the level according to LGMSOC


text:
Refit Dependency

Currently it is very difficult, if not impossible, to make certain configurations of the HttpClient instance.
For starters you have no control over the construction of the HttpClient object so you cannot pass it an instance of HttpClientHandler to be able to configure for example a proxy or other things.
https://github.com/NikiforovAll/keycloak-authorization-services-dotnet/blob/6d20ce592c224ffb32c7a3e198e9d26cef8dc5ba/src/Keycloak.AuthServices.Sdk/Admin/ServiceCollectionExtensions.cs#L46
I think that at the very least there should be an overload that allows you to pass an instance of HttpClient directly: Func<IServiceProvider, HttpClient> clientProvider. It is very common nowadays this pattern: https://learn.microsoft.com/en-us/dotnet/architecture/microservices/implement-resilient-applications/use-httpclientfactory-to-implement-resilient-http-requests
Another issue is why there is a hard dependency to Refit when it should not be necessary, the implementation should be cleaner without dependencies to Refit.
Whoever uses the library if they want to use Refit should be their choice but not an imposition.
If you agree I am willing to help with a PR.

Ok, I see that the AddKeycloakAdminHttpClient method returns an IHttpClientBuilder and I see that the Refit.HttpClientFactory dependency uses the Microsoft library I said.
Even so, I still think that the Refit dependency should not be necessary.
Examining the code I see that it provides several functionalities through C# attributes for client generation and I understand the "convenience" of using it but I still think that it should be a library for the exclusive use of the consumer of a library, not intended for whoever develops a library because you are imposing that use.

Good point, next version will focus on removing unnecessary dependencies

Will be fixed as part of: #64

Done as part of https://github.com/NikiforovAll/keycloak-authorization-services-dotnet/releases/tag/2.0.0

authors: NikiforovAll bdovaz


text:
BUG: No Attribute DTYPE_GRADIENT

When attempting to convert CV-Parametric Selection Tag I got this error in the console:

Converting this tag was the motivation behind this project, so it will certainly be a challenge, but if it's possible to get it working, that would be amazing.

Fixed in 3195e0c2afedab7796d2f39e47e61d7857a51db0

authors: NiklasRosenstein donovankeith


text:
Add SE050 test

This PR adds a test that is introduced in the admin app with https://github.com/Nitrokey/admin-app/pull/5
Note that it takes around 30seconds to complete, it's not crashing.

You are essentially calling a fixed test routine in the firmware, and waiting for the results. Instead you could construct test cases on the calling side, and use a proper direct communication channel to se050.

I wanted to test the actual APDU generation from the driver to test it, so all commands to the SE050 needs to be run from rust code. This is meant to test the driver in real conditions. Communicating to the SE050 directly from nitropy would make that much less useful, even if it were to test the T=1 over I2C part of the driver.

I do not think though running pytest itself is that much trouble for a beta tester, but that's my opinion.

I agree, but running pytest is much less discoverable while nk3 test is documented and used.

this does not interfere with anything else, should we merge this ?

Running this with the se050-test-app feature disabled now gives me:
[4/5]	se050    	SE050                   	FAILURE  	object of type 'type' has no len()

Running this with the se050-test-app feature disabled now gives me:
[4/5]	se050    	SE050                   	FAILURE  	object of type 'type' has no len()

Can you try again? This should be fixed I believe.

Yes, fixed.

repo: Nitrokey/pynitrokey


text:
Remove asn1crypto

removes the dependency on asn1crypto, replacing it with the cryptography package and a custom builder
Motivation
This is one less dependency. asn1crypto is not very widespread so using cryptography is likely the better solution.
Checklist
Make sure to run make check and make fix before creating a PR, otherwise the CI will fail.

[ ] tested with Python3.9
[x] signed commits
[ ] updated documentation (e.g. parameter description, inline doc, docs.nitrokey)
[ ] added labels

Test Environment and Execution

OS: Arch Linux
device's model: NK3AM
device's firmware version: 1.7.0-test20241022

Relevant Output Example

Fixes #

Ok, it was failing because of a missing @property.


text:
No Time to wait on codechef

Problem Link
https://www.codechef.com/MARCH21C/submit/NOTIME
Coding platform
Codechef
Programming language

[ ] C
[ ] C++
[ ] Java
[ ] Python

I would like to provide code in c++

@Nivedita967 I want to solve this in Java.

I can do this in C

authors: TechSpiritSS jasmine1601 kmryashasvi


text:
Set Matrix Zeroes

Problem Link
https://leetcode.com/problems/set-matrix-zeroes/
Coding platform
LeetCode
Programming language

[ ] C
[ ] C++
[ ] Java
[ ] Python

Additional context (OPTIONAL)
I want to solve this in C++. Please assign it to me.

Hi @Nivedita967
I would like to solve it in Java. Please assign it to me.

will do it in python

@Nivedita967 can I work in C and C++??

@Amit366 Go for C.

Hi @Nivedita967
I would like to solve it in Java. Please assign it to me.

Can I get assigned?

Hi @Nivedita967
Is this issue still open? Can I solve it in Python?

Hi @Nivedita967
Is this issue still open? Can I solve it in Python?

Sure Go for it @abhinav5481


text:
macs/flake.lock: Update and unpin nix.package

Flake lock file updates:

• Updated input 'darwin':
    'github:LnL7/nix-darwin/87b9d090ad39b25b2400029c64825fc2a8868943' (2023-01-09)
  → 'github:LnL7/nix-darwin/7e08a9dd34314fb8051c28b231a68726c54daa7b' (2024-07-31)
• Updated input 'nixpkgs':
    'github:nixos/nixpkgs/1e383aada51b416c6c27d4884d2e258df201bc11' (2023-03-08)
  → 'github:nixos/nixpkgs/c3392ad349a5227f4a3464dce87bcc5046692fce' (2024-07-31)

This should bring us to nix 2.18.5.

Deployed on:

cosmic-stud
tight-bug
destined-gannet
quality-ram
becoming-hyena

by running darwin-rebuild switch --flake "github::nixos/infra/update-darwin?dir=macs#$(uname -m)" (yes the :: is intentional, old versions of darwin-rebuild appear to have trimmed it out or something) on each of them

(They're all running Nix 2.18.5 now)

authors: cole-h mweinelt

repo: NixOS/infra


text:
apple/t2: update to kernel 6.7.7 and add tiny-dfr service

Description of changes

Update the linux kernel with t2 patches to 6.7.7
Removed fix-keyboard-backlight-and-touchbar.sh as this should no longer be needed.
Added the package and service tiny-dfr as the new patches removed this functionality from a kernal module and placed it in userland. Kekrby's fork is used since the official one does not support t2 macs.

Things done

[x] Tested the changes in your own NixOS Configuration
[x] Tested the changes end-to-end by using your fork of nixos-hardware and
importing it via <nixos-hardware> or Flake input

Any testing would be appreciated especially anyone that uses apple-set-os-loader as i do not use this and have not tested with it.

@mergify queue

repo: NixOS/nixos-hardware


text:
Add flake search feature

To make flakes more discoverable, we could add the ability to search for/in flakes to search.nixos.org. Ideally this would allow users to find packages, NixOS modules/options, etc. provided by flakes. For instance, a search for services.hydra should return the Hydra flake.
We could either index the flakes in the global registry, or all flakes on GitHub (e.g. by doing https://api.github.com/search/repositories?q=/flake.nix).
For each flake, we can do nix flake show github:<owner>/<repo> and dump the result in Elasticsearch. (TODO: add a --json flag to nix flake show to make this easier. Also, nix flake show doesn't show the options provided by NixOS modules yet.)

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/flake-discoverability/8212/2

index the flakes in the global registry

As I'm seeing it right now, those are mostly "indirections" with a shared global namespace.

all flakes on GitHub (e.g. by doing https://api.github.com/search/repositories?q=/flake.nix)

This is far more powerful, but would have to display forks. I'd prefer this since it supports flakes by design to be a more decentralized and distributed thing.
Maybe, we might need discoverability of the distinction of a gitflow contributing fork or a functional fork with added / different functionality.
{
    functionalFork = true;
}

But more probably this problem might reveal itself in time without major negative impact.

(from #115) currently we are not exporting aliases. when we rewrite the nix flake show we need to also consider including aliases.

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/contract-work-for-the-next-generation-internet/6840/9

I am willing and about to start working on this!

This is actually done :)

authors: blaggacao edolstra garbas nixos-discourse ysndr

repo: NixOS/nixos-search


text:
Convert Linux from Docbook to CommonMark

This issue tracks the conversion of /doc/builders/packages/linux.xml from Docbook to CommonMark per RFC 72.
If you intend to work on this conversion, please comment below!
Conversion instructions

Comment here that you intend to work on it. (Please also post if you stop working on it.)
Checkout a new branch of nixpkgs master.
Edit doc/builders/packages/index.xml: change linux.xml to linux.section.xml.
Rename doc/builders/packages/linux.xml to linux.section.md.
Convert the contents from Docbook to CommonMark. Follow conversion best practices. Use existing .md sections for inspiration.
Use nix-build from the doc/ folder to build the manual.
Preview the manual on your computer at http://0.0.0.0:8000/manual.html after running from doc/ folder:

nix-shell -p python3 --run 'python3 -m http.server --directory ./result/share/doc/nixpkgs'

When it looks good, submit a PR and reference this issue.

I'll take this.

authors: mmlb ryantm

repo: NixOS/nixpkgs


text:
Cannot use httplib2 with ansible on darwin

When I try to use the URI module (core ansible module) I get the following error :
httplib2 is not installed

I'm using nix from master on OSX 10.11 with ansible 1.9.4 (from nixpkgs.ansible)
This is what I already tried without success :
pip install httplib2 : permission denied error
nix-env -iA nixpkgs.python27Packages.httplib2 : problem still there.

How are you using ansible?

nix-shell -p ansible --command "python -c 'import ansible; import httplib2'" works for me

ping

Worked with nix-shell.
Thanks.

authors: domenkozar zeroware


text:
Rename virtualisation.* namespace into virtualization.*

Do we even care about british vs american?

No no, we use British spelling :-)

OK :)

@edolstra, @domenkozar, but not here? :smiley_cat: https://github.com/NixOS/nixpkgs/tree/master/pkgs/applications/virtualization

You really should reconsider this. Principle of least astonishment applies. I tried multiple times to enable the clearly obvious spelling of virtualization.vmware.guest.enable = true;
The entire tech industry has pretty much decided that American English is the one everyone uses. And then you're not even consistent about this? This is really an awful anti-feature for Nix right now and pretty much makes it unusable for me.
I can't just waste time all the time banging my head against the wall trying to guess spelling for things because you can't be consistent.

You really should reconsider this. Principle of least astonishment applies. I tried multiple times to enable the clearly obvious spelling of virtualization.vmware.guest.enable = true;
The entire tech industry has pretty much decided that American English is the one everyone uses. And then you're not even consistent about this? This is really an awful anti-feature for Nix right now and pretty much makes it unusable for me.
I can't just waste time all the time banging my head against the wall trying to guess spelling for things because you can't be consistent.

The website uses American English:

virtualization: https://nixos.org/explore.html
stabilization etc.: https://nixos.org/news.html

Package search finds many results with virtualization and none with virtualisation:

https://search.nixos.org/packages?channel=20.09&from=0&size=30&sort=relevance&query=virtualization
https://search.nixos.org/packages?channel=20.09&from=0&size=30&sort=relevance&query=virtualisation

Wiki uses American English:

customization: https://nixos.wiki/wiki/Keyboard_Layout_Customization
categorized: https://nixos.wiki/wiki/Nix_channels

Discourse uses American English: Uncategorized: https://discourse.nixos.org
The community clearly has settled on using American English, and this is an anomaly. You really should simply fix it.

The website uses American English:

virtualization: https://nixos.org/explore.html
stabilization etc.: https://nixos.org/news.html

Package search finds many results with virtualization and none with virtualisation:

https://search.nixos.org/packages?channel=20.09&from=0&size=30&sort=relevance&query=virtualization
https://search.nixos.org/packages?channel=20.09&from=0&size=30&sort=relevance&query=virtualisation

Wiki uses American English:

customization: https://nixos.wiki/wiki/Keyboard_Layout_Customization
categorized: https://nixos.wiki/wiki/Nix_channels

Discourse uses American English: Uncategorized: https://discourse.nixos.org
The community clearly has settled on using American English, and this is an anomaly. You really should simply fix it.

I agree, since most of the internet uses american English it's better to be consistent.

I agree, since most of the internet uses american English it's better to be consistent.

@lietu feel free to make a PR, but it should use the renaming module for backwards compatibility.

@lietu feel free to make a PR, but it should use the renaming module for backwards compatibility.

I'm basically trying out NixOS for the first time to see if it's something I could like, so might be a bit much for me atm - I'll consider it if it survives my attempt to pick what to focus on next, got Manjaro and FreeBSD to test out as well 🙂

I'm basically trying out NixOS for the first time to see if it's something I could like, so might be a bit much for me atm - I'll consider it if it survives my attempt to pick what to focus on next, got Manjaro and FreeBSD to test out as well 🙂

The community clearly has settled on using American English, and this is an anomaly. You really should simply fix it.

Disagree. Nix has always used British spelling (e.g. nix-store --realise).

The community clearly has settled on using American English, and this is an anomaly. You really should simply fix it.

Disagree. Nix has always used British spelling (e.g. nix-store --realise).

Disagree. Nix has always used British spelling (e.g. nix-store --realise).

Well then the community is very inconsistent about that and you should just switch everything to American English like pretty much the entire industry has.
I can say that if I have to constantly be guessing which spelling to use for every line I write, I will not be having a good time. I doubt I am alone in this.

Disagree. Nix has always used British spelling (e.g. nix-store --realise).

Well then the community is very inconsistent about that and you should just switch everything to American English like pretty much the entire industry has.
I can say that if I have to constantly be guessing which spelling to use for every line I write, I will not be having a good time. I doubt I am alone in this.

At the bare minimum, the "wrong" spelling should be detected and given a specific error message. That alone would reduce the pain here from a "WTF?" to a "sigh, fine", which is a big improvement.
This is also an issue with the online option search. I was very confused the other day when I searched for "specialization" and nothing showed up.

At the bare minimum, the "wrong" spelling should be detected and given a specific error message. That alone would reduce the pain here from a "WTF?" to a "sigh, fine", which is a big improvement.
This is also an issue with the online option search. I was very confused the other day when I searched for "specialization" and nothing showed up.

Why isn't aliasing and supporting both mentioned? If Erlang can use Behavior and  Behaviour, and it doesn't seem to matter, why can't Nix?
I run into this whenever I run
# nix optimise store

I even out of habit had to backspace my zee (ha) to type that example.
I'm biased as an American English speaker, although I don't know what would be wrong with just allowing both -ize and -ise and -or, -our if it makes people feel more "at home" using Nix. Seeing British ex-coworkers struggle during pair programming with CSS because of color vs. colour is just needlessly frustrating when both keys could be supported.

Aliasing will lead to people writing inconsistent documentation and guides etc. and end-users end up confused as to what is the right way of doing things. Also aliasing tends to cause issues to automatic verification of things in case of e.g. * { color: red; colour: blue; } it will be tougher to tell that one of them is completely ignored.

Wouldn't it be inconsistent to write documentation in two dialects of English?
I can see where this view comes from a technical viewpoint, but I feel like it causes needless frustration regardless of having one "chosen" from a language and linguistic viewpoint. Being in a country where English is a second language and gap-year international teachers, I speak with frustrated student about having spelling marked wrong each year based arbitrarily on the teacher's country of origin. I understand the compiler doesn't care and it just sees a key it wants satisfied, but it feels like the compiler is telling me I'm using English wrong when it's not. (key word: feels). Does the feeling user's get using the language matter??

e.g. * { color: red; colour: blue; }

I would expect  colour: blue to be chosen because the concept of "alias" would have a special privilege where it literally means the same thing, not just let color = colour. It would also prevent color being used for one thing and colour being used for something different.

I would expect colour: blue to be chosen because the concept of "alias" would have a special privilege where it literally means the same thing, not just let color = colour. It would also prevent color being used for one thing and colour being used for something different.

Exactly, that's what you should expect and it's what I meant. It would be confusing because they are not the same keys, and software seems them as two distinctive keys. Without colour defined you can just say it's wrong.

Wouldn't it be inconsistent to write documentation in two dialects of English?

I'm not sure where you think I'm suggesting that, I'm specifically saying that ALIASING would lead to that issue - since both are correct, two different people will choose to write their blog posts etc. using different dialects, end users will see both of them and be confused as to which is correct.

I understand the compiler doesn't care and it just sees a key it wants satisfied, but it feels like the compiler is telling me I'm using English wrong when it's not. (key word: feels). Does the feeling user's get using the language matter??

Honestly in this regard there's little that can be said except "tough luck", considering most of the software world has settled on American English and that's what you HAVE TO use to get by. It's incredibly rare that something actually forces British English on you like Nix does.
Once we all come up with good ways to solve the aliasing/automatic conversion between the languages then things might be better, but then the issue will not be limited to just z vs s and -our vs -or but people will want to write their CSS in French and Chinese as well, which is equally valid/invalid - if you allow one alias then why not multiple, and then we come up with conflicting words in different languages and who gets priority 😄 .. in which case I'd probably go for principle of least astonishment again and just use American English and nothing else.

but people will want to write their CSS in French and Chinese as well, which is equally valid/invalid

This is slipping on a slippery slope at this point :sweat_smile:
I do still think it worthwhile to cover that "tough luck" where it happens just for comfort. Seeing red squiggly lines in this <textarea> in typing examples has got to feel bad to a number of people. It seems this sort of argument comes up in a lot of communities though ... and someone always gets shut out. Usually it's not American English so I shrug, but it's not so fun being in those shoes. :P

https://github.com/NixOS/nixpkgs/pull/222236
fonts.optimizeForVeryHighDPI has been added. It would be really great if this project could seamlessly support both. Aspell still has its en_gb-ize dictionary too.

Worth noting that pkgs/tools/virtualization has the American English spelling, so both exist in nixpkgs.

Would it be possible to add a custom error message, saying something like "Maybe you meant to write virtualisation?"

authors: Gaelan domenkozar edolstra lietu michalrus quatquatt thanegill toastal


text:
packaging request: xedit

Project description

Xedit is a simple text editor for X.

On some installations this simple text editor even has syntax highlightning, but it might require non-trivial amounts of work to get that part to work.
Metadata

homepage URL: https://gitlab.freedesktop.org/xorg/app/xedit
source URL: Gitlab, https://gitlab.freedesktop.org/xorg/app/xedit, tag = xedit-${version}

or alternatively: https://gitlab.freedesktop.org/xorg/app/xedit/-/archive/xedit-${version}/xedit-xedit-${version}.tar.gz
latest current version: 1.2.2

license: MIT (according to the ebuild in the Gentoo repository)
platforms: at least linux, but might also support other platforms with X11 support

I still need this.


text:
request for packaging: spellcheck

A tool that gives warnings and suggestions for bash/sh shell scripts:
spellcheck
It has a web demo too, and easy integration with vim/emacs.
@peti @fuuzetsu @asppsa @ttuegel @jcumming @aszlig:
It's a Haskell package, so I hope you don't mind being pinged.

The package is called "shellcheck" (shell... not spell...) and it seems to be already packaged (on master).
That was easy ;-)

@bjornfor that explains a lot!  :grin:

I guess it'd be nice if it was available on stable (NixOS 16.03) too.

@bjornfor I can't find it...

It's been packaged for a long time, really, both in master and in release-16.03:
nix-env -f "<nixpkgs>" -iA haskellPackages.ShellCheck

@peti @bjornfor Works a treat! Thanks.
Still weird that it doesn't turn up on a github search.

@magnetophon: Hm, weird. Local search finds it (nixpkgs.git at fe17c7a00213dae76cb607dfd063b9e9d7aeb5df):
$ git grep shellcheck
pkgs/build-support/fetchgit/nix-prefetch-git:        # shellcheck disable=SC2064
pkgs/build-support/fetchgit/nix-prefetch-git:        # shellcheck disable=SC2064
pkgs/development/haskell-modules/hackage-packages.nix:       homepage = "http://www.shellcheck.net/";
pkgs/top-level/all-packages.nix:  shellcheck = self.haskellPackages.ShellCheck;

@peti: Good! I didn't see it because the above search doesn't match on release-16.03 (there is no lower-case "shellcheck" attribute in all-packages.nix).

Since I'm using NixOS stable, the above is my default way of checking if something is packaged in master.
Are there better ways?

The package search doesn't find Haskell packages. There are just too many to include them all.

As far as Haskell packages are concerned, there is no need to check. Nixpkgs has every single package ever published on Hackage.

@peti

The package search doesn't find Haskell packages. There are just too many to include them all.

I'm using the github search feature, you seem to assume I mean the nixos.org package search.
Or is nixos haskell in a separate repo?

As far as Haskell packages are concerned, there is no need to check. Nixpkgs has every single package ever published on Hackage.

I know.  Thanks for that!  :+1:

authors: bjornfor magnetophon peti


text:
programs.noisetorch.enable option doesn't add noisetorch package to environment.systemPackages

Describe the bug
The programs.noisetorch.enable option adds noisetorch to $PATH via the security wrapper in /run/wrappers/bin/ but doesn't add noisetorch to environment.systemPackages. It's pretty common for programs.*.enable options to add packages to environment.systemPackages (see programs.htop.enable & programs.git.enable for example) in order to make the .desktop entries available to application launchers etc.
Steps To Reproduce
Steps to reproduce the behavior:

Enable programs.noisetorch.enable
The noisetorch GUI is now available to be launched from a terminal but no .desktop entry is available to launch the UI from an application launcher because it's not in environment.systemPackages

Expected behavior
noisetorch should be added to environment.systemPackages
Notify maintainers
@PanAeon @legendofmiracles
Metadata
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 5.18.4, NixOS, 22.11 (Raccoon), 22.11.20220619.0d68d7c`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.10.0pre20220620_16c6c6c`
 - nixpkgs: `/nix/store/1njdlszpc3bchdcwk45c3ndb0nfmwqcr-source`

I completely agree with you on that. #184027 should add it to environment.systemPackages, sadly the package does not contain a .desktop neither but that should be fixed with #184022

As mentioned in the PR, isn't

like written on the PR if you could point me to any solution not doing it that way i would be very appreciative. When i look thru other occurences for security.wrappers in the repository i can just find either having it "missing" to add to  environment.systemPackages or adding it the same way the PR did.
If there is any other way, i would be happy to apply that, but cant find any.


text:
NixOS Unstable and 16.09 Release Channel Not Updating

For the past week or so, NixOS release-16.09 hasn't been updated by hydra due to issues with kernel builds.
Kernels have been timing out:

https://hydra.nixos.org/build/44741624
https://hydra.nixos.org/build/44741882
https://hydra.nixos.org/build/44769425
https://hydra.nixos.org/build/44769447
https://hydra.nixos.org/build/44769619
https://hydra.nixos.org/build/44769533

At one point, instability in the 4.8 build was also causing issues.
This is a bit dire now, because users on 16.09 using ACME / LetsEncrypt are now unable to update their certificates: https://github.com/NixOS/nixpkgs/issues/21144 making this a time-bomb as someone's certificate could be running out any moment now.
I'm not sure how to debug or investigate this, and would really like some help.
/cc @rbvermaa, @edolstra, @domenkozar

I restarted the last one and it was immediately successful (I presume the upload to cache was OK and it hung afterwards).

@vcunat Interesting ... can you try restarting the others, too, and see how it goes?

... but I think the main channel-blockers are somewhere else. Actually, I'm not even aware of 4.8 kernel being channel-critical in 16.09.

One day I went through and ran the "Reproduce Locally" script locally and every single one passed.

Yeah, I've never been able to reproduce Hydra failures where the log is correct and complete to the end, followed by a timeout.  I've got no idea why exactly these hangs happen, but it's certainly nothing new; maybe it was worse now due to increased machine load or something...

Even the VM tests where where is an error in the log, I believe every single one passed locally :(

anyway -- if the fix to this issue is changes to nixpkgs, or changes to hydra / the servers / whatever, the important thing is we get an update out.

At least the firewall tests on 16.09 seem to fail reproducibly with some vsftpd problem: http://hydra.nixos.org/build/44745942 http://hydra.nixos.org/build/44745934

I ran the reproduce script for those tests and they passed just fine.

Those tests also started failing on master.  I suspect the underlying problem might be the same as http://lists.science.uu.nl/pipermail/nix-dev/2016-December/022311.html (also maybe)

@edolstra has pushed some changes to the release and master branches, and the 16.09-small channel has already updated. Looks like we should be in the clear, but I'll update again in several hours.

So #20500 was the solution?

Not sure, now weird stuff is failing on hydra but not locally. Example: https://hydra.nixos.org/build/44846830 @edolstra assuming these changes are from that nix upgrade, can we revert nix to the older version until more testing is done?

Update: @FRidh has disabled testing on pytest, and we're now seeing issues from samba.

(messaged nix-dev about this at http://lists.science.uu.nl/pipermail/nix-dev/2016-December/022366.html)

I messaged to #nixos:

as I understand it, the issue is pytest has a test where it chmods a directory to 0000
and expects to not be able to write in there. If it can write, the test fails. with user
namespacing, it can write . hydra is running unstable nix, which turns on user
namespacing. the reason this test started failing out of the blue is because the nix
daemon is, technically, an impure input. so it didn't start failing as soon as nix was
changed, but the next time a big rebuild came around. to make things worse,
nixUnstable had a schema change, so hydra can't just be reset to nix-stable.

Further detail I sent #nixos:

this is what user namespacing is allowing, which I think breaks posix:
mkdir test; chmod 0000 test; touch test/foo

Hydra is running nixUnstable: https://github.com/NixOS/nixos-org-configurations/blob/master/hydra-provisioner/nixops.nix#L42

@edolstra @rbvermaa @domenkozar should hydra be switched nixStable so that release-16.09 can be built reliably?

To add some urgency to this: an embargoed Exim vulnerability is going public on December 25th (who picks Christmas??)... and I'm hopeful this is fixed before then.

To add some urgency to this: an embargoed Exim vulnerability is going public on December 25th (who picks Christmas??)... and I'm hopeful this is fixed before then.

(Perhaps it's on purpose; black hats will surely take a holiday ;-)

For those who want reproduce the bugs happen on hydra:
https://github.com/lethalman/nix-user-chroot
Suffers from the same problems at it uses user namespaces. I was able to reproduce go bug for instance.

I think that not running as UID 0 in the namespace should solve most of these (if not all).

nix-user-chroot does not runs as root, by mapping its own uid into the namespace. Go build still fails though.

@vcunat the issue with pytest works as a regular user, too (https://github.com/NixOS/nixpkgs/issues/21145#issuecomment-267833849)

This might be related to parted build failures on Hydra now: http://hydra.nixos.org/build/45093914
When I build parted on my own box it succeeds because it skips all the device-mapper tests, due to not being run is uid 0.
On Hydra it tries to run them as it is "root" but they fail.

Yes, parted looks like that, and coreutils, too, which blocks almost all Linux stuff.

parted had its tests disabled here: 2fdd4973ec4e867ff76ef6608ac75e89aa0d4514 I would really rather not see lots of packages have their test suites disabled if we can avoid it.

Now both -small and nixpkgs-unstable channels got updated, at least.

Commits were reverted on nix: https://github.com/NixOS/nix/commits/master
and the jobs on hydra were re-run, removing the massive 8,000 package breaking rebuild is no longer there: https://hydra.nixos.org/jobset/nixos/release-16.09

@aristidb can you revert your parted change?
@FRidh can you revert the disabling of pytest tests?

@grahamc I plan to use the latest pytest as default. Because of a circular dependency with hypothesis tests will need to remain disabled then.

@globin, @domenkozar, @cstrahan, @nathan7 (contributors to go in nixpkgs): hydra is erroring on:
--- FAIL: TestSCMCredentials (0.00s)
	creds_test.go:66: WriteMsgUnix failed with invalid argument, want EPERM

(https://hydra.nixos.org/build/44853356/nixlog/3) in 1.6 and 1.7 at least. Seemingly related: https://github.com/golang/go/issues/10703
can you look at it?

That go problem doesn't happen with my local nix (on the same nixpkgs commit).

Yes, this is introduced by user namespacing. We're still using user namespacing on hydra. Only the seccomp changes were reverted.

I see now. It should be run with UID 1 and GID 1.

KDE5 tests fail on unstable and 16.09; I don't see why currently. On unstable it's actually the last issue preventing channel update.

KDE tests frequently fail for "no reason"... will investigate.

@grahamc while I can patch that out, things shouldn't be running as UID 0, and I'm not particularly interested in ignoring a valid test

@nathan7 the tests aren't running as uid 0 at this point.

See: https://github.com/NixOS/nix/commit/3a4bd320c2c4043a4b1f73406030e9afc0677b59 this revert, put us back at uid 1000

KDE5 tests fail on unstable and 16.09; I don't see why currently. On unstable it's actually the last issue preventing channel update.

These tests frequently time-out, I'm afraid.

There were several failed attempts, so I thought it was some more permanent problem, but I see 16.09 succeeded completely now. nixos-unstable is now the only long-failing channel (~12 days).

16.09 is updating okay now, I think though:

the patch for go_1_7 should be applied to 1_6
the patches for release-16.09 should be reviewed and applied to master

@vcunat not sure where to put this, but @LnL7 and @acowley are asking for staging to  be merged to master.

We need to wait for Hydra; that's what staging is for.

My question was a bit more general, eg. are there reasons not to merge in the last commit that was built by hydra if the results look ok?
At the moment the sync between master and staging is pretty long IMHO.

In general there aren't, but the last one fully-built on Hydra is relatively old and there were a lot of changes on master since then, so the merge would create lots of new jobs by itself. My tool estimates ~10k just for x86_64-linux and it doesn't count e.g. Haskell stuff. There are thousands of jobs queued for master even now :-/
It isn't that bad, really; I remember periods where the lag was counted in months :-)

I also had to backport to go patch to go_bootstrap, which was having trouble after a mass rebuild. Now, some tests aren't completing fast enough: https://hydra.nixos.org/build/45276404/nixlog/1

It's probably better to disable go tests altogether.

That could be. I wonder, though, if it is because the machine it is running on is highly loaded, due to the mass rebuild?

The go tests are pretty cpu intensive

They passed ok, but the instability is a bit troubling. Not the biggest worry, perhaps, though...

All the five channels are recent now :-)

authors: FRidh LnL7 Mic92 aristidb edolstra grahamc nathan7 obadz ttuegel vcunat


text:
element-desktop: Start automatically after system login option not working

Describe the bug
Setting the option in Settings -> Preferences -> Start automatically after system login does not work as described.
Steps To Reproduce
Steps to reproduce the behavior:

Install pkgs.element-desktop
Set the option Settings -> Preferences -> Start automatically after system login to true.
Reboot the system

Expected behavior
Element should automatically start on login.
Screenshots

Notify maintainers
@Ma27
@fadenb
@mguentner
@Ekleog
@Ralith
@dali99
@sumnerevans
Metadata
 - system: `"x86_64-linux"`
 - host os: `Linux 6.1.10, NixOS, 22.11 (Raccoon), 22.11.2483.49efda9011e`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.11.1`
 - channels(root): `"nixos-22.11, nixpkgs, unstable"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Ok, I am having trouble finding how to set it to auto launch after login in my desktop.
Can any one tell me what option to use in configuration.nix?

I tried to build a systemd service, but that didn't work, nor made much sense for a desktop application anyway.
I tried to use a simple bash script and just add & at the end, that didn't work.

I think it has something to do with starting the program as the user I am logged in as, instead of starting it as the root or system service.
Is there a simple nixpkgs option where I can simply add a package to a list in the config and that tells the system to auto start that package's binary?
If you can just give me a link to a page that points me in the right direction, I would be very grateful.

Startup applications are handled differently in each desktop environment, you should consult the documentation for whatever DE you use

Thanks, issue has been solved!
NOTE TO SELF: not everything has to been done in a nix config


text:
Setting environment.noXlibs = true causes openjdk to rebuild

Issue description
Setting environment.noXlibs = true causes openjdk to rebuild from source.
In particular, it changes dbus package, which is a dep for some graphical stuff in JDK.
As a solution, I'd like openjdk_minimal and build it on hydra.
Another solution, is not to use environment.noXlibs = true on JDK-enabled servers... Not a big deal, in fact. Just wanted to document this.
Steps to reproduce
Set the above-mentioned option and configure services.tomcat.enable = true;
Technical details

System: nixos-17.03
Nixpkgs version: 05126bc8503a37bfd2fe80867eb5b0bea287c633

openjdk_minimal sounds sensible to me.

Hi,
setting this flag rebuilds not only openjdk, but, I suspect, any x-enabled program installed (eg. emacs).
It should be at least documented.

Going to close this, as noXlibs got removed.

authors: SuperSandro2000 danbst joachifm wfranzini


text:
llvmPackages_17.clang: clang 17 cannot locate C++ std headers

Describe the bug
When trying to build some software, build is unable to complete due to missing headers.
Steps To Reproduce
Steps to reproduce the behavior:

Use clang_17 and llvmPackages_17.stdenv.mkDerivation on project that requires it.
Run nix build.
Build fails partway through due to missing header.

Expected behavior
clang to find the std headers.
Additional context
I've been trying to build Redumper for my own testing, and have been unable to build it successfully.
Here is a log of the build, with NIX_CFLAGS_COMPILE="-v": 061glri5zp3s9rlis00vyj9pcbpcqd2x-redumper-build_297.drv.log

Click to open derivation used for testing:
{ lib
, llvmPackages_17
, fetchFromGitHub
, cmake
, ninja
, clang_17
, build_type ? "Release"
# Typical values include `Debug`, `Release`, `RelWithDebInfo` and `MinSizeRel`
# Usually set to "Release" for GitHub Actions use, so that's what it's set to by default here.
}:

llvmPackages_17.stdenv.mkDerivation rec {
pname = "redumper";
version = "build_297";

src = fetchFromGitHub {
  owner = "superg";
  repo = "redumper";
  rev = version;
  hash = "sha256-AOuWkdFT8e/aEvvORcAtLHPFgRUzFsZ86VIddEOyts4=";
};

nativeBuildInputs = [
  cmake
  ninja
  clang_17 # Should alias to `llvmPackages_17.clang`
];

env.NIX_CFLAGS_COMPILE = "-v";
env.gh_run_version = "297";

cmakeFlags = [
  "-DCMAKE_BUILD_WITH_INSTALL_RPATH=ON"
  "-DREDUMPER_CLANG_LINK_OPTIONS=-static"
  "-DREDUMPER_VERSION_BUILD=$gh_run_version"
];

meta = with lib; {
  description = "Low level CD dumper utility";
  homepage = "https://github.com/superg/redumper";
  license = licenses.gpl3Only;
  maintainers = with maintainers; [ whovian9369 ];
  mainProgram = "redumper";
  platforms = platforms.all;
};
}

Notify maintainers
@dtzWill
@Ericson2314
@lovek323
@primeos
@alyssais
@RaitoBezarius
@rrbutani
@sternenseemann
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.1.64, NixOS, 23.11 (Tapir), 23.11.928.50aa30a13c4a`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.1`
 - channels(root): `"nixos-23.11"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Add a :+1: reaction to issues you find important.

This doesn't seem to be specific to llvmPackages_17, as replacing it with llvmPackages_16 doesn't help.

You need llvmPackages_17.libcxxStdenv.mkDerivation, because Redumper hardcodes -stdlib=libc++  inside CMakeLists.txt when it detects that Clang is used as a C++ compiler.

Thanks, I'll test that for my specific issue. I'll leave this open as I'm personally unsure if it is "enough" to close as user error.

You need llvmPackages_17.libcxxStdenv.mkDerivation, because Redumper hardcodes -stdlib=libc++ inside CMakeLists.txt when it detects that Clang is used as a C++ compiler.

Can you please elaborate on the hardcoding part? Is there a better way to specify a C++ runtime library?

I ran into this precise problem while also trying to package redumper myself yesterday and running into a brick wall.
The issue linked by @hmenke suggests specifying the includes manually, but I wouldn't know how to do that on NixOS (and with my extremely minimal cmake/gcc/clang knowledge). Did you manage to get this working @Whovian9369? Is there anything @superg can do to help us with this?

Did you manage to get this working @Whovian9369?
Haven't tried anything more since, no. If you want to talk about this at all and use Discord, please feel free to send me a friend request on Discord, @romatthe !

This seems to be a nix issue with the wrapper. The same llvm packages end up working on ubuntu.

I just tested this, and it seems to still be occurring when using: llvmPackages_18.stdenv.mkDerivation, nativeBuildInputs = [ cmake ninja clang_18  ];
Said log: 27naig5iqc1d71hss2ybghd2lxg3sx9k-redumper-git-371.drv.log

Even compiling something simple like a hello world through cmake doesn't work when you use libcxx llvm stdenv, it seems to be a problem with the dependency scanner. You can work around it by manually specifying the headers in the build flags but that is awful.

Possible related issues: https://github.com/NixOS/nixpkgs/issues/277564
https://github.com/NixOS/nixpkgs/issues/191152
cc @qyriad because i know you were complaining about the cc wrapper assuming libstdc++ on non-macOS.

cc @RossComputerGuy

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/clang-cannot-locate-c-std-headers/51095/1

I think I figured out the problem. I had to explicitly pass includes for glibc's include dir and a C++ stdlib impl header directory. Using NIX_CFLAGS_COMPILE or other similar arguments was not good enough. This might mean that we will have to wrap clang-scan-deps.

There's already a wrapped clang-scan-deps in llvmPackages.clang-tools. Adding it to nativeBuildInputs fixes the issue.

Seems I'm late to the redumper packaging party.
@leo60228 am I to understand that you are able to build it? As below my clangStdenv still has library path issues (same if I use GNU ld)
Running phase: buildPhase
[1/190] Scanning /build/source/generate_offsets.cc for CXX dependencies
warning: argument unused during compilation: '-fuse-ld=lld'
warning: argument unused during compilation: '-stdlib=libc++'
[3/190] Building CXX object CMakeFiles/generate_offsets.dir/generate_offsets.cc.o
clang++: warning: argument unused during compilation: '-fuse-ld=lld' [-Wunused-command-line-argument]
clang++: warning: argument unused during compilation: '-stdlib=libc++' [-Wunused-command-line-argument]
[12/190] Linking CXX executable generate_offsets/Threads.c.oK
FAILED: generate_offsets
: && /nix/store/4rz4z2bkb68vwbdxcwq0jxh2fyhhiqkh-clang-wrapper-18.1.8/bin/clang++ -fuse-ld=lld -O2 -g -DNDEBUG -stdlib=libc++ -static CMakeFiles/generate_offsets.dir/generate_offsets.cc.o -o generate_offsets   && :
ld.lld: error: unable to find library -lc++
ld.lld: error: unable to find library -lm
ld.lld: error: unable to find library -lc
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.
error: builder for '/nix/store/w50715li5j8rdv7yv51gdm92fqyw4swa-redumper-415.drv' failed with exit code 1;
       last 10 log lines:
       > clang++: warning: argument unused during compilation: '-fuse-ld=lld' [-Wunused-command-line-argument]
       > clang++: warning: argument unused during compilation: '-stdlib=libc++' [-Wunused-command-line-argument]
       > [12/190] Linking CXX executable generate_offsets/Threads.c.oK
       > FAILED: generate_offsets
       > : && /nix/store/4rz4z2bkb68vwbdxcwq0jxh2fyhhiqkh-clang-wrapper-18.1.8/bin/clang++ -fuse-ld=lld -O2 -g -DNDEBUG -stdlib=libc++ -static CMakeFiles/generate_offsets.dir/generate_offsets.cc.o -o generate_offsets   && :
       > ld.lld: error: unable to find library -lc++
       > ld.lld: error: unable to find library -lm
       > ld.lld: error: unable to find library -lc
       > clang++: error: linker command failed with exit code 1 (use -v to see invocation)
       > ninja: build stopped: subcommand failed.
       For full logs, run 'nix log /nix/store/w50715li5j8rdv7yv51gdm92fqyw4swa-redumper-415.drv'.

derivation
{ lib
, fetchFromGitHub
, clangStdenv
, cmake
, ninja
, llvmPackages
}:

clangStdenv.mkDerivation (finalAttrs: {
  pname = "redumper";
  version = "415";

  src = fetchFromGitHub {
    owner = "superg";
    repo = "redumper";
    rev = "build_${finalAttrs.version}";
    hash = "sha256-c5bVCIJMsFrn/Z6ufvm72Ro3d5JkqSeUfM/B1PQBg3g=";
  };

  cmakeBuildType = "RelWithDebInfo";
  nativeBuildInputs = [ cmake ninja llvmPackages.clang-tools llvmPackages.lld ];
  enableParallelBuilding = false;

  cmakeFlags = [
    "-DCMAKE_BUILD_WITH_INSTALL_RPATH=ON"
    "-DREDUMPER_CLANG_LINK_OPTIONS=-static"
    "-DREDUMPER_VERSION_BUILD=${finalAttrs.version}"
    "-DCMAKE_CXX_FLAGS=-fuse-ld=lld"
    "-G Ninja"
  ];

  buildPhase = ''
    cmake --build . -j 1
  '';

  meta = with lib; {
    homepage = "https://github.com/superg/redumper";
    description = "Low level CD dumper utility";
    license = licenses.gpl3Plus;
    maintainers = with maintainers; [ hughobrien ];
    platforms = platforms.linux;
  };
})

Here's an updated attempt, thanks to @Whovian9369  https://github.com/NixOS/nixpkgs/pull/364796

I think the actual issue here is that CMake uses clang-scan-deps for clang 16+, and without clang-tools in nativeBuildInputs its heuristics manage to find the unwrapped clang-scan-deps and try (and fail) to use that instead of immediately erroring out.

authors: I-mikan-I RossComputerGuy Whovian9369 emilazy hmenke hughobrien kanashimia leo60228 lf- nixos-discourse romatthe superg wegank


text:
KDE not showing any window borders in 18.03

Issue description
I just updated to 18.03 and KDE is broken. I can't close or resize windows anymore as window decorations are not displayed
Steps to reproduce
Upgrade to 18.03
Technical details
I can't as I can't open a browser on the machine

Sorry for the terse description but I can't open a web browser on the machine. Or at least. I can't make the window focus..

Can't reproduce. It may be due to the configuration in your home directory. If you move that out (~/.kde, and a number of files in ~/.config), does the issue persist? Are there any other details about your computer?

Runs successfully for me without issue.

When I'm home I'll investigate further :)
On Sat, Apr 14, 2018, 09:17 Bastian Köcher notifications@github.com wrote:

Yeah, @arianvp https://github.com/arianvp should try that. If for you
everything works, I did not expect anything else ;)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NixOS/nixpkgs/issues/38870#issuecomment-381309697,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAmWo5JwwFNeiHFzfd8WrWjuqYLkaal4ks5toaKmgaJpZM4TSekx
.

Possible dup of #38752

After running 18.03 for a day, this suddenly started happening for me, as well. I rolled back to 17.09 and rebuild 18.03 just to be certain, and it still happens. I'll try the step bkchr mentioned above.

$ nix-info
system: "x86_64-linux", multi-user?: yes, version: nix-env (Nix) 1.11.16, channels(root): "nixos-18.03.132083.06c576b0525", channels(b): "unstable-18.09pre135256.6c064e6b1f3", nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs

This does look like a dupe of #38752, though I'm not sure how that helps me :)

nix-info from the broken 18.03:

system: "x86_64-linux"
host os: Linux 4.14.35, NixOS, 18.03.132083.06c576b0525 (Impala)
multi-user?: yes
sandbox: no
version: nix-env (Nix) 2.0
channels(root): "nixos-18.03.132083.06c576b0525"
channels(b): "unstable-18.09pre135256.6c064e6b1f3"
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs

Maybe it's time to switch away from KDE.

@chreekat did it fix your installation to delete the config folder?

I will try that and let you know.
On Apr 22, 2018 15:36, "Bastian Köcher" notifications@github.com wrote:
@chreekat https://github.com/chreekat did it fix your installation to
delete the config folder?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NixOS/nixpkgs/issues/38870#issuecomment-383406631, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAg3qg7P1kXZrDcEhwcIsWxj8XNA6Myzks5trNu4gaJpZM4TSekx
.

@chreekat which GPU are you using?
I found a similar bug report for gnome: https://bugzilla.redhat.com/show_bug.cgi?id=1462507
Do you also use wayland?

I am using X11. I have some integrated graphics, probably Intel. NixOS doesn't seem to have lspci, and I'm not sure what else to use to look up the info. lshw doesn't give anything useful.
Ah, the GNOME 'about' pages says, "Intel® Haswell Mobile".

NixOS doesn't seem to have lspci

nix-shell -p pciutils --run lspci or nix-env -f '<nixpkgs>' -iA pciutils then try again.

Thanks,
00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 09)

I said "seems to not have" because I got no prompt to install a particular package, as I sometimes do with missing utilities, and I am not sure how to map particular utilities to particular packages. Except for grepping the sources, I suppose, which I could have done...

I'm now getting the issue, with the same error as chreekat (kwin_x11[1364]: segfault at 4 ip 00007f414ff1ca98 sp 00007ffd5e041820 error 4 in libxkbcommon.so.0.0.0[7f414ff00000+3e000]). Similarly affecting old generations. Have cleared out ~/.config, ~/.kde /var, /tmp
Have attempted to clear out most qt-using packages from user-env. Currently the only version from 5.10.1 is the phonon backend using 5.6
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 620 (rev 02)
00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller (rev 21)
00:14.2 Signal processing controller: Intel Corporation Sunrise Point-LP Thermal subsystem (rev 21)
00:15.0 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #0 (rev 21)
00:15.1 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #1 (rev 21)
00:16.0 Communication controller: Intel Corporation Sunrise Point-LP CSME HECI #1 (rev 21)
00:17.0 SATA controller: Intel Corporation Sunrise Point-LP SATA Controller [AHCI mode] (rev 21)
00:1c.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #1 (rev f1)
00:1d.0 PCI bridge: Intel Corporation Device 9d1b (rev f1)
00:1f.0 ISA bridge: Intel Corporation Sunrise Point-LP LPC Controller (rev 21)
00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 21)
00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21)
00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21)
01:00.0 3D controller: NVIDIA Corporation GM108M [GeForce 940MX] (rev ff)
02:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32)```

My error was likely related to qt versions. Fixed by removing version of spectacle  which was more recent than expected for the release I was on (spectacle was version 18.04 from unstable, expected version was 17.12 or earlier).

Got same problem when I installed qt5 app (telegram client) from nixpkgs-unstable. It got fixed once I removed it from user profile.

Considering the lack of recent comments, this issue was probably fixed a while ago.

authors: FliegendeWurst arianvp bkchr chreekat jasoncarr0 lheckemann sopvop


text:
Please add netgen package

Upstream site: https://ngsolve.org
https://sourceforge.net/projects/netgen-mesher/
Most other repos package it as 'netgen' see https://repology.org/metapackage/netgen/versions

bump to 'freshen' up this ticket

bump

bump

authors: cyber-murmel luzpaz


text:
Update Fwupd

Describe the bug
We had to revert a patch because it doesn't apply to the current version https://github.com/NixOS/nixpkgs/commit/283ef6bc6d075f85f049299b11c0f5ef417a9553.
And it's probably a good idea to do this anyway, fwupd moves pretty quickly.
Newest looking tag is https://github.com/fwupd/fwupd/releases/tag/1.3.2, though I don't I've seen them doing release simultaneously to https://github.com/fwupd/fwupd/releases/tag/1.2.11.
Changes can be found at https://github.com/fwupd/fwupd/blob/master/data/org.freedesktop.fwupd.metainfo.xml.
Additional info
Current Version: 1.2.10
Version to update to: 1.3.2
As previously mentioned, not sure what's going on with the 1.2.* series.

see also #71114

1.3 is a new stable series, 1.2.11 is a backport to a old stable branch.

authors: jtojnar worldofpeace


text:
telepathy-idle: 0.2.0 → 0.2.2

Motivation for this change

Update (switches to Meson and Python 3)
https://github.com/TelepathyIM/telepathy-idle/blob/telepathy-idle-0.2.2/NEWS#L1-L38
Enable tests

Had to disable twisted since two of those are failing on internal timeout.

Move build time dependencies to nativeBuildInputs.
Use pkg-config instead of pkgconfig alias
Format the expression
Correct the license (based on source code comments, some files are 2.1-only, others 2.1-or later).

Does not build without https://github.com/TelepathyIM/telepathy-idle/pull/10
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[x] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 102449 run on x86_64-linux 1

2 packages failed to build:

gnome3.polari
telepathy-idle

Yes, the files are missing, I opened https://github.com/TelepathyIM/telepathy-idle/pull/10

superseded by later updates.

authors: NickCao SuperSandro2000 jtojnar


text:
[RFC] libssl abstraction, default to libressl instead of openssl

This is a RFC to add a generic libssl attribute to depend on an openssl compatible libssl implementation. Also, this changes the default libssl implementation to libressl.
Some software doesn't work yet with libressl, so there are some hardcoded dependencies on openssl where I stumbled on problems, but not all packages were tested. My laptop and some service VMs are working flawlessly. This is a work in progress.
Currently, libssl also includes libcrypto and the openssl utility (both included in libressl) but this could also be split out if needed.
I'd like some feedback if this change is welcome or if you prefer to add this in another way.
Side note: The libressl folks are working on a new TLS API called libtls, thus the choice to name the old API libssl (which is also the actual name of the library in question), which is already available in libressl today: http://www.openbsd.org/papers/libtls-fsec-2015/

Why is libresslpreferable to openssl?

@peti Personally I would prefer LibreSSL because their aim is to clean up the code in OpenSSL and make it at least somewhat maintainable, which I, having unfortunately spent some time looking at the original code, can only welcome.
See also (very informal) http://www.openbsd.org/papers/bsdcan14-libressl/mgp00001.html -- it's very biased towards LibreSSL of course, but it shows main pain points.

Funny that libressl got a security advisory a few days ago (doesn't affect openssl) http://seclists.org/oss-sec/2015/q4/87

Generally openssl has had much more CVEs than openssl since libressl forking off and libressl aim to clean up a lot of the old cruft from which is totally worthless now.
See https://wiki.freebsd.org/LibreSSL for a list of vulnerabilities.

How do other distributions handle this? Does anyone else prefer libressl over openssl?

I think no, apart from OpenBSD but they don't qualify as a Linux distribution ^_^.

I can't even find the package in major distros, but I suppose it would be nontrivial for them to have a different version of libssl along with the default. Void Linux sounds as a Linux distribution, though https://en.wikipedia.org/wiki/LibreSSL#Adoption

I also remember several Arch Linux packages in AUR and guides for replacing OpenSSL with LibreSSL on it; the biggest problem is, as @vcunat said, a big difficulty in having two libssl versions -- some packages use OpenSSL APIs that LibreSSL has discontinued. This is a problem that Nix solves elegantly.

@abbradar up to libressl 2.2* there should be no problems with discontinued APIs, only 2.3 removes all SSLv3 code which I have seen break 2 packages so far, one fixed on master (#10463), the other open in #10465

I personally would prefer using libressl 2.2.4 as default for now in NixOS as that is the latest stable release, 2.3 being the current snapshot releases.

Might I suggest to first only introduce pkgs.libssl as an abstraction for "a libssl-compatible library" ? Reaching consensus for this might be quicker than mixing both items. This branch touches a lot of packages and is likely expensive to maintain. I believe that there is also more that two choices: gnutls and boringssl also come to mind (although boringssl seem like a pain to bootstrap).
In regards to pkgs.libss. Is aliasing a good-enough solution or do we need a mechanism to fallback to openssl for well-known broken libraries ?
Also related, how do we prevent package authors to link openssl instead of libssl when creating new packages ?

:+1:

Void Linux sounds as a Linux distribution, though

Also see Gentoo's overlay.

How do we prevent package authors to link openssl instead of libssl when creating new packages ?

This seems impossible; openssl is what is in all the documentation etc., NixOS is not powerful enough to make everyone switch to using libssl instead.
Here's how I would allow libressl:
openssl-official = <current openssl>
openssl = if config.useLibressl or false then libressl else openssl-official;

openssl is a generic[1] term for both the official OpenSSL library and its forks, and openssl-official can be used for packages that don't work with libressl, like so:
mypkg = callPackage ../development/mypkg { openssl = openssl-official; };

[1] Generic terms are generic, not the first user owns them -- Kay Sievers

This seems impossible; openssl is what is in all the documentation etc., NixOS is not powerful enough to make everyone switch to using libssl instead.

We can always solve the problem with another layer of indirection :p Maybe pkgs.libssl would become a function that takes a white and a black list and returns the right derivation. Then all SSL libraries are removed from the top-level and then the only way to access them is trough that function.
That being said, I don't think that most people will want to switch libraries. After all you need the recompile half of the programs in the system and don't benefit from the hydra builds anymore.
I like your idea of taking openssl as the generic name, this is the library I would look for when developing packages and not libssl. Then I would read the all-packages.nix and understand what's going on from a comment. Just having openssl = libressl is probably enough as it can be changed with overrides and is not likely to be frequent.

I like your idea of taking openssl as the generic name

Me too. The switch shouldn't involve touching hundreds of expressions. That tends to create merge interactions, e.g. with the closure-size branch. And there's not just libssl but libcrypto in there, too.
The line openssl = if ..... is probably unnecessary, as packageOverrides seems perfectly suited for such changes.

Indeed. I don't see a reason for this change, packageOverrides is perfectly enough.
Also for the discussion and a friendly reminder, that libressl and all other alternatives have seen less vulnerabilities because they are much less used than openssl.

We have stopped using this ourselves and changed to an approach overriding openssl with libressl_2_3 with the help of #11673 and #11653.
Then one can either set openssl_1_0_1 explicitly on packages that need ABI compatibility or patching software that relies on obsolete libssl code (#11674)

Okay, thanks for all the feedback. We will move forward by keeping the openssl attribute name for generic openssl API compatible implementations.

authors: Mathnerd314 abbradar domenkozar fpletz globin lethalman peti vcunat zimbatm


text:
pylance: init at 2020.11.2

Motivation for this change
pylance is the new Python language server by Microsoft for vscode. Probably very useful for a
lot of developers.
This is resolving merge conflicts appearing in this PR:
https://github.com/NixOS/nixpkgs/pull/103025
Didn't find a sane way to fix this.
Things done

[ x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ x] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x ] Ensured that relevant documentation is up to date
[x ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 105601 run on x86_64-linux 1

1 package built:

vscode-extensions.ms-python.vscode-pylance


text:
phpExtensions.ftp: enable FTPS support

Motivation for this change
Enable FTPS support.
cc @NixOS/php
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 105808 run on x86_64-linux 1

2 packages marked as broken and skipped:

hhvm
php73Packages.phpmd

13 packages failed to build:

drush
php73
php73Extensions.ftp
php73Packages.box
php73Packages.composer
php73Packages.composer2
php73Packages.php-cs-fixer
php73Packages.php-parallel-lint
php73Packages.phpcbf
php73Packages.phpcs
php73Packages.phpstan
php73Packages.psalm
php73Packages.psysh

43 packages built:

adminer
arcanist
icingaweb2
libsForQt5.kcachegrind (kdeApplications.kcachegrind ,libsForQt515.kcachegrind)
libsForQt512.kcachegrind
libsForQt514.kcachegrind
lsp-plugins
matomo
matomo-beta
nagios
nextcloud-news-updater
phoronix-test-suite
php (php74)
phpExtensions.ftp (php74Extensions.ftp)
phpPackages.box (php74Packages.box)
phpPackages.composer (php74Packages.composer)
phpPackages.composer2 (php74Packages.composer2)
phpPackages.php-cs-fixer (php74Packages.php-cs-fixer)
phpPackages.php-parallel-lint (php74Packages.php-parallel-lint)
phpPackages.phpcbf (php74Packages.phpcbf)
phpPackages.phpcs (php74Packages.phpcs)
phpPackages.phpmd (php74Packages.phpmd)
phpPackages.phpstan (php74Packages.phpstan)
phpPackages.psalm (php74Packages.psalm)
phpPackages.psysh (php74Packages.psysh)
php80
php80Extensions.ftp
php80Packages.box
php80Packages.composer
php80Packages.composer2
php80Packages.php-cs-fixer
php80Packages.php-parallel-lint
php80Packages.phpcbf
php80Packages.phpcs
php80Packages.phpmd
php80Packages.phpstan
php80Packages.psalm
php80Packages.psysh
pulseeffects
qcachegrind
unit
wp-cli
yle-dl

  configure: error: Cannot find OpenSSL's <evp.h>

Result of nixpkgs-review pr 105808 run on x86_64-darwin 1

1 package marked as broken and skipped:

php80

2 packages failed to build:

drush
php73

11 packages built:

adminer
arcanist
icingaweb2
matomo
matomo-beta
nextcloud-news-updater
phoronix-test-suite
php (php74)
qcachegrind
wp-cli
yle-dl

php errrors with
configure: error: Cannot find OpenSSL's <evp.h>

Will the issues mentioned here be addressed? If it is, it can be rebased, have the conflicts fixed and then the issues fixed and re-opened.

authors: Izorkin SuperSandro2000 etu


text:
mosquitto: 1.6.12 -> 2.0.5

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/mosquitto/versions.
meta.description for mosquitto is: "An open source MQTT v3.1/3.1.1 broker"
meta.homepage for mosquitto is: "https://mosquitto.org/"
meta.changelog for mosquitto is: ""
Updates performed

Version update

To inspect upstream changes

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 2.0.5 with grep in /nix/store/awl185d61b301gfwgmw634rp2sfa5jm2-mosquitto-2.0.5

directory tree listing: https://gist.github.com/14b88ae8cd8f2ed869a5a144702e2822

du listing: https://gist.github.com/f8f40715d91dbe42306b70dc87bf981d

Rebuild report (if merged into master) (click to expand)

16 total rebuild path(s)

4 package rebuild(s)

4 x86_64-linux rebuild(s)
4 i686-linux rebuild(s)
4 x86_64-darwin rebuild(s)
4 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
collectd
collectd-data
domoticz
mosquitto

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/awl185d61b301gfwgmw634rp2sfa5jm2-mosquitto-2.0.5 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A mosquitto https://github.com/r-ryantm/nixpkgs/archive/1546a14bcd524768622b9de91b10859d2c2b0810.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/awl185d61b301gfwgmw634rp2sfa5jm2-mosquitto-2.0.5
ls -la /nix/store/awl185d61b301gfwgmw634rp2sfa5jm2-mosquitto-2.0.5/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

4 packages built:

collectd
collectd-data
domoticz
mosquitto

Maintainer pings
cc @peterhoeg for testing.

Superseded by https://github.com/NixOS/nixpkgs/pull/110863

Superseded by https://github.com/NixOS/nixpkgs/pull/110863

authors: prusnak r-ryantm


text:
libpcap: 1.10.0 -> 1.10.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/libpcap/versions.
meta.description for libpcap is: "Packet Capture Library"
meta.homepage for libpcap is: "https://www.tcpdump.org"
meta.changelog for libpcap is: ""
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

/nix/store/05gzb6r593p64ybvhdyh3vqxg2yc7pbf-libpcap-1.10.1/bin/pcap-config passed the binary check.

1 of 1 passed binary check by having a zero exit code.

0 of 1 passed binary check by having the new version present in output.

found 1.10.1 with grep in /nix/store/05gzb6r593p64ybvhdyh3vqxg2yc7pbf-libpcap-1.10.1

found 1.10.1 in filename of file in /nix/store/05gzb6r593p64ybvhdyh3vqxg2yc7pbf-libpcap-1.10.1

directory tree listing: https://gist.github.com/ad520a6007df2aa991da06a53271da52

du listing: https://gist.github.com/4aacbf0ece32152d141d0d6280dc97b2

Rebuild report (if merged into master) (click to expand)

30359 total rebuild path(s)

11070 package rebuild(s)

11058 x86_64-linux rebuild(s)
9589 i686-linux rebuild(s)
311 x86_64-darwin rebuild(s)
9401 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
AusweisApp2
CHOWTapeModel
DisnixWebService
EBTKS
EmptyEpsilon
MIDIVisualizer
MMA
OSCAR
OVMF
OVMF-CSM
OVMF-secureBoot
R
SDL
SDL2
SDL2_gfx
SDL2_image
SDL2_mixer
SDL2_net
SDL2_ttf
SDL_Pango
SDL_gfx
SDL_gpu
SDL_image
SDL_mixer
SDL_net
SDL_sound
SDL_stretch
SDL_ttf
Sylk
_1oom
_1password-gui
_20kly
_3mux
_90secondportraits
a2jmidid
abbaye-des-morts
abcde
abcl
abiword
abootimg
abuse
accountsservice
acl2
acme-sh
acoustidFingerprinter
acsccid
act
adapta-gtk-theme
adementary-theme
adlplug

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/05gzb6r593p64ybvhdyh3vqxg2yc7pbf-libpcap-1.10.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A libpcap https://github.com/r-ryantm/nixpkgs/archive/453558d4a86d25122c02a6cf5e2926765a2430e6.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/05gzb6r593p64ybvhdyh3vqxg2yc7pbf-libpcap-1.10.1
ls -la /nix/store/05gzb6r593p64ybvhdyh3vqxg2yc7pbf-libpcap-1.10.1/bin

Pre-merge build results
NixPkgs review skipped

Maintainer pings
cc @fpletz for testing.

Wednesday, June 9, 2021:
  Summary for 1.10.1 libpcap release:
    Packet filtering:
      Fix "type XXX subtype YYY" giving a parse error
    Source code:
      Add PCAP_AVAILABLE_1_11.
    Building and testing:
      Rename struct bpf_aux_data to avoid NetBSD compile errors
      Squelch some compiler warnings
      Squelch some Bison warnings
      Fix cross-builds with older kernels lacking BPF_MOD and BPF_XOR
      Fix Bison detection for minor version 0.
      Fix parallel build with FreeBSD make.
      Get DLT_MATCHING_MAX right in gencode.c on NetBSD.
      Define timeradd() and timersub() if necessary.
      Fix Cygwin/MSYS target directories.
      Fix symlinking with DESTDIR.
      Fix generation of libpcap.pc with CMake when not building a shared
          library.
      Check for Arm64 as well as x86-64 when looking for packet.lib on
          Windows.
    Documentation:
      Refine Markdown in README.md.
      Improve the description of portrange in filters.
      README.linux.md isn't Markdown, rename it just README.linux.
    pcapng:
      Support reading version 1.2, which some writers produce, and which
          is the same as 1.0 (some new block types were added, but
          that's not sufficient reason to bump the minor version number,
          as code that understands those new block types can handle them
          in a 1.0 file)
    Linux:
      Drop support for text-mode USB captures, as we require a 2.6.27
          or later kernel (credit to Chaoyuan Peng for noting the
          sscanf vulnerabilities in the text-mode code that got me to
          realize that we didn't need this code any more)
      Bluetooth: fix non-blocking mode.
      Don't assume that all compilers used to build for Linux support
          the __atomic builtins
    Windows:
      Add more information in "interface disappeared" error messages, in
        the hopes of trying to figure out the cause.
      Treat ERROR_DEVICE_REMOVED as "device was removed".
      Indicate in the error message which "device was removed" error
          occurred.
      Report the Windows error status if PacketSendPacket() fails.
      Use %lu for ULONGs in error message formats.
      Don't treat the inability to find airpcap.dll as an error.
      Ignore spurious error reports by Microsoft Surface mobile
          telephony modem driver
    rpcap:
      Clean up error checking and error messages for server address
          lookup.

https://www.tcpdump.org/libpcap-changes.txt

authors: mweinelt r-ryantm


text:
Convert phases that contain ":" to dont* = true

Motivation for this change
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Relase notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

@ofborg build python2Packages.pip python3Packages.pip vimPlugins.vim-bracketed-paste libunwind

This disabled custom build phases in all vim plugins. Fix in https://github.com/NixOS/nixpkgs/pull/132734


text:
shfmt: 3.3.0 -> 3.3.1

https://github.com/mvdan/sh/releases/tag/v3.3.1

Motivation for this change
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[x] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Relase notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 132357 run on x86_64-linux 1

2 packages built:

bat-extras.prettybat
shfmt

Result of nixpkgs-review pr 132357 at a02430c9 run on aarch64-linux 1

2 packages built successfully:

bat-extras.prettybat
shfmt

authors: Kranzes r-rmcgibbo zowoq


text:
notcurses: 2.3.8 -> 2.3.13

Motivation for this change
New upstream. https://github.com/dankamongmen/notcurses/releases/tag/v2.3.13
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[X] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

I didn't update the hash yet (was having some trouble doing so), so I'm kinda surprised that most of this CI succeeded.

I didn't update the hash yet (was having some trouble doing so), so I'm kinda surprised that most of this CI succeeded.

Because it just takes the old sources.

Latest version is 2.4.0 (seems that you are the developer of this, thanks for your contribution!), would you like to resolve the merge conflict and do another upgrade here? (We probably also need someone to test building this on x86_64-darwin).

Latest version is 2.4.0 (seems that you are the developer of this, thanks for your contribution!), would you like to resolve the merge conflict and do another upgrade here? (We probably also need someone to test building this on x86_64-darwin).

aye, it's been on my to-do list. i'll either be cutting 2.4.1 by the end of this weekend, in which case i'll bring this up to speed for it, or i'll get this handled for 2.4.0. sorry for the delay!

rebased and attempted the merge, but might have done so incompetently; let's see what the CI has to say...

The sha256 also needs an update, and also will be nice to test building this locally to make sure things work.

@ofborg build notcurses

@dankamongmen if you don't want to buy in the nix ecosystem too much, you can also build it in a docker container: https://nix.dev/tutorials/install-nix#docker
$ git clone git@github.com:NixOS/nixpkgs
$ docker run -it -v $(pwd)/nixpkgs:/nixpkgs nixos/nix
docker> nix-build -I nixpkgs=/nixpkgs -A notcurses

@mic92 AWESOME, thanks! =]


text:
python38Packages.rq: 1.8.1 -> 1.9.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python38Packages.rq is: "A simple, lightweight library for creating background jobs, and processing them"
meta.homepage for python38Packages.rq is: "https://github.com/nvie/rq/"
meta.changelog for python38Packages.rq is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS

Warning: a test defined in passthru.tests did not pass

/nix/store/47b5xw7q9q7w8c62hk1mmkir6iifixc9-python3.8-rq-1.9.0/bin/rq passed the binary check.

/nix/store/47b5xw7q9q7w8c62hk1mmkir6iifixc9-python3.8-rq-1.9.0/bin/rqinfo passed the binary check.

/nix/store/47b5xw7q9q7w8c62hk1mmkir6iifixc9-python3.8-rq-1.9.0/bin/rqworker passed the binary check.

/nix/store/47b5xw7q9q7w8c62hk1mmkir6iifixc9-python3.8-rq-1.9.0/bin/.rq-wrapped passed the binary check.

/nix/store/47b5xw7q9q7w8c62hk1mmkir6iifixc9-python3.8-rq-1.9.0/bin/.rqinfo-wrapped passed the binary check.

/nix/store/47b5xw7q9q7w8c62hk1mmkir6iifixc9-python3.8-rq-1.9.0/bin/.rqworker-wrapped passed the binary check.

6 of 6 passed binary check by having a zero exit code.

2 of 6 passed binary check by having the new version present in output.

found 1.9.0 with grep in /nix/store/47b5xw7q9q7w8c62hk1mmkir6iifixc9-python3.8-rq-1.9.0

found 1.9.0 in filename of file in /nix/store/47b5xw7q9q7w8c62hk1mmkir6iifixc9-python3.8-rq-1.9.0

directory tree listing: https://gist.github.com/9ed0db735501227b35b2933a4685e6c6

du listing: https://gist.github.com/15456a01e745799d8003fd49e452f938

Rebuild report (if merged into master) (click to expand)

8 total rebuild path(s)

2 package rebuild(s)

2 x86_64-linux rebuild(s)
2 i686-linux rebuild(s)
2 x86_64-darwin rebuild(s)
2 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
python38Packages.rq
python39Packages.rq

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/47b5xw7q9q7w8c62hk1mmkir6iifixc9-python3.8-rq-1.9.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python38Packages.rq https://github.com/r-ryantm/nixpkgs/archive/b2bf78e11b0d2b311e7bfc3998ae24797081f01d.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/47b5xw7q9q7w8c62hk1mmkir6iifixc9-python3.8-rq-1.9.0
ls -la /nix/store/47b5xw7q9q7w8c62hk1mmkir6iifixc9-python3.8-rq-1.9.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

2 packages built:

python38Packages.rq
python39Packages.rq

Maintainer pings
cc @MrMebelMan for testing.

Builds happily on macos 10.15 & nixos x86_64, but no tests and no pythonImportsCheck so :shrug:

Result of nixpkgs-review pr 134833 at b2bf78e1 run on x86_64-linux 1

2 packages built successfully:

python38Packages.rq
python39Packages.rq

1 suggestion:

warning: python-include-tests
Consider adding a checkPhase for tests, or if not feasible, pythonImportsCheck.
Near pkgs/development/python-modules/rq/default.nix:21:0:
   |
21 |     description = "A simple, lightweight library for creating background jobs, and processing them";
   | ^

authors: r-rmcgibbo r-ryantm risicle


text:
ocamlPackages.tezos-stdlib: fix hash

Motivation for this change
Current hash seems wrong.
cc maintainer @ulrikstrid
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

I'm pretty sure the hash was correct when we merged this but it must have changed from under us.

authors: ulrikstrid vbgl


text:
python3Packages.amcrest: 1.9.2 -> 1.9.3

Motivation for this change
Update to latest upstream release 1.9.3
Change log: https://github.com/tchellomello/python-amcrest/releases/tag/1.9.3
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 138461 run on x86_64-linux 1

2 packages built:

python38Packages.amcrest
python39Packages.amcrest


text:
torch: add expression for Torch7 the machine-learning framework

This change adds support for Torch7 which is a collection of Lua packages run by luajit interpreter. Instead of using Lua infrastructure from lua-packages.nix, the hand-made Lua wrappers are used. The main reason for this - lack of luarocks support in lua-packages.nix.
To try Torch, install Torch REPL with nix-env -i trepl
There is an expression for ipython-like interface named iTorch, but it doesn't build yet, unfortunately.

Would you please change the commit subject to torch: init at version.
Also, the travis failure looks like a legitimate build error.

I use Torch taken from github directly. Is it OK to use 'torch: init at GITHASH' pattern in commit subject? Yes, the error looks valid, I am working on it.

Use the format pkgname-git-2016-03-13, where the date is the timestamp of the revision you are using. See https://nixos.org/nixpkgs/manual/#sec-package-naming for details.

Looks like it is fine now

Haven't checked everything thoroughly but have some small comments, see above. But great work definitely :tada:

Fix issues pointed out by @globin

Here them are! The hotfixes :)

It's quite unfortunate that the lua framework cannot be re-used, but I suppose that's something that can be improved later. If this is useful in its current state, I think we should just merge it. Let me know when you're ready.

Thanks. I decided to try to integrate Torch with lua-packages to some extent. Luarocks can't be moved easily, but I think I will be able to merge the luajit compiler.

By the way, I checked the current version of Torch expression against char-rnn project, and it works!

Travis failed to run the build due to some unrelated file .../chromium/source/update.nix which is missing. Could you please re-check?
Besides that, I think the request is ready for merging. It now shares luajit with luajitPackages which is an instance of luaPackages. This way, we may combine packages installed into ~/.luarocks with torch libaraies.

Travis restarted. I'll merge this once it completes, seeing as there's been no objections to this change thus far, though I hope that the code is refactored at some point (working code that exists beats perfect code that doesn't, of course).

Travis is ill. This time it decided to build everything starting from coreutils. The job exceeded the maximum time limit for jobs, and has been terminated.

Travis is ill. This time it decided to rebuild everything including coreutils.The job exceeded the maximum time limit for jobs, and has been terminated

One final suggestion: add the main applications to the top-level package set, to improve discoverability. As far as I can tell, trepl is the only one that works; what about exposing it as torch-repl (or even use the original attrname, whatever works)?

Good idea. I added new commit.

Unfortunately, introducing luajitPackages was a bit optimistic. Travis shows that some packages doesn't work with luajit. For example, lua-zlib links with -llua which AFAIK is not required when using luajit. I'll revert this change.

Looks like Travis reports false-negative again. The job exceeded the maximum time limit for jobs, and has been terminated. Could you please recheck it?

Yeah, it wants to rebuild the kernel and so will time out, restarting it won't help until hydra catches up, I think

Is there something I can do to improve the situation with Travis?

Restarted travis

Sadly, same thing.. rebuilding the kernel

I think is mainly an issue with the branches seeing lots of heavy rebuilds lately. There's no way torch would trigger a kernel build, or am I blind?

I think we can go ahead with this, if you can verify that 1) nox-review passes on master; 2) that you've performed a properly sandboxed build; 3) and tested that the output of the top-level attr works.

I merged & built this locally; it works, but I get these warnings during the build of torch-repl:
sh: /nix/store/acqx4m997cvnc9d5ylgfiryvz3p2kiwb-trepl/bin/lua: No such file or directory
No existing manifest. Attempting to rebuild...
Missing dependency for trepl scm-1: penlight scm-1
Missing dependency for trepl scm-1: torch scm-1
Missing dependency for trepl scm-1: penlight scm-1
Missing dependency for trepl scm-1: torch scm-1
Updating manifest for /nix/store/acqx4m997cvnc9d5ylgfiryvz3p2kiwb-trepl/lib/luarocks/rocks

Is this just noise or do they indicate a problem with the build recipe? If not, I'm happy to merge this, seeing that it at least builds & runs for me.

Regarding warnings, I think it is the consequences of the chosen build strategy: from the point of view of luarocks, we create new 'tree' for each package. 'Tree' should contain manifest describing whats in, which should be re-created.
After all, penlight library is available from the th, for example:
th> require "pl.url"
{
  unquote : function: 0x410a77b8
  quote : function: 0x410a78d0
}

Regarding nix-review and sandboxed builds - I didn't try these tools yet, but I think I should find time to learn them. Currently, I switch the system to the version of nixpkgs, containing the torch changes and rebuild it, then install torch-repl to the local user's profile.
Besides that, I have a fork of torch-distro repo. The fork contains a standalone expression build3.nix, which uses <nixpkgs/torch-distro.nix> with src set to ./. . This approach makes it possible to debug the expression easily.

Okay. Sandboxed builds tend to expose lots of problems, such as implicit dependencies, and so lowers the bar for merging changes. Anyway, this worked for me, so I'm just going to merge it.

Thanks! Let me know if something stop working.

authors: globin grwlf ilanacarra joachifm


text:
python38Packages.simple-salesforce: 1.11.3 -> 1.11.4

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python38Packages.simple-salesforce is: "A very simple Salesforce.com REST API client for Python"
meta.homepage for python38Packages.simple-salesforce is: "https://github.com/simple-salesforce/simple-salesforce"
meta.changelog for python38Packages.simple-salesforce is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 1.11.4 with grep in /nix/store/kxyar3ywnwsqlgwgz4yvxdlj59rgmznj-python3.8-simple-salesforce-1.11.4

found 1.11.4 in filename of file in /nix/store/kxyar3ywnwsqlgwgz4yvxdlj59rgmznj-python3.8-simple-salesforce-1.11.4

directory tree listing: https://gist.github.com/2986eda65a1e54cc3d9de64e41567f4d

du listing: https://gist.github.com/956fe425890282609cb625f0c094b353

Rebuild report (if merged into master) (click to expand)

8 total rebuild path(s)

2 package rebuild(s)

2 x86_64-linux rebuild(s)
2 i686-linux rebuild(s)
2 x86_64-darwin rebuild(s)
2 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
python38Packages.simple-salesforce
python39Packages.simple-salesforce

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/kxyar3ywnwsqlgwgz4yvxdlj59rgmznj-python3.8-simple-salesforce-1.11.4 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python38Packages.simple-salesforce https://github.com/r-ryantm/nixpkgs/archive/25c00b83d0f68a138bfdc98de755e2957f347da8.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/kxyar3ywnwsqlgwgz4yvxdlj59rgmznj-python3.8-simple-salesforce-1.11.4
ls -la /nix/store/kxyar3ywnwsqlgwgz4yvxdlj59rgmznj-python3.8-simple-salesforce-1.11.4/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

2 packages built:

python38Packages.simple-salesforce
python39Packages.simple-salesforce

Maintainer pings
cc @costrouc for testing.

Result of nixpkgs-review pr 139251 at 25c00b83 run on x86_64-linux 1

2 packages built successfully:

python38Packages.simple-salesforce
python39Packages.simple-salesforce

2 suggestions:

warning: unused-argument
Unused argument: mock.
Near pkgs/development/python-modules/simple-salesforce/default.nix:6:3:
  |
6 | , mock
  |   ^

warning: unused-argument
Unused argument: isPy27.
Near pkgs/development/python-modules/simple-salesforce/default.nix:7:3:
  |
7 | , isPy27
  |   ^

authors: r-rmcgibbo r-ryantm