jiebi/CodeConvo huggingface dataset:
Code change:
<del> { dpkg, fetchurl, lib, stdenv }: </del> <ins> { squashfsTools, fetchurl, lib, stdenv }: # This derivation roughly follows the update-ffmpeg script that ships with the official Vivaldi # downloads at https://vivaldi.com/download/ </ins> stdenv.mkDerivation rec { pname = "chromium-codecs-ffmpeg-extra"; <del> version = "112.0.5615.49"; </del> <ins> version = "111306"; </ins> src = fetchurl { <del> url = "https://launchpadlibrarian.net/660647727/${pname}_${version}-0ubuntu0.18.04.1_amd64.deb"; sha256 = "sha256-mHjvjRG+toRcsOMca+JPXNZPgyQROH2qtSpBPHLmt3s="; </del> <ins> url = "https://api.snapcraft.io/api/v1/snaps/download/XXzVIXswXKHqlUATPqGCj2w2l7BxosS8_34.snap"; sha256 = "sha256-Dna9yFgP7JeQLAeZWvSZ+eSMX2yQbX2/+mX0QC22lYY="; </ins> }; <del> buildInputs = [ dpkg ]; </del> <ins> buildInputs = [ squashfsTools ]; </ins> unpackPhase = '' <del> dpkg-deb -x $src . </del> <ins> unsquashfs -dest . $src </ins> ''; installPhase = '' <del> install -vD usr/lib/chromium-browser/libffmpeg.so $out/lib/libffmpeg.so </del> <ins> install -vD chromium-ffmpeg-${version}/chromium-ffmpeg/libffmpeg.so $out/lib/libffmpeg.so </ins> ''; meta = with lib; {

Related discussion:
text: Proprietary HTML5 videos break the whole site Workaround is to disable . Steps to reproduce the behavior: Vivaldi package with the package in your Configuration (home-manager) YouTube YouTube should display and the video should play. !
I hit this issue myself yesterday as well. I had reported it to Vivaldi before I realized it was indeed an outdated chromium-ffmpeg dependency. See . I wrote a PR at to fix this. For a quick fix, here's the code I have in my overlay to work around this straight away:
I just saw it. Thanks a lot! I will close this issue now as you already created an issue for discussion.
Code change:
<del> [ "twentynineteen" , "twentytwenty" , "twentytwentytwo" , "twentytwentyone" , "twentytwentythree" ] </del> <ins> { "twentynineteen": "gpl2Plus" , "twentytwenty": "gpl2Plus" , "twentytwentytwo": "gpl2Plus" , "twentytwentyone": "gpl2Plus" , "twentytwentythree": "gpl2Plus" } </ins>

