< michagogo>
That should be adaptable for KVM, or you can just recreate the base image
< wumpus>
thanks, I'll give it a try
< fanquake>
wumpus would you be able to merge my two sets of sigs for rc1 & rc2 ?
< wumpus>
fanquake: sure
< fanquake>
I'm building the 0.10 rc now
< fanquake>
Cheers
< michagogo>
Are we doing the detached signing?
< wumpus>
michagogo: for 0.11 we are, not sure about 0.10 (but I think so)
< michagogo>
I mean specifically the RCa
< michagogo>
RCs*
< wumpus>
for rc2 there will be detached sigs, for rc1 we don't bother because of the lack of version bump and it became superseded so fast
< nartac>
if count of forked coin wallets will be >50%. Is it mean new coins will get all old coins wallets
< wumpus>
nartac: sounds like a #bitcoin question
< wumpus>
michagogo: your instructions almost worked - for KVM you need a start-target in there somewhere
< wumpus>
...and a stop-target at the end, before copying
< wumpus>
oh, but I get a new error now: Could not open 'base-precise-amd64.qcow2': Too many open files
< wumpus>
it gets in a loop
< wumpus>
well, create a new image it is
< michagogo>
wumpus: yeah, makes sense. I think I mentioned (or if not, I meant to mention) that for KVM, you probably need to adapt the instructions. I think the command for making the image copy is different too, not just a cp -- take a look at make-clean-vm.
< wumpus>
michagogo: yes, I naively thought it worked - almost literally - for KVM, but that was only apparantly. The qcows keep a reference to the base image, so copying the result back to the base image creates an infinite loop
< michagogo>
Ah. Yeah, so it's an actual snapshot/forked clone mechanism.
< michagogo>
So just reversing the command used in make-base-vm wouldn't work either, but I'm sure it's possible to do the same thing if you know how to use the tools.
< wumpus>
I think most straightforward would be to start the vm using the base image directly, then upgrade that, skip the copy/move step at the end
< michagogo>
Anyway, for KVM, you're probably just better off creating a new image anyway. If I'm not mistaken, when you upgrade the base image, something about the way the upgrade process works means that the automatic upgrade as part of the building is broken and that breaks the whole build, so you need to repeat the upgrade process every time anything updates
< wumpus>
right
< michagogo>
Yeah, probably. I just don't know enough about KVM to get into that… And I'm running inside a VM anyway, so I'm stuck with LXC
< michagogo>
With KVM, you can just create a new base image and be done with it, whereas with LXE you have to do the whole upgrade-the-base thing because of the debootstrap switch.
< wumpus>
I first accidentally created a lxc image, that takes quite a bit longer
< michagogo>
Eh? LXC should take less time than KVM
< michagogo>
Or maybe not, I don't remember all the details.
< michagogo>
Anyway, g2g... In a couple hours hopefully I can get someone to boot my computer, remote in and kick off the rc2 builds.
< michagogo>
(Oh, and just to make sure: you saw my note about the wrong release name for 0.10-win, right?)
< wumpus>
michagogo: hm?
< wumpus>
nothing should have changed there
< wumpus>
oh I see now, using the wrong windows dirname in my script
< wumpus>
michagogo: removed my 0.10.3rc1 win sigs, indeed, 0.10 was pre-detached windows signatures
< fanquake>
btcdrak Have you contributed a gitian build to the sigs repo?
< btcdrak>
I'm just building 0.10.3rc2 now
< michagogo>
wumpus: yeah, it's a good thing that Friday night I ran the 0.11 build and not the 0.10 build. I only realized later that I probably had to tweak the script for it to do 0.10 right.
< fanquake>
wumpus Your sig is missing from the 0.10.3rc2 osx dir
< wumpus>
fanquake: huh, will add
< fanquake>
Anyone running osx 10.11 that can test mounting the latest RC ? See #6800
< michagogo>
Side note: I'm kinda surprised nothing breaks when a gitian build is running in LXC in Ubuntu in Virtualbox in Windows and Windows hibernates
< michagogo>
-Whois cfields cfields
< michagogo>
...
< michagogo>
Oops
< tripleslash>
michagogo, that's quite the chain of environments
< michagogo>
tripleslash: it's really just 3 layers
< michagogo>
LXC in VM
< michagogo>
But yeah
< michagogo>
wumpus: are you able to detached-sign, or does cfields need to do it?
< michagogo>
Hm, gitian idea: an option to select inputs dir
< michagogo>
Could help avoid issues like building multiple versions before detached sigs are posted
< tripleslash>
I can't speak for Virtualbox, but having used Hyper-V extensively, I know it to be very resilient with regard to suspensions.
< michagogo>
Okay, 0.10.3rc2 should be PR'd soonish
< sipa>
PRd?
< sipa>
oh, gitian sigs :)
< michagogo>
Giti-yeah
< btcdrak>
I signed too
< michagogo>
Correction: they've been added to my 0.11.1rc2 PR.
< Luke-Jr>
are rc2s tagged?
< sipa>
yes
< PRab>
Is there a proper procedure for updating your gitian gpg key? My old one expired and I noticed that new stuff has been tagged, so I was going to build it.
< PRab>
There we go, that looks good to me. The commit contains data signed by both the old and new key, so once its merged there is permanent proof that I control both keys.
< Luke-Jr>
PRab: next time just update the same PR with the new branch..
< PRab>
I couldn't do a force push through SourceTree, so that was easier.