log☇︎
121 entries in 0.468s
mod6: I hope I'm not doing anything redundant really. The Makefiles itself take care of the compilation of Boost/BDB/OpenSSL. The one thing that I still need from the rotor.tar.gz is 'openssl-004-musl-termios.patch'
asciilifeform: hanbot: it is also possible to bootstrap any vtron using naked gpg, ancient gnupatch, and bare teeth ( manually check sig and patch -p0 < foo.patch, for ea. )
bvt: they disabled weak symbols for c++/fortran components, http://port70.net/~nsz/musl/gcc-5.3.0/0004-gthr.patch
mircea_popescu: 3. you sign yet another new patch, hurr-biff.patch, referencing fixing-bugzappers.
mircea_popescu: 2. you sign another new patch, later on, "fixing-bugzappers.patch". this patch references manifest patch and ircbot-multichan-etc.
mircea_popescu: 1. you sign a new patch, manifest.patch. at this juncture, phf's viewer will show it to the side, unconnected to the tree.
phf: fair, https://github.com/bitcoin/bitcoin/commit/82a10c81707dcff5ee24dec7ef7ebf8eccfded03.patch then
shinohai: tfw sifting through old trb stuff and you find "rotor-db-configure-fix.patch"
a111: 111 results for "\".patch\"", http://btcbase.org/log-search?q=%22.patch%22
mircea_popescu: !#s ".patch"
a111: Logged on 2015-09-24 00:25 mod6: <+phf> shinohai: you probably have rm_gitignore.patch applied, which removes .gitignore files from src/obj/nogui and nukes the folders along the way? << i said to disregard this patch. reason is, it wipes out output dirs required by the bitcoin makefile.
asciilifeform: ( you have a .wot, .seals, .patches, these can be named something else, but these are their conventional names; out of these, vtron 'presses' a particular tree that you want.)
asciilifeform: i just said above: you put it in the .patches dir. and its seal, in your .seals
asciilifeform: the vpatch will go in your .patches, where everything from genesis onwards lives
phf: http://lisphacker.com/temp/lispos/os-0.9.14-m3.patch
asciilifeform: this is pure martian-level surreality: gnat-gcc-...[crapola].patch doesn't exist. but no package takes ownership of it.
asciilifeform: * ( gnat-gcc-4.9.3-make-default-paths-match-slot.patch )
asciilifeform: * /usr/portage/dev-lang/gnat-gcc/files/gnat-gcc-4.9.3-make-default-paths-match-slot.patch
a111: Logged on 2016-12-26 02:38 phf: ben_vulpes: according to master this is the reason http://glyf.org/tmp/ironclad-sha512.patch unsigned for obvious reasons
phf: ben_vulpes: according to master this is the reason http://glyf.org/tmp/ironclad-sha512.patch unsigned for obvious reasons ☟︎
asciilifeform: i will rephrase again for clarity: for so long as you have 1 pubkey, which was used to make 1 seal, and that seal is for one, single patch, your only one, a genesis, you can display a flow. and literally every other file in .seals, .wot, .patches can be a lolcat.
mircea_popescu: mod6 the idea is that you should be able to alter the end product by altering .wot rather than by altering .wot AND .patch or .seal
asciilifeform: (would apply patch regardless of signed or not, if present in .patches)
asciilifeform: patch -p0 < foo.patch ?
a111: Logged on 2015-06-24 18:15 ascii_field: ben_vulpes, mod6, mircea_popescu, et al: can anyone recall why http://therealbitcoin.org/ml/btc-dev/attachments/20141218/bitcoin-v0_5_3-rm_checkpoints_41327b9a962e6d27869f4d361d742ab5c7061ede.5.patch didn't make it in ?
a111: Logged on 2015-06-24 18:15 ascii_field: ben_vulpes, mod6, mircea_popescu, et al: can anyone recall why http://therealbitcoin.org/ml/btc-dev/attachments/20141218/bitcoin-v0_5_3-rm_checkpoints_41327b9a962e6d27869f4d361d742ab5c7061ede.5.patch didn't make it in ?
mod6: !!deed http://mod6.net/deeds/rotor-db-configure-fix.patch.asc
mod6: the two .sh scripts you have in there can be integrated into the makefiles directly i think. however, we'll still need the openssl-004-musl-termios.patch and rotor_buildroot_dot_config
assbot: Logged on 28-02-2016 03:38:49; phf: 1) brew install cmake 2) patch < foo.patch 3) link_directories and include_directories in CMakeList.txt need to point to be modified to point to your boost/db4/openssl locations 4) mkdir foo; cd foo; cmake ..; make
phf: 1) brew install cmake 2) patch < foo.patch 3) link_directories and include_directories in CMakeList.txt need to point to be modified to point to your boost/db4/openssl locations 4) mkdir foo; cd foo; cmake ..; make ☟︎
assbot: shiva_hooks.patch · GitHub ... ( http://bit.ly/20NR2ma )
assbot: shiva_hooks.patch · GitHub ... ( http://bit.ly/20NQyMF )
gernika: mod6: testing out v99995. I notice that if I attempt to press a non-existant v.patch, there is no error, and it goes ahead and presses *something* (seems to generate the full source in the target dir). Not sure if this is intended behavior or not.
mod6: kako: http://therealbitcoin.org/ml/btc-dev/attachments/20150808/rotor-db-configure-fix_a955ba9174ccb17790dc9d7c1e2a61794a1c803d.patch
BingoBoingo: http://ftp.openbsd.org/pub/OpenBSD/patches/5.7/common/022_ssh.patch.sig
mircea_popescu: http://log.bitcoin-assets.com/?date=28-12-2015#1354663 <<< genesis.patch. ☝︎
asciilifeform: ;;later tell jurov http://therealbitcoin.org/ml/btc-dev/attachments/20151219/mempool_dev2_a654caa4f28ed6f78906fef28060c2f46470f067.patch << why not vpatch ?
mod6: <+phf> shinohai: you probably have rm_gitignore.patch applied, which removes .gitignore files from src/obj/nogui and nukes the folders along the way? << i said to disregard this patch. reason is, it wipes out output dirs required by the bitcoin makefile. ☟︎
phf: shinohai: you probably have rm_gitignore.patch applied, which removes .gitignore files from src/obj/nogui and nukes the folders along the way?
asciilifeform: ;;later tell mod6 therealbitcoin www points out, correctly, that certain patches (e.g., asciilifeform_tx-orphanage_amputation.patch) are considered experimental; but asciilifeform_maxint_locks_corrected.patch is pretty much mandatory - node will not sync without it, afaik.
mircea_popescu: h < asciilifeform_dns_thermonyukyoolar_kleansing_691f046b0a66c2c80deecd8df0b42d11665b0396.patch < asciilifeform_ver_now_5_4_and_irc_is_gone_and_now_must_give_ip_ebed1af0253ef629bbef4bf2b2d1a94742a81f0e.patch
mircea_popescu: bitcoin < asciilifeform_dnsseed_snipsnip_192f7bc7c14c1d31c7b417c9cd77be51c4d255f2.patch < asciilifeform_orphanage_thermonuke_2d219fdd1a0da960be38797566e9c0820df11ce6.patch < asciilifeform_tx-orphanage_amputation_6ed529e594301a791fb2f8becbe344dd2de9c45f.patch < asciilifeform_zap_hardcoded_seeds_a367b89765d0b82ce2c7f8043f52006399a1e0b8.patch < asciilifeform_zap_showmyip_crud_ebf527ba3b180b1952c4c8b5af990c1fd61e04da.patc
mircea_popescu: asciilifeform_dnsseed_snipsnip_192f7bc7c14c1d31c7b417c9cd77be51c4d255f2.patch
mod6: asciilifeform: ok, got it figured: check here please: http://thebitcoin.foundation/misc/rel1-test-20150822.patch && http://thebitcoin.foundation/misc/rel2-pre-test-20150822.patch
mod6: ok, here is the diffs between your posted patches w/timestamps v. new ones w/o ts: http://thebitcoin.foundation/misc/rel1-test-20150822.patch && http://thebitcoin.foundation/misc/rel2-pre-test-20150822.patch
thestringpuller: asciilifeform: what ended up happening with this patch? << http://therealbitcoin.org/ml/btc-dev/attachments/20150803/asciilifeform_jettison_mempool_195c600991e7306b0f21eddd834b38b9301cf12b.patch
pete_dushenski: hanbot: your stator build didn't get wedged even though you didn't add the asciilifeform_maxint_locks_corrected.patch ?
mod6: orchestra/rel2-pre.patch v. orchestra/test-v054-patches/rel2-pre-test.patch
mod6: orchestra/rel1.patch v. orchestra/test-v0531-patches/rel1-test.patch
mod6: So I've basically been able to reproduce both of your rel1.patch & rel2-pre.patch -- and I went through your patch with my script's created patch side by side by hand and verified the sha512s
mod6: asciilifeform: I have successfully reproduced the rel1.patch on my own now with the same matching antecedent/new hashes. I have script that reproduces this all the way up through v0.5.3.1 -- will continue on and do the same for up through v0.5.4 before let everyone see. But, so far, so good.
mod6: asciilifeform: ok cool! rel1.patch and rel2-pre.patch do apply cleanly to all of the existing patches
asciilifeform: to edit rel1.patch and rel2-pre.patch.
gernika: mod6 I applied asciilifeform_maxint_locks_corrected.patch
n6: i'm getting "patch -pl < buildroot-asciilifeform-pogov4_0567b86c55934a8b5d1351b4ccba9306ee3406c3.patch" when running patch -p1 < buildroot-asciilifeform-pogov4.patch
n6: I don't see buildroot-asciilifeform-pogov4.patch in the list of files.
hanbot: the ml patching guide (http://therealbitcoin.org/ml/btc-dev/2015-March/000067.html) step 0x07] Clean Source Base involves manifests which i take it are part of the guide's referenced patch tarballs. given the stator patch battery is single .patch file only, how's one to handle this step (and why does guide assume patch will come in ball?)?
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
assbot: Logged on 05-08-2015 18:55:16; mod6: now, it might be that I'm not exactly understanding what the proceedure for submitting to deed bot would be. but if clearsigned .patch files, that can not work.
ascii_field: http://therealbitcoin.org/ml/btc-dev/attachments/20150710/asciilifeform_add_verifyall_option_e35906e7432550b0cadd46bbc253258d39a8c210.patch << loads in all browsers
assbot: Logged on 05-08-2015 18:55:16; mod6: now, it might be that I'm not exactly understanding what the proceedure for submitting to deed bot would be. but if clearsigned .patch files, that can not work.
ascii_field: while preserving the simultaneously total and minimal representation of .patch
mod6: will deedbot take 2 parameters, a non-signed .patch file and a detached signature and somehow colese them?
mod6: now, it might be that I'm not exactly understanding what the proceedure for submitting to deed bot would be. but if clearsigned .patch files, that can not work. ☟︎☟︎
jurov: (currently on has to clearsign the .txt, make detached armored sig for .patch and use non-braindamaged email client to put them together)
jurov: how would it look for user? got a .txt, a .patch , now what?
asciilifeform: ;;later tell ben_vulpes i have nothing against 'git', 'mercurial', etc., and even sometimes use these in civilian life, there is even somewhere ~horror~ a 'github' page with my name and some old crud, yes. but the ~canonical walk from pedigreed 0.5.3 to therealbitcoin~ has to be in .patch form!
mod6: Thanks all for working lastnight to get the db locks issue resolved! I've got a new bitcoin-v0_5_4-TEST2 bundle created. Patch added was `asciilifeform_maxint_locks_corrected.patch'. Applies cleanly. All automated tests passed.
mod6: i might just be dumb. build a test env with http://dpaste.com/23VKWD8.txt and see if anyone can get the rm_gitignore.patch file to apply without removing the obj/test obj/nogui or obj-test dirrs
mod6: so yeah this is annoying with `patch`. if you do `patch -p1 --posix < rm_gitignore.patch` it doesn't remove the dirs /or/ the files, just leaves 'em truncated. which is dumb too.
punkman: mod6: try adding a newline at end of .patch file
punkman: it's still a mess, will need debug_sanity_part2.patch
asciilifeform: punkman: http://therealbitcoin.org/ml/btc-dev/attachments/20150713/punkman_debug_sanity_part1_f0023d64470b05705a891da5b52bb1c24eed955b.patch << neato
jurov: there is one empty line in the end of received .patch
punkman: hmm I downloaded .patch attachment and it fails indeed
assbot: 200-cstdint_missing_include.patch in packages/libs/boost/patches – OpenWrt ... ( http://bit.ly/1NCy6Bd )
trinque: then this happened: https://dev.openwrt.org/browser/packages/libs/boost/patches/200-cstdint_missing_include.patch?rev=34635
assbot: dpaste: 2DDHFF4: jautenim_openssl_docs_snip.patch.sig ... ( http://bit.ly/1f1Ifwl )
assbot: dpaste: 2XV9P7V: jautenim_openssl_docs_snip.patch ... ( http://bit.ly/1f1IebW )
ascii_field: where is this 'turd.patch' ?
jurov: much better that turd.patch
ascii_field: how is asciilifeform_ver_now_5_4_and_irc_is_gone_and_now_must_give_ip_ebed1af0253ef629bbef4bf2b2d1a94742a81f0e.patch an improvement over asciilifeform_ver_now_5_4_and_irc_is_gone_and_now_must_give_ip.patch ?
ascii_field: ben_vulpes, mod6, mircea_popescu, et al: can anyone recall why http://therealbitcoin.org/ml/btc-dev/attachments/20141218/bitcoin-v0_5_3-rm_checkpoints_41327b9a962e6d27869f4d361d742ab5c7061ede.5.patch didn't make it in ? ☟︎☟︎
mod6: well, so here's the deal. I can't get it to compile "by hand". meaning, that if i extract the 2 bzip'd files for uclibc: uClibc-0.9.33.2.tar.bz2 & uClibc-0.9.33.2-patches.tar.bz2 and then patch the former with the latter with something like this: for i in `ls ../patch/*.patch | sort` ; do patch -p1 < ../patch/$i ; done
mod6: well, i've got the stdint thing figured out for the time being. i've applied your patch "asciilifeform-kills-integer-retardation.patch" and "nubs-gentoo-sanity.patch".
mod6: <+asciilifeform> mod6: please post any data you may have collected at the moment of the oomkill << so just to reiterate here, the current perf test I'm running is with the v0.5.3.1-RELEASE which oomkill'd (as it's known to do). I'll post the nmon charts, log, and vmstat log. no core file was created. However, as a reminder, the previous perf test that I ran with v0.5.3.1-RELEASE+{asciilifeform_orphanage_thermonuke.patch}(http://thebitcoin.foun
mod6: ascii_field: I'm running with this patch: http://therealbitcoin.org/ml/btc-dev/attachments/20150504/asciilifeform_orphanage_thermonuke_2d219fdd1a0da960be38797566e9c0820df11ce6.patch
mod6: 9d7cab14db48000ed91d12301f19341ce55e86fe919922f8a4f80f49625b881b296deb037d35ef899996e097b4f1c0ab5a035c2ced04758b9838f3924ce4ed78 asciilifeform_orphanage_thermonuke.patch
mod6: # sha512sum asciilifeform_orphanage_thermonuke.patch
asciilifeform: sha512(asciilifeform_orphanage_thermonuke.patch) == 9d7cab14db48000ed91d12301f19341ce55e86fe919922f8a4f80f49625b881b296deb037d35ef899996e097b4f1c0ab5a035c2ced04758b9838f3924ce4ed78
mod6: -rw-r--r-- 1 root root 4007 May 5 00:19 asciilifeform_orphanage_thermonuke.patch
mod6: curl -s http://therealbitcoin.org/ml/btc-dev/attachments/20150504/asciilifeform_orphanage_thermonuke_6f320afb2423a2892d89e855829e3915c8b7a170.patch.sig -o asciilifeform_orphanage_thermonuke.patch.sig
mod6: curl -s http://therealbitcoin.org/ml/btc-dev/attachments/20150504/asciilifeform_orphanage_thermonuke_2d219fdd1a0da960be38797566e9c0820df11ce6.patch -o asciilifeform_orphanage_thermonuke.patch
asciilifeform: it should go without saying that asciilifeform-kills-integer-retardation_8685d541f20bcfe8d8cc9fefba663dd861f7b237.patch is not a tree candidate !
nubbins`: http://therealbitcoin.org/ml/btc-dev/attachments/20150401/asciilifeform-kills-integer-retardation_8685d541f20bcfe8d8cc9fefba663dd861f7b237.patch
asciilifeform: ben_vulpes: http://therealbitcoin.org/ml/btc-dev/attachments/20150128/asciilifeform-porta-tronic_67d6162e1cc78b3a6aca584e2123e59fdee189f6.patch
mod6: next part here... in your email, it seems that you apply your patch "asciilifeform-kills-integer-retardation.patch", and this doesnt seem to completely solve it...
ascii_field: this is -after- i apply my http://therealbitcoin.org/ml/btc-dev/attachments/20150128/asciilifeform-porta-tronic_67d6162e1cc78b3a6aca584e2123e59fdee189f6.patch << the second half, you folks did merge the first
nubbins`: http://therealbitcoin.org/ml/btc-dev/attachments/20141112/bitcoin-asciilifeform_ea4c4745bc4b10fc19bf0a2be7d0797dfd948a33.2-https_snipsnip.patch
nubbins`: in a perfect world, remove_wallet.patch