@eyedeekay
&zzz
+R4SAS
+RN
+StormyCloud
+T3s|4
+acetone
+dr|z3d
+hk
+orignal
+postman
+radakayot
+snex
+weko
+wodencafe
Arch
BravoOreo
Dann
FreeB
FreefallHeavens_
Irc2PGuest11045
Irc2PGuest48814
Irc2PGuest59134
Irc2PGuest60478
Irc2PGuest7448
Irc2PGuest90968
Leopold
Onn4l7h
Onn4|7h
Sleepy_
Soni
T3s|4_
Teeed
aeiou
aisle
ardu
b3t4f4c3__
bak83_
dickless
dr4wd3
enoxa
eyedeekay_bnc_
hagen_
not_bob_afk
phil
plap
poriori
profetikla
qend-irc2p
rapidash
solidx66_
u5657
uop23ip
w8rabbit
x74a6h
zzz
launchpad done, deb repo tomorrow
zzz
deb repo done
zzz
off to start on 2.9.0
zzz
eyedeekay, don't know if you and ech have given up on apple notarization for good, but a bitcoin core dev put up her signing/notarization scripts that bitcoin is using: github.com/achow101/signapple
zzz
looks very well documented
eyedeekay
Worth a look, maybe some mysteries will be solved
zzz
I think there's a windows flavor also, where did it go...
eyedeekay
Oh wow that is extensive... I'll see if I can get it to work on our dmg, seems pretty smart
zzz
seems like you could run it from linux
eyedeekay
Will depend on whether it depends on mac tools underneath but maybe
zzz
I don't know where you guys got stuck, but it does appear to be very professional
zzz
actually I don't think bitcoin has used it yet but they're going to for their next release
eyedeekay
We sort of got into a loop, send for notarization, get rejected, look at what went wrong, try again
zzz
for windows, bitcoin is using 'osslsigncode' which is in ubunutu
eyedeekay
Executing on that loop quickly became the challenge, because I do the fixes, send them to ech, ech sends them to apple, apple sends them to ech, ech sends them to me, repeat
eyedeekay
I am familiar with osslsigncode
zzz
that loop seems like one too many people involved. I don't think we can have ech in our release process unless he gets a lot more responsive
eyedeekay
Yeah it would go a lot faster if I could do the notarizarion part
zzz
so either he'd need to give you his keys or you'd have to get your own
zzz
if neither is possible then there's no use trying to make it work
zzz
her docs in the docs/ directory are insanely detailed, she's gone thru Apple source code and written up everything
zzz
checklists, requirements, steps to follow, ...
eyedeekay
Well that will be helpful because one big problem with it is how opaque the errors are, in addition to how complicated it is for me to see them
lbt
Hi! Debian: "Package i2p has conffile prompt and needs to be upgraded manually" - while there was no prompt it did force me to do the update manually. Was this intended / are you aware / am I missing something?
eyedeekay
Doesn't sound right, probably need to reproduce it
zzz
havent seen that before
zzz
oh I know, that's like on dist-upgrade where you changed a config file and it asks you if you want to keep your changes
zzz
just run sudo apt upgrade from the shell
zzz
we've marked the config files in $I2P and /etc like that
lbt
Ya - and in general it makes sense to have some way to state "don't install this unattended". Just unsure if it makes sense here - as well as what triggers it ...
zzz
do it from the CLI and you'll find out what file it is
lbt
I did, and there was no prompt whatsoever. That's why I'm wondering about it
lbt
Installed fine, too, far as I can say
zzz
normally ppl don't edit those files, so it's in there as a protection so you don't lose your changes
zzz
I assume that doesn't trigger unless a file was actually modified?
zzz
hmph
lbt
Cannot say what triggers it tbh. To check for it they would need both versions and diff the conf-files I guess?
lbt
Also ... a changed comment in the conf-file probably shouldn't fire this either, so might not be trivial?
zzz
yeah that's what it does, if you've ever done distribution upgrades you've probably seen it
zzz
so I guess it's working as intended
lbt
It? To me it seems like either unattended-upgrade has a bug in how it determines whether it needs to prompt or the i2p-package has something in it that provokes this behaviour although not needed. But I should either get that prompt or it should have been upgraded unattended, right?
eyedeekay
I see your logic but somewhere in unattended-upgrades or the packages that comprise it there are rules that express what is happening, what we should do, if anything, may depend on which rule we're triggering
dr|z3d
does the discussion hinge on whether i2p updates should be unattended from repo?
zzz
the trigger is that we put conf files in /etc and declare additional ones in $I2P
zzz
obviously it checks for the presence of conffiles pre-install, not for diffs to conffiles during install, which is reasonable
lbt
Hm, you need the diff to be able to tell if you need to ask about changes, though?
zzz
conffiles does that