1596594689 Q * gnarface Quit: Leaving 1596594960 J * gnarface ~gnarface@108-227-52-42.lightspeed.irvnca.sbcglobal.net 1596598151 M * bertl_oO off to bed now ... have a good one everyone! 1596598153 N * bertl_oO Bertl_zZ 1596598220 Q * jrklein_ Quit: Quitting 1596598278 J * jrklein ~cloud@34.234.31.16 1596623393 N * Bertl_zZ Bertl 1596623399 M * Bertl morning folks! 1596633324 M * Bertl off for now ... bbl 1596633326 N * Bertl Bertl_oO 1596633554 Q * AlexanderS Ping timeout: 480 seconds 1596634118 J * AlexanderS ~Alexander@home.zedat.fu-berlin.de 1596637632 J * fstd ~fstd@xdsl-89-1-53-35.nc.de 1596637859 Q * fstd_ Ping timeout: 480 seconds 1596640519 Q * Aiken Remote host closed the connection 1596655254 J * emanuel ~emanuel@2a02:1748:dd5e:7720:aad8:61cd:1c3a:de3f 1596655877 M * emanuel Hello, there is newer version of the 4.4 and 4.9 Kernel available: 232 1596656152 M * emanuel I tried to apply the 217 patch and it still fails on self.c so I uploaded the Terminal output and the self.c to a pastebin: https://bin.snopyta.org/?442f09395d5bf74a#GSWy3jRL3uxUKuopBSTYEt5PRCL8yZwoPZDcX1zy3aJE 1596656444 M * emanuel Bertl, Bertl_oO, Ghislain: ^ 1596656726 M * emanuel Oh, and the pastebin is also reachable as a hidden service(Tor): http://5cs6g2gtee7lqkbvliotggauvwi7vtc6tmgw2li7jzmoyoeuvqwsldqd.onion/?442f09395d5bf74a#GSWy3jRL3uxUKuopBSTYEt5PRCL8yZwoPZDcX1zy3aJE 1596658041 J * Aiken ~Aiken@b951.h.jbmb.net 1596659443 M * Guy- emanuel: hang on, I'll look at the conflict - maybe it's easy 1596659521 M * Guy- emanuel: you can ignore it -- the patch is trying to insert a comment, and the lines where the comment should go are gone 1596659540 M * Guy- struct inode *inode = new_inode_pseudo(s); 1596659540 M * Guy- + 1596659540 M * Guy- + // self->vx_flags = IATTR_PROC_SYMLINK; 1596659540 M * Guy- if (inode) { 1596659600 M * Guy- instead of this, the context looks like this now: 1596659603 M * Guy- if (self) { 1596659603 M * Guy- struct inode *inode = new_inode(s); 1596659603 M * Guy- if (inode) { 1596659603 M * Guy- inode->i_ino = self_inum; 1596659634 M * Guy- but obviously there is no functional difference due to this reject 1596661982 M * gnarface emanuel: it would be easy to fix the patch yourself too, and educational 1596662067 M * gnarface emanuel: the process will be conceptually simple but very picky about tiny details, in a way that is both good practice for you and a nice way to experience how a part of the tools work at a low level 1596662338 M * emanuel well I don't have much coding experience and I couldn't figure out what the code means, so I might need some help, but you are right it would be "both good practice for you and a nice way to experience how a part of the tools work at a low level" 1596662481 M * gnarface emanuel: luckily, to edit this patch, you don't have to actually understand how the code works, you just have to make all the lines on either side of the replaced one(s) match the ones in the kernel code 1596662529 M * gnarface emanuel: mabye you haven't noticed but that patch file is just plain text, you can change it with any text editor 1596662557 M * gnarface emanuel: you don't have to understand how the code works, you just have to understand how the patch tool works 1596662616 M * emanuel Okay I think I can do that... 1596663626 M * emanuel I think I made it ... if that was it it was really easy: https://bin.snopyta.org/?aa83e99681512792#H5SeRXHHTPgxbQP2FJaHekNN12GoaLdVa9yvddSNGaCB 1596663694 M * gnarface emanuel: it won't work if it's wrong 1596663722 M * gnarface emanuel: just make sure you don't change anything other than empty lines and the comment 1596663899 M * emanuel well i changed new_inude_pseudo(s) to new_inode(s) and the subversion in the makefile 1596664081 M * Guy- fwiw, I usually just open the .c and the .c.rej in an editor and hand-merge the patch, without creating a modified patch file 1596664192 M * emanuel oh i don't know how that works I opened the .diff file with a text editor 1596664722 M * Guy- same way, just open self.c and self.c.rej in the editor instead 1596664740 M * Guy- (after the first attempt to apply the patch failed) 1596664959 M * emanuel so should I do it again the other way? 1596664979 M * Guy- only as practice, if you want to 1596665002 M * Guy- what you did is technically a more correct solution in that it produces an updated diff file you can re-use 1596665046 M * Guy- my way is quick and dirty, but it gets the immediate job done 1596665131 M * gnarface emanuel: you're not being assigned homework, it's just being pointed out to help you see what the tool is doing 1596665167 M * emanuel Guy-: oh, so you say my way was actually better? 1596665168 M * gnarface emanuel: that .c.rej file is not part of the original code base, that was created by the patch tool as a result of the initial rejection, you see? 1596665205 M * gnarface emanuel: sorta like in math class when they teach you how to check a solution both directions, you know? 1596665234 M * Guy- emanuel: editing the .diff is better, I'd say, yes 1596665239 M * emanuel gnarface: I see, thanks 1596665280 M * Guy- yes, the .c.rej file only contains the parts of the diff that couldn't be applied 1596665350 M * Guy- another way of arriving at an updated diff is to hand-merge the conflicts (based on the .rej files, which you remove when done), then do a recursive diff between the original source and the modified source 1596665416 M * gnarface emanuel: (you won't be tested on any of this) 1596665428 M * Guy- gnarface: you don't know that! :) 1596665453 M * gnarface Guy-: hehe, well, not by US anyway... we can't predict what reality may throw at him though, you're right... 1596665486 M * Guy- emanuel: I find hand merging easier than diff-editing because you're working with the actual code, without diff markup, but ymmv 1596665732 M * emanuel I think for me both methods are even 1596665989 M * emanuel so, will the new .diff file be distributed or is that someone else's task 1596666363 A * gnarface doesn't work here 1596666671 M * emanuel what do you mean 1596666768 M * gnarface Guy-: you don't have access to the server do you? 1596666834 M * emanuel no I meant will someone publish it one the server 1596666875 M * gnarface ask Bertl when he wakes up 1596666921 M * emanuel oh 1596666935 M * gnarface this whole thing is actually his operation 1596666944 M * gnarface but it's sorta a side thing, he's a busy guy 1596666985 M * gnarface i don't know if he'll decide it's not worth it over a 1-line fix or not, i have no idea actually 1596667043 M * emanuel well I just was curious how it works 1596667092 M * gnarface well, i don't know either is what i mean, really. i could imagine not wanting to clutter the server directory with a new patch for every single tiny update 1596667190 M * emanuel what are those tiny updates 1596667221 M * emanuel are they security updates? 1596667795 M * gnarface there would be all kinds of changes 1596667813 M * gnarface security updates, some of them, but maybe just naming changes or basic unrelated functionality changes 1596667976 M * gnarface the thing is, the kernel does A LOT, and most of it is not directly related to the low-level memory mapping stuff that linux-vservers manages, but it's sorta right at the heart of everything, so it's easily trampled 1596668133 M * gnarface oh don't forget stability updates 1596668139 M * gnarface performance updates 1596668159 M * gnarface but a lot of this stuff turns out to be hardware-specific 1596668172 M * gnarface so if you don't have that type of hardware it doesn't matter to you 1596668220 M * emanuel so which .config should I use to build my kernel do I have to change the .config to work with linux-vserver 1596668262 M * gnarface i think the defaults are fine but i'm not 100% sure. you should "make menuconfig" to check 1596668381 M * emanuel what are the defaults the config of the kernel on my os 1596668427 M * gnarface you might be able to find them in /boot/ or /proc/config.gz 1596668458 M * gnarface in debian they're named /boot/config-* 1596668465 M * gnarface (debian and derivatives thereof) 1596668488 M * emanuel The installed Kernel is 4.19.118-2+deb10u1 1596668505 M * gnarface the version is probably in the file name 1596668512 M * Guy- you can copy its /boot/config-$(uname -r) to .config in the source tree 1596668541 M * Guy- then make oldconfig to get prompted for every new option (which should be the vserver options) 1596668584 M * Guy- menuconfig works too, but it won't immediately tell you what options came into being due to the patch 1596668631 M * Guy- oh, going back from 4.19 to 4.9 there's probably going to be some unrelated stuff too, options that exist in 4.9 but no longer do in 4.19 1596668763 M * gnarface emanuel: a better option would be to try to get a config from the a debian kernel of a closer version 1596668790 M * emanuel I got some errors: https://bin.snopyta.org/?14a9c7a240ad29de#EUc3DVqLzWgVCif9ffMU2MyExMNheS99EsFTaxxfrBqE 1596668925 M * emanuel Guy-: As recommended i am on Devuan (fork of Debian without systemd) now. don't know if that makes any difference 1596669011 M * gnarface emanuel: uh erm. sorry i'm really paranoid, but if you're gonna want me to look at that please use paste.debian.net 1596669048 M * gnarface emanuel: or just paste them to me in a /msg window 1596669353 M * emanuel paste.debian.net didn't work. I think I already pasted to much: "Do not spam" this is the first irc chatroom i ever entered so i don't know how that works exactly 1596669431 M * gnarface if you really pasted more than the limit i'm not gonna read it all anyway, just paste part of it, like the tail end of it 1596669455 M * gnarface if you only pasted a few lines it might have auto-detected it as spam because they looked like urls 1596669464 M * emanuel not now a few days ago 1596669465 M * gnarface if that's the case, then just /msg it to me 1596669566 M * emanuel like that? 1596669677 M * gnarface that doesn't look like an error, that looks like an input prompt 1596669712 M * emanuel but what about the warnings 1596669803 M * gnarface well fix them if you care... there's only 3 possible values, m, y, and n 1596669823 M * gnarface i'd probably just let it default... 1596669885 M * gnarface actually maybe they've been removed entirely 1596669888 M * gnarface not sure 1596669973 M * gnarface anyway, the point is the value will probably be ignored 1596669981 M * gnarface that's why it is a warning, not an error 1596670046 M * gnarface also, full disclosure, i'm not even remotely qualified to say what any of those things are, but i'd guess that you're not even using ANDROID_BINDER_IPC, so there's that at least... 1596670202 M * emanuel what about the prompt? i dont undestand it 1596670258 M * gnarface uh... you're not cross-compiling, are you? 1596670288 M * gnarface you're building a kernel for the machine you're currently using, right? 1596670361 M * emanuel yes but will this disable cross-compiling when I use the kernel 1596670388 M * gnarface no it's asking for the path to the toolchain to use, and the default is empty: [] 1596670395 M * gnarface i'd just hit enter 1596670398 M * gnarface leave it as-is 1596670415 M * gnarface it will also probably not be used 1596670428 M * gnarface but if you put something there it might try to use it 1596670434 M * gnarface which would not work 1596670535 M * emanuel Expose hardware/virtual IRQ mapping via debugfs (IRQ_DOMAIN_DEBUG) [N/y/?] (NEW) 1596670592 M * gnarface ok, so when the [] part has something in it, and it's these letters like n/y/? etc, the one that's capitalized is the default. so in this case N, for no 1596670632 M * gnarface usually defaults are safe to take, especially when it's a DEBUG default and the default is no 1596670649 M * gnarface so for that one, i'd just hit enter again 1596670661 M * emanuel oh, thanks 1596670704 M * gnarface now, you should really make your own judgements about all of these 1596670721 M * gnarface but that's gonna require a lot of research 1596670721 M * emanuel Temporary per-CPU NMI log buffer size (12 => 4KB, 13 => 8KB) (NMI_LOG_BUF_SHIFT) [13] (NEW) 1596670753 M * emanuel sorry I dont know what that means 1596670790 M * gnarface i would have to look it up too, but for stuff like this usually the default is intended to be safe and you should use it unless you know you need something different specific for your hardware 1596670825 M * gnarface and if it is irrelevant to your hardware, it won't matter anyway 1596670831 M * emanuel okay 1596670875 M * gnarface the "help" panels in the menuconfig interface have more detailed information about all the options, but it won't step-by-step guide you through all of them 1596670932 M * gnarface a great way to learn about your hardware and the kernel is to just go through menuconfig manually and disable everything you're not using (which will be most of it, so it will take hours, maybe days...) 1596671042 M * gnarface in general though if it's something that you don't recognize, the defaults are usually intended to be safe 1596671082 M * emanuel i used oldconfig 1596671141 M * gnarface you can still use menuconfig afterwards if you want 1596671223 M * emanuel But I'll have to chose now 1596671240 M * emanuel *choose 1596671268 M * gnarface yes, and the more different the kernel version you are using is from the kernel version the config came from, the more discrepancies there will be 1596671298 M * gnarface once oldconfig is done, those discrepancies will all be ironed out 1596671319 M * gnarface but you can still use menuconfig to browse and change anything afterwards 1596671373 M * gnarface also menuconfig is a menu, so it makes it really a lot easier to visualize the options hierarchy 1596671459 M * emanuel this looks like a linux vserver one 1596671572 M * gnarface i'm not sure it actually is 1596671639 M * emanuel so I should just hit enter 1596671648 M * gnarface yea 1596671824 M * emanuel IPv4 connection tracking support (required for NAT) (NF_CONNTRACK_IPV4) [N/m/?] (NEW) 1596671904 M * emanuel "required for NAT" could that be a problem