Related discussion:
text: The package with that are automatically fetched carry no license. ` cc
Poking upstream does not seem to yield anything. They did indicate they wouldn't support this use case, so what are you expecting from them?
I talked to the authors of wp4nix and they are happy for new contributions. It would be nice if the wp4nix script would somehow handle license informations, for example by manually defining them. Not quite sure yet how to implement it
If we don't know the licenses to these packages we honestly cannot keep them around. For example, it is absolutely unclear, whether we have a license to even redistribute them. Of course upstream will take patches, but they're not exactly in the same boat we are. I think your attitude towards the whole licensing situation around wp4nix/nc4nix and its resulting packages is alarming.
As written : Fixing this for Wordpress packages and themes (wp4nix) and Nextcloud apps (nc4nix) in a foreseeable time exceeds my skills and competence. Therefore I would like to offer to add a flag to these package sets and remove them for the next release 23.11 if it's not resolved by then.
Couldn't we mark them as unfree so they don't get cached on hydra but people can still use them if they want? Unfortunately it seems like the wordpress plugins repository doesn't seem to provide the license information in an easy manner. And I don't know whether it is stored somewhere else or can even be extracted from the derivation without import-from-derivation.
Actuallly we seem to be safe in theory. claims
In an ideal world, that would hold true, but it is up to the user and distributor to validate the final outcome. I therefore think this situation remains unresolved.
Code change:
, lib , buildGoPackage , fetchFromGitHub <del> , openssl_1_0_2 </del> <ins> , openssl </ins> , pkgconfig , libpcap }:

Related discussion:
text: Upstream , but we still have many packages depending on it. I know of no issues since the last release, so I'm not marking it as vulnerable yet, but the dependents would better start migrating in advance. Stable: it's unclear to me what we do about these in 19.09, but perhaps there won't be any notable vulnerabilities before 19.09 support ends :-) 1.0.2 is the default in 19.03, but we don't support that anymore.
List of files:
I think we should mark it vulnerable. Other EOL packages have been marked vulnerable because of the EOL before, e.g. Firefox, and if there’s any package we should be extra-careful with, its OpenSSL.
I bumped it to fix the last CVE minutes before opening this ticket, so I was obviously biased against marking it immediately ;-)
BTW, it's still a decision to make, as there's surely some LTS distro that will keep shipping 1.0.2 for some time, so patching the worst probably won't be too difficult. I'm personally not willing to invest significant time into it, though :-)
Best way to motivate somebody to volunteer is to mark it as insecure. ;)
OK, I think the we've given enough time and now we should press on a bit:
Code change:
<ins> { lib, buildGoModule, fetchFromGitHub, }: buildGoModule rec { pname = "gorm-gentool"; version = "0.0.1"; src = fetchFromGitHub { owner = "go-gorm"; repo = "gen"; rev = "tools/gentool/v${version}"; hash = "sha256-JOecNYEIL8vbc7znkKbaSrTkGyAva3ZzKzxducDtTx0="; }; modRoot = "tools/gentool"; proxyVendor = true; vendorHash = "sha256-8xUJcsZuZ1KpFDM1AMTRggl7A7C/YaXYDzRKNFKE+ww="; meta = with lib; { homepage = "https://github.com/go-gorm/gen"; description = "Gen: Friendly & Safer GORM powered by Code Generation"; license = licenses.mit; mainProgram = "gentool"; maintainers = with maintainers; [tembleking]; }; } </ins>

Related discussion:
text: Project description Gorm is Golang ORM for SQL databases. Gen Tool is a single binary without dependencies can be used to generate structs from database. Metadata homepage URL: source URL: license: mit platforms: all? Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
stunnel = handleTest ./stunnel.nix {}; sudo = handleTest ./sudo.nix {}; sudo-rs = handleTest ./sudo-rs.nix {}; <ins> sunshine = handleTest ./sunshine.nix {}; </ins> suwayomi-server = handleTest ./suwayomi-server.nix {}; swap-file-btrfs = handleTest ./swap-file-btrfs.nix {}; swap-partition = handleTest ./swap-partition.nix {};

Related discussion:
text: Project description <!-- Describe the project a little: --Sunshine has already been packaged here in nixpkgs: But it doesn't come out of the box just by , according to and and , at least it needs a and maybe . It would be better if we could add a NixOS module for it to make it availale just by sth. like or . CC maintainer Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This has been on my to-do list for ages :) The module itself wouldn't be a huge deal, and I think I have a plan for tests, just need some time to work on it.
I actually started working on this a while ago. My module can create valid and files (i.e. they work when I start sunshine manually) and open the necessary ports, however I couldn't get the systemd service to function properly. If I recall correctly, the issue was related to getting access to the screen. Here is what I have so far, maybe it can help someone:
Thanks I used yours as inspiration and opened for this. It's still a draft -- I need to work on the tests -- but any testing or comments are welcome. I've tested on Plasma 6 + Wayland + AMD and seems to work, have not tested much with Xorg or NVIDIA.
Think it's got all the functionality I had planned -- marked as ready for review.
Code change:
notes</link> for details. </para> </listitem> <ins> <listitem> <para> Module authors can use <literal>mkRenamedOptionModuleWith</literal> to automate the deprecation cycle without annoying out-of-tree module authors and their users. </para> </listitem> </ins> </itemizedlist> </section> <section xml:id="sec-release-22.05-new-services">

Related discussion:
text: The current process for renames puts out-of-tree modules in a situation where users are confronted with warnings they can't solve, and neither can the maintainers. Steps to reproduce the behavior: one change, create the new option/package/..., create the alias with a deprecation warning that goes into effect immediately -of-tree modules, such as home-manager, nix-darwin, start emitting warnings reports warning -of-tree module maintainer can't do anything, because stable release does not have the new option All generated warnings can be resolved by the user. Suggested process: one change, create the new option/package/... and the alias but no deprecation warning 1-7 months pass. All current branches now support the new way. enable the warning on master (more on that) -of-tree modules, such as home-manager, nix-darwin, start emitting warnings warnings can now be fixed To facilitate the process, we can add an argument to functions like to indicate the first release that will support the change. We'll maintain two (hidden?) version numbers that we update during the NixOS release process. For example, at the time of writing, the only supported stable version is 21.11 and 22.05 has not been released yet. To enable warnings on , we only need to update . Interestingly, we'll be deprecating functions that deprecate without . Sounds meta, but it's not complicated. It just means that some old style deprecations will slip through the net for some more time. (also a big one, but no complaints yet)
This is also related to NixOS/rfcs, which was a previous attempt at establishing general such deprecation behaviors
Code change:
stdenvNoCC.mkDerivation rec { pname = "adw-gtk3"; <del> version = "5.4"; </del> <ins> version = "5.3"; </ins> src = fetchFromGitHub { owner = "lassekongo83"; repo = pname; rev = "v${version}"; <del> sha256 = "sha256-FwODgA3BK5O1WoNNbn27H18Epuqwcsnoc3hZUB59+Wg="; </del> <ins> sha256 = "sha256-DpJLX9PJX1Q8dDOx7YOXQzgNECsKp5uGiCVTX6iSlbI="; </ins> }; nativeBuildInputs = [

Related discussion:
text: In latest version of Adw-gtk3, window title bar on Electron-based app be weird transparent Steps to reproduce the behavior: Adw-gtk3 to latest version (from Nixpkgs) it as usual Electron based app title bar be weird transparent It looks as usual I show screenshots from my installed Electron-based apps, VS Code & YouTube Music by th-ch ! ! I haven't idea sources of this bugs <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Based on upstream issue, it needs GTK 4.16 for v5.4 version. I wish it can solved soon as possible
This for Gnome 47 needs to merge first.
!
Maybe we could just revert and update it again once GNOME 47 is merged?
I override it on my configurations and it works properly
Code change:
license = license; platforms = platforms.unix; }; <del> } // drvArgs) </del> <ins> } // builtins.removeAttrs drvArgs [ "configureFlags" ]) </ins>

Related discussion:
text: Steps to reproduce the behavior: Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
, glib, libgudev, udisks2, libgcrypt, libcap, polkit , libgphoto2, avahi, libarchive, fuse, libcdio , libxml2, libxslt, docbook_xsl, docbook_xml_dtd_42, samba, libmtp <del> , gnomeSupport ? false, gnome, makeWrapper </del> <ins> , gnomeSupport ? false, gnome, wrapGAppsHook </ins> , libimobiledevice, libbluray, libcdio-paranoia, libnfs, openssh , libsecret, libgdata, python3 }:

Related discussion:
text: Inkscape has support for openclipart but it doesn't work in the package provided by nixpkgs. inkscape to File -Import Clip Art... a search term and click the Search button. the in the GUI and in the terminal. NixOS 18.09 and nixpkgs master.
I researched a bit and thought adding glib-networking would fix it. I wrote the following patch, but it doesn't seem to have any effect:
I wonder whether it really is because TLS support is unavailable, or because uses an invalid security certificate?
Good point. Hm, that's weird. I followed that URL () a day or two ago (when I first noticed this) and was redirected to https:// without problems. But now I see the certificate warning in firefox.
I think it may be a packaging bug after all. Look at this grep: The message only appears in the glib tree, in the gdummytlsbackend.c file. No matches from glib-networking, which AFAIK, provides TLS support.
I tried the patch and am getting Probably because the site is down.
is not down for me.
Thank you!
Code change:
<ins> commit 166afaf144d6473464975438353257359dd51708 Author: Andreas Wiese <andreas.wiese@kernkonzept.com> Date:   Thu Feb 1 11:35:02 2024 +0100 aa-remove-unknown: fix readability check This check is intended for ensuring that the profiles file can actually be opened.  The *actual* check is performed by the shell, not the read utility, which won't even be executed if the input redirection (and hence the test) fails. If the test succeeds, though, using `read` here might actually jeopardize the test result if there are no profiles loaded and the file is empty. This commit fixes that case by simply using `true` instead of `read`. diff --git a/utils/aa-remove-unknown b/utils/aa-remove-unknown index 0e00d6a0..3351feef 100755 --- a/utils/aa-remove-unknown +++ b/utils/aa-remove-unknown @@ -63,7 +63,7 @@ fi # We have to do this check because error checking awk's getline() below is # tricky and, as is, results in an infinite loop when apparmorfs returns an # error from open(). -if ! IFS= read -r _ < "$PROFILES" ; then +if ! true < "$PROFILES" ; then echo "ERROR: Unable to read apparmorfs profiles file" 1>&2 exit 1 elif [ ! -w "$REMOVE" ] ; then </ins>

Related discussion:
text: Can someone else try it and see if it works on their system too? If so, it may help to figure out the proper solution.
I tried it and it actually rebuilds without error the first time too. Hopefully that helps you or someone else figure out a permanent fix! Many thanks.
From my side the issue seems to be be fixed with the merged fixes. So I will close the issue.
If anyone wants to track the merger of the fix :
Code change:
postFixup = optionalString (stdenv.isLinux && withLib) '' addOpenGLRunpath ${placeholder "lib"}/lib/libavcodec.so addOpenGLRunpath ${placeholder "lib"}/lib/libavutil.so <ins> '' # https://trac.ffmpeg.org/ticket/10809 + optionalString (versionAtLeast version "5.0" && withVulkan) '' patchelf $lib/lib/libavcodec.so --add-needed libvulkan.so --add-rpath ${lib.makeLibraryPath [ vulkan-loader ]} </ins> ''; enableParallelBuilding = true;

Related discussion:
text: Ffmpeg 6.1 supports vulkan video, but it is not enabled in the default version of ffmpeg, it is only enabled in ffmpeg-full. The default version of ffmpeg should support vulkan video so that applications like mpv can use it. Arch enables vulkan by . Vulkan video already works with amd GPUs using ffmpeg-full with this command: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This seems reasonable. I'm in favor.
EDIT: Error on my end, skip reading this. Hm, your command doesn't work for me on Mesa 23.3.3: Another aspect to consider is closure size.
If you haven't tried already, can you try with something in h264? Vulkan video currently only supports h264, h265 and av1(experminental), and only if you gpu supports them.
Indeed it's h.265, let me try h.264. This looks like a generic VK issue though.
As suspected, this happens on h.264 too.
Do you have multiple GPUs in your system except the amd one perhaps? This chooses the first one arbitrarily.
Same error for all.
Then I am not sure about what's causing it, that's the exact same error I receive when using ffmpeg 6.1 instead of ffmpeg-full 6.1.
Uhhh about that... So and that commit didn't seem to have been pulled into this brain thingy of mine... It works as expected with ffmpeg-full.
Code change:
<ins> { lib , stdenv , fetchFromGitHub , pkg-config , expat , libcdio , libcdio-paranoia , libpulseaudio , smooth , uriparser , zlib }: stdenv.mkDerivation rec { pname = "BoCA"; version = "1.0.3"; src = fetchFromGitHub { owner = "enzo1982"; repo = "boca"; rev = "v${version}"; sha256 = "0x6pqd5cdag0l283lkq01qaqwyf1skxbncdwig8b2s742nbzjlz8"; }; nativeBuildInputs = [ pkg-config ]; buildInputs = [ expat libcdio libcdio-paranoia libpulseaudio smooth uriparser zlib ]; makeFlags = [ "prefix=$(out)" ]; meta = with lib; { description = "A component library used by the fre:ac audio converter"; license = licenses.gpl2Plus; homepage = "https://github.com/enzo1982/boca"; maintainers = with maintainers; [ shamilton ]; platforms = platforms.linux; }; } </ins>

Related discussion:
text: Project description fre:ac is a free audio converter and CD extractor for Microsoft Windows, Linux, macOS and FreeBSD, distributed under the GNU General Public License.[1] Besides extracting audio from compact discs (with various features including hidden track detection), fre:ac can also convert audio files from one format to another or to the same format but a lower bitrate. fre:ac is compatible with many audio formats such as Ogg Vorbis, FLAC, MP3, MP4/M4A, AAC, WAV, WMA and more.[2][3] fre:ac uses the CDex library to convert from CDs and uses freedb to retrieve artist/song information from the internet which is written to the files as various types of ID3 tags; this library supports cdparanoia which aims to improve audio quality.[4] The user interface is multilingual with 43 languages and is able to be a portable install on a USB drive. Metadata homepage URL: source URL: license: GNU General Public License v2.0 platforms: Windows, macOS, Linux, FreeBSD, HaikuOS
freac is already available on my nur repo If you want to avoid building it, it should be on my cachix https://scott- (for nixos-20.9, nixpkgs-unstable and nixos-unstable)
Code change:
<ins> { lib, buildPythonPackage, fetchFromGitHub, poetry-core, rich, pytestCheckHook, }: buildPythonPackage rec { pname = "rich-theme-manager"; version = "0.11.0"; pyproject = true; src = fetchFromGitHub { owner = "RhetTbull"; repo = "rich_theme_manager"; rev = "refs/tags/v${version}"; hash = "sha256-nSNG+lWOPmh66I9EmPvWqbeceY/cu+zBpgVlDTNuHc0="; }; build-system = [ poetry-core ]; dependencies = [ rich ]; pythonImportsCheck = [ "rich_theme_manager" ]; nativeCheckInputs = [ pytestCheckHook ]; meta = { description = "Define custom styles and themes for use with rich"; license = lib.licenses.mit; homepage = "https://github.com/RhetTbull/rich_theme_manager"; maintainers = with lib.maintainers; [ sigmanificient ]; }; } </ins>

Related discussion:
text: Project description Python app to work with pictures and associated metadata from Apple Photos on macOS. Also includes a package to provide programmatic access to the Photos library, pictures, and metadata. Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This was the most complex package i ever tried to write :sweat_smile:
Code change:
{ stdenv, fetchFromGitHub, cmake, makeWrapper <del> , llvmPackages_39, hiredis, z3_opt, gtest </del> <ins> , llvmPackages_4, hiredis, z3_opt, gtest </ins> }: let klee = fetchFromGitHub { <del> owner = "klee"; </del> <ins> owner = "rsas"; </ins> repo  = "klee"; <del> rev   = "a743d7072d9ccf11f96e3df45f25ad07da6ad9d6"; sha256 = "0qwzs029vlba8xz362n4b00hdm2z3lzhzmvix1r8kpbfrvs8vv91"; </del> <ins> rev   = "57cd3d43056b029d9da3c6b3c666c4153554c04f"; sha256 = "197wb7nbirlfpx2jr3afpjjhcj7slc4dxxi02j3kmazz9kcqaygz"; </ins> }; in stdenv.mkDerivation { <del> name = "souper-unstable-2017-01-05"; </del> <ins> name = "souper-unstable-2017-03-07"; </ins> src = fetchFromGitHub { owner  = "google"; repo   = "souper"; <del> rev    = "1be75fe6a96993b57dcba038798fe6d1c7d113eb"; sha256 = "0r8mjb88lwz9a3syx7gwsxlwfg0krffaml04ggaf3ad0cza2mvm8"; </del> <ins> rev    = "5faed54ddc4a0e0e12647a0eac1da455a1067a47"; sha256 = "1v8ml94ryw5wdls9syvicx4sc9l34yaq8r7cf7is6x7y1q677rps"; </ins> }; nativeBuildInputs = [

Related discussion:
text: was recently updated to use LLVM 4.0, which is rather good news for my use cases. Can we update our version to use this? It also seems they now so perhaps we should switch to using that as well? (maintainer)--LMK your thoughts and if you want to tackle it or want me to (I'd probably get to it this weekend). Thanks!
I'm pretty busy these days but if you're interested in updating it feel free :+1:
Sure thing! Although actually we'll need to actually add LLVM 4.0 first, forgot that wasn't in-tree yet :innocent:. Maybe I'll give that a go as well :+1: (cc )
Code change:
homepage    = http://gitolite.com/gitolite/index.html; license     = licenses.gpl2; platforms   = platforms.unix; <del> maintainers = [ maintainers.thoughtpolice ]; </del> <ins> maintainers = [ maintainers.thoughtpolice maintainers.lassulus ]; </ins> }; }

Related discussion:
text: I don't know much more than this: and but I don't know how to fix this.
I was bit by this as well. It fails on other key for me -- looks like it would fail on any.
How did you solve this issue?
Can someone tell me where this "keydir" should be located? I cannot find it in my !
The keydir should be in your gitolite datadir, which is /var/lib/gitolite in the default settings.
Okay. My shows:
oh it should be in "/var/lib/gitolite/.gitolite/keydir", my bad.
Okay, everything is there. How to check why it fails?
It failed for me for every key on v3.6.2. So, besides upgrading gitolite to v3.6.3, there is not really much you can do.
Update solved the issue.