<gchristensen>
I misunderstood -create record_path [key [val ...]] to mean I can specify multiple multiple key/value pairs, but it doesn't: it means you can specify multiple values for that one key
<orivej>
aha
<gchristensen>
:/
<jtojnar>
orivej: is there even any reason for the source-release archive disctinction?
<jtojnar>
it feels to me like some relict of autotools based toolchains, sparing users of having to fiddle with the horrendous macros
<jtojnar>
that much
<orivej>
jtojnar: arhives are generated by github and they change over time (even though their unpacked content does not change), and releases are maid by the authors of projects and they do not change automatically
<gchristensen>
w00t
<jtojnar>
I thought it was being done to preprocess the source code
<jtojnar>
for example libgnome-games-support release archive contains generated C code
<jtojnar>
while the source code is pure Vala
ris has quit [(Ping timeout: 240 seconds)]
<orivej>
then it's fine to switch to the source archive if you want to ensure the purely source build
<Dezgeg>
IMHO the pure source archives are better since otherwise you're in pain when you need to add a patch that touches one of those autoconf files
<gchristensen>
+1
<orivej>
I believe jtojnar is speaking about packages using the meson build system without autotools
<jtojnar>
well I was wondering how the distinction was created
<jtojnar>
because I also think it is more trouble than it is worth
<jtojnar>
and am thankful meson does not seem to have the distinction
<orivej>
"I thought it was being done to preprocess the source code" - some other uses: (1) publish the signature or hashes of the release, (2) publish the release on mirrors / CDN, (3) embed the version number into the source distribution
<jtojnar>
I was mainly concerned about the cases when the release archive was different from the source code
<jtojnar>
i.e. the preprocessing
<jtojnar>
which I think is more trouble than it is worth
<jtojnar>
but it is quite common with autotools based apps (e.g. large part of GNOME)
<orivej>
when switching from a release to a git checkout, just pay attention to the way the upstream handles version numbers so that e.g they don't disappear from the Help > About dialog
<jtojnar>
hmm, that might be what is happening with gnomeExtensions.dashToDock
mbrgm has quit [(Ping timeout: 250 seconds)]
mbrgm has joined joined #nixos-dev
<gchristensen>
guh hydra continues to fail to eval
jtojnar has quit [(Ping timeout: 240 seconds)]
jtojnar has joined joined #nixos-dev
jtojnar has quit [(Remote host closed the connection)]
jtojnar has joined joined #nixos-dev
jtojnar has quit [(Quit: jtojnar)]
jtojnar has joined joined #nixos-dev
jtojnar has quit [(Quit: jtojnar)]
jtojnar has joined joined #nixos-dev
jtojnar has quit [(Remote host closed the connection)]
jtojnar has joined joined #nixos-dev
jtojnar has quit [(Remote host closed the connection)]
phreedom has quit [(Quit: No Ping reply in 180 seconds.)]
phreedom has joined joined #nixos-dev
<FRidh>
gchristensen: via the API you could get a list of commits. Perhaps fetch for each item in the list the patch and apply those?
<gchristensen>
sorry, what for?
<FRidh>
the bot
<gchristensen>
oh, yeah, so I did that first actually, but it caused failures to apply patches that can be solved via merging
<FRidh>
to reduce the amount of fetching
ris has quit [(Ping timeout: 264 seconds)]
<FRidh>
alright
goibhniu has joined joined #nixos-dev
<gchristensen>
the recent change is instead of building in buildpath/nixos-nixpkgs/pr/32075 (for example) it now builds in buildpath/nixos-nixpkgs/checkout. this way I don't have to implement GC for the per-PR checkout
goibhniu has quit [(Ping timeout: 250 seconds)]
ma27 has quit [(Ping timeout: 250 seconds)]
ma27 has joined joined #nixos-dev
ma27 has quit [(Quit: WeeChat 1.9.1)]
zraexy has joined joined #nixos-dev
JosW has joined joined #nixos-dev
taktoa has joined joined #nixos-dev
<LnL>
is there a way to see nix debug logging for a build started with build-remote?
Sonarpulse has quit [(Ping timeout: 255 seconds)]
phreedom has quit [(Quit: No Ping reply in 180 seconds.)]
phreedom has joined joined #nixos-dev
orivej has quit [(Ping timeout: 255 seconds)]
phreedom has quit [(Ping timeout: 248 seconds)]
phreedom has joined joined #nixos-dev
orivej has joined joined #nixos-dev
<gchristensen>
niksnut, ikwildrpepper, domenkozar, someone reported a security issue to me that only you three can solve. can any of you PM me immediately?
<gchristensen>
domen has PM'd me
<gchristensen>
all sorted :)
Mic92 has quit [(Quit: WeeChat 1.9.1)]
JosW has quit [(Quit: Konversation terminated!)]
orivej has quit [(Read error: Connection reset by peer)]
_ris has joined joined #nixos-dev
orivej has joined joined #nixos-dev
ma27 has joined joined #nixos-dev
FRidh has quit [(Quit: Konversation terminated!)]
ma27 has quit [(Quit: WeeChat 1.9.1)]
ma27 has joined joined #nixos-dev
ma27 has quit [(Ping timeout: 276 seconds)]
<jtojnar>
so how exactly does the staging merge cycle work? do we merge bunch of pull requests at the ssame time and then just wait untill hydra finishes building it?
<gchristensen>
any time I need to do something with it, I ping vcunat and let him merge my thing in to it when he's ready
<LnL>
yeah basically, depending on the state of staging it's merged back into master every 1-2 weeks