3200+ entries in 0.265s
ascii_field: mod6: i kinda assumed you and ben_vulpes would roll the
patch sequence docs into releases
mod6: there are a number of different directions these emails go in; patching for v0.5.3.1, pogotronic, gentoo, etc, etc. so I'll try my best to make this apparent when I write up a
patch list, etc.
assbot: Logged on 03-07-2015 19:44:53; phf: mod6: well, lets say you have something like mutt open with the current email. it's pretty easy to write a script that takes current email and feeds it to an external script, that splits out
patch, verifies it with the provided sig, and then applies it to the codebase (or pushes it into some queue of patches as a case may be). i.e. you read the email, push "p" to do everything for you, and then move on to the n
mod6: basically, instead of me making a whole bunch of different one-off scripts for peoples seperate clients and whatever stack they've got, I just create one script that will
patch in & verify all the scripts at once. usually after I've tried and tested them all myself, peronsally.
phf: mod6: well, lets say you have something like mutt open with the current email. it's pretty easy to write a script that takes current email and feeds it to an external script, that splits out
patch, verifies it with the provided sig, and then applies it to the codebase (or pushes it into some queue of patches as a case may be). i.e. you read the email, push "p" to do everything for you, and then move on to the next email
☟︎ mod6: <+phf> mod6: no no each email. i thought that was the whole point of ascii's approach, i.e. linux kernel style "read email, think, apply the
patch" << im not sure what their process is.
phf: mod6: no no each email. i thought that was the whole point of ascii's approach, i.e. linux kernel style "read email, think, apply the
patch"
phf: mod6: i don't necessarily have problems, i have a bitcoind with all the patches up to eatblock (haven't looked at stator yet, but then i'm building with enemy tools). the way i assembled patches is by reading through web archive and saving/verifying each
patch as i saw it
mod6: ex: are you trying to
patch v0.5.3 to get to v0.5.3.1? (You can just download the release tarball). Are you trying to
patch v0.5.3.1-RELEASE with alf's patches? (must read emails to figure out the deps, OR you can just build the stator which includes all of alf's patches with exception of dumpblock & eatblock), those must be patched post extraction of the stator tarball -- of which im actually testing now.
mod6: I will work on a
patch list and maybe a script later this month. It is a bit hard to follow.
☟︎ phf: mod6: it would be nice to have an mbox or maildir tgz for the mailing list with all the attachments still included. took me couple of hours to reconstruct and verify
patch list, while could've been done in matter of minutes with procmail and mimetools
ronaz: we are also shipping first
patch of Denarium coins in a weeks time
assbot: Logged on 30-06-2015 17:59:00; mod6: ah, i don't think you're in assbot's L2. Sorry if I wasted your time. Just send the
patch to me: modsix@gmail.com
decimation: these were made with your thermonuke
patch mod6: I did it like that because the list of
patch names is far too long. makes it look kinda ridiculous in the header
shinohai: @ mod6 so no more manual
patch applications?
mod6: <+mod6> plz clearsign your email, and attach a detached signature of the
patch file << along with the
patch itself i might add!
mod6: plz clearsign your email, and attach a detached signature of the
patch file
mod6: ah, i don't think you're in assbot's L2. Sorry if I wasted your time. Just send the
patch to me: modsix@gmail.com
☟︎ mod6: <+Jautenim> shall i submit a
patch to the mailing list? it's quite a simple fix << If you're in the WoT (looks like you are) feel free to submit a
patch as you like.
mod6: Jautenim: sorry, I had it kinda mixed up. The
patch link I posted is to resolve the issue where the libs and headers don't get copied over.
Jautenim: but this
patch don't seem to avoid the offending makefile directive, does it?
mod6: nubs submitted a
patch for that -- it'll be fixed in the next milestone for sure. thanks for the heads up Jautenim.
Jautenim: shall i submit a
patch to the mailing list? it's quite a simple fix
decimation: asciilifeform: yeah that's the kind of
patch I was implying
ben_vulpes wonders at actual utility of a
patch shaped like this
jurov: asciilifeform: ^ we're back to using our own
patch hashes somehow
ascii_field: notice that you don't even need the
patch file for this
mod6: so after review you just expect or perhaps exepect to just see a .sig file attached alone without the
patch itself?
jurov: and user is unwilling to work with
patch ID the system must somehow heuristically
mod6: anyway, i like the idea of a checksum for the patches. if we can somehow hvae that without it being in the name of the
patch, that would be neat.
ascii_field: but for those discussions to make sense, the
patch had to be out there
mod6: i think the nomenclature is pretty straightforward. easy to use. you specify which base your coming off of, the
patch name, and a number for any that are required to come before it.
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 ?
jurov: fellows, we have with mod6 noticed disconnect between
patch IDs in mailing list and in release notes
ascii_field: mod6: please post the net.cpp immediately prior to the failed
patch ascii_field: shinohai: when you apply that
patch, please be sure to read the instructions
shinohai: I still haven't done the irc
patch. I need to stop being lazy
mod6: i'll take it down, and add the irc
patch ascii_field: thinking that mod6 will roll them up into a 'static fix'
patch mod6: (11:31) <+mod6> asciilifeform: I just did the following: extracted v0.5.3.1-RELEASE applied the following patches successfully { dnsseed_snipsnip, kills-integer-retardation, nubs-gentoo-sanity, orphange-thermonuke, orphange-tx-amputation, dns-thermonyukyoolar } but when I added the
patch for IRC demo, got the following error:
mod6: ascii_field: oh, i did have an issue patching in that last IRC demo
patch.... im gonna try it again, but it complained about net.cpp:ThreadGetMyExternalIP
mod6: asciilifeform: I just did the following: extracted v0.5.3.1-RELEASE applied the following patches successfully { dnsseed_snipsnip, kills-integer-retardation, nubs-gentoo-sanity, orphange-thermonuke, orphange-tx-amputation, dns-thermonyukyoolar } but when I added the
patch for IRC demo, got the following error:
mod6: But anyone is welcome to
patch on their own.
mod6: i've tried like 3 different versions of gcc, with and without my special gcc
patch shoehorned in, 2 different versions of uclibc. not quite sure what to think yet.
mod6: if we do anything else other than 5.4, that'd probably be good cause otherwise we'll hvae to
patch your
patch. :]
mod6: yeah, as far as the version number, in hindsight; going forward, we should probably keep all version bumps in it's own
patch incase something changes. i.e. your latest IRC Full Demolition
Patch.
decimation: ah I see, was looking at earlier
patch decimation: phf: I made a
patch to note from which node each block comes
mod6: So anyway, we'll have to remember this when we revist the Checkpoints issue. My
patch will be rejected then, and we'll come up with something that gets rid of line 939 as well as pulling the checkpoints themselves out of checkpoints.cpp and into a separate config file.
ascii_field: and was forgotten when bdb locks
patch discovered
mod6: ascii_field: re: checkpoints: the
patch worked fine to remove checkpoints, but it was tabled for the time being. the main discussion around this was that it could be helpful to hvae checkpoints in there to prevent spamming of blocks from timestamps before a checkpoint.
☟︎ mod6: if I add a simple
patch file for the -fPIC to /etc/portage/patches/sys-lib/<patchfile> and then emerge uclibc, then it builds, but the outcome is the same of the bitcoind compilation
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
trinque: mod6: could
patch the Makefile using that patches mechanism
mod6: guess like we're gonna have to get this
patch to work
mod6: If this dones't help (i doubt it will), I'll need to make another AMI with a recent stage3 and try to shoehorn in this gcc
patch I made.
mod6: if that doens't work, then truly will have to get everything in sync and shoe-horn our own
patch while all the stage3 stuff is up to speed.
mod6: Anyway, trinque wasn't even able to apply my
patch successfully on his side.
mod6: So this is interesting: I was able to use my gcc
patch successfully against my AWS instance which has an AMI that utilizes a stage3-uclibc-hardened from 20150510. And meanwhile, trinque was helping me test to ensure I'm not doing something totally retarded, and on his side he was using the Physical hardware steps where it says to pull the latest (which should be 20150610) stage3-uclibc-hardened.
mod6: as soon as I can, i'll be sure to
patch everything in the order specified and kick off a full regression cycle.
mod6: ok weird. same exact error as last time after complete nuke. tomorrow i'll nuke again and see if gcc will compile without the
patch.
mod6: i'm gonna nuke that machine again and try to compile it again with the
patch. see if it works. if not, i'll just see if it'll even compile gcc itself.
mod6: oh, and I keep hitting an additional problem aside from what the "gentoo sanitiy" resolves. i've been holding off submitting a
patch for it until I can get this thing actually compiled and working.
mod6: oh hey, i think my
patch built ok...
mod6: The
patch we got from that mailing list was from a different version for sure than 4.8.4 -- so i've had to hack it in by hand. gentoo is now applying the
patch properly. and it's compiling as we speak. there is one caviat that I need to get over before I can test it though.
ben_vulpes: ;;later tell asciilifeform can't find my fat-fingering, but my node running your
patch *does* connect to lfnet. it does not, however, obtain a connection to another node thereby.
mod6:
patch applies manually just fine, seems to choak when used by emerge becuase of directory levels or something. hopefully can overcome this...
mod6: ok, i've got a
patch i created myself (post application of patches: gentoo/uclibc/PIE) for gcc... just trying to get it to work with emerge.
mod6: lol, this is uglier than I had thought. I patched the gcc-4.8.4 source with all of the patches from /their/ bundle v1.5 (
http://dpaste.com/1NRJTT7.txt), and now i'm in there apply patches by hand, and only 2 out of ~10 files to
patch actually exist here (the rest are for pr# files (Problem Report?)). And when I can apply a
patch, the surrounding code is slightly different.
mod6: so trinque & I have discovered that the
patch provided by the email mentioned (
https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00410.html ) doesn't
patch cleanly at all. Even with some McGuyvering of the
patch to ensure the paths are correct etc, there are still a number of files not found. It might be plausible to write our own custom
patch for 4.8.4 to resolve the issue.
mod6: So, I think I'm gonna stay the course on trying to
patch 4.8.4... if we get into a giant hassle with it, we'll cut bait for the time being and try to build something like 3.7 and try that.
mod6: if not, we might have to McGuyver our own
patch.
mod6: I, with trinque's help, need to
patch gcc 4.8.4 with gentoo using /etc/portage/patches via ebuild flag(?). If that works, then I can test that the R.I. will link properly. If that works, maybe we finally have static apple pie.