19800+ entries in 0.03s
mod6: yeah, that's after we freeze everything though right?
mod6: ah shinohai, location echo?
mod6: If someone wants to give it a try on x86_64 on a similar linux let me know. I've had to install a few pre-reqs on a totally bare minimum 10.04 like: build-essentials, curl, rsync, and unzip
mod6: So Shinohai and I just got done testing my TEST2 bundle with rotor script. We've built successfully on: Gentoo/glibc, Ubuntu 10.04, Debian 6 and Debian 8 :: All x86_64
mod6: trinque: sig verifies & patch applies cleanly. thx again.
mod6: yah, I left him a note to re-send a patch with a detached sig to the ML. can help or do it for him if required, etc.
mod6: was a gentoo/glibc environement -- compiled buildroot with the musl settings. didn't change anything to the "rotor" steps execept for adding the change to BDB configure options in trinque's message.
mod6: was nice to see rotor build cleanly today btw.
mod6: once we have that, and a new patch from trinque, i can complete my script and have a rotor that builds these test bundles with x86-64
mod6: ok. that's my next basic goal. build a patched bundle up through verify-all with rotor.
mod6: so it wouldnt be a waste of my time to proceed in that direction?
☟︎ mod6: do you think we should even bother with block dump/eat, -verify all?
mod6: was thinking that next I'll work on a patched bundle up through -verify all with rotor. and then work ourselves up to a place where we feel comfortable.
mod6: it has to be downloaded seperately. thats fine. i did this today.
mod6: so i don't wanna seem like im replicating work; just trying to clean it up a bit.
mod6: yeah. but your bundle doesn't have the right directory structure, and doesn't really have a patching trail or anything.
mod6: asciilifeform: so, what my goal is, short term, is to produce a bundle that (similar to TEST2) is patched up through -verifyall that we can drop into the rotor, and use that for testing next.
mod6: I can not wait until we get past all of this.
mod6: I appreciate you trying to build it.
mod6: pete_dushenski: don't bother with the testing for TEST2 (or anyone else), just work for now on building rotor.
mod6: im mis remembering that from v0.5.3.1
mod6: However, I have seen that on Ubuntu & Debian if you build boost without libboost-python-dev boost will complain -- it will still compile, but it'll complain. it complains less with the python errors if it has that and the libbost-python-dev dependentcies installed.
mod6: Right, should be trying to bulid the Rotor, really.
mod6: Let me dig something up for you here quick.
mod6: <shinohai> funkenstein_ confirmed that the bug is only on my end, and not in bitcoind << ok thanks for the update
mod6: If that's what you mean. So in this case, SHA1 instead of SHA256, unless that's not what you were referring to.
mod6: <+hanbot> re ml: where are sha256sums for, eg,
http://therealbitcoin.org/ml/btc-dev/2015-February/000040.html (patch)? << Hi, in the case of that patch email, the SHA1 sum is embedded in the file name. For example: asciilifeform_dnsseed_snipsnip_192f7bc7c14c1d31c7b417c9cd77be51c4d255f2.patch -- if you were to download this patch, you could then run `sha1sum asciilifeform_dnsseed_snipsnip_192f7bc7c14c1d31c7b417c9cd77be51c4d255f2.patch` and it sh
mod6: If not, I can do it for you. Just let me know what works, or if you need help.
mod6: trinque: would you be opposed to resubmitting your patch for the rotor to the ML as a attachment with a detached sig? I have a list of concise steps that is basically a simple script to do all of the steps to build rotor/static-deterministic-stator just need to get that piece into place. that's the only manual step at this point.
mod6: asciilifeform, mircea_popescu, ben_vulpes: rotor built successfully.
☟︎ mod6: Ok, yup, next try on v0.5.3
mod6: specifics are good :]
mod6: other versions as in .. from us? or from power rangers?
mod6: It also couldn't hurt to describe exactly what you're trying to do in here.
mod6: shinohai: ok, did you get a chance to try it on v0.5.3?
mod6: The whole 'we need to get to a sane environment -- let's use Gentoo' idea was pre-dated the rotor. Now I just gotta get rotor to work for me :]
mod6: Sure thing. Agree 100%, but since 'rotor' can run on any "sane" linux (to quote ascii), we don't have to marry ourselves to Gentoo and thereby also provide steps to build Gentoo. As 'rotor' should work basically anywhere. Needs to really.
mod6: I appreciate your giving it a run through.
mod6: It took me 6 weeks to build that thing with tons of Trinque's help. n6: I understand your frustration totally.
☟︎ mod6: So now that we have 'rotor', most likly we won't need to have the gentoo guide. We'll see how it goes but in the future we'll probably just point people at the gentoo handbook if they want to run Gentoo.
mod6: Been bogged down with fiat job manditory overtime bs.
mod6: I'm gonna re-tackle the rotor build tomorrow btw.
mod6: <+ben_vulpes> twould please him no end to see test reports coming in from that platform << certainly let me know how it goes. yeah, might have issues with rotor on there. I'm still sync'ing my obsd bitcoind build (patched up through -verifyall).
mod6: hanbot: good news! thanks for the update
mod6: was just derpin i guess.
mod6: <+asciilifeform> them & the grapher. << i can live with this.
mod6: but i see your point.
mod6: i just figured it was a neato way to keep the patches that we sign separate from the rest of the heap of stuff.
mod6: no different than what we're already doing.
mod6: <+mircea_popescu> moreover, it just puts you in harm's way mod6. << well. not all patches, just ones that we've signed off on anyway.
mod6: well, nevermind then.
mod6: on the other side of the coin, if we do something like this with deedbot, we need to ensure a mirror is always available.
mod6: so i guess all in all, the deedbot solution, if it can be created, seems better than my initial proposal of 2 mailing lists; one for everything, one for patches accepted only. which seems simple as well, but now we have to manage two lists.
mod6: maybe something can be added? like trinque is saying? i dunno.
mod6: i guess this thought was sort of a work in progress.
mod6: that way it sort of also solves the problem of keeping track of who signed which patch. since deedbot stores these sigs in a horizontal fashion next to the address.
mod6: oh, i think he was saying that he would need to implement accepting a second argument and making it so that the URL contains a hash of the original plaintext patch.
mod6: trinque thinks this might be able to be implemented without moving heaven and earth
mod6: but what if we then, say, at the end of a testing/release cycle were to (instead of signing or as well as posting to the mailing list) post the plaintext patch and a detach signature from the originating author, myself & ben to deedbot as a perm storage for these patches?
mod6: ok so was kinda thinking about something here... so we all love to hate the mailing list in a way - but it's a decent spot to post new things, experimental, SoBAs etc. But it's not good for keeping track of patches that /actually/ are accepted and a part of a given "release".
mod6: well and probably error prone if he/she has to cut the upper text out just to get down to "bare" patch to re-clearsign and submit to deedbot... could miss line, something bad.
mod6: that would be the way to do it as I said earlier. but not sure if that's really feasable.
mod6: but then you could just have detached sigs?
mod6: im not ciked about that either.
mod6: ok so another question i have about the deedbot way.. would be: if we submit a patch to deedbot, how do we tie a message to that same submission? say we wanna be like "Hey, this thing is neat!" Will it need to reference anothe deedbot submission or does the patch have to come after our statment in the clearsigned message?
mod6: had to look that up.
mod6: was gonna say. "how does that makes sense?!"
mod6: it doesn't ask. derp.
mod6: oh actually, im wrong about that.
mod6: main difference seems to be... we would now need to enter our password every time to verify the signature as opposed to just --verify
mod6: <+jurov> mod6 decrypt on *clearsigned* file << this indeed works. created file A.txt. copied A.txt to B.txt and subtracted some lines. created a unified diff of both. clearsigned the diff -- which is mutilated for escaped hyphens. upon `gpg --decrypt` of the clearsigned output patch file, i get the same hash as the pre-clearsigned hash file.
mod6: <+mircea_popescu> already sounds like a quantum leap tbh << it is.
mod6: <+mircea_popescu> mod6 ^ give that a long think. << i like this idea with the wot graph + source patches as a tree next to it so relations can be easily seen & drilled into.
mod6: ah, encrypt/decrypt, but we want clearsign or am i misunderstanding this?
mod6: and honestly, this is no poor reflection on deedbot. the thing is cool.
mod6: i guess for me thats the one big thing, we can't have any mutilation of the patch files. or we'll just find ourselves banging our heads all the time.
mod6: ok then we're settled.
mod6: <+danielpbarron> can't you unmutilate by using gpg --decrypt ? <+jurov> mod6 just do gpg --decrypt and it undoes it