HI Erich; Am Dienstag, 14. April 2015, 00:00:40 schrieb Erich Titl: > Am 13.04.2015 um 21:04 schrieb kp kirchdoerfer: > > Hi Erich; > > ... > > > Make shure you have the Bering-3.14.36-config -xxx.patches, otherwise > > apllying the patches will fail. This happended to me after your new > > config, therefor I had to create the new patch files. > > Yes I know, sorry about that. Unfortunately there seems to be some kind > of a breach in the generation of the config files. > > I recently pulled the latest git state and found that the > Bering-3.14.36-config still dated from an earlier version, despite the > patch files contained the latest changes. This surprised me, as I > concluded, that base Bering config files themselves were never updated. > I also saw that some common options were all done in the atch files and > not in the base Bering-release-config. > > Another thing that really puzzles me is > > mega@leafbuilder:~/leaf/devel/bering-uclibc/source/i486-unknown-linux-uclibc > /linux$ diff Bering-3.14.36.config ../../../repo/linux/Bering-3.14.36.config > 1169c1169 > < # CONFIG_CFG80211_REG_DEBUG is not set > --- > > > CONFIG_CFG80211_REG_DEBUG=y > > 1172c1172 > < CONFIG_CFG80211_DEBUGFS=y > --- > > > # CONFIG_CFG80211_DEBUGFS is not set > > 1190c1190 > < # CONFIG_CFG80211_REG_DEBUG is not set > --- > > > # CONFIG_MAC80211_DEBUGFS is not set > > So it appears the config file in the source directory is different from > the config file in the repo. These files are not linked neither and I > have trouble understanding this. > > Given that a new release often has new features I would expect that the > patch files need to be regenerated whenever there is a release change. > Apparently adding common features to the main config file requires the > same. I do not understand neither why there are architecture dependent > files like Bering-3.14.36.config-geode in the repo directory. I would > have expected to see them generated from Bering-3.14.36.config using the > patch files. Reading the makefile I see how it is done, but I fail to > understand the reasoning behind keeping a copy in the repo. > > I inspected the differences between the patch files and found there was > hardly any, for example > > 4,5c4,26 > < > --- Bering-3.14.36.config-i486 2015-04-12 14:09:02.902612880 +0200 > < 51c51 > --- > > > > --- Bering-3.14.36.config-i686 2015-04-12 14:09:46.882611473 +0200 > > > > 4c4 > > < *** 1,6 **** > > --- > > > > > *** 1,8 **** > > > > 9c9 > > < # CONFIG_64BIT is not set > > --- > > > > > ! # CONFIG_64BIT is not set > > > > 11c11,13 > > < --- 1,6 ---- > > --- > > > > > CONFIG_X86=y > > > CONFIG_INSTRUCTION_DECODER=y > > > > > > --- 1,8 ---- > > > > 16c18 > > < # CONFIG_64BIT is not set > > --- > > > > > ! # CONFIG_64BIT is not set > > > > 17a20,21 > > > > > CONFIG_X86=y > > > CONFIG_INSTRUCTION_DECODER=y > > > > 51c55 > > 9c30 > < 56c56 > --- > > > 56c60 > > Both patch files contain a LOT of common changes and this makes me > wonder why they are that big then. I conclude that there is very little > common config base but lots of common config patch.
This is all correct; and I may have disturbed it. I confess I never got used to the idea and when I ran into pb's it was the short path to adjust the config files. Once we move to a newer kernel, we, and esp. myself, should take care to get it right. Any help is welcome. For the current version we may have to live with the faults I've made. sorry kp btw: I've switched/I was switched to VDSL, quite fast, but a lot of work to get all the infrastructure up and running again, incl. offline times etc... So response time slows down from time to time. ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
