Question:
Except from If the main module specifies go 1.17 or higher, go mod vendor now omits and files for vendored dependencies, which can otherwise interfere with the ability of the go command to identify the correct module root when invoked within the vendor tree. This may change the hashes of vendorSha256 in existing packages that are using buildGoModule. Originally posted by in
go 1.17 may not be portable across different go versions, but go 1.16 will be EOL next month (when 1.18 releases). 15 is EOL and should be removed. There isn't a remediation for this problem correct? The only answer I see is to move the versions forward with breaking changes.
Yeah - Regenning the hashes isn't that hard - I'm going to confirm they're stable, and then stack a PR using the infra I used for the og hashes. Walking through the cases vendorSha256 = null Fine - no vendoring happens Go 1.16 to 1.17, not go1.17 No module change - testcase clipman. go 1.16 to go1.17, is go1.17
I'm already working on this.
- Do you have an ETA? I expect I can get this pounded out this weekend, but if you don't want me to I won't.
Also any objection to me trying to clean out the go1.15 deps? I think some of them (i.e. terraform / prometheus), might not be updateable, but the rest probably are.
Hopefully in the coming week. We need to handle the hashes and the usual breakage from the update so I really don't want to push something though quickly in case it turns into a mess. I'm also avoiding normalizing any of the vendor hashes so we aren't needlessly adding noise to the git history. I've been moving some things to 1.16 or 1.17 in advance to limit diff and rebuilds and checking that the updated hashes still build on darwin+linux. If you don't mind doing the hashes in smaller batches like in that would be helpful? Fixing or pinning any broken packages would also help. No that should be fine, only looks like a few packages plus the pinned which needs to be either unpinned or removed.
I'm happy to cut small PRs - How many hashes do you want them batched to? 10 hash updates per PR, 100? I have no strong opinion on how to batch these (and normally my tooling generates a commit per package, so its' real easy for me to batch arbitrarily). I'll probably try and clean out most of the easy stuff (i.e. everything with a null vendorSha, everything which doesn't have a changed vendorSha), then deal with the stuff which causes mod vendor changes, but if you want I can start on the gnarlier stuff first (modules with vendorSha changes + the non module stuff).
20 or less per PR would make merges simple as we can let test it. Unless the needs to be updated or it's broken on 1.17 I'm leaving these for the final PR when the default is changed. Also anything that causes more than a few rebuilds is probably easier left for the final PR as well. I'm not planning to fixing every first before the final PR when the default gets changed but if we can get it down to 50-100 hashes it'll make it easier to test and also avoid conflicts with other PRs.
Got it - so focus on the changed hashes - or anything which breaks. I also just pushed out working PRs for every go1.15 package except one (mostly to go1.17), so we might be able to get rid of go1.15 before go1.18 lands.
Should be under 100 now but I'll keep going until there is only a few left (basically just stuff that should stay in sync with the default or causes a few rebuilds) as I've found some with broken vendoring on 1.17 and it's easier to address that first so the final PR is fairly simple.

}; modRoot = "gopls"; <del> vendorSha256 = "sha256-nKjJjtVHk/RLIHI/5v8tO4RcaLLZhr0A6llYGsB0ifQ="; </del> <ins> vendorSha256 = "sha256-8osb5C5G58x9KWCxqiepmN6J0jp+q6aR+As/pJeeTKM="; </ins> doCheck = false;


Question:
Except from If the main module specifies go 1.17 or higher, go mod vendor now omits and files for vendored dependencies, which can otherwise interfere with the ability of the go command to identify the correct module root when invoked within the vendor tree. This may change the hashes of vendorSha256 in existing packages that are using buildGoModule. Originally posted by in
go 1.17 may not be portable across different go versions, but go 1.16 will be EOL next month (when 1.18 releases). 15 is EOL and should be removed. There isn't a remediation for this problem correct? The only answer I see is to move the versions forward with breaking changes.
Yeah - Regenning the hashes isn't that hard - I'm going to confirm they're stable, and then stack a PR using the infra I used for the og hashes. Walking through the cases vendorSha256 = null Fine - no vendoring happens Go 1.16 to 1.17, not go1.17 No module change - testcase clipman. go 1.16 to go1.17, is go1.17
I'm already working on this.
- Do you have an ETA? I expect I can get this pounded out this weekend, but if you don't want me to I won't.
Also any objection to me trying to clean out the go1.15 deps? I think some of them (i.e. terraform / prometheus), might not be updateable, but the rest probably are.
Hopefully in the coming week. We need to handle the hashes and the usual breakage from the update so I really don't want to push something though quickly in case it turns into a mess. I'm also avoiding normalizing any of the vendor hashes so we aren't needlessly adding noise to the git history. I've been moving some things to 1.16 or 1.17 in advance to limit diff and rebuilds and checking that the updated hashes still build on darwin+linux. If you don't mind doing the hashes in smaller batches like in that would be helpful? Fixing or pinning any broken packages would also help. No that should be fine, only looks like a few packages plus the pinned which needs to be either unpinned or removed.
I'm happy to cut small PRs - How many hashes do you want them batched to? 10 hash updates per PR, 100? I have no strong opinion on how to batch these (and normally my tooling generates a commit per package, so its' real easy for me to batch arbitrarily). I'll probably try and clean out most of the easy stuff (i.e. everything with a null vendorSha, everything which doesn't have a changed vendorSha), then deal with the stuff which causes mod vendor changes, but if you want I can start on the gnarlier stuff first (modules with vendorSha changes + the non module stuff).
20 or less per PR would make merges simple as we can let test it. Unless the needs to be updated or it's broken on 1.17 I'm leaving these for the final PR when the default is changed. Also anything that causes more than a few rebuilds is probably easier left for the final PR as well. I'm not planning to fixing every first before the final PR when the default gets changed but if we can get it down to 50-100 hashes it'll make it easier to test and also avoid conflicts with other PRs.
Got it - so focus on the changed hashes - or anything which breaks. I also just pushed out working PRs for every go1.15 package except one (mostly to go1.17), so we might be able to get rid of go1.15 before go1.18 lands.
Should be under 100 now but I'll keep going until there is only a few left (basically just stuff that should stay in sync with the default or causes a few rebuilds) as I've found some with broken vendoring on 1.17 and it's easier to address that first so the final PR is fairly simple.

sha256 = "0n9pf0i5y59kiiv6dq8h8w1plaz9w6s67rqr2acqgxa45iq36mkh"; }; <del> vendorSha256 = "1lzhhg9wimn8nfzrrla5bshgk1ghnlsdfmq6iask0zqz311g96bv"; </del> <ins> vendorSha256 = "1xgl4avq0rblzqqpaxl4dwg4ysrhacwhfd21vb0v9ffr3zcpdw9n"; proxyVendor = true; </ins> subPackages = [ "." ];


Question:
Except from If the main module specifies go 1.17 or higher, go mod vendor now omits and files for vendored dependencies, which can otherwise interfere with the ability of the go command to identify the correct module root when invoked within the vendor tree. This may change the hashes of vendorSha256 in existing packages that are using buildGoModule. Originally posted by in
go 1.17 may not be portable across different go versions, but go 1.16 will be EOL next month (when 1.18 releases). 15 is EOL and should be removed. There isn't a remediation for this problem correct? The only answer I see is to move the versions forward with breaking changes.
Yeah - Regenning the hashes isn't that hard - I'm going to confirm they're stable, and then stack a PR using the infra I used for the og hashes. Walking through the cases vendorSha256 = null Fine - no vendoring happens Go 1.16 to 1.17, not go1.17 No module change - testcase clipman. go 1.16 to go1.17, is go1.17
I'm already working on this.
- Do you have an ETA? I expect I can get this pounded out this weekend, but if you don't want me to I won't.
Also any objection to me trying to clean out the go1.15 deps? I think some of them (i.e. terraform / prometheus), might not be updateable, but the rest probably are.
Hopefully in the coming week. We need to handle the hashes and the usual breakage from the update so I really don't want to push something though quickly in case it turns into a mess. I'm also avoiding normalizing any of the vendor hashes so we aren't needlessly adding noise to the git history. I've been moving some things to 1.16 or 1.17 in advance to limit diff and rebuilds and checking that the updated hashes still build on darwin+linux. If you don't mind doing the hashes in smaller batches like in that would be helpful? Fixing or pinning any broken packages would also help. No that should be fine, only looks like a few packages plus the pinned which needs to be either unpinned or removed.
I'm happy to cut small PRs - How many hashes do you want them batched to? 10 hash updates per PR, 100? I have no strong opinion on how to batch these (and normally my tooling generates a commit per package, so its' real easy for me to batch arbitrarily). I'll probably try and clean out most of the easy stuff (i.e. everything with a null vendorSha, everything which doesn't have a changed vendorSha), then deal with the stuff which causes mod vendor changes, but if you want I can start on the gnarlier stuff first (modules with vendorSha changes + the non module stuff).
20 or less per PR would make merges simple as we can let test it. Unless the needs to be updated or it's broken on 1.17 I'm leaving these for the final PR when the default is changed. Also anything that causes more than a few rebuilds is probably easier left for the final PR as well. I'm not planning to fixing every first before the final PR when the default gets changed but if we can get it down to 50-100 hashes it'll make it easier to test and also avoid conflicts with other PRs.
Got it - so focus on the changed hashes - or anything which breaks. I also just pushed out working PRs for every go1.15 package except one (mostly to go1.17), so we might be able to get rid of go1.15 before go1.18 lands.
Should be under 100 now but I'll keep going until there is only a few left (basically just stuff that should stay in sync with the default or causes a few rebuilds) as I've found some with broken vendoring on 1.17 and it's easier to address that first so the final PR is fairly simple.

