**** BEGIN LOGGING AT Thu Nov 26 02:59:56 2009 Nov 26 14:59:11 Hi. Can anyone help me with a NSLU2-Debian problem? Nov 26 14:59:39 Oh, it's the developer channel. Sorry :( Nov 26 15:05:43 silsha, #nslu2-general Nov 26 19:16:52 @eno: are you there? Nov 26 19:19:05 do you know a project that try to list all opensource software and the current version? Nov 26 19:28:28 jomaster: http://en.wikipedia.org/wiki/List_of_free_and_open_source_software_packages might get you so far Nov 26 19:28:35 just not all on one page for versions.. Nov 26 19:29:09 http://en.wikipedia.org/wiki/List_of_open_source_software_packages Nov 26 22:05:52 jomaster: freshmeat.net ohloh.net Nov 26 22:06:14 subscribe to their RSS Nov 26 22:23:25 eno: that is not what i am thinking about. their should be a always up to date list with detailed informations about opensource software, which contains of thinks like: current stable version, unstable version, important security fixed version,.... Nov 26 22:25:53 so that an autobuilder can look at there and builds new versions by themself. so most maintain work is to get this list up to date and not that lots of build-system maintainer always have to look for new versions and edit packages. Nov 26 22:26:59 new version constantly breaks build recipes, it won't be that automatic Nov 26 22:27:24 especially for cross compilation recipes Nov 26 22:28:41 i'd say 25% of the time you need to adjust build recipes Nov 26 22:33:56 yes, i know. but should be most automated as possible. autobuilder should build normal stable builds and always try to build newest version for unstable branch which can be marked as stable if all works fine. Nov 26 22:35:36 i think if we look at svn logs many normal updates are 'version x -> version y' without changes at packes. Nov 26 22:36:34 freshmeat usually lists stable/unstable branches Nov 26 22:37:26 creating a separate list will be a lot of duplicated effort Nov 26 22:37:55 rather script these to get these info Nov 26 22:38:27 but again, latest version does not necessarily mean better Nov 26 22:39:19 it can get tricky, at best this is good for a white-list approach instead of a black-list approach Nov 26 22:41:01 look at freebsd/debian/macports, they have way more resource than nslu2-linux, but they are still manual Nov 26 22:41:54 as i understand debian packages are much more manual than optware. Nov 26 22:42:45 there're hundreds and thousands more maintainers of debs Nov 26 22:43:17 you are right with white-list. but i think this could part of information of the software list like 'recommended version' Nov 26 22:44:14 yes, i know. that is way their manual system works excellent. but do that means that this is the best? Nov 26 22:44:32 that is why :-) Nov 26 22:44:48 we don't even have stable/unstable separation Nov 26 22:45:20 and the mechanism of promoting unstable version to stable Nov 26 22:45:43 these're more important than automation from my PoV Nov 26 22:46:38 for me the different would be that new versions which are build from autobuilder by using the list will not published at available feeds. Nov 26 22:46:55 PoV? Nov 26 22:47:04 point of view Nov 26 22:47:32 you want some people to test it, but also don't want all people to use it Nov 26 22:47:52 we just don't have big enough user base and resource to do this Nov 26 22:48:34 i think it could be a help for maintainer: he have not update by himself. instead he looks for new builded versions and only mark they as stable Nov 26 22:49:54 i c what you mean, that helps Nov 26 22:53:26 i think that would be THAT great change. only a few lines which compare the recommended versions from (the not existing) list and build them too if it differs to our current version. Nov 26 22:55:10 would be not... Nov 26 22:55:31 what's missing are scripts to retrieve latest stable versions of white-listed package Nov 26 22:55:55 scripts to automate the build and ideally generates some kind of report Nov 26 22:56:10 an entirely separate build space Nov 26 22:57:30 and it's still maintainer's job to commit the buildable upgrades Nov 26 22:57:46 we probably should limit that to minor version upgrades Nov 26 22:57:52 first should be the list. and i hoped that such a project already exists. but don't found such. Nov 26 22:58:20 i don't see the need for such a separate list Nov 26 22:58:31 only need for our white list Nov 26 22:58:43 yes, exactly this is my goal at this way: to automated the minor updates Nov 26 22:58:47 and script to retrieve latest stable version from freshmeat Nov 26 22:59:17 the white list can start with just one or two packages Nov 26 23:00:03 the scripts are where the work will be Nov 26 23:02:46 i continue thinking about this until i know this system in all details. Nov 26 23:03:10 to have a detailed plan is always the best Nov 26 23:04:15 right Nov 26 23:05:55 by the way i didn't try to build a toolchain for vt4. no time. only play around with cs-toolchains and build some toolchains with crosstool. Nov 26 23:06:17 k Nov 26 23:07:00 my current work flow is actually create a git topic branch for each package upgrade Nov 26 23:07:17 test build, and optionally runtime test Nov 26 23:07:28 git svn dcommit Nov 26 23:07:59 i think it would be a good idea try to separate the upgrade of different packages Nov 26 23:10:52 why git? Nov 26 23:11:48 git offers good integration with svn, and the support for merge/rebase is excellent Nov 26 23:12:19 local branch is cheap Nov 26 23:12:54 i never used git Nov 26 23:13:05 but read about Nov 26 23:13:21 git is wonderful Nov 26 23:14:03 i can even push/pull between native build and cross build Nov 26 23:16:50 it is late. see you next time Nov 26 23:17:01 good night **** ENDING LOGGING AT Fri Nov 27 02:59:58 2009