Matches for patch, 1691 total results Sorted by newest | relevance
Wed Feb 17 15:51:05 UTC 2016 <phf> mircea_popescu: there's another patch there that's named differently that does same thing
Wed Feb 17 15:49:50 UTC 2016 <mircea_popescu> ie, if patch on ml is X, patch on base is X
Wed Feb 17 12:54:09 UTC 2016 <asciilifeform> http://log.bitcoin-assets.com/?date=17-02-2016#1408030 << it had own genesis to establish pedigree with the historic tinyscheme. but shiva is a patch that bridges it into the trb tree. and yes i rebased it, it works with the current trb.
Wed Feb 17 08:17:51 UTC 2016 <phf> which makes me wonder about some of the patches and how to do conflict resolution, for example http://btcbase.org/hash/BDC4FC472BE4A86FB91FA69368FAACE04414FDEEE5B8C82795E31D37E21581B973CAF7F3E9CCC27D487944A5782E3B59615180EAB87C8B3E81242901F3039E4D all patch wallet.cpp towards a divergent state
Wed Feb 17 08:13:28 UTC 2016 <phf> can click on a hash from patch display and get a list of producers and consumers, like http://btcbase.org/hash/BDC4FC472BE4A86FB91FA69368FAACE04414FDEEE5B8C82795E31D37E21581B973CAF7F3E9CCC27D487944A5782E3B59615180EAB87C8B3E81242901F3039E4D
Wed Feb 17 05:49:58 UTC 2016 <punkman> phf, seems so. my initial suggestion was releases as patch sequence files, but I don't think anyone liked this idea. My vtron does .seq files with "foo.vpatch \t sha512(foo.vpatch) \n" inside, which works for my blobby vtronized things.
Wed Feb 17 03:30:02 UTC 2016 <mod6> so what would be great here, is if you apply the patch, or use the v.pl attached to the email (check the sigs ofc), then start clean, do a fresh `./v.pl i http://thebitcoin.foundation`, and then press out the entire tree, `./v.pl p v v054 asciilifeform_maxint_locks_corrected.vpatch`, then `cd v054` and run that find command at the top of this pastehttp://dpaste.com/2SQ1VZ7.txt
Wed Feb 17 02:51:05 UTC 2016 <mod6> i even had a thought, and im not even sure its feasible technically or just logically, but; we could perhaps create a wrapper for gnu patch where we strip out lines that are surrounded with "%%" or something similar to how it does with "@@", this would ultimately be needed in vtron as well to avoid issues. But the thought is, then we could put comments directly in the vpatch (surrounded by '%%') and
Wed Feb 17 02:48:26 UTC 2016 <phf> maybe press a new genesis with skull&crossbones in comments of header of every file. patch file contents will be identical, but hashes all different
Wed Feb 17 02:42:29 UTC 2016 <assbot> Logged on 12-02-2016 14:13:21; polarbeard: works like a charm, here is a patch for removing some unused functions if somebody is interested: https://github.com/polarbeard/trb/blob/master/patches/polarbeard_rm_unused_functions.vpatch https://github.com/polarbeard/trb/blob/master/sigs/polarbeard_rm_unused_functions.vpatch.polarbeard.sig
Wed Feb 17 02:39:57 UTC 2016 <mod6> and also in other news... I'm going to publish a one line change to add a bit more strictness (less fuzz) to the map building part of V -- was basically overlooked on the last beta patch (#3). So this one will be #4, and barring any further big issues, this should be it.
Tue Feb 16 20:17:47 UTC 2016 <mircea_popescu> "* An example of Red Hat's "find and fix the whole issue, not just the obvious part", is shell shock. After the initial CVE for shell shock, several people proposed different ways of fixing it. Florian was one, he quickly worked on it and released a proposed patch. Over the next few days there were three MORE CVEs for shell shock, covering different variations on the same theme. Florian's initial patch covered all of t
Tue Feb 16 16:17:38 UTC 2016 <assbot> Carlos O'Donell - [PATCH] CVE-2015-7547 --- glibc getaddrinfo() stack-based buffer overflo ... ( http://bit.ly/1LrHMwR )
Tue Feb 16 15:09:04 UTC 2016 <mod6> morning, just a heads up here. ben has been testing V for me, and we're going through it. might need another patch tonight.
Sun Feb 14 19:08:13 UTC 2016 <mod6> ok, so instead what I'll do here is add an automated test to check for this, so i don't regress later. and then most likely will put out a 3rd beta patch for people to test/review.
Sat Feb 13 23:24:49 UTC 2016 <mod6> last chance to test that beta_2 patch for V if you still want to do so.
Sat Feb 13 18:37:19 UTC 2016 <mircea_popescu> i am thinking : maybe including a comment line as "this patch is intended to be applied on prev hash blabla" would do it.
Sat Feb 13 18:27:59 UTC 2016 <ben_vulpes> perhaps a better formulation would be that there are those who curate their own patch selection and those who delegate to the foundation.
Sat Feb 13 02:38:12 UTC 2016 <mod6> well, we need to make a 1 line change to the 99996 build script, and then update the wiki. BUT on the other hand we're gonna need 99995 soon anyway, as soon as some people beat up on my latest patch for V.
Sat Feb 13 02:09:11 UTC 2016 <mod6> huh. for some reason, it didn apply that patch