rev = "v${version}"; sha256 = "sha256-WAI/rl6awVLbXqdqYAq8fyABAO2qet+GYucuiwClylI="; }; <del> vendorSha256 = "sha256-ZZTM1s/kFHkCjnaDYuP7xCrkW2an3I6kvcMXMy63ySE="; </del> <ins> vendorSha256 = "sha256-ckAnSSSEF00gbgxnPAi2Pi8TNu3nmAahK7TP6HnfmNo="; </ins> patches = [ (substituteAll {


Question:
Except from If the main module specifies go 1.17 or higher, go mod vendor now omits and files for vendored dependencies, which can otherwise interfere with the ability of the go command to identify the correct module root when invoked within the vendor tree. This may change the hashes of vendorSha256 in existing packages that are using buildGoModule. Originally posted by in
go 1.17 may not be portable across different go versions, but go 1.16 will be EOL next month (when 1.18 releases). 15 is EOL and should be removed. There isn't a remediation for this problem correct? The only answer I see is to move the versions forward with breaking changes.
Yeah - Regenning the hashes isn't that hard - I'm going to confirm they're stable, and then stack a PR using the infra I used for the og hashes. Walking through the cases vendorSha256 = null Fine - no vendoring happens Go 1.16 to 1.17, not go1.17 No module change - testcase clipman. go 1.16 to go1.17, is go1.17
I'm already working on this.
- Do you have an ETA? I expect I can get this pounded out this weekend, but if you don't want me to I won't.
Also any objection to me trying to clean out the go1.15 deps? I think some of them (i.e. terraform / prometheus), might not be updateable, but the rest probably are.
Hopefully in the coming week. We need to handle the hashes and the usual breakage from the update so I really don't want to push something though quickly in case it turns into a mess. I'm also avoiding normalizing any of the vendor hashes so we aren't needlessly adding noise to the git history. I've been moving some things to 1.16 or 1.17 in advance to limit diff and rebuilds and checking that the updated hashes still build on darwin+linux. If you don't mind doing the hashes in smaller batches like in that would be helpful? Fixing or pinning any broken packages would also help. No that should be fine, only looks like a few packages plus the pinned which needs to be either unpinned or removed.
I'm happy to cut small PRs - How many hashes do you want them batched to? 10 hash updates per PR, 100? I have no strong opinion on how to batch these (and normally my tooling generates a commit per package, so its' real easy for me to batch arbitrarily). I'll probably try and clean out most of the easy stuff (i.e. everything with a null vendorSha, everything which doesn't have a changed vendorSha), then deal with the stuff which causes mod vendor changes, but if you want I can start on the gnarlier stuff first (modules with vendorSha changes + the non module stuff).
20 or less per PR would make merges simple as we can let test it. Unless the needs to be updated or it's broken on 1.17 I'm leaving these for the final PR when the default is changed. Also anything that causes more than a few rebuilds is probably easier left for the final PR as well. I'm not planning to fixing every first before the final PR when the default gets changed but if we can get it down to 50-100 hashes it'll make it easier to test and also avoid conflicts with other PRs.
Got it - so focus on the changed hashes - or anything which breaks. I also just pushed out working PRs for every go1.15 package except one (mostly to go1.17), so we might be able to get rid of go1.15 before go1.18 lands.
Should be under 100 now but I'll keep going until there is only a few left (basically just stuff that should stay in sync with the default or causes a few rebuilds) as I've found some with broken vendoring on 1.17 and it's easier to address that first so the final PR is fairly simple.

sha256 = "sha256-JRJjuVF0MkV7KVmbAZhiWPWVwDORByCsZqPwdTuVRoA="; }; <del> vendorSha256 = "sha256-nsuI8z0xJYZwhlYHasxHpAAYycpqN0qmS8c0APvxxwc="; </del> <ins> vendorSha256 = "sha256-/N/RYqt+lhhECK+uq99vkm3Mg7PWpdE0GYLXkIYthNw="; </ins> buildInputs = lib.optionals stdenv.isDarwin [ AppKit ];


Question:
Except from If the main module specifies go 1.17 or higher, go mod vendor now omits and files for vendored dependencies, which can otherwise interfere with the ability of the go command to identify the correct module root when invoked within the vendor tree. This may change the hashes of vendorSha256 in existing packages that are using buildGoModule. Originally posted by in
go 1.17 may not be portable across different go versions, but go 1.16 will be EOL next month (when 1.18 releases). 15 is EOL and should be removed. There isn't a remediation for this problem correct? The only answer I see is to move the versions forward with breaking changes.
Yeah - Regenning the hashes isn't that hard - I'm going to confirm they're stable, and then stack a PR using the infra I used for the og hashes. Walking through the cases vendorSha256 = null Fine - no vendoring happens Go 1.16 to 1.17, not go1.17 No module change - testcase clipman. go 1.16 to go1.17, is go1.17
I'm already working on this.
- Do you have an ETA? I expect I can get this pounded out this weekend, but if you don't want me to I won't.
Also any objection to me trying to clean out the go1.15 deps? I think some of them (i.e. terraform / prometheus), might not be updateable, but the rest probably are.
Hopefully in the coming week. We need to handle the hashes and the usual breakage from the update so I really don't want to push something though quickly in case it turns into a mess. I'm also avoiding normalizing any of the vendor hashes so we aren't needlessly adding noise to the git history. I've been moving some things to 1.16 or 1.17 in advance to limit diff and rebuilds and checking that the updated hashes still build on darwin+linux. If you don't mind doing the hashes in smaller batches like in that would be helpful? Fixing or pinning any broken packages would also help. No that should be fine, only looks like a few packages plus the pinned which needs to be either unpinned or removed.
I'm happy to cut small PRs - How many hashes do you want them batched to? 10 hash updates per PR, 100? I have no strong opinion on how to batch these (and normally my tooling generates a commit per package, so its' real easy for me to batch arbitrarily). I'll probably try and clean out most of the easy stuff (i.e. everything with a null vendorSha, everything which doesn't have a changed vendorSha), then deal with the stuff which causes mod vendor changes, but if you want I can start on the gnarlier stuff first (modules with vendorSha changes + the non module stuff).
20 or less per PR would make merges simple as we can let test it. Unless the needs to be updated or it's broken on 1.17 I'm leaving these for the final PR when the default is changed. Also anything that causes more than a few rebuilds is probably easier left for the final PR as well. I'm not planning to fixing every first before the final PR when the default gets changed but if we can get it down to 50-100 hashes it'll make it easier to test and also avoid conflicts with other PRs.
Got it - so focus on the changed hashes - or anything which breaks. I also just pushed out working PRs for every go1.15 package except one (mostly to go1.17), so we might be able to get rid of go1.15 before go1.18 lands.
Should be under 100 now but I'll keep going until there is only a few left (basically just stuff that should stay in sync with the default or causes a few rebuilds) as I've found some with broken vendoring on 1.17 and it's easier to address that first so the final PR is fairly simple.

buildPackages = buildPackages // { stdenv = buildPackages.gcc8Stdenv; }; }); <del> go = go_1_16; </del> <ins> go = go_1_17; </ins> go-repo-root = callPackage ../development/tools/go-repo-root { };


Question:
Except from If the main module specifies go 1.17 or higher, go mod vendor now omits and files for vendored dependencies, which can otherwise interfere with the ability of the go command to identify the correct module root when invoked within the vendor tree. This may change the hashes of vendorSha256 in existing packages that are using buildGoModule. Originally posted by in
go 1.17 may not be portable across different go versions, but go 1.16 will be EOL next month (when 1.18 releases). 15 is EOL and should be removed. There isn't a remediation for this problem correct? The only answer I see is to move the versions forward with breaking changes.
Yeah - Regenning the hashes isn't that hard - I'm going to confirm they're stable, and then stack a PR using the infra I used for the og hashes. Walking through the cases vendorSha256 = null Fine - no vendoring happens Go 1.16 to 1.17, not go1.17 No module change - testcase clipman. go 1.16 to go1.17, is go1.17
I'm already working on this.
- Do you have an ETA? I expect I can get this pounded out this weekend, but if you don't want me to I won't.
Also any objection to me trying to clean out the go1.15 deps? I think some of them (i.e. terraform / prometheus), might not be updateable, but the rest probably are.
Hopefully in the coming week. We need to handle the hashes and the usual breakage from the update so I really don't want to push something though quickly in case it turns into a mess. I'm also avoiding normalizing any of the vendor hashes so we aren't needlessly adding noise to the git history. I've been moving some things to 1.16 or 1.17 in advance to limit diff and rebuilds and checking that the updated hashes still build on darwin+linux. If you don't mind doing the hashes in smaller batches like in that would be helpful? Fixing or pinning any broken packages would also help. No that should be fine, only looks like a few packages plus the pinned which needs to be either unpinned or removed.
I'm happy to cut small PRs - How many hashes do you want them batched to? 10 hash updates per PR, 100? I have no strong opinion on how to batch these (and normally my tooling generates a commit per package, so its' real easy for me to batch arbitrarily). I'll probably try and clean out most of the easy stuff (i.e. everything with a null vendorSha, everything which doesn't have a changed vendorSha), then deal with the stuff which causes mod vendor changes, but if you want I can start on the gnarlier stuff first (modules with vendorSha changes + the non module stuff).
20 or less per PR would make merges simple as we can let test it. Unless the needs to be updated or it's broken on 1.17 I'm leaving these for the final PR when the default is changed. Also anything that causes more than a few rebuilds is probably easier left for the final PR as well. I'm not planning to fixing every first before the final PR when the default gets changed but if we can get it down to 50-100 hashes it'll make it easier to test and also avoid conflicts with other PRs.
Got it - so focus on the changed hashes - or anything which breaks. I also just pushed out working PRs for every go1.15 package except one (mostly to go1.17), so we might be able to get rid of go1.15 before go1.18 lands.
Should be under 100 now but I'll keep going until there is only a few left (basically just stuff that should stay in sync with the default or causes a few rebuilds) as I've found some with broken vendoring on 1.17 and it's easier to address that first so the final PR is fairly simple.

buildGo116Package = callPackage ../development/go-packages/generic { go = buildPackages.go_1_16; }; <del> # go_1_17 has go module changes which may not be portable # across different go versions and/or platforms: # https://github.com/NixOS/nixpkgs/issues/144667 # # That's why `buildGoPackage != buildGo117Package`. </del> buildGo117Package = callPackage ../development/go-packages/generic { go = buildPackages.go_1_17; }; <del> buildGoPackage = buildGo116Package; </del> <ins> buildGoPackage = buildGo117Package; </ins> buildGo116Module = callPackage ../development/go-modules/generic { go = buildPackages.go_1_16; }; <del> # go_1_17 has go module changes which may not be portable # across different go versions and/or platforms: # https://github.com/NixOS/nixpkgs/issues/144667 # # That's why `buildGoModule != buildGo117Module`. </del> buildGo117Module = callPackage ../development/go-modules/generic { go = buildPackages.go_1_17; }; <del> buildGoModule = buildGo116Module; </del> <ins> buildGoModule = buildGo117Module; </ins> go2nix = callPackage ../development/tools/go2nix { };


