Question:
Project description GTK mc-like dual panel file browser ::: very nice for mc users... :) "Double Commander is a free cross platform open source file manager with two panels side by side. It is inspired by Total Commander and features some new ideas." Metadata homepage URL: source URL: license: platforms: linux, ???...
Man, this is a Pascal app! I never tried to build such a thing before...
i'm just suggesting because i'm migrating from debian where i use it... :) ... though have no idea about building or packaging... :( debian has it, if it helps in any way.... i use doublecmd-gtk
Debian rarely provides their build scripts. I am reading the ubiquitous AUR (). However, I have seen that the GTK they use is the old and abandoned-by-us GTK2.
i do not "depend" on gnome/gtk... and was about to eventually give a try qt software... so feel free not to oblige to my request, though i do think is a nice piece of software that deserves a chance of availability... maybe wait for them to upgrade their dependencies... ( hour after ) ... i just tried krusader... and filled this bug report: O.o ... so seams there is not a nice working dual panel graphical browser available... :(
Coincidentally, someone on the Discord server was asking about this application like a week ago and I wrote them a package expression to use. I don't have any interest in maintaining it myself, it sounds like you might be interested :wink: This was adapted from which has some modularity for GTK/Qt, in case you want to get that working as well.
Perfect. Friday I will look at this.
" merged commit into NixOS:master 5 hours ago" does this mean it is packaged?... how can i try?... i searched the unstable channel and cannot find doublecmd package.
It means that now the Hydra bot will build the caches in order to include this package. You can follow the progress of it in the link below: When it reaches nixpkgs-unstable you can possibly call it.
... and is now available... :) ... and installed... :) Seams to work fine, except... When i try to "Commands" -"Search", "New search instance..." or "Synchronize dirs...", sometimes i get a "Function not supported!" error... :( ... After opening the program, if it happens, it always happens until i close it... If does do happen, then does not happen until i close it... o.O?... And now that i'm trying to repeat the error, all seams to work fine... Have no idea what was that... The debian version never gave this error... Since i'm not being able to repeat this error, i will not report it until if it ever happens in a repeatable way... (5 min later) Yap ::: no error for several program restarts, cannot repeat it, have no idea on what may have caused the error (maybe is just be from sharing my home (~) with both versions, of debian and /nix). & thank you for packaging this... :)
for mere curiosity ::: do you have any plans to also pack the "qt" version?
Isn't this the QT version already? Or it has support for older QT releases?
lolz ::: yes, you are right... sorry, it does look like gtk version, here in my debian, i presumed it was the same... so then, do you have any plans to also pack the "gtk" version?...
I don't feel motivated to do it because it uses GTK2, an abandoned release of GTK.
The Free Pascal support for GTK3 is in very rough shape. GTK2 is preferred and Qt5 is getting there. what problem do you have with the qt5 version that gtk2 will solve?
i have no "problem" "with the qt5 version"... :) ... it works just fine... :) ... unlike krusader ::: ... :( I just asked "do you have any plans to also pack the "gtk" version?" out of curiosity... :) And with the small concern that if some one only uses only gnome/gtk and installs the doublecmd (qt5) ::: will be also installing some qt5 libraries just for doublecmd, when the necessary libraries for the doublecmd (gtk) are probably already installed and being shared among other gtk programs. For example, if i want to make a small-as-possible live CD based on gnome, and the only installed qt5 package is doublecmd (qt5) ::: some space could be spared with the doublecmd (gtk) instead... O.o ... i presume. So, there is not a big "problem", that i don't mind now ::: but is also not perfect... i do undersand that might rather wait for "Free Pascal support for GTK3", and agree that adding "GTK2, an abandoned release of GTK" may just be a swim against the current and a waste of time (if no one needs it for a stronger reason).
Fortunately space is cheap, so it doesn’t seem like something truly worth optimizing for. Once you start dragging in graphical programs, you’re going to carry a lot of libraries. Use GNOME Commander in this case? I know it’s not packaged in nixpkgs, but that should be trivial to sort out.
"space is cheap" ... o.O?... & what does life has to do with price?... ... and sure GNOME Commander could be a solution ::: but is not in nixpgks... (as you mentioned)... and is not double-commander... maybe is better, i have not tried it ::: is also not in debian stable, that i use... by the screenshots i would presume that has less features and looks not so nice. ... on my part, for now i'm happy with having dblcmd qt ::: i have not yet decided which to choose: qt, gtk, other or none, to cross with my xmonad... and still far from any kind of release, if ever any... and just scouting for the possibility of using nixos, or debian, or both.
Your first argument fails in the point that, well, GNOME is mostly GTK3+ nowadays, whereas DC is GTK2. Between a well-maintained flavor with an extra library versus an abandoned extra library, the choice is obvious.
It has nothing to do with neither life nor price. The point is that the impact of bringing in an extra library (or set of libraries) in a desktop environment is negligible in most cases. I appreciate that there might be corner cases such as a bootable image where space is limited. Packaging it is most likely trivial - someone just has to want it bad enough. This is getting off-topic, but having used Debian both to run servers (50+ instances, so nothing big) and workstations, NixOS is so much nicer.
i do agree with Anderson ::: "the choice is obvious." ... and sorry, for bringing "life" into the subject... what i meant was ::: i don't care about "cheap" but rather well done... o.O?... a "cheaper" typical size DVD ::: costs more and takes more space than a mini-DVD, which does fit a pocked... & yes, "This is getting off-topic"... but the thread is closed, i presume that now we are just drinking coffee, right?... :) ... "NixOS is so much nicer"... o.O?... lolz ::: at consuming hdd space and having broken packages?... i like debian because is stable, and distinguishes between "required,recommended and suggested" dependencies... i use debian since 2000, and every time i try some other distro ::: i end up getting back to debian... :) ... debian can be small, can be big, is quite stable, and others are always missing something i need... :) ... as for nix ::: i do like the one-file ... but still find unbearable when i bump into a "broken package" (why is it listed for install at all?), and miss the suggested/recommnended variations of packages... NixOS is yet not nice enough to replace my debian... :) ... and debian + /nix is very nice enough for now... :) ... i just run 3 personal machines ::: "so nothing big" at all... :)
This isn't particularly constructive, but I'll bite. "NixOS is so much nicer" When you have multiple versions of the same package, you are bound to take up more space than on a distribution where only a single version can exist. The entire closure of bash (as an example) with all its transitive dependencies doesn't take up more space than bash and its dependencies on Debian. Complaining about NixOS using more space than traditional FHS distributions is a bit like complaining that water is wet. Sure, we have broken packages. All distributions have broken packages (for various definitions of "broken" of course). Certain types of packages (KDE applications on !NixOS) is less likely to be tested well and as a consequence will be more likely to break, that's correct. Do we have more or less broken packages that others as a percentage of all packages? Are they more or less broken? I can't give you a quantifiable answer. In my experience broken packages has not been an issue. Because the existence of a package in the repository is orthogonal to its build status. Exactly the same way that a package in debian can also be installable but not fit for purpose due to bugs (or conflicts or pollution from the global environment and so on). Apart from overriding a given package which is of course always an option, some packages will allow you to toggle various features, but having an application's runtime environment be a product of the global environment is not something we strive for. It's pretty much the antithesis of what we're trying to do here. That's fine, you do you. I was simply making the point that for my personal use-cases as well as those of the company in which I work have been a tremendous upgrade from Debian. Forget about "not even the same ballpark" - it's pretty much "not even playing the same game".
O.o ... please do so... :) ... i think is constructive... i' learning about stuff... :) ... and ::: just having another coffee... :) Debian takes me much (much, much, than with recommended) less space, because i only install required packages, never the recommend, never ever the suggested... :) ... nixos seams to do that some extent with configuration and package options... :) ... but still feel much less clear and customizable to me... :( ... or maybe just don't know, NixOS yet enough, how easy that would be... o.O?... ... though never seen it on debian stable... since 2000... :D O.o ... lolz ::: & i just started now, trying to use NixOS... O.o ... & should i report this brokenness it as a bug?... (but "thanks god" ::: it worked on debian) ... seriously ::: please answer this... :) O.o ... lolz ::: am i "experienced" or what?... (just kidding) O.o ... never had packaging problems with debian since 2000... :) ... have you? ::: lolz, would be ironic... :D sorry ::: did not understand this. O.o ... are "you" not trying to please everyone and everything possible?... is not that what "you" also want?... O.o ... yes ::: i'll end up using both... :) ... i'm comparing with debian and sharing my transitional experience for "you" to be aware of it... :) ... i do find the nix approach very nice... :) ... and single file for the whole configuration is really nice... :) ... all my haskell work now goes into a nix-shell of my Debian /nix, that i test in a NixOS... o.O?... "you" do brag about good haskell support ... o.O?... and lolz ::: i bump haskell broken packages?... lolz... :D so ::: don't brag so much just yet... :) ... & make this "bite" ::: "constructive"... :) ... better yet ::: more construct-able... :) ... and more stable when announced (by being in the NixOS channel ) as stable... :) ... and ::: i hope the "bite" tasted nice... o.O?... i have not much more food for now... :( ... with any luck (for "you") i'll just keep bumping into bugs and brokennesses and report them... :)
Just to be clear, the bokenness i mention above is also broken in NixOS, i did try both.
A bit nore spacing concerns... I'm now upgrading NixOS... noticed all the -doc packages passing by... is there a way of switching them all off? ... and is there such thing like a central html index, linked to the -doc files installed? how can i access them?
Oh well, if you are comfortable using Debian Stable, your needs are such that NixOS won't be of use to you… NixOS is about avoiding conflicts between unrelated packages, supporting rollbacks so you can install fresh stuff with less risk, etc. If you want a minimal setup with Debian Stable, sure, that's another way of avoiding problems that Nix handles for large combinatations of fresh packages.
O.o ... uau ::: not bad, for a dictator... o.O?... good thing i have a will of my own... :D but thank you, for the more clear answer to my question: O.o ... guess not... "NixOS won't be of use to you" ... :( sorry, i had not realized that NixOS just targets a specific audience ): ... as you explain, is not good as debian ::: to make a smallest live-cd, with no repetition of packages and with no -doc packages... :( ... ok ::: upon your advice i'll try to use debian for that... :) ... ty And please notice ::: that you just failed in answering any of the questions i made... :( ... which would actually be even more useful to go with the coffee... :) ... suggestion ::: "get your self a cookie"... :D
I could even try to bite this, however my learning and attention problems trigger as a hell before such a badly written text. For someone complaining about elitism and bloat in an obscure and niche distro, your text does no favor being such an obfuscated and unreadable blob.
Sorry Anderson... I also was happier when we were just 2 making the more useful dialog already closed. Also my "learning and attention problems trigger"ed when someone else when off the good interpretation of my writing... O.o ... lolz ... have no idea of you are talking about. ps ::: according to you published location ::: Presumo que sejas brasileiro, e falas portugues... :) ... a minha lingua nativa ::: sempre escrevo melhor o portugues (sem acentos nem cedilhas porque o teclado nao os tem), que o ingles... e' isso ::: peco desculpa pela falta de qualidade do meu ingles nao nativo... sei e' escrever o meu codigo, e apenas aqui venho para me-vos tentar ajudar... seja ao debian, ao nixos ou whatever... :) ... mas se te estou a fazer confusao ::: ja' nao gosto... o.O?... e menos a ti ::: que empakotaste o dblcmd tao eficazmente... :) ... (lolz ::: maybe someday i'll consider inviting you for my yet non-existing crew) ... enquanto o extendido off-topic apenas esta' a deixar mais duvidas que respostas... :( ... portanto vou ficar por aqui ::: e evitar dar alento a "elitismos" maioritariamente incompreendentes... :) [ & bom dia para ti, obrigado por tudo, ] pode ser que nos encontremo-nos noutra thread. For the English speaking ::: if thou have no answers to my actual questions, please don't waste our time in replying ::: i came by to learn and help a bit, even if for now if is just by complaining and asking... :) ... sorry for my noticeable lack of "social skills" ::: thanks god for that... :) ... unfortunately written words don't carry the voice of the writer, nor attitude ::: and are quite prone to miss understanding... in future threads i'll try to hold my self from expressing so at ease. [ & have you all hopefully a nice day ]
This conversation has really veered off the original path. If you have any questions, I suggest taking them over to which is a far better forum for those types of conversations. I would however recommend considering if your writing style helps or hinders the chances of constructive feedback.

