<lovesegfault>
andi-: I tried getting LTO & PGO on the Nix build of FF
<lovesegfault>
I wasted my holiday
<andi->
lovesegfault: I tried that too... gave up very quickly
<andi->
Not wasting my holiday on that anymore ;-)
<andi->
At least not until my new workstation is here to speedup the process
<lovesegfault>
andi-: I used the Gentoo ebuild as reference since it works really well there
<lovesegfault>
but I kept running into bizarre linker issues
<andi->
lovesegfault: do you have the changes somewhere? Maybe we can go through them together some day and see if we can figure it out.
<andi->
Just finishing up the FF 72 bumps right now
<lovesegfault>
andi-: Maaaybe, I'll search after my nap
<lovesegfault>
With this war with Iran looming it may be a good time for me to visit Tweag EU offices :P
<ashkitten>
someone requested glimpse be packaged for nix, which i wasn't planning to pr for a while yet
<lovesegfault>
ashkitten: Is that the gimp fork?
<ashkitten>
correct
<lovesegfault>
ashkitten: Would it be "as easy" as copying the gimp one and overriding the name?
<ashkitten>
i've already got it packaged in my fork
<ashkitten>
and, sort of
drakonis has quit [Read error: Connection reset by peer]
<ashkitten>
they didn't include a release tarball with 0.1, but my understanding is they will for the next release
<lovesegfault>
Ha, curious
<ashkitten>
also, along with upstream 3.0 they'll be switching the build system, iirc to meson?
<ashkitten>
i guess my question for yall is, should i include all of the third party plugins packaged for upstream? my understanding is that glimpse will at some point drop compatibility with plugins built for upstream, since they'll be changing the library names
<ashkitten>
but that's not happened yet
orivej has quit [Ping timeout: 240 seconds]
<ashkitten>
also i think at least until they actually diverge away from upstream enough, we could easily patch plugins to work with glimpse regardless
<ashkitten>
simple string replacements
<ashkitten>
i'm not sure that's worth the effort, though. do we have any statistics for how many users are using the third party plugin packages?
<ashkitten>
if it's a small enough number then imo we should not package third party plugins for glimpse
<ashkitten>
especially considering the state of the plugins... i'm pretty sure several of them are just completely nonfunctional even with upstream
yl has quit [Ping timeout: 248 seconds]
drakonis has joined #nixos-dev
ris has quit [Ping timeout: 260 seconds]
lovesegfault has quit [Ping timeout: 246 seconds]
lovesegfault has joined #nixos-dev
<jtojnar>
ashkitten lot of the plugins were broken until recently and nobody seemed to complain
<aanderse>
Jan Tojnar: i just try to fix a broken package... and you push to go the extra mile. one of the many things i like about you, btw :)
<ashkitten>
jtojnar: unfortunately even though they all build now, some don't work
<ashkitten>
what comes to mind is the wavelet sharpen thing
<ashkitten>
didn't show up in the ui at all
<ashkitten>
did show up in the list of loaded plugins
<ashkitten>
honestly i'm kinda in the mood to say we should scrap them if nobody uses them
<ashkitten>
do we have a policy for removing unmaintained packages?
<qyliss>
not as such
<ashkitten>
seems like a thing that would be good to have
<gchristensen>
if it is broken for a long time, seems clear and find to drop
<qyliss>
Yeah
<gchristensen>
but check the current stable first
<ashkitten>
some of them work, supposedly, but apparently nobody noticed when they didn't
<ashkitten>
the only thing i can think to keep is the g'mic plugin, since that actually works and i've used it before
<aanderse>
i just wish we had more maintainers stick around in the long term so stuff wouldn't stay broken T_T
kenjis has quit [Ping timeout: 248 seconds]
<aanderse>
large number of broken packages isn't reassuring for people to switch to nixos
<ashkitten>
yeah, unfortunately there's not really a system in place to enforce maintainer retention
<aanderse>
... but neither is large number of removed packages
<qyliss>
Do the plugins break frequently?
<ashkitten>
i doubt "frequently"
<qyliss>
If they won't cause significant maintenance burden, I'd consider keeping the currently working ones
<ashkitten>
since gimp doesn't update that frequently, anyways
<gchristensen>
slightly broken packages are a great onramp for getting users to become contributors :P
<qyliss>
Like, if they're not hurting anybody, you know
<ashkitten>
if i package glimpse i'm probably gonna say no to third party plugins, tbh
<qyliss>
they can be added later if needed
<qyliss>
do the simplest thing first, etc
<simpson>
ashkitten++ qyliss++ walking before running
<{^_^}>
ashkitten's karma got increased to 3, qyliss's karma got increased to 22
<ashkitten>
i don't care what the gimp package maintainer does, but i don't want unmaintainable crap in my packages, and having to launch the program and search through menus makes it unmaintainable in my book
<qyliss>
It doesn't sound like we should say no if somebody else wants to use plugins
<qyliss>
But you definitely shouldn't do it
<ashkitten>
i won't say no if people want plugins
<qyliss>
At least not right no.
<qyliss>
*now
<ashkitten>
i do think we should go through the gimp plugins and mark the broken ones as broken or straight up remove them
<qyliss>
Anyway, sounds like you're doing a great job. :)
<qyliss>
ashkitten++
<{^_^}>
ashkitten's karma got increased to 4
<ashkitten>
thanks
<ashkitten>
ahah
<ashkitten>
i don't talk about on topic stuff enough to get much karma
<qyliss>
hehe
<qyliss>
I've had karma for off-topic things
<ashkitten>
i should lurk more in #nixos and help people with things
<ashkitten>
get that lurk karma
<qyliss>
the thing about people in #nixos who need help is they generally don't know about bot karma :P
<ashkitten>
hah
<ashkitten>
true
<ashkitten>
qyliss++ thanks for the help
<{^_^}>
qyliss's karma got increased to 23
kenjis has joined #nixos-dev
das_j has quit [Remote host closed the connection]
Scriptkiddi has quit [Remote host closed the connection]
das_j has joined #nixos-dev
Scriptkiddi has joined #nixos-dev
<samueldr>
along with a list of beliefs/guidelines of the community, a couple pointers about the bot would be nice
kenjis has quit [Remote host closed the connection]
<jtojnar>
I checked the majority of gimp plugins during the 2.10 upgrade (not only if they build but also are listed in the menu and work) ashkitten
<ashkitten>
alright
<ashkitten>
i know i tried the wavelet sharpen plugin and it did not work
drakonis has quit [Quit: WeeChat 2.6]
drakonis has joined #nixos-dev
bhipple has joined #nixos-dev
lovesegfault has quit [Ping timeout: 258 seconds]
drakonis has quit [Read error: Connection reset by peer]
<worldofpeace>
adisbladis: I've heard from a proverbial vine of grapes that you've provided a x86_64 community builder ref nix-community? I kinda need help QA'ing stuff like https://github.com/NixOS/nixpkgs/pull/76205 and I'm always merging certain big things without proper build testing
<zimbatm>
a lot of these non-repros are due to date changes
<FRidh>
no fake system time?
<FRidh>
we had a couple of packages/tests that started failing in 2020
<fpletz>
andi-: why isn't the firefox 71->72 bump on master/staging yet and no PR open? or am I just missing something? seems a bit weird to bump it von 19.09 first :)
<gchristensen>
usually docs generators
<gchristensen>
lots of packages like to have their --help and docs print when they werebuilt
<zimbatm>
it's nice to have reproducible dates that are not 1970-01-01
<zimbatm>
if we could extract the date of the source/commit and propagate that...
<andi->
fpletz: well because 19.09 is usually harder so I start with that
<qyliss>
that would me nice
<qyliss>
I was thinking about that yesterday because I was using Asciidoctor in Nix and it produced documentation that said "Last generated 1970-01-01" at the bottom
<qyliss>
Which was not ideal
<gchristensen>
yeah, that is why SOURCE_DATE_EPOCH is a thing
<qyliss>
I think flakes can do this, actually
<andi->
fpletz: the branch is already ready just have to sit down and test it. andir:firefox72 if you have a spare minute :)
<fpletz>
andi-: awesome, thanks :)
<qyliss>
gchristensen: how do I make SOURCE_DATE_EPOCH something useful and not 1?
<andi->
(I was waiting for the rebuild amount calculation and then got sidetracked by $job :D)
<gchristensen>
not sure, maybe it could sniff something about the source tarball
<qyliss>
In my case it was a builtins.fetchGit
<fpletz>
andi-: you're not alone :) got some time now and am going to test
<qyliss>
so probably not possible
<gchristensen>
time was a mistake anyway :P
<qyliss>
But I could have put it in as an argument from the script that runs nix-build
<zimbatm>
builtins.fetchGit already returns the revCount, it could also return a timestamp
<qyliss>
that would be ncie
<zimbatm>
then we could have a convention in the default buildenv: `SOURCE_DATE_EPOCH=${src.timestamp or 1}`
<qyliss>
That would be extremely nice
<qyliss>
Probably very easy to implement on the Nix side too since it's already been done for flakes
<zimbatm>
ok so because of flakes' lastModified, a UTC -> timestamp conversion is required
<zimbatm>
yeah
<zimbatm>
all the little things count
<gchristensen>
this sounds like a great idea, just want to note that these builds with unreproducible dates would need patching to handle SOURCE_DATE_EPOCH (or patching to remove the date altogether)
<gchristensen>
it would be really reallygood to get actual timestamps
<zimbatm>
maybe it's not too late to fix the flakes output to timestamps
<qyliss>
I think it would be a shame to throw away TZ info if we have it
<qyliss>
But we could expose UTC timestamp, and UTC offset
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
Synthetica has joined #nixos-dev
<zimbatm>
we are missing a standard reproducible archive format
<zimbatm>
`git archive` uses gettimeofday() for the file mtimes unless the commit is a git tag, then it uses the commit date for some reason
orivej has quit [Ping timeout: 268 seconds]
orivej has joined #nixos-dev
phreedom_ is now known as phreedom
FRidh2 has joined #nixos-dev
orivej has quit [Ping timeout: 268 seconds]
<fpletz>
andi-: firefox 72 with the patch works fine on master and 19.09 :)
<andi->
fpletz: great, I'll open the stable PR in a few
<gchristensen>
yay
mmlb has joined #nixos-dev
ris has joined #nixos-dev
<rnhmjoj>
i'm working on making the urxvt wrapper configurable (allowing users to add/remove plugins, etc.) but i've hit a problem. there are plugins that need extra runtime dependencies (possibly even the package itself) and the wrapper must be informed about them somehow. is there a way to add extra information to a derivation?
orivej has joined #nixos-dev
<andi->
rnhmjoj: You mean the plugin must communicate to the wrapper that it needs additional entries in PATH?
kenjis has quit [Remote host closed the connection]
<rnhmjoj>
andi-: basically the wrapper takes a list of plugins as input, where each plugin is a derivation. some plugin needs certain dependencies (like perl packages) that the wrapped needs to handle
<andi->
rnhmjoj: You could do something like `passthru.perlPackages = …;` in the plugin. And in the wrapper use that information (`plugin.perlPackages`).
<rnhmjoj>
andir-: ah, i knew there was something
<rnhmjoj>
it works exactly as i expected. thank you andi-
<andi->
rnhmjoj: yw
FRidh2 has quit [Quit: Konversation terminated!]
psyanticy has quit [Quit: Connection closed for inactivity]
<andi->
fpletz: guess you also didn't test aarch64 ? :) Seems like we are patching autotools foo there that is now checksummed within the build env..
ixxie has quit [Ping timeout: 260 seconds]
zarel has quit [Ping timeout: 240 seconds]
zarel has joined #nixos-dev
__monty__ has quit [Quit: leaving]
<fpletz>
andi-: oh, yeah :(
<fpletz>
I see you're already build 72.0.1 on the aarch64 community builder :>
<fpletz>
*building
<andi->
Yeah... judging by the amount of time it takes it probably works.. before it would terminate really early