Question:
Except from If the main module specifies go 1.17 or higher, go mod vendor now omits and files for vendored dependencies, which can otherwise interfere with the ability of the go command to identify the correct module root when invoked within the vendor tree. This may change the hashes of vendorSha256 in existing packages that are using buildGoModule. Originally posted by in
go 1.17 may not be portable across different go versions, but go 1.16 will be EOL next month (when 1.18 releases). 15 is EOL and should be removed. There isn't a remediation for this problem correct? The only answer I see is to move the versions forward with breaking changes.
Yeah - Regenning the hashes isn't that hard - I'm going to confirm they're stable, and then stack a PR using the infra I used for the og hashes. Walking through the cases vendorSha256 = null Fine - no vendoring happens Go 1.16 to 1.17, not go1.17 No module change - testcase clipman. go 1.16 to go1.17, is go1.17
I'm already working on this.
- Do you have an ETA? I expect I can get this pounded out this weekend, but if you don't want me to I won't.
Also any objection to me trying to clean out the go1.15 deps? I think some of them (i.e. terraform / prometheus), might not be updateable, but the rest probably are.
Hopefully in the coming week. We need to handle the hashes and the usual breakage from the update so I really don't want to push something though quickly in case it turns into a mess. I'm also avoiding normalizing any of the vendor hashes so we aren't needlessly adding noise to the git history. I've been moving some things to 1.16 or 1.17 in advance to limit diff and rebuilds and checking that the updated hashes still build on darwin+linux. If you don't mind doing the hashes in smaller batches like in that would be helpful? Fixing or pinning any broken packages would also help. No that should be fine, only looks like a few packages plus the pinned which needs to be either unpinned or removed.
I'm happy to cut small PRs - How many hashes do you want them batched to? 10 hash updates per PR, 100? I have no strong opinion on how to batch these (and normally my tooling generates a commit per package, so its' real easy for me to batch arbitrarily). I'll probably try and clean out most of the easy stuff (i.e. everything with a null vendorSha, everything which doesn't have a changed vendorSha), then deal with the stuff which causes mod vendor changes, but if you want I can start on the gnarlier stuff first (modules with vendorSha changes + the non module stuff).
20 or less per PR would make merges simple as we can let test it. Unless the needs to be updated or it's broken on 1.17 I'm leaving these for the final PR when the default is changed. Also anything that causes more than a few rebuilds is probably easier left for the final PR as well. I'm not planning to fixing every first before the final PR when the default gets changed but if we can get it down to 50-100 hashes it'll make it easier to test and also avoid conflicts with other PRs.
Got it - so focus on the changed hashes - or anything which breaks. I also just pushed out working PRs for every go1.15 package except one (mostly to go1.17), so we might be able to get rid of go1.15 before go1.18 lands.
Should be under 100 now but I'll keep going until there is only a few left (basically just stuff that should stay in sync with the default or causes a few rebuilds) as I've found some with broken vendoring on 1.17 and it's easier to address that first so the final PR is fairly simple.

redstore = callPackage ../servers/http/redstore { }; <del> reproxy = callPackage ../servers/reproxy { }; </del> <ins> reproxy = callPackage ../servers/reproxy { buildGoModule = buildGo116Module; }; </ins> restic = callPackage ../tools/backup/restic { };


Question:
Except from If the main module specifies go 1.17 or higher, go mod vendor now omits and files for vendored dependencies, which can otherwise interfere with the ability of the go command to identify the correct module root when invoked within the vendor tree. This may change the hashes of vendorSha256 in existing packages that are using buildGoModule. Originally posted by in
go 1.17 may not be portable across different go versions, but go 1.16 will be EOL next month (when 1.18 releases). 15 is EOL and should be removed. There isn't a remediation for this problem correct? The only answer I see is to move the versions forward with breaking changes.
Yeah - Regenning the hashes isn't that hard - I'm going to confirm they're stable, and then stack a PR using the infra I used for the og hashes. Walking through the cases vendorSha256 = null Fine - no vendoring happens Go 1.16 to 1.17, not go1.17 No module change - testcase clipman. go 1.16 to go1.17, is go1.17
I'm already working on this.
- Do you have an ETA? I expect I can get this pounded out this weekend, but if you don't want me to I won't.
Also any objection to me trying to clean out the go1.15 deps? I think some of them (i.e. terraform / prometheus), might not be updateable, but the rest probably are.
Hopefully in the coming week. We need to handle the hashes and the usual breakage from the update so I really don't want to push something though quickly in case it turns into a mess. I'm also avoiding normalizing any of the vendor hashes so we aren't needlessly adding noise to the git history. I've been moving some things to 1.16 or 1.17 in advance to limit diff and rebuilds and checking that the updated hashes still build on darwin+linux. If you don't mind doing the hashes in smaller batches like in that would be helpful? Fixing or pinning any broken packages would also help. No that should be fine, only looks like a few packages plus the pinned which needs to be either unpinned or removed.
I'm happy to cut small PRs - How many hashes do you want them batched to? 10 hash updates per PR, 100? I have no strong opinion on how to batch these (and normally my tooling generates a commit per package, so its' real easy for me to batch arbitrarily). I'll probably try and clean out most of the easy stuff (i.e. everything with a null vendorSha, everything which doesn't have a changed vendorSha), then deal with the stuff which causes mod vendor changes, but if you want I can start on the gnarlier stuff first (modules with vendorSha changes + the non module stuff).
20 or less per PR would make merges simple as we can let test it. Unless the needs to be updated or it's broken on 1.17 I'm leaving these for the final PR when the default is changed. Also anything that causes more than a few rebuilds is probably easier left for the final PR as well. I'm not planning to fixing every first before the final PR when the default gets changed but if we can get it down to 50-100 hashes it'll make it easier to test and also avoid conflicts with other PRs.
Got it - so focus on the changed hashes - or anything which breaks. I also just pushed out working PRs for every go1.15 package except one (mostly to go1.17), so we might be able to get rid of go1.15 before go1.18 lands.
Should be under 100 now but I'll keep going until there is only a few left (basically just stuff that should stay in sync with the default or causes a few rebuilds) as I've found some with broken vendoring on 1.17 and it's easier to address that first so the final PR is fairly simple.

buildGoModule = buildGo116Module; }; <del> victoriametrics = callPackage ../servers/nosql/victoriametrics { }; </del> <ins> victoriametrics = callPackage ../servers/nosql/victoriametrics { buildGoModule = buildGo116Module; }; </ins> virtiofsd = callPackage ../servers/misc/virtiofsd { };


Question:
Except from If the main module specifies go 1.17 or higher, go mod vendor now omits and files for vendored dependencies, which can otherwise interfere with the ability of the go command to identify the correct module root when invoked within the vendor tree. This may change the hashes of vendorSha256 in existing packages that are using buildGoModule. Originally posted by in
go 1.17 may not be portable across different go versions, but go 1.16 will be EOL next month (when 1.18 releases). 15 is EOL and should be removed. There isn't a remediation for this problem correct? The only answer I see is to move the versions forward with breaking changes.
Yeah - Regenning the hashes isn't that hard - I'm going to confirm they're stable, and then stack a PR using the infra I used for the og hashes. Walking through the cases vendorSha256 = null Fine - no vendoring happens Go 1.16 to 1.17, not go1.17 No module change - testcase clipman. go 1.16 to go1.17, is go1.17
I'm already working on this.
- Do you have an ETA? I expect I can get this pounded out this weekend, but if you don't want me to I won't.
Also any objection to me trying to clean out the go1.15 deps? I think some of them (i.e. terraform / prometheus), might not be updateable, but the rest probably are.
Hopefully in the coming week. We need to handle the hashes and the usual breakage from the update so I really don't want to push something though quickly in case it turns into a mess. I'm also avoiding normalizing any of the vendor hashes so we aren't needlessly adding noise to the git history. I've been moving some things to 1.16 or 1.17 in advance to limit diff and rebuilds and checking that the updated hashes still build on darwin+linux. If you don't mind doing the hashes in smaller batches like in that would be helpful? Fixing or pinning any broken packages would also help. No that should be fine, only looks like a few packages plus the pinned which needs to be either unpinned or removed.
I'm happy to cut small PRs - How many hashes do you want them batched to? 10 hash updates per PR, 100? I have no strong opinion on how to batch these (and normally my tooling generates a commit per package, so its' real easy for me to batch arbitrarily). I'll probably try and clean out most of the easy stuff (i.e. everything with a null vendorSha, everything which doesn't have a changed vendorSha), then deal with the stuff which causes mod vendor changes, but if you want I can start on the gnarlier stuff first (modules with vendorSha changes + the non module stuff).
20 or less per PR would make merges simple as we can let test it. Unless the needs to be updated or it's broken on 1.17 I'm leaving these for the final PR when the default is changed. Also anything that causes more than a few rebuilds is probably easier left for the final PR as well. I'm not planning to fixing every first before the final PR when the default gets changed but if we can get it down to 50-100 hashes it'll make it easier to test and also avoid conflicts with other PRs.
Got it - so focus on the changed hashes - or anything which breaks. I also just pushed out working PRs for every go1.15 package except one (mostly to go1.17), so we might be able to get rid of go1.15 before go1.18 lands.
Should be under 100 now but I'll keep going until there is only a few left (basically just stuff that should stay in sync with the default or causes a few rebuilds) as I've found some with broken vendoring on 1.17 and it's easier to address that first so the final PR is fairly simple.

onlyoffice-bin = callPackage ../applications/office/onlyoffice-bin { }; <del> open-policy-agent = callPackage ../development/tools/open-policy-agent { }; </del> <ins> open-policy-agent = callPackage ../development/tools/open-policy-agent { buildGoModule = buildGo116Module; }; </ins> openshift = callPackage ../applications/networking/cluster/openshift { };