<ins> { lib , stdenv , fetchFromGitHub , dbus , fpc , getopt , glib , lazarus , libX11 , libqt5pas , wrapQtAppsHook }: stdenv.mkDerivation rec { pname = "doublecmd"; version = "1.0.6"; src = fetchFromGitHub { owner = "doublecmd"; repo = "doublecmd"; rev = "v${version}"; hash = "sha256-aEWu/bRVOwjK6QTWsMntRYwAfjuwo9SNuH4qkQn0mOY="; }; nativeBuildInputs = [ fpc getopt lazarus wrapQtAppsHook ]; buildInputs = [ dbus glib libX11 libqt5pas ]; NIX_LDFLAGS = "--as-needed -rpath ${lib.makeLibraryPath buildInputs}"; postPatch = '' patchShebangs build.sh install/linux/install.sh substituteInPlace build.sh  --replace '$(which lazbuild)' '"${lazarus}/bin/lazbuild --lazarusdir=${lazarus}/share/lazarus"' substituteInPlace install/linux/install.sh  --replace '$DC_INSTALL_PREFIX/usr' '$DC_INSTALL_PREFIX' ''; buildPhase = '' runHook preBuild export HOME=$(mktemp -d) ./build.sh release qt5 runHook postBuild ''; installPhase = '' runHook preInstall install/linux/install.sh -I $out runHook postInstall ''; meta = with lib; { homepage = "https://doublecmd.sourceforge.io/"; description = "Two-panel graphical file manager written in Pascal"; license = licenses.gpl2Plus; maintainers = with maintainers; [ AndersonTorres ]; platforms = with platforms; linux; }; } # TODO: deal with other platforms too </ins>


Question:
Project description GTK mc-like dual panel file browser ::: very nice for mc users... :) "Double Commander is a free cross platform open source file manager with two panels side by side. It is inspired by Total Commander and features some new ideas." Metadata homepage URL: source URL: license: platforms: linux, ???...
Man, this is a Pascal app! I never tried to build such a thing before...
i'm just suggesting because i'm migrating from debian where i use it... :) ... though have no idea about building or packaging... :( debian has it, if it helps in any way.... i use doublecmd-gtk
Debian rarely provides their build scripts. I am reading the ubiquitous AUR (). However, I have seen that the GTK they use is the old and abandoned-by-us GTK2.
i do not "depend" on gnome/gtk... and was about to eventually give a try qt software... so feel free not to oblige to my request, though i do think is a nice piece of software that deserves a chance of availability... maybe wait for them to upgrade their dependencies... ( hour after ) ... i just tried krusader... and filled this bug report: O.o ... so seams there is not a nice working dual panel graphical browser available... :(
Coincidentally, someone on the Discord server was asking about this application like a week ago and I wrote them a package expression to use. I don't have any interest in maintaining it myself, it sounds like you might be interested :wink: This was adapted from which has some modularity for GTK/Qt, in case you want to get that working as well.
Perfect. Friday I will look at this.
" merged commit into NixOS:master 5 hours ago" does this mean it is packaged?... how can i try?... i searched the unstable channel and cannot find doublecmd package.
It means that now the Hydra bot will build the caches in order to include this package. You can follow the progress of it in the link below: When it reaches nixpkgs-unstable you can possibly call it.
... and is now available... :) ... and installed... :) Seams to work fine, except... When i try to "Commands" -"Search", "New search instance..." or "Synchronize dirs...", sometimes i get a "Function not supported!" error... :( ... After opening the program, if it happens, it always happens until i close it... If does do happen, then does not happen until i close it... o.O?... And now that i'm trying to repeat the error, all seams to work fine... Have no idea what was that... The debian version never gave this error... Since i'm not being able to repeat this error, i will not report it until if it ever happens in a repeatable way... (5 min later) Yap ::: no error for several program restarts, cannot repeat it, have no idea on what may have caused the error (maybe is just be from sharing my home (~) with both versions, of debian and /nix). & thank you for packaging this... :)
for mere curiosity ::: do you have any plans to also pack the "qt" version?
Isn't this the QT version already? Or it has support for older QT releases?
lolz ::: yes, you are right... sorry, it does look like gtk version, here in my debian, i presumed it was the same... so then, do you have any plans to also pack the "gtk" version?...
I don't feel motivated to do it because it uses GTK2, an abandoned release of GTK.
The Free Pascal support for GTK3 is in very rough shape. GTK2 is preferred and Qt5 is getting there. what problem do you have with the qt5 version that gtk2 will solve?
i have no "problem" "with the qt5 version"... :) ... it works just fine... :) ... unlike krusader ::: ... :( I just asked "do you have any plans to also pack the "gtk" version?" out of curiosity... :) And with the small concern that if some one only uses only gnome/gtk and installs the doublecmd (qt5) ::: will be also installing some qt5 libraries just for doublecmd, when the necessary libraries for the doublecmd (gtk) are probably already installed and being shared among other gtk programs. For example, if i want to make a small-as-possible live CD based on gnome, and the only installed qt5 package is doublecmd (qt5) ::: some space could be spared with the doublecmd (gtk) instead... O.o ... i presume. So, there is not a big "problem", that i don't mind now ::: but is also not perfect... i do undersand that might rather wait for "Free Pascal support for GTK3", and agree that adding "GTK2, an abandoned release of GTK" may just be a swim against the current and a waste of time (if no one needs it for a stronger reason).
Fortunately space is cheap, so it doesn’t seem like something truly worth optimizing for. Once you start dragging in graphical programs, you’re going to carry a lot of libraries. Use GNOME Commander in this case? I know it’s not packaged in nixpkgs, but that should be trivial to sort out.
"space is cheap" ... o.O?... & what does life has to do with price?... ... and sure GNOME Commander could be a solution ::: but is not in nixpgks... (as you mentioned)... and is not double-commander... maybe is better, i have not tried it ::: is also not in debian stable, that i use... by the screenshots i would presume that has less features and looks not so nice. ... on my part, for now i'm happy with having dblcmd qt ::: i have not yet decided which to choose: qt, gtk, other or none, to cross with my xmonad... and still far from any kind of release, if ever any... and just scouting for the possibility of using nixos, or debian, or both.
Your first argument fails in the point that, well, GNOME is mostly GTK3+ nowadays, whereas DC is GTK2. Between a well-maintained flavor with an extra library versus an abandoned extra library, the choice is obvious.
It has nothing to do with neither life nor price. The point is that the impact of bringing in an extra library (or set of libraries) in a desktop environment is negligible in most cases. I appreciate that there might be corner cases such as a bootable image where space is limited. Packaging it is most likely trivial - someone just has to want it bad enough. This is getting off-topic, but having used Debian both to run servers (50+ instances, so nothing big) and workstations, NixOS is so much nicer.
i do agree with Anderson ::: "the choice is obvious." ... and sorry, for bringing "life" into the subject... what i meant was ::: i don't care about "cheap" but rather well done... o.O?... a "cheaper" typical size DVD ::: costs more and takes more space than a mini-DVD, which does fit a pocked... & yes, "This is getting off-topic"... but the thread is closed, i presume that now we are just drinking coffee, right?... :) ... "NixOS is so much nicer"... o.O?... lolz ::: at consuming hdd space and having broken packages?... i like debian because is stable, and distinguishes between "required,recommended and suggested" dependencies... i use debian since 2000, and every time i try some other distro ::: i end up getting back to debian... :) ... debian can be small, can be big, is quite stable, and others are always missing something i need... :) ... as for nix ::: i do like the one-file ... but still find unbearable when i bump into a "broken package" (why is it listed for install at all?), and miss the suggested/recommnended variations of packages... NixOS is yet not nice enough to replace my debian... :) ... and debian + /nix is very nice enough for now... :) ... i just run 3 personal machines ::: "so nothing big" at all... :)
This isn't particularly constructive, but I'll bite. "NixOS is so much nicer" When you have multiple versions of the same package, you are bound to take up more space than on a distribution where only a single version can exist. The entire closure of bash (as an example) with all its transitive dependencies doesn't take up more space than bash and its dependencies on Debian. Complaining about NixOS using more space than traditional FHS distributions is a bit like complaining that water is wet. Sure, we have broken packages. All distributions have broken packages (for various definitions of "broken" of course). Certain types of packages (KDE applications on !NixOS) is less likely to be tested well and as a consequence will be more likely to break, that's correct. Do we have more or less broken packages that others as a percentage of all packages? Are they more or less broken? I can't give you a quantifiable answer. In my experience broken packages has not been an issue. Because the existence of a package in the repository is orthogonal to its build status. Exactly the same way that a package in debian can also be installable but not fit for purpose due to bugs (or conflicts or pollution from the global environment and so on). Apart from overriding a given package which is of course always an option, some packages will allow you to toggle various features, but having an application's runtime environment be a product of the global environment is not something we strive for. It's pretty much the antithesis of what we're trying to do here. That's fine, you do you. I was simply making the point that for my personal use-cases as well as those of the company in which I work have been a tremendous upgrade from Debian. Forget about "not even the same ballpark" - it's pretty much "not even playing the same game".
O.o ... please do so... :) ... i think is constructive... i' learning about stuff... :) ... and ::: just having another coffee... :) Debian takes me much (much, much, than with recommended) less space, because i only install required packages, never the recommend, never ever the suggested... :) ... nixos seams to do that some extent with configuration and package options... :) ... but still feel much less clear and customizable to me... :( ... or maybe just don't know, NixOS yet enough, how easy that would be... o.O?... ... though never seen it on debian stable... since 2000... :D O.o ... lolz ::: & i just started now, trying to use NixOS... O.o ... & should i report this brokenness it as a bug?... (but "thanks god" ::: it worked on debian) ... seriously ::: please answer this... :) O.o ... lolz ::: am i "experienced" or what?... (just kidding) O.o ... never had packaging problems with debian since 2000... :) ... have you? ::: lolz, would be ironic... :D sorry ::: did not understand this. O.o ... are "you" not trying to please everyone and everything possible?... is not that what "you" also want?... O.o ... yes ::: i'll end up using both... :) ... i'm comparing with debian and sharing my transitional experience for "you" to be aware of it... :) ... i do find the nix approach very nice... :) ... and single file for the whole configuration is really nice... :) ... all my haskell work now goes into a nix-shell of my Debian /nix, that i test in a NixOS... o.O?... "you" do brag about good haskell support ... o.O?... and lolz ::: i bump haskell broken packages?... lolz... :D so ::: don't brag so much just yet... :) ... & make this "bite" ::: "constructive"... :) ... better yet ::: more construct-able... :) ... and more stable when announced (by being in the NixOS channel ) as stable... :) ... and ::: i hope the "bite" tasted nice... o.O?... i have not much more food for now... :( ... with any luck (for "you") i'll just keep bumping into bugs and brokennesses and report them... :)
Just to be clear, the bokenness i mention above is also broken in NixOS, i did try both.
A bit nore spacing concerns... I'm now upgrading NixOS... noticed all the -doc packages passing by... is there a way of switching them all off? ... and is there such thing like a central html index, linked to the -doc files installed? how can i access them?
Oh well, if you are comfortable using Debian Stable, your needs are such that NixOS won't be of use to you… NixOS is about avoiding conflicts between unrelated packages, supporting rollbacks so you can install fresh stuff with less risk, etc. If you want a minimal setup with Debian Stable, sure, that's another way of avoiding problems that Nix handles for large combinatations of fresh packages.
O.o ... uau ::: not bad, for a dictator... o.O?... good thing i have a will of my own... :D but thank you, for the more clear answer to my question: O.o ... guess not... "NixOS won't be of use to you" ... :( sorry, i had not realized that NixOS just targets a specific audience ): ... as you explain, is not good as debian ::: to make a smallest live-cd, with no repetition of packages and with no -doc packages... :( ... ok ::: upon your advice i'll try to use debian for that... :) ... ty And please notice ::: that you just failed in answering any of the questions i made... :( ... which would actually be even more useful to go with the coffee... :) ... suggestion ::: "get your self a cookie"... :D
I could even try to bite this, however my learning and attention problems trigger as a hell before such a badly written text. For someone complaining about elitism and bloat in an obscure and niche distro, your text does no favor being such an obfuscated and unreadable blob.
Sorry Anderson... I also was happier when we were just 2 making the more useful dialog already closed. Also my "learning and attention problems trigger"ed when someone else when off the good interpretation of my writing... O.o ... lolz ... have no idea of you are talking about. ps ::: according to you published location ::: Presumo que sejas brasileiro, e falas portugues... :) ... a minha lingua nativa ::: sempre escrevo melhor o portugues (sem acentos nem cedilhas porque o teclado nao os tem), que o ingles... e' isso ::: peco desculpa pela falta de qualidade do meu ingles nao nativo... sei e' escrever o meu codigo, e apenas aqui venho para me-vos tentar ajudar... seja ao debian, ao nixos ou whatever... :) ... mas se te estou a fazer confusao ::: ja' nao gosto... o.O?... e menos a ti ::: que empakotaste o dblcmd tao eficazmente... :) ... (lolz ::: maybe someday i'll consider inviting you for my yet non-existing crew) ... enquanto o extendido off-topic apenas esta' a deixar mais duvidas que respostas... :( ... portanto vou ficar por aqui ::: e evitar dar alento a "elitismos" maioritariamente incompreendentes... :) [ & bom dia para ti, obrigado por tudo, ] pode ser que nos encontremo-nos noutra thread. For the English speaking ::: if thou have no answers to my actual questions, please don't waste our time in replying ::: i came by to learn and help a bit, even if for now if is just by complaining and asking... :) ... sorry for my noticeable lack of "social skills" ::: thanks god for that... :) ... unfortunately written words don't carry the voice of the writer, nor attitude ::: and are quite prone to miss understanding... in future threads i'll try to hold my self from expressing so at ease. [ & have you all hopefully a nice day ]
This conversation has really veered off the original path. If you have any questions, I suggest taking them over to which is a far better forum for those types of conversations. I would however recommend considering if your writing style helps or hinders the chances of constructive feedback.

