2800+ entries in 0.305s
mod6: it's how I found a whole 'nother
patch of Elusive Snails.
ben_vulpes: armored and clearsigned body +
patch +
patch.sig, right?
funkenstein_: funk_add_privkey_wallet_tools.vpatch <-- experimental
patch sent to btc-dev mailing list
jurov: ascii_field: can i read that like you will reject any
patch that resembles anything from members or people affiliated to phoundation or "dev team"
ascii_field: if i had 'specifically' i would be submitting the
patch now.
punkman: ascii_field: my only real quibble with the preview of this (or was it punkman's ??) 'v' shown a while back, is that it used interactive questions to user << yeah it can export the
patch sequence and you can then press without interaction
punkman: I don't see why it's better than release being a manifest with a
patch sequence
punkman: mod6, release
patch means every other
patch you had not in release breaks though
ascii_field: any attempt to
patch kernel that is detected (and the traps move around) hangs the box
gabriel_laddel: ben_vulpes: to be clear - I've "banged together" nothing, unless you want to count a
patch allowing one to use truetype fonts. The majority of my work is assembling obtuse packages for noobz with justification as to *why* certain decision were made.
mircea_popescu: no, just make a special
patch (for historical reasons called a manifest) that does exactly what you describe
assbot: Logged on 24-09-2015 21:54:55; phf: well, the
patch gives special status to ips that were explicitly provided. if you're being mitm'd, your only recourse is operator intervention, the goal of the
patch was to ensure that your recourse does not automatically become "use random shmoe"
gernika: wedged - due to not having the
patch yes
ascii_field: as in, didn't have the bdb locks fix
patch applied ?
phf: well, the
patch gives special status to ips that were explicitly provided. if you're being mitm'd, your only recourse is operator intervention, the goal of the
patch was to ensure that your recourse does not automatically become "use random shmoe"
☟︎ phf: -connect based nodes in large avoid this problems because there's a mainloop that keeps adding same -connect supplied addresses over and over again, so even if elsewhere it's decided to drop the node, it'll be added and reconnected again on the next iteration. never the less a connect node can still be banned for misbehaving, which is something that his
patch prevents from happening
phf: to misbehave, idle however long and send data as large as they want. what's not implemented: prioritizing trusted nodes over others during node selection: you might still lose connection by natural means, in which case -addnode nodes will be dropped, and a standard node selection mechanism is used. the
patch so far is here
http://paste.lisp.org/display/155710. i'm thinking that ultimate vs. trusted distinction might be unnecessary. i would
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?
phf: i think there was a conversation at some point how diff/
patch doesn't create empty directories and you have to resort to .keepme hacks, it was suggested that the correct solution is to
patch makefile.unix instead, but i don't think that was done
mod6: <+punkman> maybe it could appear when you mouse over an edge, the files a
patch "inherits" from a previous
patch << exactly this
punkman: maybe it could appear when you mouse over an edge, the files a
patch "inherits" from a previous
patch mod6: <+ascii_field> see if you can make the
patch names clickable links << i'll see what I can do. thx.
ascii_field: see if you can make the
patch names clickable links
mod6: as far as the 'experimental' patches, i agree about the 'maxint_locks'
patch.... maybe there's a better word than experimental. and, anyway, this will all change soon anyhow, so not sure how urgent it is.
ascii_field: mats: seller, for instance, can disclose the
patch immediately after sale
trinque: does this require a musl
patch? does this ...
mircea_popescu: "this bear likes to fuck people ; you an tell it's horny by the red
patch above its nose" IS a warning.
punkman: on an unrelated note, I think I have a rough algorithm for dealing with V
patch conflicts
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 mircea_popescu: "Anyone who has arrived early at a general admission event will recognize the feeling. You lay out your blanket, thus marking off a small piece of territory for yourself. The other early arrivals do the same. After a while, you start to feel as though that
patch of land is yours by right.
ascii_field: these would expand to actual (colourized) diffs which the
patch in question concerned.
ascii_field: to see what i mean, try adding a
patch that depends on a rel1 terminus but is not built on by anything else.
jurov: i remember we discussed when the
patch went in
punkman: asciilifeform: I just noticed this earlier when I looked at press, will apply every single
patch up to HEAD
mod6: Well, one thing I don't want is a persistant store of the parents and children of a given
patch. I want it to read it fresh everytime so ensure things aren't diddled or cosmic-ray'd or just stale or something. Not sure if that's what was changed on punkmans side. But I want the one that I use to do all of this in one shot.
punkman: it's not a
patch, it's now called vit
mircea_popescu: the "with clearsigned body and .sig signature" version is exact replica of the single email i successfully sent to date, back in the days of the V
patch.
ascii_field: ideally, each 'bubble' would be clickable and contain links to download
patch and all signatures
ascii_field: it was plainly not enough to reconstruct
patch flow, yes
mike_c: No, just every
patch. I'll fiddle with it and see if anything interesting happens.
mike_c: Surely. But integrating V could allow for "this
patch solved this problem"
assbot: Logged on 05-08-2015 14:26:47; asciilifeform: mircea_popescu: i once thought about placing antecedent hashes in
patch headers
trinque: mircea_popescu: maybe not; thought was you
patch in new textfiles into some directory structure
mod6: <+asciilifeform> rather than roasting in the hell of figuring my
patch topology out with a pencil << imagine how much easier it is now for a person to literally pick a place in the flow and
patch directly to it. instead of wading through mutliated corpses trying to find the least smelly ones.
mod6: asciilifeform: qq, I was under the impression that when using press, if I picked something like 'maxint_corrected', it would
patch all the way up through that one. but it didn't seem to apply the -verifyall
patch? or do I misunderstand how its supposed to work?
http://dpaste.com/1J2BS40.txt thoughts?
ascii_field: anyway thing is made in such a way that operator is forced to remain aware of what
patch set he is pressing
assbot: Logged on 31-08-2015 14:36:31; asciilifeform: also there is no selectability of wot or
patch subsets, other than by specifying --wot customdir or same for patches, containing desired subset
ascii_field: ^ perhaps i ought to explain. picture a
patch mid-flow whose seal is annulled (removed, even if temporarily, from .wot)
assbot: Logged on 22-10-2014 18:52:16; mircea_popescu: <asciilifeform> how to do signed commits << the barbarian way. everyone who read a
patch file (yes) and is willing to sign under it, signs. this gets posted. whoever wants, can apply the patches to get a merged turdball. << i think this is exactly how it should go.
ascii_field: mircea_popescu: my point was precisely that it is a spurious distinction, and that i do not make it in the system; and that anyone who wants to try to be remembered as the first one to pen a particular
patch had better deedbot his signature
punkman: anyone try the final debug_sanity_part1
patch?
phf: "Normally this option is unnecessary, since
patch can exam- ine the time stamps on the header to determine whether a file should exist after patching."
phf: mod6: in fact if you read
patch man page, you'll see that us stripping dates basically broke that functionality
phf: mod6: try running
patch with -E ?
mod6: oh this is pretty neat. so I got the mechanics tested & rebased for rel1 -- off of classic patches & genesis.vpatch to be sure. created a "rel1.vpatch" from that. then tested it, worked good on top of extracted genesis.vpatch. then did one of these numbers "cat genesis.vpatch >> rel1-fromair.vpatch ; cat rel1.vpatch >> rel1-fromair.vpatch ;
patch -p1 < rel1-fromair.vpatch"
trinque: result of
patch -p1 < genesis.vpatch is a tree which matches the manifest.
ascii_field glad that mircea_popescu liked the concept, but noticed that he signed the old
patch ascii_field: and, for the first time ever in history of versionatrons, you can take a tree of unknown constitution and determine what
patch set it corresponds to (if any)
ascii_field: mircea_popescu: the actual
patch (optional, if the message concerns a
patch) - 2nd attach