Question:
Any local users can talk to locally running X server by default. That includes sending keyboard/mouse events, popping windows, etc. Log in as into a host running an X server under , and run I think normally you should have to do something like before you're able to talk to 's X server. System: NixOS: nix-shell -p xorg.xmessage --command xmessage test Nix version: nix-env (Nix) 1.11.2 Nixpkgs version:
Thanks, amazing nobody has spotted this before. The flag has been present ever since (when it at least had a comment about being bad idea...).
:+1:

# TODO add plugins having various licenses, see http://www.vamp-plugins.org/download.html <del> { stdenv, fetchurl, alsaLib, bzip2, fftw, jackaudio, libX11, liblo, libmad, libogg, librdf, librdf_raptor, librdf_rasqal, libsamplerate, libsndfile, makeWrapper, pulseaudio, qt4, redland, rubberband, vampSDK </del> <ins> { stdenv, fetchurl, alsaLib, bzip2, fftw, jackaudio, libX11, liblo , libmad, libogg, librdf, librdf_raptor, librdf_rasqal, libsamplerate , libsndfile, makeWrapper, pkgconfig, pulseaudio, qt4, redland , rubberband, vampSDK </ins> }: <del> stdenv.mkDerivation { name = "sonic-visualiser-1.8"; </del> <ins> stdenv.mkDerivation rec { name = "sonic-visualiser-${version}"; version = "1.9"; </ins> src = fetchurl { <del> url = http://downloads.sourceforge.net/sv1/sonic-visualiser-1.8.tar.gz; sha256 = "16ik6q9n92wljvnqcv7hyzb9v3yp3ixxp6df9kasf53fii973dh7"; </del> <ins> url = "http://code.soundsoftware.ac.uk/attachments/download/194/${name}.tar.gz"; sha256 = "00igf7j6s8xfyxnlkbqma0yby9pknxqzy8cmh0aw95ix80cw56fq"; </ins> }; buildInputs = [ libsndfile qt4 fftw /* should be fftw3f ??*/ bzip2 librdf rubberband libsamplerate vampSDK alsaLib librdf_raptor librdf_rasqal redland <ins> pkgconfig </ins> # optional jackaudio # portaudio


Question:
Any local users can talk to locally running X server by default. That includes sending keyboard/mouse events, popping windows, etc. Log in as into a host running an X server under , and run I think normally you should have to do something like before you're able to talk to 's X server. System: NixOS: nix-shell -p xorg.xmessage --command xmessage test Nix version: nix-env (Nix) 1.11.2 Nixpkgs version:
Thanks, amazing nobody has spotted this before. The flag has been present ever since (when it at least had a comment about being bad idea...).
:+1:

description = "View and analyse contents of music audio files"; homepage = http://www.sonicvisualiser.org/; license = "GPLv2"; <del> maintainers = [ stdenv.lib.maintainers.marcweber stdenv.lib.maintainers.goibhniu ]; </del> <ins> maintainers = [ stdenv.lib.maintainers.marcweber stdenv.lib.maintainers.goibhniu ]; </ins> platforms = stdenv.lib.platforms.linux; }; }