clifm = callPackage ../applications/file-managers/clifm { }; <ins> doublecmd = callPackage  ../applications/file-managers/doublecmd { inherit (qt5) wrapQtAppsHook; }; </ins> joshuto = callPackage ../applications/file-managers/joshuto { inherit (darwin.apple_sdk.frameworks) SystemConfiguration Foundation; };


Question:
With and , I still have to type my LUKS passphrase in qwerty. The logs say this: but not much else apparently. The vconsole is set up fine by the time I get a login prompt.
Dup of

"${config.boot.initrd.systemd.package}/lib/systemd/systemd-vconsole-setup" "${config.boot.initrd.systemd.package.kbd}/bin/setfont" "${config.boot.initrd.systemd.package.kbd}/bin/loadkeys" <del> "${config.boot.initrd.systemd.package.kbd.gzip}/bin/gzip" # keyboard layouts are compressed </del> <ins> "${config.boot.initrd.systemd.package.kbd.gzip}/bin/gzip" # Fonts and keyboard layouts are compressed ] ++ optionals (hasPrefix builtins.storeDir cfg.font) [ "${cfg.font}" ] ++ optionals (hasPrefix builtins.storeDir cfg.keyMap) [ "${cfg.keyMap}" </ins> ]; systemd.services.reload-systemd-vconsole-setup =


Question:
Can anybody provide a pointer on why allowing dangling commits to be fetched is a security risk? I can't seem to find any details on this. Is the risk because people assume "unreachable" means "deleted"?
There's a guess in is the original author of the documentation (see )
Hrm, that guess has to do with github's PRs, not with anything in git.
Well, I found a reason why git would want to prohibit this, but it isn't related to security. If you a branch, the commit that used to point to is still available in the repository -- at least until the next happens. If people are allowed to fetch commits by their hash even when those commits are unreachable, a force-push like this would put those commits at risk of being garbage collected. But nobody would notice the breakage until (potentially) much later, when a happened, and by then it will be too late to recover the lost commit. But since users are forced to mention a commit from which their desired ref is reachable, they will notice the breakage immediately. Most important of all, they will notice while there is probably still time to rescue the now-gc-able commit. I think this is the reason. If nobody else can come up with a security-related explanation I'm going to submit a PR to remove the word "security" in .

