**** BEGIN LOGGING AT Tue Oct 13 02:59:59 2015 Oct 13 03:09:02 * swalker wonders what blew up the svn->git thread overnight Oct 13 06:53:16 build #100 of ixp4xx is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/ixp4xx/builds/100 Oct 13 07:54:39 build #102 of kirkwood is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/kirkwood/builds/102 Oct 13 08:06:41 build #105 of brcm63xx.smp is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/brcm63xx.smp/builds/105 Oct 13 08:08:36 build #101 of lantiq.xrx200 is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/lantiq.xrx200/builds/101 Oct 13 08:14:59 build #98 of uml is complete: Failure [failed shell_14] Build details are at http://buildbot.openwrt.org:8010/builders/uml/builds/98 Oct 13 08:15:22 build #99 of au1000 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/au1000/builds/99 Oct 13 08:28:49 saik0: are you using openvpn in 15.05? I was seeing some problems with it... like the connections via openvpn seemed to "drop", stopped passing packets or something Oct 13 08:31:54 build #100 of ramips.mt7620 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/ramips.mt7620/builds/100 Oct 13 08:53:37 build #111 of cobalt is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/cobalt/builds/111 Oct 13 08:56:14 build #111 of cns21xx is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/cns21xx/builds/111 Oct 13 08:58:57 build #111 of orion is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/111 Oct 13 11:13:29 nbd: grade dne git thread gelesen. mein beileid (und support fuer svn+patches+git fuer some). ansonsten haste da noch schnaps bei mir gut Oct 13 11:14:17 roh: beileid? Oct 13 11:14:48 cyrusff: nervbacken die nicht ruhe geben und nicht kapieren warum ein pur-git workflow mehr arbeit macht Oct 13 11:15:41 naja, ändert nichts an der tatsache, dass der aktuelle workflow auch mehr arbeit macht als notwendig Oct 13 11:15:56 für user und commiter Oct 13 11:15:57 cyrusff: lies erst den thread. Oct 13 11:17:33 ja dreht sich im kreis 10x, ändert trotzdem nichts dass wir zumindest den git-mirror fixen müssen Oct 13 11:17:43 auch wenns bei svn bleibt Oct 13 11:17:55 ja. das muss passieren. das der kaputt ist wusste ich garnicht Oct 13 11:18:26 release branches sind alle separate git-repos ohne history, steht aber auch im thread Oct 13 11:18:41 und unabhaengig davon muss man auchmal sehen das fuer zentrale repos git echt mies ist und schlecht performt. Oct 13 11:19:21 ich denke, es spielt keine rolle womit man intern arbeitet solange es für außenstehende nach "normalem git" aussieht Oct 13 11:19:23 ich hab bei bei openmoko die repos betreut, und da war ca 1x die woche eines kaputt und brauchte manuelle interaktion Oct 13 11:19:40 cyrusff: solange die leute dann ordentliche patches liefern Oct 13 11:20:10 das problem hat man immer Oct 13 11:20:15 ich find ja die sollen gerne mit git arbeiten. aber das zentrale repo kann auch dann ohne probleme svn sein. wer das nicht kapiert hat git eh nicht verstanden Oct 13 11:21:43 mir persönlich ist es ziemlich egal womit ich arbeite intern (ich hab mit beiden geschichten ausgiebig zu tun gehabt), aber nach außen hin sollte halt ein git-repository mit branches und history rauskommen als "frontend" für den user Oct 13 11:22:06 ob da nun ein skript dahinter steht was alle x minuten ein SVN pullt ist detailfrage Oct 13 11:22:29 ob das nach aussen svn oder git ist bleibt m.e. egal. wenn was da ist muss es tun. Oct 13 11:22:55 eine distro wie openwrt kann eh nicht 'ein system only' sein. alleine weil es diverse unterschiedliche probleme gibt die man loesen muss. Oct 13 11:23:25 ég kann ekki þysku, hvað er í gangi hérna? Oct 13 11:23:34 karlp: exactly :P Oct 13 11:23:53 oh. sorry. i can rant in english too if that helps ;) Oct 13 11:24:11 karlp: continuining SVN vs. git rant from the ml Oct 13 11:24:17 oh. Oct 13 11:24:31 I was trying not to get into that one. too many unrelated issues talking across each other Oct 13 11:24:35 roh: well people are used to git as a frontend Oct 13 11:24:53 used to is no reason but a excuse Oct 13 11:25:30 well considering openwrt says "use git" on the getting sourcecode page ;) Oct 13 11:25:35 not sure I understand nbd's position about an svn number proving anything though. knowing an svn number as a base fork point doesn't say anyything about what's been modified or piled on top. not being able to find the commit hash of a local commit is the same, just proves there's local mods. Oct 13 11:25:49 karlp: just run a build-server once. Oct 13 11:25:57 I thought that was what the _TAINTS stuff was for anyway. Oct 13 11:26:33 with git you need a quite expensive operation AND full checkouts to compare which revision is the more recent one. with svn you do not even need a checkout. just compare 2 integers. Oct 13 11:27:04 that's not the point nbd was trying to make Oct 13 11:27:18 also, git describe vs the hash makes that not nearly as relevant as you think Oct 13 11:27:34 karlp: tell somebody 'newer than r1234' is simple to understand. try telling somebody 'fresher than $hash' an see what happens. Oct 13 11:27:35 tag+110 commits vs tag+120 commits is the same as 45767 vs 45687 Oct 13 11:27:51 karlp: there are not tags. Oct 13 11:28:04 but there should be, and would be if anyone was every going to do this :) Oct 13 11:28:10 and tagging every commit is not making sense but pure abuse Oct 13 11:28:21 who on earth said anything about tagging every commit?! Oct 13 11:28:55 if there's no rebasing on master, and you tag releases and rcs, git describe will get you a 15.05-yyyyy-hash Oct 13 11:29:03 where yyyy is the count of commits past the tag. Oct 13 11:29:16 pretending that doesn't exist and using that argument to keep svn is kinda weird. Oct 13 11:29:55 still, from my point of view, the biggest pain is moving patches between branches due to kernel changes, and I don't think git or svn changes will help with that. Oct 13 11:29:56 besides that, read nbds comments about the kernel. rebasing all the time looks really shitty on the repo Oct 13 11:30:17 roh: but what is your problem with providing that git frontend really? Oct 13 11:30:26 for users Oct 13 11:30:41 i mean we've done that for a long time Oct 13 11:30:45 thank god. Oct 13 11:30:56 cyrusff: it can be a secondary frontend.afaik it is Oct 13 11:31:04 yeah thats what i am saying Oct 13 11:31:28 as long as that thing does what users expect it is really secondary if we use svn internally or git Oct 13 11:31:43 but for the sake of maintainers sanity i understand the wish for a linear timeline and proper enforcement. makes lots of stuff easier Oct 13 11:31:58 yes, and thats why you can use SVN internally Oct 13 11:32:11 but you don't have to use it as a frontend Oct 13 11:32:20 so i don't understand your point really Oct 13 11:32:31 my point is: if you have git locally. why care what the maintainers use? why bother them at all? Oct 13 11:32:32 how do you claim that you can't have straight lines in git too? (I don't think it's helpful or relevant, but it's werid that people claim you can't have them in git) Oct 13 11:32:43 roh: I would agree on that one :) Oct 13 11:32:57 roh: thats what i am saying the whole time Oct 13 11:33:02 however, it is annoying having separate repositoroes for the different branches Oct 13 11:33:20 ever we switch to git if there are compelling reasons or we stick with svn and fix the git frontend Oct 13 11:33:42 it doesn't make much of a difference to the user Oct 13 11:33:46 from the discussion I gethered two main wishes Oct 13 11:33:53 1) havbe branches in the git mirror Oct 13 11:34:03 2) put the kernel into git Oct 13 11:34:07 1 = ok Oct 13 11:34:07 2 = bs Oct 13 11:34:11 right Oct 13 11:34:19 cyrusff: 'users' are not that important if you only have so few maintainers in the middle. so their wishes count most and first. Oct 13 11:34:53 yeah, with you on 2 being unnecessary Oct 13 11:34:55 13:32 < karlp> how do you claim that you can't have straight lines in git too? (I don't think it's helpful or relevant Oct 13 11:35:20 igrh. sorry.. cnp fail Oct 13 11:35:31 cyrusff: I while back I attempted a full git-svn --stdlayout clone of svn... due to various broken merge tracking metadata it will contain a number of disjunct historical brnaches but i guess its not too much of a problem Oct 13 11:36:08 jow_laptop: i guess it would be fine if it would work reliably for the last 5 years of history or so Oct 13 11:36:40 cyrusff: should be doable, theoretically we cal also manually replay commits and ignore merge tracking entirely Oct 13 11:37:19 yeah, svn and merges is kind of meh anyway Oct 13 11:38:27 bruno's covered my thoughts on the revision numbers well enough I think. Oct 13 11:38:35 what I do not want though is moving the authorative codebase to github and continue there Oct 13 11:38:49 nah i guess thats what we all agree about Oct 13 11:39:00 jow_laptop: were people really suggesting that? Oct 13 11:39:04 karlp: yes Oct 13 11:39:08 that seems out of scope and unnecessary Oct 13 11:39:16 it works for the packages feed, but thats different Oct 13 11:39:25 some people apparently confuse github with git Oct 13 11:39:35 oh, I guess some people wanted all the "patches" to become continually rebased git trees too didn't they. Oct 13 11:39:44 yep Oct 13 11:40:18 somewhat side related, but how are the kernel updates handled? is it always manual? I mean, I have a "patch" for a board, that addes a mach-xxx file and has patches in patches-X.Y, Oct 13 11:40:46 so even if I format-patch that and apply it to the "future" branch, it applies cleanly, but against a now out of date X.Y version. Oct 13 11:41:04 when core people are updating kernel versions, is this always just a hand move of the files and fix? Oct 13 11:41:24 it's one of the problems I've had, and it's definitely something that neither git nor svn are helping with. Oct 13 11:41:52 its am anual process Oct 13 11:42:03 hard things are hard I'd say here Oct 13 11:42:11 that's a totally fair point :) Oct 13 11:42:23 was just wondering if there was some trick I was missing out on :) Oct 13 11:42:29 eventually one has to do some work, regardless of the nice abstractions provided by the various tools of the months Oct 13 11:44:20 having an openwrt-kernel might be nice for some ppl but afaik the linux kernel proves that this is something not really maintainable for smaller OpenWrt Oct 13 11:45:31 because you have all the different subsystem branches (sometimes with -next) , then you have linux-next, then you have linux-stable and those are not simple "branches" - or are they? Oct 13 12:03:43 build #109 of pxa is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/pxa/builds/109 Oct 13 12:04:10 karlp: depends on how big the breakage is; if it's just whitespace/easy to fix up context I handedit the patches, but if requires larger rework and the patch is in git format I sometimes apply it to linux-stable.git#, then rebase onto #new-version (with a lot of reference to the kernel log on how similar changes were handled) Oct 13 12:37:11 build #99 of brcm47xx.mips74k is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/brcm47xx.mips74k/builds/99 Oct 13 12:56:30 build #100 of ar71xx is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx/builds/100 Oct 13 13:15:08 jbj1: yes in 15.05, I've not noticed any connections dropping Oct 13 13:21:04 jbj1: openwrt is openvpn client, tun, udp, topology Oct 13 14:51:53 build #99 of ath25 is complete: Failure [failed shell_14] Build details are at http://buildbot.openwrt.org:8010/builders/ath25/builds/99 Oct 13 15:17:59 build #97 of mvebu is complete: Failure [failed shell_14] Build details are at http://buildbot.openwrt.org:8010/builders/mvebu/builds/97 Oct 13 15:18:50 build #98 of ar71xx.mikrotik is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx.mikrotik/builds/98 Oct 13 15:21:08 build #109 of ppc40x is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/ppc40x/builds/109 Oct 13 15:32:03 build #112 of brcm47xx.legacy is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/brcm47xx.legacy/builds/112 Oct 13 15:48:51 build #98 of adm8668 is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/adm8668/builds/98 Oct 13 16:49:32 Hi all, I have created a new board for openwrt and I want to get the changes into the main repo. I have all modified files locally on the latest CC branch. The documentation on adding a board is a little light on the main openwrt site, what would be the first steps to get a new board into the repo? Oct 13 16:51:39 the board is based on ramips. I have modified base-files, makefile and new dts, profile Oct 13 17:01:22 just found the trac page Oct 13 17:04:15 mcudev: you can add info to http://wiki.openwrt.org/doc/devel/add.new.device or maybe a new wiki entry like add.new.board or link it from there Oct 13 17:05:17 you should look over previous additions of boards for ramips Oct 13 17:05:58 normally first kernel support/dts files are added and then in a separate file the image building/profile is added Oct 13 17:06:08 separate patch Oct 13 17:06:41 ok, so the dts and the profile mk file? Oct 13 17:06:49 the kernel supports this proc already Oct 13 20:13:45 mcudev: you should base your work on top of trunk Oct 13 20:13:57 but that should not be hard as there are not big diferences Oct 13 20:14:39 mcudev: here is a documentation on how to submit a patch: https://dev.openwrt.org/wiki/SubmittingPatches Oct 13 20:52:08 build #111 of ramips.mt7628 is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/ramips.mt7628/builds/111 Oct 13 20:52:27 build #112 of brcm47xx is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/brcm47xx/builds/112 Oct 13 20:55:05 build #103 of avr32 is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/103 Oct 13 21:58:58 build #112 of lantiq is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/lantiq/builds/112 Oct 14 00:18:44 hmm, made a run at updating iproute2 last night, ran into uapi/musl problems Oct 14 00:22:03 * swalker deleted iproute2's bundled include/linux/in.h Oct 14 02:31:22 build #111 of ramips.rt3883 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/ramips.rt3883/builds/111 **** ENDING LOGGING AT Wed Oct 14 02:59:59 2015