Question:
YouTube tabs reliably crash within a few minutes on nixpkgs-built firefox Steps to reproduce the behavior: firefox from latest (NixOS/nixpkgs to some youtube user's video list up and down for a bit This doesn't happen with my previous env (using firefox 92.0.1, I think NixOS/nixpkgs but I haven't confirmed), nor with . It does happen with . Also, the page is not available on the nixpkgs-built firefox. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
I think it happens when you hover over a video and it starts showing the preview.
Yep that does it!
Possibly this bug?
Seems familiar. Will try the fix they suggest.
Note that in bisecting I've found a commit with the same version of ff but not this bug.
I don't think it's the same bug, I'm able to watch both linked videos (as long as I don't mouse-over a preview on the side)
It's happening for me as well, not sure why though
Not happening with firefox-bin 94.0
As said in the issue it doesn't happen with firefox-bin at all (also checked that myself) (also not 94.0.1)
Also happening for me (using nixpkgs.firefox).
Hotlinking directly to webp files also recreates the issue. That should narrow it down a bit. [edit: I guess these links expire after some time, but its just the url to an animated youtube thumbnail]
Also works on firefox-bin 94.0.1 (master is on 94.0).
Seeing crash locally as well on and . I bisected down to (had to apply to avoid build failures). It is a merge commit with the following conflict resolution:
While at it how does one get meaningful debug symbols out of firefox? is very sad: I tried patching in the below, but got no symbols: Is there a generic way to get the symbols? Or maybe it's a good opportunity to add them to specifically?
I tried reverting , still broken. Worked when 94.0.1 was merged in .
Yeah, I have no idea on how to accomplish that either. And having that could be really helpful :+1:
I can confirm this occurs when mousing over YouTube video link/thumbnail pairs in either the main page, search results or video sidebar (on Firefox 94.0.1). Not only that but doesn't exist at all, which probably means the crash reporting feature is entirely disabled for nixpkgs Firefox?
With the stdenv patch, does ff work on both parents of the merge commit but not the commit itself?
we have crashreporter turned off by default for some reason
its been that way since (2008) we should set it to
Crash report: https://crash-
correct. Re-tested again just in case: ^0: - crash ^1: - ok ^2: - ok ^3: <invalid, only 2 parentsNote that these two branches contain about 2 weeks of commits. One of them is a update, another is an update. This merge mixes both together and firefox does not seem to work. is a full picture of all the commits involved. Anecdotally I tried to disable lto with and got working (but I suspect it also flips to in that case). Would be nice if controlled just aspect and not the rest of toolchain.
Although using is possible for LTO ultimately it complicates the expression and deviates from upstream. When I implemented support for LTO, I think it was agreed upon that we should try to follow upstream as close as possible. Hence enforcing and . The reduced maintenance burden of having to test more configurations was also a plus. That being said it would be nice if someone wants to take on that burden and expand the LTO support to be more general (and maintain it). The end goal was to actually change to build to using too but allow the native system linker. I never got around to implementing that. The reasoning being upstream tests vigorously against . This is speculation on my part but I think a point of interest here is Firefox now builds against instead of . Building with was never a requirement for LTO but a side effect of the old stdenv. At the time did not have a proper nixpkgs wrapper script and was unable to be used outside of it. (On a side note, for some reason had issues during linking with not being configured to pull in LLVM's hence the workaround. It can be removed now since is being used.) reports (about:buildconfig) being built with LLVM 12 and rustc 1.55 so this might be a new bug introduced with LLVM 13 or the newer rustc. A definitive way to test if it is a bug in the switch to would be keeping the same firefox version and having applied (so is used) but change the underlying LLVM and rustc versions to 12 and 1.55 respectively. If the crash goes away then it is tied to the LLVM and rustc version if not then something wrong is happening when using .
I created a upstream bug 3 days ago, including stack backtrace with symbols. The crash function is in . Disabling webp () can mitigate but it of course quite hurt. :disappointed: If anyone gets more information, please also post in the bug thread. BTW: Enabling debug symbols need to set configure flags and set . won't work due to .
It is mentioned in that bug report that directly opening links canot reproduce the crash. I actually had the opposite experience. I was able to recreate the crash by directly opening a webp file, although it's not 100% consistent. I also stumbled across this other URL that crashes firefox, this one is a PNG. If I right-click this URL and "Open in new window" the tab will crash about 50% of the time. Curiously, this URL seems unaffected, despite the resulting file being hash-identical. !
I just now noticed that the above image is being served with a content-type, so looks like its still webp-specific, even though no webp content is being actually rendered.
I cannot reproduce with that URL at all after tens of tries. This DOES crash me sometimes. And note that the URL actually responds a WEBP image despite it contains , maybe due to HTTP fields. You can confirm it by the tab title (once you don't crash) or download and check with . This is also fine for me. It's more complex than I think. I'll guess it might be an index-out-of-bound or other kind of heap corruption? Could you post about this in my bugzilla report?
Can you share exact change needed? Here is my non-working example of enabling the symbols:
Yeah, whatever optimization tricks is doing here is just confusing things. I'm going to ignore those results for now. I was able to create a very small poc for the bug that works reliably with the same image, though. (Also posted in the bugzilla thread)
For how to build with debug symbols, see I'm still working on this issue now and I'll make a PR about that later. Note that you need to follow and set environment before starting or .
This is happening for me.
See
the in the first post is a typo, right? If I read it right, we can keep stable nixpkgs as it is, thanks to using LLVM 12 for firefox.
Yes, updated.

, ltoSupport ? (stdenv.isLinux && stdenv.is64bit), overrideCC, buildPackages , gssSupport ? true, libkrb5 , pipewireSupport ? waylandSupport && webrtcSupport, pipewire <del> , jemallocSupport ? true, jemalloc </del> <ins> # Workaround: disabled since currently jemalloc causes crashes with LLVM 13. # https://bugzilla.mozilla.org/show_bug.cgi?id=1741454 , jemallocSupport ? false, jemalloc </ins> ## privacy-related options


Question:
YouTube tabs reliably crash within a few minutes on nixpkgs-built firefox Steps to reproduce the behavior: firefox from latest (NixOS/nixpkgs to some youtube user's video list up and down for a bit This doesn't happen with my previous env (using firefox 92.0.1, I think NixOS/nixpkgs but I haven't confirmed), nor with . It does happen with . Also, the page is not available on the nixpkgs-built firefox. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
I think it happens when you hover over a video and it starts showing the preview.
Yep that does it!
Possibly this bug?
Seems familiar. Will try the fix they suggest.
Note that in bisecting I've found a commit with the same version of ff but not this bug.
I don't think it's the same bug, I'm able to watch both linked videos (as long as I don't mouse-over a preview on the side)
It's happening for me as well, not sure why though
Not happening with firefox-bin 94.0
As said in the issue it doesn't happen with firefox-bin at all (also checked that myself) (also not 94.0.1)
Also happening for me (using nixpkgs.firefox).
Hotlinking directly to webp files also recreates the issue. That should narrow it down a bit. [edit: I guess these links expire after some time, but its just the url to an animated youtube thumbnail]
Also works on firefox-bin 94.0.1 (master is on 94.0).
Seeing crash locally as well on and . I bisected down to (had to apply to avoid build failures). It is a merge commit with the following conflict resolution:
While at it how does one get meaningful debug symbols out of firefox? is very sad: I tried patching in the below, but got no symbols: Is there a generic way to get the symbols? Or maybe it's a good opportunity to add them to specifically?
I tried reverting , still broken. Worked when 94.0.1 was merged in .
Yeah, I have no idea on how to accomplish that either. And having that could be really helpful :+1:
I can confirm this occurs when mousing over YouTube video link/thumbnail pairs in either the main page, search results or video sidebar (on Firefox 94.0.1). Not only that but doesn't exist at all, which probably means the crash reporting feature is entirely disabled for nixpkgs Firefox?
With the stdenv patch, does ff work on both parents of the merge commit but not the commit itself?
we have crashreporter turned off by default for some reason
its been that way since (2008) we should set it to
Crash report: https://crash-
correct. Re-tested again just in case: ^0: - crash ^1: - ok ^2: - ok ^3: <invalid, only 2 parentsNote that these two branches contain about 2 weeks of commits. One of them is a update, another is an update. This merge mixes both together and firefox does not seem to work. is a full picture of all the commits involved. Anecdotally I tried to disable lto with and got working (but I suspect it also flips to in that case). Would be nice if controlled just aspect and not the rest of toolchain.
Although using is possible for LTO ultimately it complicates the expression and deviates from upstream. When I implemented support for LTO, I think it was agreed upon that we should try to follow upstream as close as possible. Hence enforcing and . The reduced maintenance burden of having to test more configurations was also a plus. That being said it would be nice if someone wants to take on that burden and expand the LTO support to be more general (and maintain it). The end goal was to actually change to build to using too but allow the native system linker. I never got around to implementing that. The reasoning being upstream tests vigorously against . This is speculation on my part but I think a point of interest here is Firefox now builds against instead of . Building with was never a requirement for LTO but a side effect of the old stdenv. At the time did not have a proper nixpkgs wrapper script and was unable to be used outside of it. (On a side note, for some reason had issues during linking with not being configured to pull in LLVM's hence the workaround. It can be removed now since is being used.) reports (about:buildconfig) being built with LLVM 12 and rustc 1.55 so this might be a new bug introduced with LLVM 13 or the newer rustc. A definitive way to test if it is a bug in the switch to would be keeping the same firefox version and having applied (so is used) but change the underlying LLVM and rustc versions to 12 and 1.55 respectively. If the crash goes away then it is tied to the LLVM and rustc version if not then something wrong is happening when using .
I created a upstream bug 3 days ago, including stack backtrace with symbols. The crash function is in . Disabling webp () can mitigate but it of course quite hurt. :disappointed: If anyone gets more information, please also post in the bug thread. BTW: Enabling debug symbols need to set configure flags and set . won't work due to .
It is mentioned in that bug report that directly opening links canot reproduce the crash. I actually had the opposite experience. I was able to recreate the crash by directly opening a webp file, although it's not 100% consistent. I also stumbled across this other URL that crashes firefox, this one is a PNG. If I right-click this URL and "Open in new window" the tab will crash about 50% of the time. Curiously, this URL seems unaffected, despite the resulting file being hash-identical. !
I just now noticed that the above image is being served with a content-type, so looks like its still webp-specific, even though no webp content is being actually rendered.
I cannot reproduce with that URL at all after tens of tries. This DOES crash me sometimes. And note that the URL actually responds a WEBP image despite it contains , maybe due to HTTP fields. You can confirm it by the tab title (once you don't crash) or download and check with . This is also fine for me. It's more complex than I think. I'll guess it might be an index-out-of-bound or other kind of heap corruption? Could you post about this in my bugzilla report?
Can you share exact change needed? Here is my non-working example of enabling the symbols:
Yeah, whatever optimization tricks is doing here is just confusing things. I'm going to ignore those results for now. I was able to create a very small poc for the bug that works reliably with the same image, though. (Also posted in the bugzilla thread)
For how to build with debug symbols, see I'm still working on this issue now and I'll make a PR about that later. Note that you need to follow and set environment before starting or .
This is happening for me.
See
the in the first post is a typo, right? If I read it right, we can keep stable nixpkgs as it is, thanks to using LLVM 12 for firefox.
Yes, updated.

# > the experience of Firefox users, you won't have any issues using the # > official branding. , enableOfficialBranding ? true <ins> # On 32bit platforms, we disable adding "-g" for easier linking. , enableDebugSymbols ? !stdenv.is32bit </ins> }: assert stdenv.cc.libc or null != null;


Question:
YouTube tabs reliably crash within a few minutes on nixpkgs-built firefox Steps to reproduce the behavior: firefox from latest (NixOS/nixpkgs to some youtube user's video list up and down for a bit This doesn't happen with my previous env (using firefox 92.0.1, I think NixOS/nixpkgs but I haven't confirmed), nor with . It does happen with . Also, the page is not available on the nixpkgs-built firefox. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
I think it happens when you hover over a video and it starts showing the preview.
Yep that does it!
Possibly this bug?
Seems familiar. Will try the fix they suggest.
Note that in bisecting I've found a commit with the same version of ff but not this bug.
I don't think it's the same bug, I'm able to watch both linked videos (as long as I don't mouse-over a preview on the side)
It's happening for me as well, not sure why though
Not happening with firefox-bin 94.0
As said in the issue it doesn't happen with firefox-bin at all (also checked that myself) (also not 94.0.1)
Also happening for me (using nixpkgs.firefox).
Hotlinking directly to webp files also recreates the issue. That should narrow it down a bit. [edit: I guess these links expire after some time, but its just the url to an animated youtube thumbnail]
Also works on firefox-bin 94.0.1 (master is on 94.0).
Seeing crash locally as well on and . I bisected down to (had to apply to avoid build failures). It is a merge commit with the following conflict resolution:
While at it how does one get meaningful debug symbols out of firefox? is very sad: I tried patching in the below, but got no symbols: Is there a generic way to get the symbols? Or maybe it's a good opportunity to add them to specifically?
I tried reverting , still broken. Worked when 94.0.1 was merged in .
Yeah, I have no idea on how to accomplish that either. And having that could be really helpful :+1:
I can confirm this occurs when mousing over YouTube video link/thumbnail pairs in either the main page, search results or video sidebar (on Firefox 94.0.1). Not only that but doesn't exist at all, which probably means the crash reporting feature is entirely disabled for nixpkgs Firefox?
With the stdenv patch, does ff work on both parents of the merge commit but not the commit itself?
we have crashreporter turned off by default for some reason
its been that way since (2008) we should set it to
Crash report: https://crash-
correct. Re-tested again just in case: ^0: - crash ^1: - ok ^2: - ok ^3: <invalid, only 2 parentsNote that these two branches contain about 2 weeks of commits. One of them is a update, another is an update. This merge mixes both together and firefox does not seem to work. is a full picture of all the commits involved. Anecdotally I tried to disable lto with and got working (but I suspect it also flips to in that case). Would be nice if controlled just aspect and not the rest of toolchain.
Although using is possible for LTO ultimately it complicates the expression and deviates from upstream. When I implemented support for LTO, I think it was agreed upon that we should try to follow upstream as close as possible. Hence enforcing and . The reduced maintenance burden of having to test more configurations was also a plus. That being said it would be nice if someone wants to take on that burden and expand the LTO support to be more general (and maintain it). The end goal was to actually change to build to using too but allow the native system linker. I never got around to implementing that. The reasoning being upstream tests vigorously against . This is speculation on my part but I think a point of interest here is Firefox now builds against instead of . Building with was never a requirement for LTO but a side effect of the old stdenv. At the time did not have a proper nixpkgs wrapper script and was unable to be used outside of it. (On a side note, for some reason had issues during linking with not being configured to pull in LLVM's hence the workaround. It can be removed now since is being used.) reports (about:buildconfig) being built with LLVM 12 and rustc 1.55 so this might be a new bug introduced with LLVM 13 or the newer rustc. A definitive way to test if it is a bug in the switch to would be keeping the same firefox version and having applied (so is used) but change the underlying LLVM and rustc versions to 12 and 1.55 respectively. If the crash goes away then it is tied to the LLVM and rustc version if not then something wrong is happening when using .
I created a upstream bug 3 days ago, including stack backtrace with symbols. The crash function is in . Disabling webp () can mitigate but it of course quite hurt. :disappointed: If anyone gets more information, please also post in the bug thread. BTW: Enabling debug symbols need to set configure flags and set . won't work due to .
It is mentioned in that bug report that directly opening links canot reproduce the crash. I actually had the opposite experience. I was able to recreate the crash by directly opening a webp file, although it's not 100% consistent. I also stumbled across this other URL that crashes firefox, this one is a PNG. If I right-click this URL and "Open in new window" the tab will crash about 50% of the time. Curiously, this URL seems unaffected, despite the resulting file being hash-identical. !
I just now noticed that the above image is being served with a content-type, so looks like its still webp-specific, even though no webp content is being actually rendered.
I cannot reproduce with that URL at all after tens of tries. This DOES crash me sometimes. And note that the URL actually responds a WEBP image despite it contains , maybe due to HTTP fields. You can confirm it by the tab title (once you don't crash) or download and check with . This is also fine for me. It's more complex than I think. I'll guess it might be an index-out-of-bound or other kind of heap corruption? Could you post about this in my bugzilla report?
Can you share exact change needed? Here is my non-working example of enabling the symbols:
Yeah, whatever optimization tricks is doing here is just confusing things. I'm going to ignore those results for now. I was able to create a very small poc for the bug that works reliably with the same image, though. (Also posted in the bugzilla thread)
For how to build with debug symbols, see I'm still working on this issue now and I'll make a PR about that later. Note that you need to follow and set environment before starting or .
This is happening for me.
See
the in the first post is a typo, right? If I read it right, we can keep stable nixpkgs as it is, thanks to using LLVM 12 for firefox.
Yes, updated.

}) else stdenv; <del> # --enable-release adds -ffunction-sections & LTO that require a big amount of # RAM and the 32-bit memory space cannot handle that linking # We also disable adding "-g" for easier linking releaseFlags = if stdenv.is32bit then [ "--disable-release" "--disable-debug-symbols" ] else [ "--enable-release" ]; </del> in buildStdenv.mkDerivation ({


Question:
YouTube tabs reliably crash within a few minutes on nixpkgs-built firefox Steps to reproduce the behavior: firefox from latest (NixOS/nixpkgs to some youtube user's video list up and down for a bit This doesn't happen with my previous env (using firefox 92.0.1, I think NixOS/nixpkgs but I haven't confirmed), nor with . It does happen with . Also, the page is not available on the nixpkgs-built firefox. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
I think it happens when you hover over a video and it starts showing the preview.
Yep that does it!
Possibly this bug?
Seems familiar. Will try the fix they suggest.
Note that in bisecting I've found a commit with the same version of ff but not this bug.
I don't think it's the same bug, I'm able to watch both linked videos (as long as I don't mouse-over a preview on the side)
It's happening for me as well, not sure why though
Not happening with firefox-bin 94.0
As said in the issue it doesn't happen with firefox-bin at all (also checked that myself) (also not 94.0.1)
Also happening for me (using nixpkgs.firefox).
Hotlinking directly to webp files also recreates the issue. That should narrow it down a bit. [edit: I guess these links expire after some time, but its just the url to an animated youtube thumbnail]
Also works on firefox-bin 94.0.1 (master is on 94.0).
Seeing crash locally as well on and . I bisected down to (had to apply to avoid build failures). It is a merge commit with the following conflict resolution:
While at it how does one get meaningful debug symbols out of firefox? is very sad: I tried patching in the below, but got no symbols: Is there a generic way to get the symbols? Or maybe it's a good opportunity to add them to specifically?
I tried reverting , still broken. Worked when 94.0.1 was merged in .
Yeah, I have no idea on how to accomplish that either. And having that could be really helpful :+1:
I can confirm this occurs when mousing over YouTube video link/thumbnail pairs in either the main page, search results or video sidebar (on Firefox 94.0.1). Not only that but doesn't exist at all, which probably means the crash reporting feature is entirely disabled for nixpkgs Firefox?
With the stdenv patch, does ff work on both parents of the merge commit but not the commit itself?
we have crashreporter turned off by default for some reason
its been that way since (2008) we should set it to
Crash report: https://crash-
correct. Re-tested again just in case: ^0: - crash ^1: - ok ^2: - ok ^3: <invalid, only 2 parentsNote that these two branches contain about 2 weeks of commits. One of them is a update, another is an update. This merge mixes both together and firefox does not seem to work. is a full picture of all the commits involved. Anecdotally I tried to disable lto with and got working (but I suspect it also flips to in that case). Would be nice if controlled just aspect and not the rest of toolchain.
Although using is possible for LTO ultimately it complicates the expression and deviates from upstream. When I implemented support for LTO, I think it was agreed upon that we should try to follow upstream as close as possible. Hence enforcing and . The reduced maintenance burden of having to test more configurations was also a plus. That being said it would be nice if someone wants to take on that burden and expand the LTO support to be more general (and maintain it). The end goal was to actually change to build to using too but allow the native system linker. I never got around to implementing that. The reasoning being upstream tests vigorously against . This is speculation on my part but I think a point of interest here is Firefox now builds against instead of . Building with was never a requirement for LTO but a side effect of the old stdenv. At the time did not have a proper nixpkgs wrapper script and was unable to be used outside of it. (On a side note, for some reason had issues during linking with not being configured to pull in LLVM's hence the workaround. It can be removed now since is being used.) reports (about:buildconfig) being built with LLVM 12 and rustc 1.55 so this might be a new bug introduced with LLVM 13 or the newer rustc. A definitive way to test if it is a bug in the switch to would be keeping the same firefox version and having applied (so is used) but change the underlying LLVM and rustc versions to 12 and 1.55 respectively. If the crash goes away then it is tied to the LLVM and rustc version if not then something wrong is happening when using .
I created a upstream bug 3 days ago, including stack backtrace with symbols. The crash function is in . Disabling webp () can mitigate but it of course quite hurt. :disappointed: If anyone gets more information, please also post in the bug thread. BTW: Enabling debug symbols need to set configure flags and set . won't work due to .
It is mentioned in that bug report that directly opening links canot reproduce the crash. I actually had the opposite experience. I was able to recreate the crash by directly opening a webp file, although it's not 100% consistent. I also stumbled across this other URL that crashes firefox, this one is a PNG. If I right-click this URL and "Open in new window" the tab will crash about 50% of the time. Curiously, this URL seems unaffected, despite the resulting file being hash-identical. !
I just now noticed that the above image is being served with a content-type, so looks like its still webp-specific, even though no webp content is being actually rendered.
I cannot reproduce with that URL at all after tens of tries. This DOES crash me sometimes. And note that the URL actually responds a WEBP image despite it contains , maybe due to HTTP fields. You can confirm it by the tab title (once you don't crash) or download and check with . This is also fine for me. It's more complex than I think. I'll guess it might be an index-out-of-bound or other kind of heap corruption? Could you post about this in my bugzilla report?
Can you share exact change needed? Here is my non-working example of enabling the symbols:
Yeah, whatever optimization tricks is doing here is just confusing things. I'm going to ignore those results for now. I was able to create a very small poc for the bug that works reliably with the same image, though. (Also posted in the bugzilla thread)
For how to build with debug symbols, see I'm still working on this issue now and I'll make a PR about that later. Note that you need to follow and set environment before starting or .
This is happening for me.
See
the in the first post is a typo, right? If I read it right, we can keep stable nixpkgs as it is, thanks to using LLVM 12 for firefox.
Yes, updated.

AVFoundation MediaToolbox CoreLocation Foundation libobjc AddressBook cups ]; <del> NIX_LDFLAGS = lib.optionalString ltoSupport '' -rpath ${llvmPackages.libunwind.out}/lib ''; </del> MACH_USE_SYSTEM_PYTHON = "1"; postPatch = ''


Question:
YouTube tabs reliably crash within a few minutes on nixpkgs-built firefox Steps to reproduce the behavior: firefox from latest (NixOS/nixpkgs to some youtube user's video list up and down for a bit This doesn't happen with my previous env (using firefox 92.0.1, I think NixOS/nixpkgs but I haven't confirmed), nor with . It does happen with . Also, the page is not available on the nixpkgs-built firefox. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
I think it happens when you hover over a video and it starts showing the preview.
Yep that does it!
Possibly this bug?
Seems familiar. Will try the fix they suggest.
Note that in bisecting I've found a commit with the same version of ff but not this bug.
I don't think it's the same bug, I'm able to watch both linked videos (as long as I don't mouse-over a preview on the side)
It's happening for me as well, not sure why though
Not happening with firefox-bin 94.0
As said in the issue it doesn't happen with firefox-bin at all (also checked that myself) (also not 94.0.1)
Also happening for me (using nixpkgs.firefox).
Hotlinking directly to webp files also recreates the issue. That should narrow it down a bit. [edit: I guess these links expire after some time, but its just the url to an animated youtube thumbnail]
Also works on firefox-bin 94.0.1 (master is on 94.0).
Seeing crash locally as well on and . I bisected down to (had to apply to avoid build failures). It is a merge commit with the following conflict resolution:
While at it how does one get meaningful debug symbols out of firefox? is very sad: I tried patching in the below, but got no symbols: Is there a generic way to get the symbols? Or maybe it's a good opportunity to add them to specifically?
I tried reverting , still broken. Worked when 94.0.1 was merged in .
Yeah, I have no idea on how to accomplish that either. And having that could be really helpful :+1:
I can confirm this occurs when mousing over YouTube video link/thumbnail pairs in either the main page, search results or video sidebar (on Firefox 94.0.1). Not only that but doesn't exist at all, which probably means the crash reporting feature is entirely disabled for nixpkgs Firefox?
With the stdenv patch, does ff work on both parents of the merge commit but not the commit itself?
we have crashreporter turned off by default for some reason
its been that way since (2008) we should set it to
Crash report: https://crash-
correct. Re-tested again just in case: ^0: - crash ^1: - ok ^2: - ok ^3: <invalid, only 2 parentsNote that these two branches contain about 2 weeks of commits. One of them is a update, another is an update. This merge mixes both together and firefox does not seem to work. is a full picture of all the commits involved. Anecdotally I tried to disable lto with and got working (but I suspect it also flips to in that case). Would be nice if controlled just aspect and not the rest of toolchain.
Although using is possible for LTO ultimately it complicates the expression and deviates from upstream. When I implemented support for LTO, I think it was agreed upon that we should try to follow upstream as close as possible. Hence enforcing and . The reduced maintenance burden of having to test more configurations was also a plus. That being said it would be nice if someone wants to take on that burden and expand the LTO support to be more general (and maintain it). The end goal was to actually change to build to using too but allow the native system linker. I never got around to implementing that. The reasoning being upstream tests vigorously against . This is speculation on my part but I think a point of interest here is Firefox now builds against instead of . Building with was never a requirement for LTO but a side effect of the old stdenv. At the time did not have a proper nixpkgs wrapper script and was unable to be used outside of it. (On a side note, for some reason had issues during linking with not being configured to pull in LLVM's hence the workaround. It can be removed now since is being used.) reports (about:buildconfig) being built with LLVM 12 and rustc 1.55 so this might be a new bug introduced with LLVM 13 or the newer rustc. A definitive way to test if it is a bug in the switch to would be keeping the same firefox version and having applied (so is used) but change the underlying LLVM and rustc versions to 12 and 1.55 respectively. If the crash goes away then it is tied to the LLVM and rustc version if not then something wrong is happening when using .
I created a upstream bug 3 days ago, including stack backtrace with symbols. The crash function is in . Disabling webp () can mitigate but it of course quite hurt. :disappointed: If anyone gets more information, please also post in the bug thread. BTW: Enabling debug symbols need to set configure flags and set . won't work due to .
It is mentioned in that bug report that directly opening links canot reproduce the crash. I actually had the opposite experience. I was able to recreate the crash by directly opening a webp file, although it's not 100% consistent. I also stumbled across this other URL that crashes firefox, this one is a PNG. If I right-click this URL and "Open in new window" the tab will crash about 50% of the time. Curiously, this URL seems unaffected, despite the resulting file being hash-identical. !
I just now noticed that the above image is being served with a content-type, so looks like its still webp-specific, even though no webp content is being actually rendered.
I cannot reproduce with that URL at all after tens of tries. This DOES crash me sometimes. And note that the URL actually responds a WEBP image despite it contains , maybe due to HTTP fields. You can confirm it by the tab title (once you don't crash) or download and check with . This is also fine for me. It's more complex than I think. I'll guess it might be an index-out-of-bound or other kind of heap corruption? Could you post about this in my bugzilla report?
Can you share exact change needed? Here is my non-working example of enabling the symbols:
Yeah, whatever optimization tricks is doing here is just confusing things. I'm going to ignore those results for now. I was able to create a very small poc for the bug that works reliably with the same image, though. (Also posted in the bugzilla thread)
For how to build with debug symbols, see I'm still working on this issue now and I'll make a PR about that later. Note that you need to follow and set environment before starting or .
This is happening for me.
See
the in the first post is a typo, right? If I read it right, we can keep stable nixpkgs as it is, thanks to using LLVM 12 for firefox.
Yes, updated.

++ lib.optionals buildStdenv.isDarwin [ xcbuild rsync ] ++ extraNativeBuildInputs; <ins> separateDebugInfo = enableDebugSymbols; setOutputFlags = false; # `./mach configure` doesn't understand `--*dir=` flags. </ins> preConfigure = '' # remove distributed configuration files rm -f configure


Question:
YouTube tabs reliably crash within a few minutes on nixpkgs-built firefox Steps to reproduce the behavior: firefox from latest (NixOS/nixpkgs to some youtube user's video list up and down for a bit This doesn't happen with my previous env (using firefox 92.0.1, I think NixOS/nixpkgs but I haven't confirmed), nor with . It does happen with . Also, the page is not available on the nixpkgs-built firefox. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
I think it happens when you hover over a video and it starts showing the preview.
Yep that does it!
Possibly this bug?
Seems familiar. Will try the fix they suggest.
Note that in bisecting I've found a commit with the same version of ff but not this bug.
I don't think it's the same bug, I'm able to watch both linked videos (as long as I don't mouse-over a preview on the side)
It's happening for me as well, not sure why though
Not happening with firefox-bin 94.0
As said in the issue it doesn't happen with firefox-bin at all (also checked that myself) (also not 94.0.1)
Also happening for me (using nixpkgs.firefox).
Hotlinking directly to webp files also recreates the issue. That should narrow it down a bit. [edit: I guess these links expire after some time, but its just the url to an animated youtube thumbnail]
Also works on firefox-bin 94.0.1 (master is on 94.0).
Seeing crash locally as well on and . I bisected down to (had to apply to avoid build failures). It is a merge commit with the following conflict resolution:
While at it how does one get meaningful debug symbols out of firefox? is very sad: I tried patching in the below, but got no symbols: Is there a generic way to get the symbols? Or maybe it's a good opportunity to add them to specifically?
I tried reverting , still broken. Worked when 94.0.1 was merged in .
Yeah, I have no idea on how to accomplish that either. And having that could be really helpful :+1:
I can confirm this occurs when mousing over YouTube video link/thumbnail pairs in either the main page, search results or video sidebar (on Firefox 94.0.1). Not only that but doesn't exist at all, which probably means the crash reporting feature is entirely disabled for nixpkgs Firefox?
With the stdenv patch, does ff work on both parents of the merge commit but not the commit itself?
we have crashreporter turned off by default for some reason
its been that way since (2008) we should set it to
Crash report: https://crash-
correct. Re-tested again just in case: ^0: - crash ^1: - ok ^2: - ok ^3: <invalid, only 2 parentsNote that these two branches contain about 2 weeks of commits. One of them is a update, another is an update. This merge mixes both together and firefox does not seem to work. is a full picture of all the commits involved. Anecdotally I tried to disable lto with and got working (but I suspect it also flips to in that case). Would be nice if controlled just aspect and not the rest of toolchain.
Although using is possible for LTO ultimately it complicates the expression and deviates from upstream. When I implemented support for LTO, I think it was agreed upon that we should try to follow upstream as close as possible. Hence enforcing and . The reduced maintenance burden of having to test more configurations was also a plus. That being said it would be nice if someone wants to take on that burden and expand the LTO support to be more general (and maintain it). The end goal was to actually change to build to using too but allow the native system linker. I never got around to implementing that. The reasoning being upstream tests vigorously against . This is speculation on my part but I think a point of interest here is Firefox now builds against instead of . Building with was never a requirement for LTO but a side effect of the old stdenv. At the time did not have a proper nixpkgs wrapper script and was unable to be used outside of it. (On a side note, for some reason had issues during linking with not being configured to pull in LLVM's hence the workaround. It can be removed now since is being used.) reports (about:buildconfig) being built with LLVM 12 and rustc 1.55 so this might be a new bug introduced with LLVM 13 or the newer rustc. A definitive way to test if it is a bug in the switch to would be keeping the same firefox version and having applied (so is used) but change the underlying LLVM and rustc versions to 12 and 1.55 respectively. If the crash goes away then it is tied to the LLVM and rustc version if not then something wrong is happening when using .
I created a upstream bug 3 days ago, including stack backtrace with symbols. The crash function is in . Disabling webp () can mitigate but it of course quite hurt. :disappointed: If anyone gets more information, please also post in the bug thread. BTW: Enabling debug symbols need to set configure flags and set . won't work due to .
It is mentioned in that bug report that directly opening links canot reproduce the crash. I actually had the opposite experience. I was able to recreate the crash by directly opening a webp file, although it's not 100% consistent. I also stumbled across this other URL that crashes firefox, this one is a PNG. If I right-click this URL and "Open in new window" the tab will crash about 50% of the time. Curiously, this URL seems unaffected, despite the resulting file being hash-identical. !
I just now noticed that the above image is being served with a content-type, so looks like its still webp-specific, even though no webp content is being actually rendered.
I cannot reproduce with that URL at all after tens of tries. This DOES crash me sometimes. And note that the URL actually responds a WEBP image despite it contains , maybe due to HTTP fields. You can confirm it by the tab title (once you don't crash) or download and check with . This is also fine for me. It's more complex than I think. I'll guess it might be an index-out-of-bound or other kind of heap corruption? Could you post about this in my bugzilla report?
Can you share exact change needed? Here is my non-working example of enabling the symbols:
Yeah, whatever optimization tricks is doing here is just confusing things. I'm going to ignore those results for now. I was able to create a very small poc for the bug that works reliably with the same image, though. (Also posted in the bugzilla thread)
For how to build with debug symbols, see I'm still working on this issue now and I'll make a PR about that later. Note that you need to follow and set environment before starting or .
This is happening for me.
See
the in the first post is a typo, right? If I read it right, we can keep stable nixpkgs as it is, thanks to using LLVM 12 for firefox.
Yes, updated.

${lib.optionalString buildStdenv.cc.isClang "-idirafter ${buildStdenv.cc.cc.lib}/lib/clang/${lib.getVersion buildStdenv.cc.cc}/include"}  ${lib.optionalString buildStdenv.cc.isGNU "-isystem ${lib.getDev buildStdenv.cc.cc}/include/c++/${lib.getVersion buildStdenv.cc.cc} -isystem ${buildStdenv.cc.cc}/include/c++/${lib.getVersion buildStdenv.cc.cc}/${buildStdenv.hostPlatform.config}"}  $NIX_CFLAGS_COMPILE" <ins> ${ # Bindgen doesn't like the flag added by `separateDebugInfo`. lib.optionalString enableDebugSymbols '' BINDGEN_CFLAGS="''${BINDGEN_CFLAGS/ -Wa,--compress-debug-sections/}" ''} </ins> echo "ac_add_options BINDGEN_CFLAGS='$BINDGEN_CFLAGS'" >> $MOZCONFIG '' + (lib.optionalString googleAPISupport '' # Google API key used by Chromium and Firefox.


Question:
YouTube tabs reliably crash within a few minutes on nixpkgs-built firefox Steps to reproduce the behavior: firefox from latest (NixOS/nixpkgs to some youtube user's video list up and down for a bit This doesn't happen with my previous env (using firefox 92.0.1, I think NixOS/nixpkgs but I haven't confirmed), nor with . It does happen with . Also, the page is not available on the nixpkgs-built firefox. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
I think it happens when you hover over a video and it starts showing the preview.
Yep that does it!
Possibly this bug?
Seems familiar. Will try the fix they suggest.
Note that in bisecting I've found a commit with the same version of ff but not this bug.
I don't think it's the same bug, I'm able to watch both linked videos (as long as I don't mouse-over a preview on the side)
It's happening for me as well, not sure why though
Not happening with firefox-bin 94.0
As said in the issue it doesn't happen with firefox-bin at all (also checked that myself) (also not 94.0.1)
Also happening for me (using nixpkgs.firefox).
Hotlinking directly to webp files also recreates the issue. That should narrow it down a bit. [edit: I guess these links expire after some time, but its just the url to an animated youtube thumbnail]
Also works on firefox-bin 94.0.1 (master is on 94.0).
Seeing crash locally as well on and . I bisected down to (had to apply to avoid build failures). It is a merge commit with the following conflict resolution:
While at it how does one get meaningful debug symbols out of firefox? is very sad: I tried patching in the below, but got no symbols: Is there a generic way to get the symbols? Or maybe it's a good opportunity to add them to specifically?
I tried reverting , still broken. Worked when 94.0.1 was merged in .
Yeah, I have no idea on how to accomplish that either. And having that could be really helpful :+1:
I can confirm this occurs when mousing over YouTube video link/thumbnail pairs in either the main page, search results or video sidebar (on Firefox 94.0.1). Not only that but doesn't exist at all, which probably means the crash reporting feature is entirely disabled for nixpkgs Firefox?
With the stdenv patch, does ff work on both parents of the merge commit but not the commit itself?
we have crashreporter turned off by default for some reason
its been that way since (2008) we should set it to
Crash report: https://crash-
correct. Re-tested again just in case: ^0: - crash ^1: - ok ^2: - ok ^3: <invalid, only 2 parentsNote that these two branches contain about 2 weeks of commits. One of them is a update, another is an update. This merge mixes both together and firefox does not seem to work. is a full picture of all the commits involved. Anecdotally I tried to disable lto with and got working (but I suspect it also flips to in that case). Would be nice if controlled just aspect and not the rest of toolchain.
Although using is possible for LTO ultimately it complicates the expression and deviates from upstream. When I implemented support for LTO, I think it was agreed upon that we should try to follow upstream as close as possible. Hence enforcing and . The reduced maintenance burden of having to test more configurations was also a plus. That being said it would be nice if someone wants to take on that burden and expand the LTO support to be more general (and maintain it). The end goal was to actually change to build to using too but allow the native system linker. I never got around to implementing that. The reasoning being upstream tests vigorously against . This is speculation on my part but I think a point of interest here is Firefox now builds against instead of . Building with was never a requirement for LTO but a side effect of the old stdenv. At the time did not have a proper nixpkgs wrapper script and was unable to be used outside of it. (On a side note, for some reason had issues during linking with not being configured to pull in LLVM's hence the workaround. It can be removed now since is being used.) reports (about:buildconfig) being built with LLVM 12 and rustc 1.55 so this might be a new bug introduced with LLVM 13 or the newer rustc. A definitive way to test if it is a bug in the switch to would be keeping the same firefox version and having applied (so is used) but change the underlying LLVM and rustc versions to 12 and 1.55 respectively. If the crash goes away then it is tied to the LLVM and rustc version if not then something wrong is happening when using .
I created a upstream bug 3 days ago, including stack backtrace with symbols. The crash function is in . Disabling webp () can mitigate but it of course quite hurt. :disappointed: If anyone gets more information, please also post in the bug thread. BTW: Enabling debug symbols need to set configure flags and set . won't work due to .
It is mentioned in that bug report that directly opening links canot reproduce the crash. I actually had the opposite experience. I was able to recreate the crash by directly opening a webp file, although it's not 100% consistent. I also stumbled across this other URL that crashes firefox, this one is a PNG. If I right-click this URL and "Open in new window" the tab will crash about 50% of the time. Curiously, this URL seems unaffected, despite the resulting file being hash-identical. !
I just now noticed that the above image is being served with a content-type, so looks like its still webp-specific, even though no webp content is being actually rendered.
I cannot reproduce with that URL at all after tens of tries. This DOES crash me sometimes. And note that the URL actually responds a WEBP image despite it contains , maybe due to HTTP fields. You can confirm it by the tab title (once you don't crash) or download and check with . This is also fine for me. It's more complex than I think. I'll guess it might be an index-out-of-bound or other kind of heap corruption? Could you post about this in my bugzilla report?
Can you share exact change needed? Here is my non-working example of enabling the symbols:
Yeah, whatever optimization tricks is doing here is just confusing things. I'm going to ignore those results for now. I was able to create a very small poc for the bug that works reliably with the same image, though. (Also posted in the bugzilla thread)
For how to build with debug symbols, see I'm still working on this issue now and I'll make a PR about that later. Note that you need to follow and set environment before starting or .
This is happening for me.
See
the in the first post is a typo, right? If I read it right, we can keep stable nixpkgs as it is, thanks to using LLVM 12 for firefox.
Yes, updated.

#   https://bugzilla.mozilla.org/show_bug.cgi?id=1538724 # elf-hack is broken when using clang+lld: #   https://bugzilla.mozilla.org/show_bug.cgi?id=1482204 <del> ++ lib.optional ltoSupport "--enable-lto" </del> <ins> ++ lib.optional ltoSupport "--enable-lto=cross" # Cross-language LTO. </ins> ++ lib.optional (ltoSupport && (buildStdenv.isAarch32 || buildStdenv.isi686 || buildStdenv.isx86_64)) "--disable-elf-hack" ++ lib.optional (ltoSupport && !buildStdenv.isDarwin) "--enable-linker=lld"


Question:
YouTube tabs reliably crash within a few minutes on nixpkgs-built firefox Steps to reproduce the behavior: firefox from latest (NixOS/nixpkgs to some youtube user's video list up and down for a bit This doesn't happen with my previous env (using firefox 92.0.1, I think NixOS/nixpkgs but I haven't confirmed), nor with . It does happen with . Also, the page is not available on the nixpkgs-built firefox. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
I think it happens when you hover over a video and it starts showing the preview.
Yep that does it!
Possibly this bug?
Seems familiar. Will try the fix they suggest.
Note that in bisecting I've found a commit with the same version of ff but not this bug.
I don't think it's the same bug, I'm able to watch both linked videos (as long as I don't mouse-over a preview on the side)
It's happening for me as well, not sure why though
Not happening with firefox-bin 94.0
As said in the issue it doesn't happen with firefox-bin at all (also checked that myself) (also not 94.0.1)
Also happening for me (using nixpkgs.firefox).
Hotlinking directly to webp files also recreates the issue. That should narrow it down a bit. [edit: I guess these links expire after some time, but its just the url to an animated youtube thumbnail]
Also works on firefox-bin 94.0.1 (master is on 94.0).
Seeing crash locally as well on and . I bisected down to (had to apply to avoid build failures). It is a merge commit with the following conflict resolution:
While at it how does one get meaningful debug symbols out of firefox? is very sad: I tried patching in the below, but got no symbols: Is there a generic way to get the symbols? Or maybe it's a good opportunity to add them to specifically?
I tried reverting , still broken. Worked when 94.0.1 was merged in .
Yeah, I have no idea on how to accomplish that either. And having that could be really helpful :+1:
I can confirm this occurs when mousing over YouTube video link/thumbnail pairs in either the main page, search results or video sidebar (on Firefox 94.0.1). Not only that but doesn't exist at all, which probably means the crash reporting feature is entirely disabled for nixpkgs Firefox?
With the stdenv patch, does ff work on both parents of the merge commit but not the commit itself?
we have crashreporter turned off by default for some reason
its been that way since (2008) we should set it to
Crash report: https://crash-
correct. Re-tested again just in case: ^0: - crash ^1: - ok ^2: - ok ^3: <invalid, only 2 parentsNote that these two branches contain about 2 weeks of commits. One of them is a update, another is an update. This merge mixes both together and firefox does not seem to work. is a full picture of all the commits involved. Anecdotally I tried to disable lto with and got working (but I suspect it also flips to in that case). Would be nice if controlled just aspect and not the rest of toolchain.
Although using is possible for LTO ultimately it complicates the expression and deviates from upstream. When I implemented support for LTO, I think it was agreed upon that we should try to follow upstream as close as possible. Hence enforcing and . The reduced maintenance burden of having to test more configurations was also a plus. That being said it would be nice if someone wants to take on that burden and expand the LTO support to be more general (and maintain it). The end goal was to actually change to build to using too but allow the native system linker. I never got around to implementing that. The reasoning being upstream tests vigorously against . This is speculation on my part but I think a point of interest here is Firefox now builds against instead of . Building with was never a requirement for LTO but a side effect of the old stdenv. At the time did not have a proper nixpkgs wrapper script and was unable to be used outside of it. (On a side note, for some reason had issues during linking with not being configured to pull in LLVM's hence the workaround. It can be removed now since is being used.) reports (about:buildconfig) being built with LLVM 12 and rustc 1.55 so this might be a new bug introduced with LLVM 13 or the newer rustc. A definitive way to test if it is a bug in the switch to would be keeping the same firefox version and having applied (so is used) but change the underlying LLVM and rustc versions to 12 and 1.55 respectively. If the crash goes away then it is tied to the LLVM and rustc version if not then something wrong is happening when using .
I created a upstream bug 3 days ago, including stack backtrace with symbols. The crash function is in . Disabling webp () can mitigate but it of course quite hurt. :disappointed: If anyone gets more information, please also post in the bug thread. BTW: Enabling debug symbols need to set configure flags and set . won't work due to .
It is mentioned in that bug report that directly opening links canot reproduce the crash. I actually had the opposite experience. I was able to recreate the crash by directly opening a webp file, although it's not 100% consistent. I also stumbled across this other URL that crashes firefox, this one is a PNG. If I right-click this URL and "Open in new window" the tab will crash about 50% of the time. Curiously, this URL seems unaffected, despite the resulting file being hash-identical. !
I just now noticed that the above image is being served with a content-type, so looks like its still webp-specific, even though no webp content is being actually rendered.
I cannot reproduce with that URL at all after tens of tries. This DOES crash me sometimes. And note that the URL actually responds a WEBP image despite it contains , maybe due to HTTP fields. You can confirm it by the tab title (once you don't crash) or download and check with . This is also fine for me. It's more complex than I think. I'll guess it might be an index-out-of-bound or other kind of heap corruption? Could you post about this in my bugzilla report?
Can you share exact change needed? Here is my non-working example of enabling the symbols:
Yeah, whatever optimization tricks is doing here is just confusing things. I'm going to ignore those results for now. I was able to create a very small poc for the bug that works reliably with the same image, though. (Also posted in the bugzilla thread)
For how to build with debug symbols, see I'm still working on this issue now and I'll make a PR about that later. Note that you need to follow and set environment before starting or .
This is happening for me.
See
the in the first post is a typo, right? If I read it right, we can keep stable nixpkgs as it is, thanks to using LLVM 12 for firefox.
Yes, updated.

++ lib.optional drmSupport "--enable-eme=widevine" ++ (if debugBuild then [ "--enable-debug" "--enable-profiling" ] <del> else ([ "--disable-debug" "--enable-optimize" "--enable-strip" ] ++ releaseFlags)) </del> <ins> else [ "--disable-debug" "--enable-optimize" ]) # --enable-release adds -ffunction-sections & LTO that require a big amount of # RAM and the 32-bit memory space cannot handle that linking ++ flag (!debugBuild && !stdenv.is32bit) "release" ++ flag enableDebugSymbols "debug-symbols" ++ lib.optionals enableDebugSymbols [ "--disable-strip" "--disable-install-strip" ] </ins> ++ lib.optional enableOfficialBranding "--enable-official-branding" ++ extraConfigureFlags;