/* NOTE: fetchgit has one problem: git fetch only works for refs. <del> This is because fetching arbitrary (maybe dangling) commits may be a security risk </del> <ins> This is because fetching arbitrary (maybe dangling) commits creates garbage collection risks </ins> and checking whether a commit belongs to a ref is expensive. This may change in the future when some caching is added to git (?) Usually refs are either tags (refs/tags/*) or branches (refs/heads/*)


Question:
Steps to reproduce the behavior: Please run and paste the result.
Looks like there is already a PR to address this at And fwiw I had to bisect this to fix my config, first bad commit is
Closing since the linked PR was merged. (Not sure why merge of the linked PR didn't close this...)

interpreter = ( poetry2nix.mkPoetryPackages { projectDir = ./.; <ins> python = pkgs.python39; </ins> overrides = [ poetry2nix.defaultPoetryOverrides (import ./poetry-git-overlay.nix { inherit pkgs; })


Question:
Steps to reproduce the behavior: Please run and paste the result.
Looks like there is already a PR to address this at And fwiw I had to bisect this to fix my config, first bad commit is
Closing since the linked PR was merged. (Not sure why merge of the linked PR didn't close this...)

[[package]] name = "boto3" <del> version = "1.24.6" </del> <ins> version = "1.24.16" </ins> description = "The AWS SDK for Python" category = "main" optional = false python-versions = ">= 3.7" [package.dependencies] <del> botocore = ">=1.27.6,<1.28.0" </del> <ins> botocore = ">=1.27.16,<1.28.0" </ins> jmespath = ">=0.7.1,<2.0.0" s3transfer = ">=0.6.0,<0.7.0"


Question:
Steps to reproduce the behavior: Please run and paste the result.
Looks like there is already a PR to address this at And fwiw I had to bisect this to fix my config, first bad commit is
Closing since the linked PR was merged. (Not sure why merge of the linked PR didn't close this...)

[[package]] name = "botocore" <del> version = "1.27.6" </del> <ins> version = "1.27.16" </ins> description = "Low-level, data-driven core of boto 3." category = "main" optional = false


Question:
Steps to reproduce the behavior: Please run and paste the result.
Looks like there is already a PR to address this at And fwiw I had to bisect this to fix my config, first bad commit is
Closing since the linked PR was merged. (Not sure why merge of the linked PR didn't close this...)

[[package]] name = "certifi" <del> version = "2022.5.18.1" </del> <ins> version = "2022.6.15" </ins> description = "Python package for providing Mozilla's CA Bundle." category = "main" optional = false


Question:
Steps to reproduce the behavior: Please run and paste the result.
Looks like there is already a PR to address this at And fwiw I had to bisect this to fix my config, first bad commit is
Closing since the linked PR was merged. (Not sure why merge of the linked PR didn't close this...)

[[package]] name = "jmespath" <del> version = "1.0.0" </del> <ins> version = "1.0.1" </ins> description = "JSON Matching Expressions" category = "main" optional = false


Question:
Steps to reproduce the behavior: Please run and paste the result.
Looks like there is already a PR to address this at And fwiw I had to bisect this to fix my config, first bad commit is
Closing since the linked PR was merged. (Not sure why merge of the linked PR didn't close this...)

[metadata] lock-version = "1.1" <del> python-versions = "^3.8" content-hash = "57d7c155ae4259912291b1315f9c2fd6c918fad9ef54d1e8011f800b649f9647" </del> <ins> python-versions = "^3.9" content-hash = "781bb4378f4491b427372322c3ec71131ed7a28e0a166e0bc43969b016b5d926" </ins> [metadata.files] apache-libcloud = [


Question:
Steps to reproduce the behavior: Please run and paste the result.
Looks like there is already a PR to address this at And fwiw I had to bisect this to fix my config, first bad commit is
Closing since the linked PR was merged. (Not sure why merge of the linked PR didn't close this...)

{file = "boto-2.49.0.tar.gz", hash = "sha256:ea0d3b40a2d852767be77ca343b58a9e3a4b00d9db440efb8da74b4e58025e5a"}, ] boto3 = [ <del> {file = "boto3-1.24.6-py3-none-any.whl", hash = "sha256:1c13d555172cf88eb645af2429e4a7f42be85e365d6ffc110c952a556d3f8808"}, {file = "boto3-1.24.6.tar.gz", hash = "sha256:4af6a8bc5110b5f9d2fbd00a3c110e4c4cc36fae78d05afa354831f5789e363b"}, </del> <ins> {file = "boto3-1.24.16-py3-none-any.whl", hash = "sha256:2c6f7e4103d41ca07d6b934a6612e4b9a2666eae36e8289f88726868534b8de2"}, {file = "boto3-1.24.16.tar.gz", hash = "sha256:422c000ff2ee5226e89fe427a9c4c09db095d69c179a3bcc3cfba37cbc5e787e"}, </ins> ] botocore = [ <del> {file = "botocore-1.27.6-py3-none-any.whl", hash = "sha256:eeebe304161db6828413dc358ea80ece52f4ddbc8ecde4dd58978d5861a09293"}, {file = "botocore-1.27.6.tar.gz", hash = "sha256:97c909a6ec5ad421573c18ae67fc6ea4232502cd30cffaf03bfcb584d9df652d"}, </del> <ins> {file = "botocore-1.27.16-py3-none-any.whl", hash = "sha256:f117d59899d21beeb200130d7af2090a8112d702a06e2c2794ef576bcea36773"}, {file = "botocore-1.27.16.tar.gz", hash = "sha256:b3b9710902f675a11f5bfd46afda770150530876ae6541d099584462bf949fd1"}, </ins> ] certifi = [ <del> {file = "certifi-2022.5.18.1-py3-none-any.whl", hash = "sha256:f1d53542ee8cbedbe2118b5686372fb33c297fcd6379b050cca0ef13a597382a"}, {file = "certifi-2022.5.18.1.tar.gz", hash = "sha256:9c5705e395cd70084351dd8ad5c41e65655e08ce46f2ec9cf6c2c08390f71eb7"}, </del> <ins> {file = "certifi-2022.6.15-py3-none-any.whl", hash = "sha256:fe86415d55e84719d75f8b69414f6438ac3547d2078ab91b67e779ef69378412"}, {file = "certifi-2022.6.15.tar.gz", hash = "sha256:84c85a9078b11105f04f3036a9482ae10e4621616db313fe045dd24743a0820d"}, </ins> ] cffi = [ {file = "cffi-1.15.0-cp27-cp27m-macosx_10_9_x86_64.whl", hash = "sha256:c2502a1a03b6312837279c8c1bd3ebedf6c12c4228ddbad40912d671ccc8a962"},


Question:
Steps to reproduce the behavior: Please run and paste the result.
Looks like there is already a PR to address this at And fwiw I had to bisect this to fix my config, first bad commit is
Closing since the linked PR was merged. (Not sure why merge of the linked PR didn't close this...)

{file = "idna-3.3.tar.gz", hash = "sha256:9d643ff0a55b762d5cdb124b8eaa99c66322e2157b69160bc32796e824360e6d"}, ] jmespath = [ <del> {file = "jmespath-1.0.0-py3-none-any.whl", hash = "sha256:e8dcd576ed616f14ec02eed0005c85973b5890083313860136657e24784e4c04"}, {file = "jmespath-1.0.0.tar.gz", hash = "sha256:a490e280edd1f57d6de88636992d05b71e97d69a26a19f058ecf7d304474bf5e"}, </del> <ins> {file = "jmespath-1.0.1-py3-none-any.whl", hash = "sha256:02e2e4cc71b5bcab88332eebf907519190dd9e6e82107fa7f83b1003a6252980"}, {file = "jmespath-1.0.1.tar.gz", hash = "sha256:90261b206d6defd58fdd5e85f478bf633a2901798906be2ad389150c5c60edbe"}, </ins> ] jsonpickle = [ {file = "jsonpickle-2.2.0-py2.py3-none-any.whl", hash = "sha256:de7f2613818aa4f234138ca11243d6359ff83ae528b2185efdd474f62bcf9ae1"},


Question:
Steps to reproduce the behavior: Please run and paste the result.
Looks like there is already a PR to address this at And fwiw I had to bisect this to fix my config, first bad commit is
Closing since the linked PR was merged. (Not sure why merge of the linked PR didn't close this...)

authors = ["Adam Hoese <adam.hose@tweag.io>"] [tool.poetry.dependencies] <del> python = "^3.8" </del> <ins> python = "^3.9" </ins> nixops = {git = "https://github.com/NixOS/nixops.git"} nixops-aws = {git = "https://github.com/NixOS/nixops-aws.git"} nixops-digitalocean = {git = "https://github.com/nix-community/nixops-digitalocean.git"}


Question:
Steps to reproduce the behavior: Please run and paste the result.
Looks like there is already a PR to address this at And fwiw I had to bisect this to fix my config, first bad commit is
Closing since the linked PR was merged. (Not sure why merge of the linked PR didn't close this...)

pkgs.poetry2nix.cli pkgs.pkg-config pkgs.libvirt <del> pkgs.poetry </del> <ins> pkgs.python39Packages.poetry </ins> ]; }


Question:
Project description vibrantLinux is a GUI tool to serves the same purpose as for Windows, which to modify the saturation of any given screen whenever certain programs are launched/are in focus. Metadata homepage URL: source URL: license: MIT platforms: Linux Only
Bump. I have some low vision issues and "vibrance" makes it much easier to read the screen. Thanks!

<ins> { lib , stdenv , fetchFromGitHub , cmake , makeWrapper , libX11 , libXrandr , linuxPackages }: stdenv.mkDerivation rec { pname = "libvibrant"; version = "2100c09"; src = fetchFromGitHub { owner = "libvibrant"; repo = "libvibrant"; rev = version; hash = "sha256-nVODwP/PQgYBTHnSplgrkdNOLsF7N+vZ8iPL7gArVNY="; }; buildInputs = [ libX11 libXrandr linuxPackages.nvidia_x11.settings.libXNVCtrl ]; nativeBuildInputs = [ cmake makeWrapper ]; meta = with lib; { description = "A simple library to adjust color saturation of X11 outputs"; homepage = "https://github.com/libvibrant/libvibrant"; license = licenses.mit; platforms = platforms.linux; mainProgram = "vibrant-cli"; }; } </ins>


Question:
Project description vibrantLinux is a GUI tool to serves the same purpose as for Windows, which to modify the saturation of any given screen whenever certain programs are launched/are in focus. Metadata homepage URL: source URL: license: MIT platforms: Linux Only
Bump. I have some low vision issues and "vibrance" makes it much easier to read the screen. Thanks!

<ins> { lib , stdenv , fetchFromGitHub , qt5 , makeWrapper , libvibrant , libX11 , libXrandr , libxcb , linuxPackages }: stdenv.mkDerivation rec { pname = "vibrantLinux"; version = "2.1.10"; src = fetchFromGitHub { owner = "libvibrant"; repo = "vibrantLinux"; rev = version; hash = "sha256-rvJiVId6221hTrfEIvVO9HTMhaZ6KY44Bu3a5MinPHI="; }; nativeBuildInputs = [ makeWrapper ] ++ (with qt5; [ qmake wrapQtAppsHook ]); buildInputs = [ libX11 libXrandr libxcb libvibrant linuxPackages.nvidia_x11.settings.libXNVCtrl ] ++ (with qt5; [ qtbase qttools ]); postPatch = '' substituteInPlace vibrantLinux.pro  --replace '$$(PREFIX)' '$$PREFIX' ''; meta = with lib; { description = "A tool to automate managing your screen's saturation depending on what programs are running"; homepage = "https://github.com/libvibrant/vibrantLinux"; license = licenses.mit; maintainers = with maintainers; [ unclamped ]; platforms = platforms.linux; mainProgram = "vibrantLinux"; }; } </ins>


Question: Steps to reproduce the behavior: Added 'kanboard' to Then ran My machine: <!-- 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.

owner = "kanboard"; repo = "kanboard"; rev = "v${version}"; <del> sha256 = "sha256-pLxCm+T9jdn0FFqbTFe1tsIPTaVTT+QDeLHDxrbpGBg="; </del> <ins> sha256 = "sha256-WG2lTPpRG9KQpRdb+cS7CqF4ZDV7JZ8XtNqAI6eVzm0="; </ins> }; dontBuild = true;


Question: <!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: rustup <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 1.24.3 desired version: 1.25.1 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.

rustPlatform.buildRustPackage rec { pname = "rustup"; <del> version = "1.24.3"; </del> <ins> version = "1.25.1"; </ins> src = fetchFromGitHub { owner = "rust-lang"; repo = "rustup"; rev = version; <del> sha256 = "sha256-JpOOFwlTgwwBCrXOGYskFTgS6RZ7mHQJGT0jnHavxvI="; </del> <ins> sha256 = "sha256-zCr8xu0j/pBsdJEAYTCGrEouA8QumBnyhM4YLFZJqZI="; </ins> }; <del> cargoSha256 = "sha256-hAfGpKaWD94IxFFpnW9XwQp4P9clUX6mmekwodCK0Ag="; </del> <ins> cargoSha256 = "sha256-FDVZn2PjqxovQmmandJICkidurhoXCAxo3bibuxQSMY="; </ins> nativeBuildInputs = [ makeWrapper pkg-config ];


Question:
Linux kernel 4.6 on the stable channel cannot be compiled due to an outdated patch. The patch is removed from the master by the commit but it is not removed from the stable channel. Please backport the commit.
Cc

# 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:
Linux kernel 4.6 on the stable channel cannot be compiled due to an outdated patch. The patch is removed from the master by the commit but it is not removed from the stable channel. Please backport the commit.
Cc

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:
The system-wide LDAP client configuration in is ignored by Openldap client programs. Steps to reproduce the behavior: settings into via or any other Openldap client Openldap client programs should obey the system-wide configuration file in . strace shows it's reading the example configuration from the package instead: Since commit the openldap package no longer passes to configure, it only passes to make instead. Please run and paste the result.
It seems a bit dodgy, but this might be a solution: plus corresponding changes to all the packages and tests that refer to . I'm just rebuilding a gazillion packages on my system from source, so I can check if that works properly...
you probably meant to ping and instead
Oops, sorry about that. I forgot that the maintainer handles listed in the package do not necessarily correspond to their Github usernames.
I realised that changing is probably unwise. Not only does it break some other packages (like python-ldap) and some Nixos tests, it will also break any users who have configured slapd to refer to the schemas under , as I myself have: And changing is not necessary to fix the bug anyway. It seems that the approach of passing differently in compile and install works. I'll send a PR for it.

objectClass: organizationalUnit ou: users ''; <ins> ldapClientConfig = { enable = true; loginPam = false; nsswitch = false; server = "ldap://"; base = "dc=example"; }; </ins> testScript = '' machine.wait_for_unit("openldap.service") machine.succeed( <del> 'ldapsearch -LLL -D "cn=root,dc=example" -w notapassword -b "dc=example"', </del> <ins> 'ldapsearch -LLL -D "cn=root,dc=example" -w notapassword', </ins> ) ''; in {


Question:
The system-wide LDAP client configuration in is ignored by Openldap client programs. Steps to reproduce the behavior: settings into via or any other Openldap client Openldap client programs should obey the system-wide configuration file in . strace shows it's reading the example configuration from the package instead: Since commit the openldap package no longer passes to configure, it only passes to make instead. Please run and paste the result.
It seems a bit dodgy, but this might be a solution: plus corresponding changes to all the packages and tests that refer to . I'm just rebuilding a gazillion packages on my system from source, so I can check if that works properly...
you probably meant to ping and instead
Oops, sorry about that. I forgot that the maintainer handles listed in the package do not necessarily correspond to their Github usernames.
I realised that changing is probably unwise. Not only does it break some other packages (like python-ldap) and some Nixos tests, it will also break any users who have configured slapd to refer to the schemas under , as I myself have: And changing is not necessary to fix the bug anyway. It seems that the approach of passing differently in compile and install works. I'll send a PR for it.

}; declarativeContents."dc=example" = dbContents; }; <ins> users.ldap = ldapClientConfig; </ins> }; }) { inherit pkgs system; };


Question:
The system-wide LDAP client configuration in is ignored by Openldap client programs. Steps to reproduce the behavior: settings into via or any other Openldap client Openldap client programs should obey the system-wide configuration file in . strace shows it's reading the example configuration from the package instead: Since commit the openldap package no longer passes to configure, it only passes to make instead. Please run and paste the result.
It seems a bit dodgy, but this might be a solution: plus corresponding changes to all the packages and tests that refer to . I'm just rebuilding a gazillion packages on my system from source, so I can check if that works properly...
you probably meant to ping and instead
Oops, sorry about that. I forgot that the maintainer handles listed in the package do not necessarily correspond to their Github usernames.
I realised that changing is probably unwise. Not only does it break some other packages (like python-ldap) and some Nixos tests, it will also break any users who have configured slapd to refer to the schemas under , as I myself have: And changing is not necessary to fix the bug anyway. It seems that the approach of passing differently in compile and install works. I'll send a PR for it.

rootpw = "notapassword"; declarativeContents."dc=example" = dbContents; }; <ins> users.ldap = ldapClientConfig; </ins> }; }) { inherit system pkgs; };


Question:
The system-wide LDAP client configuration in is ignored by Openldap client programs. Steps to reproduce the behavior: settings into via or any other Openldap client Openldap client programs should obey the system-wide configuration file in . strace shows it's reading the example configuration from the package instead: Since commit the openldap package no longer passes to configure, it only passes to make instead. Please run and paste the result.
It seems a bit dodgy, but this might be a solution: plus corresponding changes to all the packages and tests that refer to . I'm just rebuilding a gazillion packages on my system from source, so I can check if that works properly...
you probably meant to ping and instead
Oops, sorry about that. I forgot that the maintainer handles listed in the package do not necessarily correspond to their Github usernames.
I realised that changing is probably unwise. Not only does it break some other packages (like python-ldap) and some Nixos tests, it will also break any users who have configured slapd to refer to the schemas under , as I myself have: And changing is not necessary to fix the bug anyway. It seems that the approach of passing differently in compile and install works. I'll send a PR for it.

enable = true; configDir = "/var/db/slapd.d"; }; <ins> users.ldap = ldapClientConfig; </ins> }; testScript = let


Question:
The system-wide LDAP client configuration in is ignored by Openldap client programs. Steps to reproduce the behavior: settings into via or any other Openldap client Openldap client programs should obey the system-wide configuration file in . strace shows it's reading the example configuration from the package instead: Since commit the openldap package no longer passes to configure, it only passes to make instead. Please run and paste the result.
It seems a bit dodgy, but this might be a solution: plus corresponding changes to all the packages and tests that refer to . I'm just rebuilding a gazillion packages on my system from source, so I can check if that works properly...
you probably meant to ping and instead
Oops, sorry about that. I forgot that the maintainer handles listed in the package do not necessarily correspond to their Github usernames.
I realised that changing is probably unwise. Not only does it break some other packages (like python-ldap) and some Nixos tests, it will also break any users who have configured slapd to refer to the schemas under , as I myself have: And changing is not necessary to fix the bug anyway. It seems that the approach of passing differently in compile and install works. I'll send a PR for it.

"CC=${stdenv.cc.targetPrefix}cc" "STRIP="  # Disable install stripping as it breaks cross-compiling. We strip binaries anyway in fixupPhase. "prefix=${placeholder "out"}" <del> "sysconfdir=${placeholder "out"}/etc" </del> <ins> "sysconfdir=/etc" </ins> "systemdsystemunitdir=${placeholder "out"}/lib/systemd/system" # contrib modules require these "moduledir=${placeholder "out"}/lib/modules"


Question:
The system-wide LDAP client configuration in is ignored by Openldap client programs. Steps to reproduce the behavior: settings into via or any other Openldap client Openldap client programs should obey the system-wide configuration file in . strace shows it's reading the example configuration from the package instead: Since commit the openldap package no longer passes to configure, it only passes to make instead. Please run and paste the result.
It seems a bit dodgy, but this might be a solution: plus corresponding changes to all the packages and tests that refer to . I'm just rebuilding a gazillion packages on my system from source, so I can check if that works properly...
you probably meant to ping and instead
Oops, sorry about that. I forgot that the maintainer handles listed in the package do not necessarily correspond to their Github usernames.
I realised that changing is probably unwise. Not only does it break some other packages (like python-ldap) and some Nixos tests, it will also break any users who have configured slapd to refer to the schemas under , as I myself have: And changing is not necessary to fix the bug anyway. It seems that the approach of passing differently in compile and install works. I'll send a PR for it.

installFlags = [ "prefix=${placeholder "out"}" <ins> "sysconfdir=${placeholder "out"}/etc" </ins> "moduledir=${placeholder "out"}/lib/modules" "INSTALL=install" ];


Question:
The change to use at broke evaluation of The expression was changed to reference but that is undefined. It evaluates and builds with the following change? What I'm not sure about is if this is all that is required or if there is anything more before I submit a PR. System: (Flounder) Nix version: nix-env (Nix) 1.11.3 Nixpkgs version: (local git checkout with patches)
Also I'm not sure if any of the other expressions changed were similarly affected. Quickly testing the expression appeared to evaluate successfully despite not having as an input.

{ stdenv, fetchurl, gmp }: stdenv.mkDerivation rec { <del> name = "ikarus-0.0.3"; </del> <ins> version = "0.0.3"; name = "ikarus-${version}"; </ins> src = fetchurl { <del> url = "http://ikarus-scheme.org/${name}.tar.gz"; </del> <ins> url = "http://launchpad.net/ikarus/0.0/${version}/+download/${name}.tar.gz"; </ins> sha256 = "0d4vqwqfnj39l0gar2di021kcf6bfpkc6g40yapkmxm6sxpdcvjv"; };


Question:
Per the , can only be installed on 32-bits systems. Is this still correct? It's a rather old expression, and given that other 32-bits software can be installed on 64-bits NixOS just fine, I'm not sure whether this needs to be changed.
I think there was another attribute for as well, but I am not sure about that.
this should be documented actually
Or the expression could be fixed to transparently install the 32-bit version. Like this does (I think):
You might be refering to there?
I thought there was also something called without the part but I guess I am wrong with that. In any case, the solution proposes looks like a good one?
Does the package work actually? I'm trying to test it, but it seems to be downloading forever.
OK, it seems to play fine.


Question: <!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: minio <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 2022-05-08 desired version: 2022-07-15 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.

in buildGoModule rec { pname = "minio"; <del> version = "2022-05-08T23-50-31Z"; </del> <ins> version = "2022-07-17T15-43-14Z"; </ins> src = fetchFromGitHub { owner = "minio"; repo = "minio"; rev = "RELEASE.${version}"; <del> sha256 = "sha256-Ssuqk/ax6MWdXtbJqWeTTtsIiTK4FmYSR5rOqxh+IaU="; </del> <ins> sha256 = "sha256-hQ52fL4Z3RHthHaJXCkKpbebWpq8MxHo4BziokTuJA4="; </ins> }; <del> vendorSha256 = "sha256-JoI3B3rDzlY0lDHF3rjrzv8/Rq+XCFRs35bWVZqfAKA="; </del> <ins> vendorSha256 = "sha256-u36oHqIxMD3HRio9A3tUt6FO1DtAcQDiC/O54ByeNyg="; </ins> doCheck = false;


Question:
When a user starts and opens a file dialog the application crashes with (Jameica 2.10.2:): GLib-GIO-ERROR **: 22:23:21.974: No GSettings schemas are installed on the system Steps to reproduce the behavior: jameica a "workspace" -manage backups -restore different backup Opens a gtk file dialog jameica crashes on every file dialog for me. the backup path is just the easiest accessible and something a user may come along quickly. i was already playing around a bit with the wrapGAppsHook, but i just dont get it running atm. so maybe someone else want to take a look on that. i am running a kde session on wayland, but i doubt that it make any difference on gnome or other DE. <!-- 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.
created a pr for it. my first tries in adding wrapGappsHook did fail as i did not get, that the order for nativeBuildinputs do matter.

<del> { lib, stdenv, fetchFromGitHub, makeDesktopItem, makeWrapper, ant, jdk, jre, gtk2, glib, xorg, Cocoa }: </del> <ins> { lib, stdenv, fetchFromGitHub, makeDesktopItem, makeWrapper, wrapGAppsHook, ant, jdk, jre, gtk2, glib, xorg, Cocoa }: </ins> let _version = "2.10.2";


Question:
When a user starts and opens a file dialog the application crashes with (Jameica 2.10.2:): GLib-GIO-ERROR **: 22:23:21.974: No GSettings schemas are installed on the system Steps to reproduce the behavior: jameica a "workspace" -manage backups -restore different backup Opens a gtk file dialog jameica crashes on every file dialog for me. the backup path is just the easiest accessible and something a user may come along quickly. i was already playing around a bit with the wrapGAppsHook, but i just dont get it running atm. so maybe someone else want to take a look on that. i am running a kde session on wayland, but i doubt that it make any difference on gnome or other DE. <!-- 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.
created a pr for it. my first tries in adding wrapGappsHook did fail as i did not get, that the order for nativeBuildinputs do matter.

pname = "jameica"; inherit version; <del> nativeBuildInputs = [ ant jdk makeWrapper ]; </del> <ins> nativeBuildInputs = [ ant jdk wrapGAppsHook makeWrapper ]; </ins> buildInputs = lib.optionals stdenv.isLinux [ gtk2 glib xorg.libXtst ] ++ lib.optional stdenv.isDarwin Cocoa;


Question:
When a user starts and opens a file dialog the application crashes with (Jameica 2.10.2:): GLib-GIO-ERROR **: 22:23:21.974: No GSettings schemas are installed on the system Steps to reproduce the behavior: jameica a "workspace" -manage backups -restore different backup Opens a gtk file dialog jameica crashes on every file dialog for me. the backup path is just the easiest accessible and something a user may come along quickly. i was already playing around a bit with the wrapGAppsHook, but i just dont get it running atm. so maybe someone else want to take a look on that. i am running a kde session on wayland, but i doubt that it make any difference on gnome or other DE. <!-- 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.
created a pr for it. my first tries in adding wrapGappsHook did fail as i did not get, that the order for nativeBuildinputs do matter.

sha256 = "1x9sybknzsfxp9z0pvw9dx80732ynyap57y03p7xwwjbcrnjla57"; }; <ins> dontWrapGApps = true; </ins> # there is also a build.gradle, but it only seems to be used to vendor 3rd party libraries # and is not able to build the application itself buildPhase = ''


Question:
When a user starts and opens a file dialog the application crashes with (Jameica 2.10.2:): GLib-GIO-ERROR **: 22:23:21.974: No GSettings schemas are installed on the system Steps to reproduce the behavior: jameica a "workspace" -manage backups -restore different backup Opens a gtk file dialog jameica crashes on every file dialog for me. the backup path is just the easiest accessible and something a user may come along quickly. i was already playing around a bit with the wrapGAppsHook, but i just dont get it running atm. so maybe someone else want to take a look on that. i am running a kde session on wayland, but i doubt that it make any difference on gnome or other DE. <!-- 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.
created a pr for it. my first tries in adding wrapGappsHook did fail as i did not get, that the order for nativeBuildinputs do matter.

install -Dm644 plugin.xml $out/share/java/ install -Dm644 build/jameica-icon.png $out/share/pixmaps/jameica.png cp ${desktopItem}/share/applications/* $out/share/applications/ <ins> ''; postFixup = '' </ins> makeWrapper ${jre}/bin/java $out/bin/jameica  --add-flags "-cp $out/share/java/jameica.jar:$out/share/jameica-${version}/* ${ lib.optionalString stdenv.isDarwin ''-Xdock:name="Jameica" -XstartOnFirstThread'' } de.willuhn.jameica.Main"  --prefix LD_LIBRARY_PATH : ${lib.escapeShellArg (lib.makeLibraryPath buildInputs)}  <del> --chdir "$out/share/java/" </del> <ins> --chdir "$out/share/java/"  "''${gappsWrapperArgs[@]}" </ins> ''; meta = with lib; {


Question:
When a user starts and opens a file dialog the application crashes with (Jameica 2.10.2:): GLib-GIO-ERROR **: 22:23:21.974: No GSettings schemas are installed on the system Steps to reproduce the behavior: jameica a "workspace" -manage backups -restore different backup Opens a gtk file dialog jameica crashes on every file dialog for me. the backup path is just the easiest accessible and something a user may come along quickly. i was already playing around a bit with the wrapGAppsHook, but i just dont get it running atm. so maybe someone else want to take a look on that. i am running a kde session on wayland, but i doubt that it make any difference on gnome or other DE. <!-- 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.
created a pr for it. my first tries in adding wrapGappsHook did fail as i did not get, that the order for nativeBuildinputs do matter.

''; sourceProvenance = with sourceTypes; [ fromSource <del> binaryBytecode  # source bundles dependencies as jars </del> <ins> binaryBytecode # source bundles dependencies as jars </ins> ]; license = licenses.gpl2Plus; platforms = [ "x86_64-linux" "i686-linux" "x86_64-darwin" ];


Question: <!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: tutanota-desktop <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 3.95.4 desired version: 3.98.15 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Version 3.95.4 is not supported by Tutao GmbH anymore. I don't know how that exactly works with Nixpkgs, but it would be desirable to update tutanota in the stable 22.05 channel too. Please tag this issue in your PR.

stdenv.mkDerivation rec { pname = "tutanota-desktop"; <del> version = "3.95.4"; </del> <ins> version = "3.98.15"; </ins> src = fetchurl { url = "https://github.com/tutao/tutanota/releases/download/tutanota-desktop-release-${version}/${pname}-${version}-unpacked-linux.tar.gz"; name = "tutanota-desktop-${version}.tar.gz"; <del> sha256 = "0kkkp0nw4fby4663w7g0k2y1sg89pm336slzii1s3n70h8cak3dx"; </del> <ins> sha256 = "sha256-yuSFDLQ7ckuZYuXREbW0VvMapzO2VhVIH1Ccr1uQHmo="; </ins> }; nativeBuildInputs = [


Question: name: flexoptix-app current version: 5.11.0 desired version: 5.12.1 maintainers: Please tag this issue in your PR.

{ lib, appimageTools, fetchurl, nodePackages }: let pname = "flexoptix-app"; <del> version = "5.11.0"; name = "${pname}-${version}"; </del> <ins> version = "5.12.1"; </ins> src = fetchurl { <del> name = "${name}.AppImage"; </del> <ins> name = "${pname}-${version}.AppImage"; </ins> url = "https://flexbox.reconfigure.me/download/electron/linux/x64/FLEXOPTIX%20App.${version}.AppImage"; <del> hash = "sha256-Nj6S53b4w84qppkGB7lMpJhJlxifaD4acPryuZxY7cM="; </del> <ins> hash = "sha256-ugnJcSFgEEPJ9qxqmRGgW1fraE4E/HbbxpK/00TXPmw="; </ins> }; udevRules = fetchurl {


Question: name: flexoptix-app current version: 5.11.0 desired version: 5.12.1 maintainers: Please tag this issue in your PR.

hash = "sha256-OZe5dV50xq99olImbo7JQxPjRd7hGyBIVwFvtR9cIVc="; }; <del> appimageContents = (appimageTools.extract { inherit name src; }).overrideAttrs (oA: { </del> <ins> appimageContents = (appimageTools.extract { inherit pname version src; }).overrideAttrs (oA: { </ins> buildCommand = '' ${oA.buildCommand}


Question: name: flexoptix-app current version: 5.11.0 desired version: 5.12.1 maintainers: Please tag this issue in your PR.

}); in appimageTools.wrapAppImage { <del> inherit name; </del> <ins> inherit pname version; </ins> src = appimageContents; multiPkgs = null; # no 32bit needed


Question: name: flexoptix-app current version: 5.11.0 desired version: 5.12.1 maintainers: Please tag this issue in your PR.

extraInstallCommands = '' # Add desktop convencience stuff <del> mv $out/bin/{${name},${pname}} </del> <ins> mv $out/bin/{${pname}-*,${pname}} </ins> install -Dm444 ${appimageContents}/flexoptix-app.desktop -t $out/share/applications install -Dm444 ${appimageContents}/flexoptix-app.png -t $out/share/pixmaps substituteInPlace $out/share/applications/flexoptix-app.desktop


Question:
Steps to reproduce the behavior: See . Regression of Blocks: Blocks: porting GSound and GNOME Clocks to macOS Notify upstream: libproxy/libproxy <!-- 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.
A possible fix:
That looks like an upstream bug – the build system should never use functions it is undefining. And either way, on Darwin, I would expect system JavaScriptCore to be used instead of Duktape.

<del> { lib, stdenv </del> <ins> { lib , stdenv </ins> , fetchFromGitHub <ins> , fetchpatch </ins> , pkg-config , cmake , zlib


Question:
Steps to reproduce the behavior: See . Regression of Blocks: Blocks: porting GSound and GNOME Clocks to macOS Notify upstream: libproxy/libproxy <!-- 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.
A possible fix:
That looks like an upstream bug – the build system should never use functions it is undefining. And either way, on Darwin, I would expect system JavaScriptCore to be used instead of Duktape.

hash = "sha256-pqj1LwRdOK2CUu3hYIsogQIXxWzShDuKEbDTbtWkgnQ="; }; <ins> patches = lib.optionals stdenv.isDarwin [ # https://github.com/libproxy/libproxy/pull/189 (fetchpatch { url = "https://github.com/libproxy/libproxy/commit/4331b9db427ce2c25ff5eeb597bec4bc35ed1a0b.patch"; sha256 = "sha256-uTh3rYVvEke1iWVHsT3Zj2H1F+gyLrffcmyt0JEKaCA="; }) ]; </ins> outputs = [ "out" "dev" "py3" ]; nativeBuildInputs = [


Question: Steps to reproduce the behavior: git-town on MacOS Please run and paste the result.

<del> { lib, buildGoModule, fetchFromGitHub, installShellFiles, git, testers, git-town, makeWrapper }: </del> <ins> { lib, buildGoModule, fetchFromGitHub, fetchpatch, installShellFiles, git, testers, git-town, makeWrapper }: </ins> buildGoModule rec { pname = "git-town"; <del> version = "7.7.0"; </del> <ins> version = "7.8.0"; </ins> src = fetchFromGitHub { owner = "git-town"; repo = "git-town"; rev = "v${version}"; <del> sha256 = "sha256-FpBEBx2gb33fGDndvZmvG1A61NoJ4Qy4V3YQSb+Ugsc="; </del> <ins> sha256 = "sha256-g9ooMIMN8DN2FcWYkDC1hICCleQYdHf30PYMCit/NMI="; </ins> }; <ins> patches = [ # Fix "go vet" when building using Go 1.18. (fetchpatch { name = "fix-go-vet-in-go-1.18.patch"; url = "https://github.com/git-town/git-town/commit/23eb0aca7b28c6a0afc21db553aa0e35d35891aa.patch"; sha256 = "sha256-EyfhKVrQxRJNrYqaZI04dJogaXs1J+bbOIu7p8g2Clc="; }) ]; </ins> vendorSha256 = null; nativeBuildInputs = [ installShellFiles makeWrapper ];


Question:
If I try to run Solaar via Rofi nothing happens, when trying it via terminal the following error occurred: If I open a nix-shell with and run solaar it opens and works without issues. Relevant configuration: Steps to reproduce the behavior: system from unstable to run solaar Solaar GUI main windows opens I've tried to find out more and was directed from that it could be related to missing but regardless where I it it didn't solve the issue. Please run and paste the result. nixos-unstable -
see
Thanks :)

outputs = [ "out" "udev" ]; <del> nativeBuildInputs = [ wrapGAppsHook gdk-pixbuf ]; buildInputs = [ libappindicator librsvg ]; </del> <ins> nativeBuildInputs = [ gdk-pixbuf gobject-introspection wrapGAppsHook ]; buildInputs = [ libappindicator librsvg ]; </ins> propagatedBuildInputs = with python3Packages; [ evdev <del> gobject-introspection </del> gtk3 psutil pygobject3


Question:
If I try to run Solaar via Rofi nothing happens, when trying it via terminal the following error occurred: If I open a nix-shell with and run solaar it opens and works without issues. Relevant configuration: Steps to reproduce the behavior: system from unstable to run solaar Solaar GUI main windows opens I've tried to find out more and was directed from that it could be related to missing but regardless where I it it didn't solve the issue. Please run and paste the result. nixos-unstable -
see
Thanks :)

install -Dm444 -t $udev/etc/udev/rules.d rules.d-uinput/*.rules ''; <ins> dontWrapGApps = true; preFixup = '' makeWrapperArgs+=("''${gappsWrapperArgs[@]}") ''; # no tests doCheck = false; pythonImportsCheck = [ "solaar" ]; </ins> meta = with lib; { description = "Linux devices manager for the Logitech Unifying Receiver"; longDescription = ''


Question:
Putting this out here in case anybody else is seeing this. On am Acer Swift SF314-43, the touchpad goes missing with kernel 5.19. Works again with kernel 5.18 and no other changes. Steps to reproduce the behavior: to kernel 5.19 that it's broken With kernel 5.18: With kernel 5.19:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This happended to me as well, on a Tuxedo Aura Gen 1 with an ElanTech clickpad and NixOS 22.05. Comparing the output of between kernel 5.18 and 5.19 I found three modules, which haven't been loaded on 5.19: , and . ~I them to , ran and after rebooting the touchpad is working again.~ Adding them to in my NixOS configuration did not help. Edit: Was on the wrong kernel version, when testing if manually adding the modules would help.
Ah, on 5.19: Kernel rebuilding time. Haven't done that in a while...
So that did it. I didn't need to specify the list of modules, only add the kernel option.
That fixed it on my Tuxedo as well.

MOUSE_PS2_VMMOUSE  = yes; MTRR_SANITIZER     = yes; NET_FC             = yes; # Fibre Channel driver support <ins> # Needed for touchpads to work on some AMD laptops PINCTRL_AMD        = whenAtLeast "5.19" yes; </ins> # GPIO on Intel Bay Trail, for some Chromebook internal eMMC disks PINCTRL_BAYTRAIL   = yes; # GPIO for Braswell and Cherryview devices


Question:
Right now, we have sections covering Perl, Python, Ruby, Go, and more. is another popular language and we have an easy/automated way to add new packages to nixpkgs. We should make this easier for people who don't already know how! I plan on tackling this based on instructions I received over at
cc
Some of the entries in the document have a comment like Should I enhance the in and then generate the XML file? Can anyone clue me in to how they're generated?
They are generated in (using pandoc).
Once I've it to , how can I actually generate the XML?
The XML is generated during the build. To have it in the manual you need to include it with in . The confusing part is that refers some files that exists only at build-time (the files generated by ). It is also possible to keep the build directory with to inspect the generated files.

outputFile = "languages-frameworks/idris.xml"; } + toDocbook { <ins> inputFile = ../pkgs/development/node-packages/README.md; outputFile = "languages-frameworks/node.xml"; } + toDocbook { </ins> inputFile = ../pkgs/development/r-modules/README.md; outputFile = "languages-frameworks/r.xml"; }


Question:
Right now, we have sections covering Perl, Python, Ruby, Go, and more. is another popular language and we have an easy/automated way to add new packages to nixpkgs. We should make this easier for people who don't already know how! I plan on tackling this based on instructions I received over at
cc
Some of the entries in the document have a comment like Should I enhance the in and then generate the XML file? Can anyone clue me in to how they're generated?
They are generated in (using pandoc).
Once I've it to , how can I actually generate the XML?
The XML is generated during the build. To have it in the manual you need to include it with in . The confusing part is that refers some files that exists only at build-time (the files generated by ). It is also possible to keep the build directory with to inspect the generated files.

<xi:include href="idris.xml" /> <!-- generated from ../../pkgs/development/idris-modules/README.md  --> <xi:include href="java.xml" /> <xi:include href="lua.xml" /> <ins> <xi:include href="node.xml" /> <!-- generated from ../../pkgs/development/node-packages/README.md  --> </ins> <xi:include href="perl.xml" /> <xi:include href="python.xml" /> <xi:include href="qt.xml" />


Question:
Right now, we have sections covering Perl, Python, Ruby, Go, and more. is another popular language and we have an easy/automated way to add new packages to nixpkgs. We should make this easier for people who don't already know how! I plan on tackling this based on instructions I received over at
cc
Some of the entries in the document have a comment like Should I enhance the in and then generate the XML file? Can anyone clue me in to how they're generated?
They are generated in (using pandoc).
Once I've it to , how can I actually generate the XML?
The XML is generated during the build. To have it in the manual you need to include it with in . The confusing part is that refers some files that exists only at build-time (the files generated by ). It is also possible to keep the build directory with to inspect the generated files.

<del> NPM packages =========== </del> <ins> Node.js packages =============== To add a package from [NPM](https://www.npmjs.com/) to nixpkgs: </ins> 1. Install node2nix: `nix-env -f '<nixpkgs>' -iA node2nix`. 2. Modify `pkgs/development/node-packages/node-packages.json`, to add, update, or remove package entries.


Question: glslc binary in shaderc has invalid signature Steps to reproduce the behavior: to compile shader on aarch64-darwin to SPIR-V should not be killed

<del> { lib, stdenv, fetchFromGitHub, cmake, darwin, python3 }: </del> <ins> { lib, stdenv, fetchFromGitHub, cmake, python3, autoSignDarwinBinariesHook, cctools }: </ins> # Like many google projects, shaderc doesn't gracefully support separately compiled dependencies, so we can't easily use # the versions of glslang and spirv-tools used by vulkan-loader. Exact revisions are taken from # https://github.com/google/shaderc/blob/known-good/known_good.json


Question: glslc binary in shaderc has invalid signature Steps to reproduce the behavior: to compile shader on aarch64-darwin to SPIR-V should not be killed

rev = "0c28b6451d77774912e52949c1e57fa726edf113"; sha256 = "sha256-KpCMceTV/BRaoJe1qeXhKYQNQqdGaM6Q9nklpJKzHFY="; }; <del> in stdenv.mkDerivation rec { </del> <ins> in stdenv.mkDerivation rec { </ins> pname = "shaderc"; version = "2021.0";


Question: glslc binary in shaderc has invalid signature Steps to reproduce the behavior: to compile shader on aarch64-darwin to SPIR-V should not be killed

ln -s ${spirv-headers} third_party/spirv-tools/external/spirv-headers ''; <del> nativeBuildInputs = [ cmake python3 ] ++ lib.optionals stdenv.isDarwin [ darwin.cctools ]; </del> <ins> nativeBuildInputs = [ cmake python3 ] ++ lib.optionals stdenv.isDarwin [ cctools ] ++ lib.optionals (stdenv.isDarwin && stdenv.isAarch64) [ autoSignDarwinBinariesHook ]; </ins> postInstall = '' moveToOutput "lib/*.a" $static


Question: glslc binary in shaderc has invalid signature Steps to reproduce the behavior: to compile shader on aarch64-darwin to SPIR-V should not be killed

session-desktop = callPackage ../applications/networking/instant-messengers/session-desktop { }; <del> shaderc = callPackage ../development/compilers/shaderc { }; </del> <ins> shaderc = callPackage ../development/compilers/shaderc { inherit (darwin) autoSignDarwinBinariesHook cctools; }; </ins> shades-of-gray-theme = callPackage ../data/themes/shades-of-gray { };


Question:
Easyeffects crashes when Echo Canceller is used (at least when applied on input). I've been told that it works fine on arch linux. Though it might be my hardware that somehow makes it crash. Steps to reproduce the behavior: Echo Canceller module to the Input Easy Effects to one of recording apps It doesn't crash It doesn't write anything useful in the logs, just exits with code 137. Please run and paste the result.
I can reproduce it but it is not a regular crash – there is not core dump. It appears to be killed. Weirdly when I run it with: The termination is not caught.
For me it reproduced with gdb: Maybe it's terminated when child process is crashed?
hmm, it seems to be something wrong with speex when configured to use the fftw library... not sure what, but this doesn't crash:
The same also happens in Speech Processor effect now:
Unfortunately this didn't seem to do the trick for me, it still crashes with the Echo Canceller.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I have the same problem. The thing is, used to work OK on my system. Then I tried the module, after which this issue appeared. However, now it's persisting. I undid the change, even tried booting into old generation, but is still getting killed with the echo canceller on. For reference, this is what I used to try to enable the echo cancel module (not sure if it ever worked):

<del> { lib, stdenv, fetchurl, autoreconfHook, pkg-config, fftw }: </del> <ins> { lib , stdenv , fetchurl , autoreconfHook , pkg-config , fftw , withFftw3 ? true }: </ins> stdenv.mkDerivation rec { pname = "speexdsp";


Question:
Easyeffects crashes when Echo Canceller is used (at least when applied on input). I've been told that it works fine on arch linux. Though it might be my hardware that somehow makes it crash. Steps to reproduce the behavior: Echo Canceller module to the Input Easy Effects to one of recording apps It doesn't crash It doesn't write anything useful in the logs, just exits with code 137. Please run and paste the result.
I can reproduce it but it is not a regular crash – there is not core dump. It appears to be killed. Weirdly when I run it with: The termination is not caught.
For me it reproduced with gdb: Maybe it's terminated when child process is crashed?
hmm, it seems to be something wrong with speex when configured to use the fftw library... not sure what, but this doesn't crash:
The same also happens in Speech Processor effect now:
Unfortunately this didn't seem to do the trick for me, it still crashes with the Echo Canceller.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I have the same problem. The thing is, used to work OK on my system. Then I tried the module, after which this issue appeared. However, now it's persisting. I undid the change, even tried booting into old generation, but is still getting killed with the echo canceller on. For reference, this is what I used to try to enable the echo cancel module (not sure if it ever worked):

outputs = [ "out" "dev" "doc" ]; nativeBuildInputs = [ autoreconfHook pkg-config ]; <del> buildInputs = [ fftw ]; </del> <ins> buildInputs = lib.optionals withFftw3 [ fftw ]; </ins> <del> configureFlags = [ "--with-fft=gpl-fftw3" ] ++ lib.optional stdenv.isAarch64 "--disable-neon"; </del> <ins> configureFlags = lib.optionals withFftw3 [ "--with-fft=gpl-fftw3" ] ++ lib.optional stdenv.isAarch64 "--disable-neon"; </ins> meta = with lib; { homepage = "https://www.speex.org/";


Question:
Easyeffects crashes when Echo Canceller is used (at least when applied on input). I've been told that it works fine on arch linux. Though it might be my hardware that somehow makes it crash. Steps to reproduce the behavior: Echo Canceller module to the Input Easy Effects to one of recording apps It doesn't crash It doesn't write anything useful in the logs, just exits with code 137. Please run and paste the result.
I can reproduce it but it is not a regular crash – there is not core dump. It appears to be killed. Weirdly when I run it with: The termination is not caught.
For me it reproduced with gdb: Maybe it's terminated when child process is crashed?
hmm, it seems to be something wrong with speex when configured to use the fftw library... not sure what, but this doesn't crash:
The same also happens in Speech Processor effect now:
Unfortunately this didn't seem to do the trick for me, it still crashes with the Echo Canceller.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I have the same problem. The thing is, used to work OK on my system. Then I tried the module, after which this issue appeared. However, now it's persisting. I undid the change, even tried booting into old generation, but is still getting killed with the echo canceller on. For reference, this is what I used to try to enable the echo cancel module (not sure if it ever worked):

libcardiacarrest = callPackage ../misc/libcardiacarrest { }; <del> easyeffects = callPackage ../applications/audio/easyeffects { }; </del> <ins> easyeffects = callPackage ../applications/audio/easyeffects { # Fix crashes with speexdsp effects speexdsp = speexdsp.override { withFftw3 = false; }; }; </ins> pulseeffects-legacy = callPackage ../applications/audio/pulseeffects-legacy { };


Question: When using as a root user the following error is produced: . This needs to be included, see = "source ${}/share/zsh-"; Please run and paste the result.

installPhase = '' install -D powerlevel10k.zsh-theme --target-directory=$out/share/zsh-powerlevel10k <ins> install -D powerlevel9k.zsh-theme --target-directory=$out/share/zsh-powerlevel10k </ins> install -D config/* --target-directory=$out/share/zsh-powerlevel10k/config install -D internal/* --target-directory=$out/share/zsh-powerlevel10k/internal cp -R gitstatus $out/share/zsh-powerlevel10k/gitstatus


Question:
consists mostly of syscalls (including ). There are even Ruby-specific workarounds. C/C++ would be a better language for the task. This should also reduce closure size and startup time of FHS-sandboxed apps (Ruby needs to load itself and its libraries from disk).
Can't we just use to setup the chroot?
I'm not sure if it's capable of doing all things that we need for this, but it should be worth checking. Can it run a container as a process (not as a systemd service), and can it be used not by a superuser?
needs root privileges. btw has C code to set them up, the rest is probably bash only?
D: A pity. Well, let's continue with the old plan then. Unfortunately we can't do much more in Bash than we already do because we need to do mounts in the same process we set the namespaces, in children necessary privileges are already gone. I'm not completely sure about this but I remember that when I tried to write this in Bash completely long time ago (using for setting up namespaces mounts and chroot were a problem.
How about using this one?
bind mounts, sysfs, tmpfs and procfs should be
I can confirm that these mounts are possible from using unprivileged lxc containers. But you cannot bind mount something from the host this way, because it needs to be done after . UPDATE: ok even that should be possible if the correct order is maintained: unshare -mount -chroot.
Oh, I should look at it! cc in case he's interested in this thread. I think that checks if the user is root -- that's why this doesn't work. This means that we need to call by ourselves... (I was going to hit "Comment" but you were faster ~_^) I expect that LXC containers do user maps such that you have UID 0 in new userns -- we, however, need to retain user uid.
why do we have to retain user id?
Multiple user apps use uid and username for their purposes -- we don't want to lie to them. I can't give a complete example (I remember that Steam breaks) but for example we have directories which apps can find based on uid.
I have another suggestion: the Go programming language. Bear in mind that I'm generally not a super big fan of Go (in fact, while I use Go extensively at work, I generally use Haskell for my personal projects); however, I think that a higher level, simple (in terms of specification) language would be conducive to maintenance and further development. The binaries should be pretty small, and the closure should be pretty small, too. I might give that a go (no pun intended) and see what we think.
Several possible issues: need native and then before any calls to pthreads (or you'll get or something close); I remember that Go has a runtime so there may be problems; need several syscalls which may not be readily available, namely , and others. In Ruby I import them from libc dynamically and redefine constants from C by hand, but doing this (especially redefining constants) is one of the reasons I want to move from Ruby in the first place. However these are only potential problems -- I don't know if they actually exist! I'm actually interested in how this turns out.
You cannot use clone() properly because of the language runtime. That's why docker uses a little C for that job.
Ah, you must be referring to this from : I'll need to give that a thorough reading before I understand why the runtime gets in the way (unless, perhaps, you have an explanation of why/how pthreads mucks things up).
Oh, I'm guessing that's probably stuff like this: Though, if there are other details, I'd love to hear them :smile:.
If you refer to my remark about fork and pthreads, it's actually 's limitation. You can look at how I workaround this in Ruby by calling imported instead of Ruby's builtin. You will know if you encounter it -- will just fail. I think the best way to find out is with an experiment. (notice that I don't know about Go runtime and haven't even used Go before, so, as I underline again, those might be non-issues)
Interesting. I referred to the , but I don't see any mention of failure when used with pthreads. I don't doubt you; I'd just like to know how all this stuff works.
No problem even if these were doubts ~^. From man page:
Ah, dunno why I didn't try reading the man page -- thanks for pointing that out :wink:.
Anybody done any more work on this? Also, this should probably be tagged with security, due to
a rewrite in a different language will not solve your grsecurity problems. I also do not see how the rewrite discussed here is related to security.
Anything related to grsecurity is security-related. A rewrite into a compiled language means that a setuid wrapper can be created, which means I don't have to run shit as root.
You can drop your privileges via right after you enter the environment as -- it's less convenient but you get roughly what you want.

<del> #!/usr/bin/env ruby # Bind mounts hierarchy: from => to (relative) # If 'to' is nil, path will be the same mounts = { '/' => 'host', '/proc' => nil, '/sys' => nil, '/nix' => nil, '/tmp' => nil, '/var' => nil, '/run' => nil, '/dev' => nil, '/home' => nil, } # Propagate environment variables envvars = [ 'TERM', 'DISPLAY', 'XAUTHORITY', 'HOME', 'XDG_RUNTIME_DIR', 'LANG', 'SSL_CERT_FILE', 'DBUS_SESSION_BUS_ADDRESS', ] require 'tmpdir' require 'fileutils' require 'pathname' require 'set' require 'fiddle' def write_file(path, str) File.open(path, 'w') { |file| file.write str } end # Import C standard library and several needed calls $libc = Fiddle.dlopen nil def make_fcall(name, args, output) c = Fiddle::Function.new $libc[name], args, output lambda do |*args| ret = c.call *args raise SystemCallError.new Fiddle.last_error if ret < 0 return ret end end $fork = make_fcall 'fork', [], Fiddle::TYPE_INT CLONE_NEWNS   = 0x00020000 CLONE_NEWUSER = 0x10000000 $unshare = make_fcall 'unshare', [Fiddle::TYPE_INT], Fiddle::TYPE_INT MS_BIND = 0x1000 MS_REC  = 0x4000 MS_SLAVE  = 0x80000 $mount = make_fcall 'mount', [Fiddle::TYPE_VOIDP, Fiddle::TYPE_VOIDP, Fiddle::TYPE_VOIDP, Fiddle::TYPE_LONG, Fiddle::TYPE_VOIDP], Fiddle::TYPE_INT # Read command line args abort "Usage: chrootenv program args..." unless ARGV.length >= 1 execp = ARGV # Populate extra mounts if not ENV["CHROOTENV_EXTRA_BINDS"].nil? $stderr.puts "CHROOTENV_EXTRA_BINDS is discussed for deprecation." $stderr.puts "If you have a usecase, please drop a note in issue #16030." $stderr.puts "Notice that we now bind-mount host FS to '/host' and symlink all directories from it to '/' by default." for extra in ENV["CHROOTENV_EXTRA_BINDS"].split(':') paths = extra.split('=') if not paths.empty? if paths.size <= 2 mounts[paths[0]] = paths[1] else $stderr.puts "Ignoring invalid entry in CHROOTENV_EXTRA_BINDS: #{extra}" end end end end # Set destination paths for mounts mounts = mounts.map { |k, v| [k, v.nil? ? k.sub(/^/*/, '') : v] }.to_h # Create temporary directory for root and chdir root = Dir.mktmpdir 'chrootenv' # Fork process; we need this to do a proper cleanup because # child process will chroot into temporary directory. # We use imported 'fork' instead of native to overcome # CRuby's meddling with threads; this should be safe because # we don't use threads at all. $cpid = $fork.call if $cpid == 0 # If we are root, no need to create new user namespace. if Process.uid == 0 $unshare.call CLONE_NEWNS # Mark all mounted filesystems as slave so changes # don't propagate to the parent mount namespace. $mount.call nil, '/', nil, MS_REC | MS_SLAVE, nil else # Save user UID and GID uid = Process.uid gid = Process.gid # Create new mount and user namespaces # CLONE_NEWUSER requires a program to be non-threaded, hence # native fork above. $unshare.call CLONE_NEWNS | CLONE_NEWUSER # Map users and groups to the parent namespace begin # setgroups is only available since Linux 3.19 write_file '/proc/self/setgroups', 'deny' rescue end write_file '/proc/self/uid_map', "#{uid} #{uid} 1" write_file '/proc/self/gid_map', "#{gid} #{gid} 1" end # Do rbind mounts. mounts.each do |from, rto| to = "#{root}/#{rto}" FileUtils.mkdir_p to $mount.call from, to, nil, MS_BIND | MS_REC, nil end # Don't make root private so privilege drops inside chroot are possible File.chmod(0755, root) # Chroot! Dir.chroot root Dir.chdir '/' # New environment new_env = Hash[ envvars.map { |x| [x, ENV[x]] } ] # Finally, exec! exec(new_env, *execp, close_others: true, unsetenv_others: true) end # Wait for a child. If we catch a signal, resend it to child and continue # waiting. def wait_child begin Process.wait # Return child's exit code if $?.exited? exit $?.exitstatus else exit 1 end rescue SignalException => e Process.kill e.signo, $cpid wait_child end end begin wait_child ensure # Cleanup FileUtils.rm_rf root, secure: true end </del>